클러스터 업데이트

bmctl로 클러스터를 만든 후 다음 일련의 작업을 수행하여 클러스터 구성의 여러 측면을 변경할 수 있습니다.

  1. 클러스터 구성 파일의 특정 필드 값을 변경합니다. 기본적으로 구성 파일은 bmctl-workspace/CLUSTER-NAME/CLUSTER-NAME.yaml에 있습니다.

  2. bmctl update 명령어를 실행하여 클러스터를 업데이트합니다.

이 방법을 통해 클러스터의 노드를 추가 또는 삭제하거나 클러스터의 노드를 바꾸는 등의 작업을 할 수 있습니다. 이 문서에서는 이러한 업데이트 및 기타 클러스터 업데이트를 수행하는 방법을 설명합니다.

그러나 클러스터 구성의 많은 부분을 변경할 수 없으며 클러스터를 만든 후에는 업데이트할 수 없습니다. 변경 가능한 필드와 변경할 수 없는 필드의 전체 목록은 클러스터 구성 필드 참조를 확인하세요. 필드 참조는 정렬 가능한 테이블입니다. 정렬 순서를 변경하려면 열 제목을 클릭하세요. 설명을 보려면 필드 이름을 클릭하세요.

클러스터에서 노드 추가 또는 삭제

노드 풀은 클러스터 내에서 구성이 모두 동일한 노드 그룹입니다. 노드는 항상 노드 풀에 속합니다. 새 노드를 클러스터에 추가하려면 특정 노드 풀에 추가해야 합니다. 노드 풀에서 노드를 삭제하면 클러스터에서 노드가 모두 삭제됩니다.

베어메탈용 GKE에는 제어 영역, 부하 분산기, 워커 노드 풀과 같은 3가지 종류의 노드 풀이 있습니다.

클러스터 구성 파일의 특정 섹션에 있는 노드의 IP 주소를 추가하거나 삭제하여 노드 풀에서 노드를 추가하거나 삭제합니다. 다음 목록에서는 특정 노드 풀에서 수정할 섹션을 보여줍니다.

  • 워커 노드 풀: NodePool 사양의 spec.nodes 섹션에 있는 노드의 IP 주소를 추가하거나 삭제합니다.
  • 제어 영역 노드 풀: Cluster 사양의 spec.controlPlane.nodePoolSpec.nodes 섹션에 있는 노드의 IP 주소를 추가하거나 삭제합니다.
  • 부하 분산기 노드 풀: Cluster 사양의 spec.loadBalancer.nodePoolSpec.nodes 섹션에 있는 노드의 IP 주소를 추가하거나 삭제합니다.

예시: 워커 노드 삭제 방법

다음은 워커 노드 두 개의 사양을 보여주는 클러스터 구성 파일 샘플입니다.

---
apiVersion: baremetal.cluster.gke.io/v1
kind: NodePool
metadata:
  name: nodepool1
  namespace: cluster-cluster1
spec:
  clusterName: cluster1
  nodes:
  - address: 172.18.0.5
  - address: 172.18.0.6

노드를 삭제하려면 다음 안내를 따르세요.

  1. (선택사항) 삭제할 노드에서 중요한 포드를 실행하는 경우 먼저 노드를 유지보수 모드로 전환합니다.

    NodePool 리소스의 status.nodesDrainedstatus.nodesDraining 필드를 확인하면 워커 노드의 노드 드레이닝 프로세스를 모니터링할 수 있습니다.

  2. 클러스터 구성 파일을 수정하여 노드의 IP 주소 항목을 삭제합니다.

  3. 클러스터를 업데이트합니다.

    bmctl update cluster -c CLUSTER_NAME \
        --kubeconfig=ADMIN_KUBECONFIG
    

    다음을 바꿉니다.

    • CLUSTER_NAME: 업데이트하려는 클러스터의 이름
    • ADMIN_KUBECONFIG: 관리자 클러스터 kubeconfig 파일의 경로

    bmctl update 명령어가 성공적으로 실행된 후 machine-preflightmachine-init 작업이 완료되는 데 다소 시간이 걸립니다. 이 문서의 업데이트 확인 섹션에 설명된 명령어를 실행하여 노드와 해당 노드 풀의 상태를 볼 수 있습니다.

