Google Cloud로 컨테이너 마이그레이션: OpenShift 프로젝트를 GKE Enterprise로 마이그레이션

Last reviewed 2022-01-24 UTC

이 문서는 OpenShift에서 GKE Enterprise로의 프로젝트 마이그레이션을 계획, 설계, 구현하는 데 도움이 됩니다. 잘못 수행할 경우 워크로드를 다른 환경으로 이동하는 작업이 어려워질 수 있으므로 마이그레이션 계획과 실행에 신중을 기하세요.

이 문서는 Google Cloud로 마이그레이션하는 방법을 다루는 시리즈의 일부입니다. 시리즈의 개요에 대해 자세히 알아보려면 Google Cloud로 마이그레이션: 마이그레이션 경로 선택을 참조하세요.

이 문서는 컨테이너를 Google Cloud로 마이그레이션하는 방법을 설명하는 시리즈의 일부입니다.

이 문서는 OpenShift 프로젝트를 GKE Enterprise로 마이그레이션하려는 경우에 유용합니다. 이 문서는 마이그레이션 기회를 평가하고 그 결과를 살펴보고 싶은 경우에도 유용합니다.

이 문서에서는 Google Cloud로 마이그레이션: 시작하기, Google Cloud로 컨테이너 마이그레이션: Kubernetes를 GKE로 마이그레이션, Google Cloud로 컨테이너 마이그레이션: OpenShift에서 GKE Enterprise로 마이그레이션, GKE 네트워킹 권장사항에 설명된 개념을 사용합니다. 이 문서는 해당하는 경우 이전 문서에 연결됩니다.

이 문서의 안내에서는 워크로드의 리프트 앤 시프트 마이그레이션을 실행한다고 가정합니다. 리프트 앤 시프트 마이그레이션에서는 워크로드가 대상 GKE Enterprise 환경에서 작동하는 데 필요한 최소한의 변경사항만 적용합니다.

OpenShift 리소스를 GKE Enterprise로 마이그레이션하려면 Kubernetes에 매핑하고 변환합니다. 이 문서에서는 GKE Enterprise에 워크로드를 배포하고 운영하는 데 필요한 다음 OpenShift 프로젝트 구성 리소스의 마이그레이션을 설명합니다.

OpenShift 프로젝트 구성과 관련 리소스를 GKE Enterprise로 마이그레이션하려면 다음을 수행하는 것이 좋습니다.

  1. OpenShift 프로젝트 구성 리소스 설명자를 내보냅니다.
  2. OpenShift 프로젝트 구성 리소스를 Kubernetes 리소스에 매핑합니다.
  3. OpenShift 프로젝트 구성 리소스에 매핑되는 Kubernetes 리소스를 만듭니다.
  4. 구성 동기화를 사용하여 Kubernetes 리소스를 관리합니다.

이 문서에서는 마이그레이션 단계를 완료하는 방법의 예시를 제공합니다.

OpenShift 프로젝트 구성 리소스 설명자 내보내기

OpenShift 프로젝트 구성 리소스를 내보내려면 다음을 수행하는 것이 좋습니다.

  1. OpenShift 프로젝트 설명자를 내보냅니다.
  2. 클러스터 범위 리소스 설명자를 내보냅니다.
  3. 프로젝트 범위 리소스 설명자를 내보냅니다.

OpenShift 클러스터에서 내보내는 설명자에는 spec 및 status 필드와 같은 구성과 리소스 상태를 설명하는 필드가 포함됩니다. 설명자에는 metadata.managedFields 필드와 같은 리소스 상태 정보를 저장하는 필드도 포함됩니다. Kubernetes 및 OpenShift에서 리소스 상태 정보와 해당 값을 자동으로 저장하는 필드를 관리합니다. OpenShift 리소스 설명자 평가를 간소화하려면 리소스 설명자마다 다음을 수행하는 것이 좋습니다.

  1. 동적으로 생성된 리소스 상태 정보와 해당 값을 저장하는 필드를 다음과 같이 기록합니다.

    • openshift.io 프리픽스로 시작하는 metadata.annotations 아래에 중첩된 모든 필드
    • metadata.creationTimestamp
    • metadata.generation
    • metadata.managedFields
    • metadata.resourceVersion
    • metadata.selfLink
    • metadata.uid
    • status

  2. 동적으로 생성된 리소스 상태 정보가 저장된 필드를 리소스 설명자에서 삭제합니다.

OpenShift 프로젝트 구성 리소스 설명자를 내보내려면 OpenShift 명령줄 인터페이스(oc CLI)를 사용합니다. oc CLI에서 리소스 설명자를 내보내려면 cluster-admin 역할로 인증해야 합니다. oc CLI에서 지원하는 모든 OpenShift 리소스 목록을 보려면 oc api-resources 명령어를 실행합니다.

OpenShift 프로젝트 설명자 내보내기

이 섹션에서는 프로젝트 설명자를 내보내는 방법을 설명합니다. istio-system 구성요소와 같이 시스템 구성요소를 실행하는 OpenShift 프로젝트와 이름이 openshift-, kube-, 또는 knative-로 시작하는 OpenShift 프로젝트를 제외하는 것이 좋습니다. OpenShift에서 자동으로 이러한 OpenShift 프로젝트를 관리하지만 워크로드를 배포하는 데 사용되지 않으므로 이 마이그레이션에서 다루지 않습니다. OpenShift 프로젝트 설명자를 내보내려면 OpenShift 클러스터마다 다음을 수행합니다.

  1. OpenShift 클러스터에 액세스할 수 있는 터미널에서 oc get 명령어를 사용하여 OpenShift 프로젝트 목록을 가져옵니다.

    oc get projects

    출력은 다음과 비슷합니다.

    NAME                 DISPLAY NAME      STATUS
example-project                        Active
...

    현재 OpenShift 클러스터에 설정된 OpenShift 프로젝트 목록이 출력에 표시됩니다.

  2. 목록의 OpenShift 프로젝트마다 설명자를 YAML 파일 형식으로 내보내고 출력을 표시하고 나중에 처리할 수 있도록 tee 명령어를 사용하여 파일에 저장합니다. 예를 들어 example-project OpenShift 프로젝트 설명자를 내보냅니다.

    oc get project example-project -o yaml | tee project-example-project.yaml

    출력은 다음과 비슷합니다.

    apiVersion: project.openshift.io/v1
kind: Project
metadata:
  annotations:
  name: example-project
spec:
  finalizers:
  - kubernetes

    example-project OpenShift 프로젝트 설명자가 YAML 파일 형식으로 출력에 표시됩니다. 출력은 project-example-project.yaml 파일에 저장됩니다.

클러스터 범위 리소스 설명자 내보내기

이 섹션에서는 클러스터 범위가 있지만 보안 컨텍스트 제약조건은 포함되지 않는 리소스의 설명자를 내보내는 방법을 설명합니다. 보안 정책 마이그레이션은 OpenShift에서 GKE Enterprise로 마이그레이션: OpenShift SCC를 정책 컨트롤러 제약조건으로 마이그레이션을 참조하세요. 다른 리소스 설명자를 내보내려면 OpenShift 클러스터마다 다음을 수행합니다.

  1. 터미널에서 ClusterResourceQuota 목록을 가져옵니다.

    oc get clusterresourcequotas

    출력은 다음과 비슷합니다.

    NAME       AGE
for-name   6m15s
for-user   4s
...

    현재 OpenShift 클러스터에 설정된 ClusterResourceQuota 목록이 출력에 표시됩니다.

  2. 목록의 ClusterResourceQuota마다 설명자를 YAML 파일 형식으로 내보내고 출력을 표시하고 나중에 처리할 수 있도록 파일에 저장합니다. 예를 들어 for-name ClusterResourceQuota 설명자를 내보냅니다.

    oc get clusterresourcequota for-name -o yaml | tee clusterresourcequota-for-name.yaml

    출력은 다음과 비슷합니다.

    apiVersion: quota.openshift.io/v1
kind: ClusterResourceQuota
metadata:
  name: for-name
spec:
  quota:
    hard:
      pods: "10"
      secrets: "20"
  selector:
    annotations: null
    labels:
      matchLabels:
        name: frontend

    for-name ClusterResourceQuota 설명자가 YAML 형식으로 출력에 표시됩니다. 출력은 clusterresourcequota-for-name.yaml 파일에 저장됩니다.

  3. ClusterRole 목록을 가져옵니다.

    oc get clusterroles

    출력은 다음과 비슷합니다.

    NAME                           CREATED AT