노드 강제 삭제

bmctl update 명령어로 노드를 삭제할 수 없는 경우 클러스터에서 노드를 강제로 삭제해야 할 수 있습니다. 자세한 내용은 손상된 노드 강제 삭제를 참조하세요.

HA 제어 영역 노드 교체

관리자, 사용자, 독립형, 하이브리드 클러스터에서 고가용성(HA) 제어 영역 노드를 바꿀 수 있습니다.

클러스터의 노드를 바꾸려면 다음 단계를 따르세요.

  1. 클러스터 구성 파일에서 노드의 IP 주소를 삭제합니다.
  2. 클러스터를 업데이트합니다.
  3. 클러스터의 노드 상태를 확인합니다.
  4. 새 노드의 IP 주소를 동일한 클러스터 구성 파일에 추가합니다.
  5. 클러스터를 업데이트합니다.

이 섹션의 나머지 부분에서는 예시를 통해 설명합니다.

다음은 사용자 클러스터의 제어 영역 노드 세 개를 보여주는 샘플 클러스터 구성 파일입니다.

---
apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
 name: user-cluster
 namespace: cluster-user-cluster
spec:
  controlPlane:
   nodePoolSpec:
     nodes:
     - address: 10.200.0.11
     - address: 10.200.0.12
     - address: 10.200.0.13

spec.controlPlane.nodePoolSpec.nodes 섹션에 나열된 마지막 노드를 바꾸려면 다음 단계를 수행하세요.

  1. 클러스터 구성 파일에서 IP 주소 항목을 삭제하여 노드를 삭제합니다. 이렇게 변경하면 클러스터 구성 파일이 다음과 같이 표시됩니다.

    ---
    apiVersion: baremetal.cluster.gke.io/v1
    kind: Cluster
    metadata:
     name: user-cluster
     namespace: cluster-user-cluster
    spec:
      controlPlane:
       nodePoolSpec:
         nodes:
         - address: 10.200.0.11
         - address: 10.200.0.12
    
  2. 다음 명령어를 실행하여 클러스터를 업데이트합니다.

    bmctl update cluster -c CLUSTER_NAME \
        --kubeconfig=KUBECONFIG
    

    다음과 같이 변경하세요.

    • CLUSTER_NAME을 업데이트하려는 클러스터 이름으로 바꿉니다.
    • 클러스터가 자체 관리 클러스터(예: 관리자 또는 독립형 클러스터)인 경우 KUBECONFIG를 클러스터의 kubeconfig 파일 경로로 바꿉니다. 이 예시에서와 같이 클러스터가 사용자 클러스터인 경우 KUBECONFIG관리자 클러스터의 kubeconfig 파일 경로로 바꿉니다.
  3. bmctl update 명령어가 성공적으로 실행된 후 machine-preflightmachine-init 작업이 완료되는 데 다소 시간이 걸립니다. 이 문서의 업데이트 확인 섹션에 설명된 명령어를 실행하여 노드 및 해당 노드 풀의 상태를 볼 수 있습니다. 노드 풀 및 노드가 준비 상태가 되면 다음 단계로 진행할 수 있습니다.

  4. 새 제어 영역 노드의 IP 주소를 클러스터 구성 파일의 spec.controlPlane.nodePoolSpec.nodes 섹션에 추가하여 노드 풀에 새 제어 영역 노드를 추가합니다. 이렇게 변경하면 클러스터 구성 파일이 다음과 같이 표시됩니다.

    ---
    apiVersion: baremetal.cluster.gke.io/v1
    kind: Cluster
    metadata:
     name: user-cluster
     namespace: cluster-user-cluster
    spec:
      controlPlane:
       nodePoolSpec:
         nodes:
         - address: 10.200.0.11
         - address: 10.200.0.12
         - address: 10.200.0.14
    
  5. 다음 명령어를 실행하여 클러스터를 업데이트합니다.

    bmctl update cluster -c CLUSTER_NAME \
        --kubeconfig=KUBECONFIG
    

    다음과 같이 변경하세요.

    • CLUSTER_NAME을 업데이트하려는 클러스터 이름으로 바꿉니다.
    • 클러스터가 자체 관리 클러스터(예: 관리자 또는 독립형 클러스터)인 경우 KUBECONFIG를 클러스터의 kubeconfig 파일 경로로 바꿉니다. 이 예시에서와 같이 클러스터가 사용자 클러스터인 경우 KUBECONFIG관리자 클러스터의 kubeconfig 파일 경로로 바꿉니다.