admin                          2021-02-02T06:17:02Z
aggregate-olm-edit             2021-02-02T06:17:59Z
aggregate-olm-view             2021-02-02T06:18:01Z
alertmanager-main              2021-02-02T06:48:26Z
basic-user                     2021-02-02T06:26:42Z
...

    현재 OpenShift 클러스터에 설정된 ClusterRole 목록이 출력에 표시됩니다. ClusterRole 목록에는 OpenShift 기본 ClusterRole과 OpenShift 시스템 구성요소를 참조하는 ClusterRole이 포함됩니다. 목록의 모든 ClusterRole을 평가하여 마이그레이션해야 하는 역할과 대상 GKE Enterprise 환경에 적용할 수 없는 역할을 평가하는 것이 좋습니다.

  4. 목록의 ClusterRole마다 설명자를 YAML 파일 형식으로 내보내고 출력을 표시하고 나중에 처리할 수 있도록 파일에 저장합니다. 예를 들어 admin ClusterRole 설명자를 내보냅니다.

    oc get clusterrole admin -o yaml | tee clusterrole-admin.yaml

    출력은 다음과 비슷합니다.

    aggregationRule:
  clusterRoleSelectors:
  - matchLabels:
      rbac.authorization.k8s.io/aggregate-to-admin: "true"
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  annotations:
    rbac.authorization.kubernetes.io/autoupdate: "true"
  labels:
    kubernetes.io/bootstrapping: rbac-defaults
  name: admin
rules:
- apiGroups:
  - operators.coreos.com
  resources:
  - subscriptions
  verbs:
  - create
  - update
  - patch
  - delete
...

    출력에는 admin ClusterRole 설명자가 YAML 형식으로 표시됩니다. 출력은 clusterrole-admin.yaml 파일에 저장됩니다.

  5. ClusterRoleBinding 목록을 가져옵니다.

    oc get clusterrolebindings

    출력은 다음과 비슷합니다.

    NAME                                        ROLE                                             AGE
alertmanager-main                           ClusterRole/alertmanager-main                    21d
basic-users                                 ClusterRole/basic-user                           21d
cloud-credential-operator-rolebinding       ClusterRole/cloud-credential-operator-role       21d
cluster-admin                               ClusterRole/cluster-admin                        21d
cluster-admins                              ClusterRole/cluster-admin                        21d
cluster-autoscaler                          ClusterRole/cluster-autoscaler                   21d
cluster-autoscaler-operator                 ClusterRole/cluster-autoscaler-operator          21d
cluster-monitoring-operator                 ClusterRole/cluster-monitoring-operator          21d
...

    현재 OpenShift 클러스터에 설정된 ClusterRoleBinding 목록이 출력에 표시됩니다. ClusterRoleBinding 목록에는 OpenShift 시스템 구성요소를 참조하는 ClusterRoleBinding이 포함됩니다. 목록의 모든 ClusterRoleBinding을 평가하여 마이그레이션해야 하는 바인딩과 대상 GKE Enterprise 환경에 적용할 수 없는 바인딩을 평가하는 것이 좋습니다.

  6. 목록의 ClusterRoleBinding마다 설명자를 YAML 파일 형식으로 내보내고 출력을 표시하고 나중에 처리할 수 있도록 파일에 저장합니다. 예를 들어 cluster-admin ClusterRoleBinding 설명자를 내보냅니다.

    oc get clusterrolebinding cluster-admin -o yaml | tee clusterrolebinding-cluster-admin.yaml

    출력은 다음과 비슷합니다.

    apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  annotations:
    rbac.authorization.kubernetes.io/autoupdate: "true"
  labels:
    kubernetes.io/bootstrapping: rbac-defaults
  name: cluster-admin
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: cluster-admin
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: Group
  name: system:masters

    cluster-admin ClusterRoleBinding 설명자가 YAML 형식으로 출력에 표시됩니다. 출력은 clusterrolebinding-cluster-admin.yaml 파일에 저장됩니다.

맞춤설정된 NetNamespace 내보내기

이 섹션에서는 멀티 테넌트 격리 구성을 평가하는 방법을 설명합니다. 이 섹션은 클러스터의 모든 OpenShift 프로젝트에 맞춤설정된 NetNamespace를 만들어 네트워크 네임스페이스를 격리하거나 조인하는 경우에 적용됩니다. 맞춤설정된 NetNamespace를 만들지 않은 경우 프로젝트 범위 리소스 설명자 내보내기로 건너뜁니다.

OpenShift는 관리형 OpenShift 프로젝트의 NetNamespace를 자동으로 만들고 관리합니다. OpenShift 관리 프로젝트의 NetNamespace는 이 마이그레이션에서 다루지 않습니다.

맞춤설정된 NetNamespace를 내보내려면 다음을 수행합니다.

  1. NetNamespace 목록을 가져옵니다.

    oc get netnamespaces

    출력은 다음과 비슷합니다.

    NAME                                          NETID      EGRESS IPS