업데이트 확인

kubectl get 명령어를 사용하면 노드 및 각 노드 풀의 상태를 확인할 수 있습니다.

예를 들어 다음 명령어는 클러스터 네임스페이스 cluster-my-cluster의 노드 풀 상태를 보여줍니다.

kubectl -n cluster-my-cluster get nodepools.baremetal.cluster.gke.io

시스템에서 다음과 비슷한 결과를 반환합니다.

NAME                    READY   RECONCILING   STALLED   UNDERMAINTENANCE   UNKNOWN
cluster-my-cluster      3       0             0         0                  0
cluster-my-cluster-lb   2       0             0         0                  0
np1                     3       0             0         0                  0

Reconciling=1은 조정 단계가 아직 진행 중임을 의미합니다. 상태가 Reconciling=0으로 변경될 때까지 기다려야 합니다.

다음 명령어를 실행하여 클러스터의 노드 상태를 확인할 수도 있습니다.

kubectl get nodes --kubeconfig=KUBECONFIG

클러스터 진단 방법에 대한 자세한 내용은 클러스터 진단을 위한 스냅샷 만들기를 참조하세요.

업데이트로 변경할 수 있는 기능

노드 추가, 삭제, 교체 외에도 bmctl update 명령어를 사용하여 클러스터 구성 파일의 변경 가능한 특정 필드 값, 커스텀 리소스(CR) 및 주석을 수정할 수 있습니다.

클러스터 리소스를 업데이트하려면 클러스터 구성 파일을 수정하고 bmctl update를 사용하여 변경사항을 적용합니다.

다음 섹션에서는 필드 값, CR 또는 주석을 변경하여 기존 클러스터를 업데이트하는 몇 가지 일반적인 예시를 설명합니다.

loadBalancer.addressPools

addressPools 섹션에는 번들 부하 분산기의 부하 분산 풀을 지정할 수 있는 필드가 포함되어 있습니다. 언제든지 부하 분산 주소 풀을 추가할 수 있지만 기존 주소 풀을 삭제하거나 수정할 수는 없습니다.

addressPools:
- name: pool1
  addresses:
  - 192.168.1.0-192.168.1.4
  - 192.168.1.240/28
- name: pool2
  addresses:
  - 192.168.1.224/28

부적절한 클러스터 삭제 방지

클러스터 구성 파일에 baremetal.cluster.gke.io/prevent-deletion: "true" 주석을 추가하면 클러스터가 삭제되지 않습니다. 예를 들어 kubectl delete cluster 또는 bmctl reset cluster를 실행하면 오류가 발생합니다.

apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: ci-10c3c6f4d9c698e
  namespace: cluster-ci-10c3c6f4d9c698e
  annotations:
    baremetal.cluster.gke.io/prevent-deletion: "true"
spec:
  clusterNetwork:

bypassPreflightCheck

bypassPreflightCheck 필드의 기본값은 false입니다. 클러스터 구성 파일에서 이 필드를 true로 설정하면 기존 클러스터에 리소스를 적용할 때 내부 실행 전 검사가 무시됩니다.

apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: cluster1
  namespace: cluster-cluster1
  annotations:
    baremetal.cluster.gke.io/private-mode: "true"
spec:
  bypassPreflightCheck: true

loginUser

노드 액세스 구성에서 loginUser 필드를 설정할 수 있습니다. 이 필드에서는 머신 로그인의 비밀번호가 없는 sudo 기능을 지원합니다.

apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: cluster1
  namespace: cluster-cluster1
  annotations:
    baremetal.cluster.gke.io/private-mode: "true"
spec:
  nodeAccess:
    loginUser: abm

NetworkGatewayGroup

NetworkGatewayGroup 커스텀 리소스는 이그레스 NAT 게이트웨이BGP를 사용하는 번들 부하 분산 기능과 같은 고급 네트워킹 기능의 유동 IP 주소를 제공하는 데 사용됩니다. NetworkGatewayGroup 커스텀 리소스와 관련 네트워킹 기능을 사용하려면 클러스터를 만들 때 clusterNetwork.advancedNetworkingtrue로 설정해야 합니다.