default                                       0
kube-node-lease                               13240579
kube-public                                   15463168
kube-system                                   16247265
openshift                                     9631477
openshift-apiserver                           12186643
openshift-apiserver-operator                  6097417
openshift-authentication                      2862939
openshift-authentication-operator             723750
openshift-cloud-credential-operator           11544971
openshift-cluster-csi-drivers                 7650297
openshift-cluster-machine-approver            7836750
openshift-cluster-node-tuning-operator        7531826
...

    현재 OpenShift 클러스터에 설정된 NetNamespace 목록이 출력에 표시됩니다.

  2. 목록의 NetNamespace마다 설명자를 YAML 파일 형식으로 내보내고 출력을 표시하고 나중에 처리할 수 있도록 파일에 저장합니다. 예를 들어 default NetNamespace 설명자를 내보냅니다.

    oc get netnamespace example-project -o yaml | tee netnamespace-example-project.yaml

    동일한 netid 값이 없는 NetNamespace의 경우 출력은 다음과 비슷합니다.

    apiVersion: network.openshift.io/v1
kind: NetNamespace
metadata:
  name: example-project
netid: 1234
netname: example-project

    example-project NetNamespace 설명자가 YAML 파일 형식으로 출력에 표시됩니다. 출력은 netnamespace-example-project.yaml 파일에 저장됩니다.

    동일한 netid 값이 있는 NetNamespace의 경우 출력은 다음과 비슷합니다.

    apiVersion: network.openshift.io/v1
kind: NetNamespace
metadata:
  name: example-project
netid: 1234
netname: example-project

apiVersion: network.openshift.io/v1
kind: NetNamespace
metadata:
  name: example-project-2
netid: 1234
netname: example-project-2

프로젝트 범위 리소스 설명자 내보내기

프로젝트 범위가 있는 리소스의 설명자를 내보내려면 OpenShift 프로젝트마다 다음을 수행합니다.

  1. 터미널에서 평가하려는 OpenShift 프로젝트를 선택합니다. 예를 들어 example-project OpenShift 프로젝트를 선택합니다.

    oc project example-project

  2. ResourceQuota 목록을 가져옵니다.

    oc get resourcequotas

    출력은 다음과 비슷합니다.

    NAME        AGE   REQUEST                        LIMIT
gpu-quota   6s    requests.nvidia.com/gpu: 1/1
...

    현재 선택된 OpenShift 프로젝트의 OpenShift 클러스터에 설정된 ResourceQuotas 목록이 출력에 표시됩니다.

  3. 목록의 ResourceQuota마다 설명자를 YAML 형식으로 내보내고 출력을 표시하고 나중에 처리할 수 있도록 파일에 저장합니다. 예를 들어 gpu-quota ResourceQuota 설명자를 내보냅니다.

    oc get resourcequota gpu-quota -o yaml | tee resourcequota-gpu-quota.yaml

    출력은 다음과 비슷합니다.

    apiVersion: v1
kind: ResourceQuota
metadata:
  name: gpu-quota
  namespace: example-project
spec:
  hard:
    requests.nvidia.com/gpu: "1"

    gpu-quota ResourceQuota 설명자가 YAML 파일 형식으로 출력에 표시됩니다. 출력은 resourcequota-gpu-quota.yaml 파일에 저장됩니다.

  4. 역할 목록을 가져옵니다.

    oc get roles

    출력은 다음과 비슷합니다.

    NAME             CREATED AT
example          2021-02-02T06:48:27Z

...

    현재 선택된 OpenShift 프로젝트의 OpenShift 클러스터에 설정된 역할 목록이 출력에 표시됩니다. 역할 목록에는 OpenShift 시스템 구성요소를 참조하는 역할이 포함됩니다. 목록의 모든 역할을 평가하여 마이그레이션해야 하는 역할과 대상 GKE Enterprise 환경에 적용할 수 없는 역할을 평가하는 것이 좋습니다.

  5. 목록의 역할마다 설명자를 YAML 파일 형식으로 내보내고 출력을 표시하고 나중에 처리할 수 있도록 파일에 저장합니다. 예를 들어 example 역할 설명자를 내보냅니다.

    oc get role example -o yaml | tee role-example.yaml

    출력은 다음과 비슷합니다.

    apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: example
  namespace: example-project
rules:
- apiGroups:
  - ""
  resources:
  - services
  - endpoints
  - pods
  verbs:
  - get
  - list
  - watch

    example 역할 설명자가 YAML 파일 형식으로 출력에 표시됩니다. 출력은 role-example.yaml 파일에 저장됩니다.

  6. RoleBinding 목록을 가져옵니다.

    oc get rolebindings

    출력은 다음과 비슷합니다.

    NAME                               ROLE                                           AGE
machine-config-controller-events   ClusterRole/machine-config-controller-events   21d
machine-config-daemon-events       ClusterRole/machine-config-daemon-events       21d
example                            Role/example                                   21d
system:deployers                   ClusterRole/system:deployer                    21d
system:image-builders              ClusterRole/system:image-builder               21d
system:image-pullers               ClusterRole/system:image-puller                21d
...

    선택된 OpenShift 프로젝트의 OpenShift 클러스터에 설정된 RoleBinding 목록이 출력에 표시됩니다. RoleBinding 목록에는 OpenShift 시스템 구성요소를 참조하는 RoleBinding이 포함됩니다. 목록의 모든 RoleBinding을 평가하여 마이그레이션해야 하는 바인딩과 대상 GKE Enterprise 환경에 적용할 수 없는 바인딩을 평가하는 것이 좋습니다.

  7. 목록의 RoleBinding마다 설명자를 YAML 파일 형식으로 내보내고 출력을 표시하고 나중에 처리할 수 있도록 파일에 저장합니다. 예를 들어 example RoleBinding 설명자를 내보냅니다.

    oc get rolebinding example -o yaml | tee rolebinding-example.yaml

    출력은 다음과 비슷합니다.

    apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: example
  namespace: example-project
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: example
subjects:
- kind: ServiceAccount
  name: example
  namespace: example-ns

    example RoleBinding 설명자가 YAML 파일 형식으로 출력에 표시됩니다. 출력은 rolebinding-example.yaml 파일에 저장됩니다.

  8. EgressNetworkPolicy 목록을 가져옵니다.

    oc get egressnetworkpolicies

    출력은 다음과 비슷합니다.

    NAME      AGE
default   2m2s
...

    현재 선택된 OpenShift 프로젝트의 OpenShift 클러스터에 설정된 EgressNetworkPolicy 목록이 출력에 표시됩니다.

  9. 목록의 EgressNetworkPolicy마다 설명자를 YAML 파일 형식으로 내보내고 출력을 표시하고 나중에 처리할 수 있도록 파일에 저장합니다. 예를 들어 default EgressNetworkPolicy 설명자를 내보냅니다.

    oc get egressnetworkpolicy default -o yaml | tee egressnetworkpolicy-default.yaml

    출력은 다음과 비슷합니다.

    apiVersion: network.openshift.io/v1
kind: EgressNetworkPolicy
metadata:
  name: default
  namespace: example-project
spec:
  egress:
  - to:
      cidrSelector: 1.2.3.0/24
    type: Allow
  - to:
      dnsName: www.example.com
    type: Allow
  - to:
      cidrSelector: 0.0.0.0/0
    type: Deny

    default EgressNetworkPolicy 설명자가 YAML 형식으로 출력에 표시됩니다. 출력은 egressnetworkpolicy-default.yaml 파일에도 저장됩니다.

  10. NetworkPolicy 목록을 가져옵니다.

    oc get networkpolicies

    출력은 다음과 비슷합니다.

    NAME          POD-SELECTOR   AGE
test-policy   app=mongodb    3s
...

    현재 선택된 OpenShift 프로젝트의 OpenShift 클러스터에 설정된 NetworkPolicy 목록이 출력에 표시됩니다.

  11. 목록의 NetworkPolicy마다 설명자를 YAML 파일 형식으로 내보내고 출력을 표시하고 나중에 처리할 수 있도록 파일에 저장합니다. 예를 들어 test-policy NetworkPolicy 설명자를 내보냅니다.

    oc get networkpolicy test-policy -o yaml | tee networkpolicy-test-policy.yaml

    출력은 다음과 비슷합니다.

    apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: test-policy
  namespace: example-project
spec:
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: app
    ports:
    - port: 27017
      protocol: TCP
  podSelector:
    matchLabels:
      app: mongodb
  policyTypes:
  - Ingress

    test-policy NetworkPolicy 설명자가 YAML 파일 형식으로 출력에 표시됩니다. 출력은 networkpolicy-test-policy.yaml 파일에 저장됩니다.

OpenShift 프로젝트 구성 리소스를 Kubernetes 리소스에 매핑

OpenShift 프로젝트 구성 리소스의 인벤토리를 완료한 후에는 다음과 같이 리소스를 평가합니다.

  1. 인벤토리의 리소스가 Kubernetes 리소스와 OpenShift 리소스인지 평가합니다.
  2. OpenShift 리소스를 Kubernetes, GKE, GKE Enterprise에 매핑합니다.