apiVersion: networking.gke.io/v1
kind: NetworkGatewayGroup
  name: default
  namespace: cluster-bm
spec:
  floatingIPs:
  - 10.0.1.100
  - 10.0.2.100

BGPLoadBalancer

BGP로 번들 부하 분산기를 구성하면 데이터 영역 부하 분산은 기본적으로 제어 영역 피어링에 지정된 피어와 동일한 외부 피어를 사용합니다. 또는 BGPLoadBalancer 커스텀 리소스(및 BGPPeer 커스텀 리소스)를 사용하여 데이터 영역 부하 분산을 개별적으로 구성할 수 있습니다. 자세한 내용은 BGP로 번들 부하 분산기 구성을 참조하세요.

apiVersion: networking.gke.io/v1
kind: BGPLoadBalancer
metadata:
  name: default
  namespace: cluster-bm
spec:
  peerSelector:
    cluster.baremetal.gke.io/default-peer: "true"

BGPPeer

BGP로 번들 부하 분산기를 구성하면 데이터 영역 부하 분산은 기본적으로 제어 영역 피어링에 지정된 피어와 동일한 외부 피어를 사용합니다. 또는 BGPPeer 커스텀 리소스(및 BGPLoadBalancer 커스텀 리소스)를 사용하여 데이터 영역 부하 분산을 개별적으로 구성할 수 있습니다. 자세한 내용은 BGP로 번들 부하 분산기 구성을 참조하세요.

apiVersion: networking.gke.io/v1
kind: BGPPeer
metadata:
  name: bgppeer1
  namespace: cluster-bm
  labels:
    cluster.baremetal.gke.io/default-peer: "true"
spec:
  localASN: 65001
  peerASN: 65002
  peerIP: 10.0.3.254
  sessions: 2

NetworkAttachmentDefinition

bmctl update 명령어를 사용하여 네트워크에 해당하는 NetworkAttachmentDefinition 커스텀 리소스를 수정할 수 있습니다.

apiVersion: "k8s.cni.cncf.io/v1"
kind: NetworkAttachmentDefinition
metadata:
  name: gke-network-1
  namespace: cluster-my-cluster