다음 목록은 OpenShift 클러스터에서 프로비저닝한 리소스가 Kubernetes 리소스이고 OpenShift에서만 리소스를 사용할 수 있는지 평가하는 데 도움이 됩니다.

  • OpenShift 프로젝트는 추가 주석이 있는 Kubernetes 네임스페이스입니다.
  • 역할, ClusterRole, RoleBinding, ClusterRoleBinding은 Kubernetes 리소스입니다.
  • ResourceQuota는 Kubernetes 리소스입니다.
  • NetworkPolicy는 Kubernetes 리소스입니다.
  • ClusterResourceQuota는 Kubernetes 리소스가 아니며 OpenShift에서만 사용 가능합니다.
  • NetNamespace 및 EgressNetworkPolicy는 Kubernetes 리소스가 아니며 OpenShift에서만 사용 가능합니다.

다음 표에서는 OpenShift 프로젝트 구성 리소스를 GKE Enterprise에서 사용한 리소스에 매핑하는 방법을 요약 설명합니다.

OpenShift GKE Enterprise
프로젝트 추가 주석이 있는 Kubernetes 네임스페이스로 변환
역할, ClusterRole, RoleBinding, ClusterRoleBinding Kubernetes RBAC 리소스
ResourceQuotas Kubernetes RBAC 리소스
ClusterResourceQuota ResourceQuota로 변환하거나 계층적 리소스 할당량 사용
NetworkPolicies Kubernetes 네트워크 리소스
NetNamespace, EgressNetworkPolicy NetworkPolicy로 변환

OpenShift 환경의 리소스를 평가한 후 OpenShift 리소스를 GKE 및 GKE Enterprise에서 프로비저닝하고 구성할 수 있는 리소스에 매핑합니다. OpenShift 클러스터에서 사용 중인 Kubernetes 리소스를 매핑할 필요가 없습니다. GKE Enterprise에서 직접 지원하기 때문입니다. OpenShift를 GKE Enterprise로 기능 매핑 요약의 설명대로 다음을 매핑하는 것이 좋습니다.

  • OpenShift 프로젝트를 Kubernetes 네임스페이스로 매핑
  • ClusterResourceQuota를 ResourceQuota로 매핑
  • NetNamespace 및 EgressNetworkPolicy를 NetworkPolicy로 매핑

OpenShift 프로젝트 구성 리소스에 매핑되는 Kubernetes 리소스 만들기

매핑을 완료한 후 OpenShift 리소스에 매핑된 Kubernetes 리소스를 만듭니다. 다음을 만드는 것이 좋습니다.

  • OpenShift 프로젝트마다 Kubernetes 네임스페이스 하나
  • ClusterResourceQuota에서 제한하는 Kubernetes 네임스페이스마다 ResourceQuota 하나
  • NetNamespace 및 EgressNetworkPolicy와 일치하는 NetworkPolicy

Kubernetes 네임스페이스 만들기

OpenShift 프로젝트는 추가 주석이 있는 Kubernetes 네임스페이스입니다. OpenShift 프로젝트 API는 Kubernetes Namespace API와 매우 유사하게 일치합니다. OpenShift 프로젝트를 마이그레이션하려면 OpenShift 프로젝트마다 Kubernetes 네임스페이스를 만드는 것이 좋습니다. API가 호환되므로 OpenShift 프로젝트에서 Kubernetes 네임스페이스를 만들 수 있습니다.

OpenShift 프로젝트에서 Kubernetes 네임스페이스를 만들려면 OpenShift 프로젝트 설명자의 값을 각 OpenShift 프로젝트의 해당 Kubernetes 네임스페이스 API 버전으로 변경하는 것이 좋습니다. 이렇게 하려면 OpenShift 프로젝트 객체 API 버전에서 OpenShift 프로젝트 설명자의 apiVersion 필드 값과 kind 필드 값을 해당 Kubernetes 네임스페이스 객체 API 버전으로 변경합니다. 예를 들어 이전 섹션에서 평가한 OpenShift 프로젝트는 다음과 비슷합니다.

apiVersion: project.openshift.io/v1
kind: Project
metadata:
  annotations:
  name: default
spec:
  finalizers:
  - kubernetes

프로젝트를 마이그레이션하려면 apiVersion 필드 값을 project.openshift.io/v1에서 v1로, kind 필드 값을 Project에서 Namespace로 변경합니다.

apiVersion: v1
kind: Namespace
Metadata:
  annotations:
  name: default
spec:
  finalizers:
  - kubernetes

Kubernetes ResourceQuota 만들기

OpenShift ClusterResourceQuota를 사용하면 여러 OpenShift 프로젝트에서 할당량을 공유할 수 있습니다. ClusterResourceQuota를 만들 때 할당량을 정의하고 할당량을 적용하려는 OpenShift 프로젝트와 일치하도록 선택기를 정의합니다. 이 섹션에서는 OpenShift ClusterResourceQuota를 앞에서 만든 네임스페이스의 Kubernetes ResourceQuota로 마이그레이션합니다.

ClusterResourceQuota를 마이그레이션하려면 ClusterResourceQuota마다 다음을 수행하는 것이 좋습니다.

  1. ClusterResourceQuota의 spec.quota 필드와 spec.selector 필드를 평가하여 ClusterResourceQuota를 OpenShift 프로젝트에 매핑합니다. 예를 들어 이전 섹션에서 내보낸 for-name ClusterResourceQuota는 다음과 같습니다.

    apiVersion: quota.openshift.io/v1
kind: ClusterResourceQuota
metadata:
  name: for-name
spec:
  quota:
    hard:
      pods: "10"
      secrets: "20"
  selector:
    annotations: null
    labels:
      matchLabels:
        name: frontend

    for-name ClusterResourceQuota에서 포드 및 보안 비밀 할당량 한도를 적용합니다. spec.selector 필드는 frontend OpenShift 프로젝트에 이러한 한도를 적용합니다.

  2. 앞선 Kubernetes 네임스페이스 만들기에서 OpenShift 프로젝트에 해당하는 Kubernetes 네임스페이스를 만들었습니다. 이 정보를 사용하여 ClusterResourceQuota를 새 Kubernetes 네임스페이스에 매핑합니다. 예를 들어 frontend OpenShift 프로젝트에는 for-name ClusterResourceQuota가 포함됩니다. 프로젝트는 frontend Kubernetes 네임스페이스에 해당하므로 for-name ClusterResourceQuota를 frontend Kubernetes 네임스페이스에 매핑합니다.

  3. ClusterResourceQuota quota 필드의 할당량 정의마다 원하는 기준에 따라 ClusterResourceQuota를 매핑한 Kubernetes 네임스페이스에서 할당량을 분할합니다. 예를 들어 for-name ClusterResourceQuota로 설정된 할당량을 frontend Kubernetes 네임스페이스 간에 균등하게 분할할 수 있습니다.

  4. ClusterResourceQuota에 매핑된 Kubernetes 네임스페이스마다 해당 네임스페이스에 할당량을 적용하는 Kubernetes ResourceQuota를 만듭니다. 이전 단계에서 수집한 정보에 따라 할당량을 설정합니다. 예를 들어 frontend Kubernetes 네임스페이스에 ResourceQuota를 만듭니다.

    apiVersion: v1
kind: ResourceQuota
metadata:
  name: pods-secrets
  namespace: frontend
spec:
  hard:
    pods: "10"
    secrets: "20"

    또 다른 예시로 for-name ClusterResourceQuota를 고유한 Kubernetes 네임스페이스 두 개인 example-1 및 example-2에 매핑합니다. 매핑을 완료하려면 Kubernetes 네임스페이스에 ResourceQuota를 만들어 리소스를 균등하게 분할합니다. ResourceQuota의 첫 번째 절반을 할당합니다.

    apiVersion: v1
kind: ResourceQuota
metadata:
  name: pods-secrets
  namespace: example-1
spec:
  hard:
    pods: "5"
    secrets: "10"

    ResourceQuota의 첫 번째 절반을 할당한 후 ResourceQuota의 두 번째 절반을 할당합니다.

    apiVersion: v1
kind: ResourceQuota
metadata:
  name: pods-secrets
  namespace: example-2
spec:
  hard:
    pods: "5"
    secrets: "10"

    이 방식을 사용하면 여러 Kubernetes 네임스페이스에 단일 한도를 설정하는 대신에 ResourceQuota를 만드는 Kubernetes 네임스페이스마다 한도를 적용할 수 있습니다.

ResourceQuota를 사용하여 Kubernetes 네임스페이스에 할당량 적용은 ClusterResourceQuota를 사용하여 모든 Kubernetes 네임스페이스에 할당량 하나 적용과 다릅니다. 클러스터 범위 할당량을 서로 다른 Kubernetes 네임스페이스로 분할은 최적의 분할이 아닐 수 있습니다. 분할은 일부 Kubernetes 네임스페이스의 할당량을 과도하게 프로비저닝하고 다른 Kubernetes 네임스페이스의 할당량을 부족하게 프로비저닝할 수 있습니다.

해당 ClusterResourceQuota에 설정된 총 할당량을 고려하여 Kubernetes 네임스페이스의 ResourceQuota 구성을 동적으로 조정하여 할당량 할당을 최적화하는 것이 좋습니다. 예를 들어 pods-secrets ResourceQuota에 의해 적용되는 할당량을 동적으로 늘리거나 줄여 example-1 및 example-2 Kubernetes 네임스페이스의 할당량이 과도하게 또는 부족하게 프로비저닝되는 것을 방지할 수 있습니다. pods-secrets ResourceQuota의 총 할당량이 해당 ClusterResourceQuota의 할당량을 초과해서는 안 됩니다.