spec:
  config: '{
  "type": "ipvlan",
  "master": "enp2342",
  "mode": "l2",
  "ipam": {
    "type": "whereabouts",
    "range": "172.120.0.0/24"

구성 파일을 수정한 후 다음 bmctl update 명령어를 실행하여 클러스터를 업데이트합니다.

bmctl update cluster -c CLUSTER_NAME --kubeconfig=KUBECONFIG

다음과 같이 변경하세요.

  • CLUSTER_NAME을 업데이트하려는 클러스터 이름으로 바꿉니다.
  • 클러스터가 자체 관리 클러스터(예: 관리자 또는 독립형 클러스터)인 경우 KUBECONFIG를 클러스터의 kubeconfig 파일 경로로 바꿉니다. 클러스터가 사용자 클러스터인 경우 KUBECONFIG관리자 클러스터의 kubeconfig 파일 경로로 바꿉니다.

Kubelet 읽기 전용 포트 중지

베어메탈용 GKE 출시 버전 1.15.0부터는 기본으로 kubelet 읽기 전용 포트인 10255를 사용 중지합니다. 이 안전하지 않은 kubelet 포트 10255에서 데이터를 읽도록 구성된 모든 고객 워크로드는 보안 kubelet 포트 10250을 사용하도록 마이그레이션해야 합니다.

버전 1.15.0 이상으로 생성된 클러스터에서만 이 포트가 기본으로 사용 중지됩니다. kubelet 읽기 전용 포트 10255는 클러스터를 1.15.0 이상으로 업그레이드한 후에도 버전이 1.15.0 미만의 클러스터에서 계속 액세스될 수 있습니다.

이렇게 변경한 이유는 kubelet이 인증되지 않은 포트 10255를 통해 민감도가 낮은 정보를 유출하기 때문입니다. 이 정보에는 공격자에게 유리한 노드에서 실행되는 모든 포드에 대한 전체 구성 정보가 담겨 있습니다. 또한 측정항목과 상태 정보를 노출하여 비즈니스에 민감한 정보를 제공할 수 있습니다.

CIS Kubernetes 벤치마크에서는 kubelet 읽기 전용 포트를 중지할 것을 권장합니다. 버전 1.14에서 포트를 수동으로 중지하려면 다음 단계를 완료합니다.

  1. 클러스터 구성 파일을 수정하고 다음 주석을 추가합니다.

    baremetal.cluster.gke.io/enable-kubelet-read-only-port: "false"
    

    다음 클러스터 구성 파일 예시에서는 이 주석이 추가되었음을 보여줍니다.

    [...]
    ---
    apiVersion: v1
    kind: Namespace
    metadata:
      name: cluster-my-cluster
    ---
    apiVersion: baremetal.cluster.gke.io/v1
    kind: Cluster
    metadata:
      annotations:
        baremetal.cluster.gke.io/enable-kubelet-read-only-port: "false"
      name: my-cluster
      namespace: cluster-my-cluster
    [...]
    
  2. 클러스터 웹훅 유효성 검사 클러스터 리소스를 수정합니다.

    kubectl edit validatingwebhookconfigurations lcm-validating-webhook-configuration
    
  3. UPDATE 동사가 있는 줄을 삭제하여 웹훅 유효성 검사를 일시적으로 중지합니다.

    - admissionReviewVersions:
    - v1
    clientConfig:
      caBundle: 
      service:
        name: lcm-webhook-service
        namespace: kube-system
        path: /validate-baremetal-cluster-gke-io-v1-cluster
        port: 443
    failurePolicy: Fail
    matchPolicy: Equivalent
    name: vcluster.kb.io
    namespaceSelector: {}
    objectSelector: {}
    rules:
    - apiGroups:
      - baremetal.cluster.gke.io
      apiVersions:
      - v1
      operations:
      - CREATE
      - UPDATE # <- DELETE THIS LINE
      - DELETE
      resources:
      - clusters
      scope: '*'
    sideEffects: None
    timeoutSeconds: 10
    
  4. 클러스터 커스텀 리소스에 주석을 추가합니다.

    kubectl edit clusters CLUSTER_NAME --kubeconfig KUBECONFIG_PATH
    

    다음과 같이 변경하세요.

    • CLUSTER_NAME을 업데이트하려는 클러스터 이름으로 바꿉니다.
    • KUBECONFIG_PATH을 클러스터의 kubeconfig 파일 경로로 바꿉니다.
  5. 다음 업데이트된 클러스터 커스텀 리소스 예시와 같이 주석을 추가합니다.

    apiVersion: baremetal.cluster.gke.io/v1
    kind: Cluster
    metadata:
      annotations:
        baremetal.cluster.gke.io/enable-kubelet-read-only-port: "false"
    [...]
    
  6. 클러스터 커스텀 리소스를 저장하고 닫습니다.

  7. 클러스터 웹훅 유효성 검사 클러스터 리소스에 UPDATE 동사를 다시 추가하여 웹훅 유효성 검사를 다시 사용 설정합니다.

    kubectl edit validatingwebhookconfigurations lcm-validating-webhook-configuration
    

    커스텀 리소스의 operations 섹션에 UPDATE 동사를 다시 추가합니다.

    - admissionReviewVersions:
    - v1
    clientConfig:
      caBundle: 
      service:
        name: lcm-webhook-service
        namespace: kube-system
        path: /validate-baremetal-cluster-gke-io-v1-cluster
        port: 443
    failurePolicy: Fail
    matchPolicy: Equivalent
    name: vcluster.kb.io
    namespaceSelector: {}
    objectSelector: {}
    rules:
    - apiGroups:
      - baremetal.cluster.gke.io
      apiVersions:
      - v1
      operations:
      - CREATE
      - UPDATE # <- ADD THIS LINE BACK
      - DELETE
      resources:
      - clusters
      scope: '*'
    sideEffects: None
    timeoutSeconds: 10
    

    클러스터 커스텀 리소스를 저장하고 닫습니다.

이러한 변경사항은 버전 1.15.0 이상으로 업그레이드해도 유지됩니다.