ResourceQuota를 구성할 때 GKE 할당량 및 한도와 VMware용 GKE 할당량 및 한도를 고려합니다. 이러한 할당량과 한도는 ResourceQuota보다 낮은 한도를 적용할 수 있습니다. 예를 들어 GKE는 ResourceQuota 구성 방식에 관계없이 노드당 최대 포드 수를 제한합니다.

NetworkPolicy 만들기

OpenShift NetNamespace를 사용하면 OpenShift 프로젝트 간 네트워크 격리를 구성할 수 있습니다. OpenShift EgressNetworkPolicy를 사용하면 OpenShift 클러스터에서 나가는 아웃바운드 트래픽을 규제할 수 있습니다. 이 섹션에서는 트래픽 제한 개념을 사용합니다.

NetNamespace 및 EgressNetworkPolicy를 마이그레이션하려면 다음을 수행합니다.

  1. NetNamespace 및 EgressNetworkPolicy를 평가하여 OpenShift 프로젝트와 OpenShift 클러스터에서 나가는 아웃바운드 트래픽 간의 네트워크 트래픽 규제 방법을 파악합니다. 예를 들어 이전 섹션에서 내보낸 NetNamespace 및 EgressNetworkPolicy를 평가합니다.

    apiVersion: network.openshift.io/v1
kind: NetNamespace
metadata:
  name: example-project
netid: 1234
netname: example-project

apiVersion: network.openshift.io/v1
kind: NetNamespace
metadata:
  name: example-project-2
netid: 1234
netname: example-project-2

apiVersion: network.openshift.io/v1
kind: EgressNetworkPolicy
metadata:
  name: default
  namespace: example-project
spec:
  egress:
  - to:
      cidrSelector: 1.2.3.0/24
    type: Allow
  - to:
      cidrSelector: 0.0.0.0/0
    type: Deny

    example-project 및 example-project-2 NetNamespace는 1234의 동일한 netid 값으로 오버레이 네트워크를 정의합니다. 따라서 example-project OpenShift 프로젝트의 포드는 example-project-2 OpenShift 프로젝트의 포드와 통신할 수 있으며 그 반대의 경우도 마찬가지입니다.

    default EgressNetworkPolicy는 다음과 같은 아웃바운드 네트워크 트래픽 규칙을 정의합니다.

    • 1.2.3.0/24 서브넷으로 나가는 아웃바운드 트래픽을 허용합니다.
    • 다른 규칙과 일치하지 않는 아웃바운드 트래픽을 거부합니다.

  2. 네트워크 트래픽 제한 요구사항에 맞게 NetworkPolicy 및 OPA 정책을 만듭니다. 예를 들어 default-np 및 default-np-2는 다음 정책을 구현합니다.

    • default EgressNetworkPolicy에 의해 적용되는 정책
    • netid 라벨이 example-project 및 example-project-2로 설정된 네임스페이스의 example-project 및 example-project-2 NetNamespace에 의해 적용되는 정책

    정책은 다음과 비슷합니다.

    ---
kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: default-np
  namespace: example-project
spec:
  policyTypes:
  - Ingress
  - Egress
  podSelector: {}
  egress:
    - to:
      - namespaceSelector:
          matchLabels:
            netid: example-project-2
      - podSelector: {}
      - ipBlock:
          cidr: 1.2.3.0/24
  ingress:
    - from:
      - namespaceSelector:
          matchLabels:
            netname: example-project-2

---
kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: default-np-2
  namespace: example-project-2
spec:
  policyTypes:
  - Ingress
  - Egress
  podSelector: {}
  egress:
    - to:
      - namespaceSelector:
          matchLabels:
            netid: example-project-2
      - podSelector: {}
      - ipBlock:
          cidr: 1.2.3.0/24
  ingress:
    - from:
      - namespaceSelector:
          matchLabels:
            netname: example-project

구성 동기화를 사용하여 Kubernetes 리소스 관리

Kubernetes 리소스와 GKE 클러스터 구성을 관리하려면 구성 동기화를 사용하는 것이 좋습니다.

GKE 클러스터에서 구성 동기화를 사용 설정하는 방법은 구성 동기화 설치를 참조하세요.

GKE Enterprise 환경에서 구성 동기화를 프로비저닝하고 구성한 후 이를 사용하여 구성을 만들고 자동으로 GKE 클러스터에 적용합니다.

다음 단계