웹훅을 사용할 때 컨트롤 플레인 안정성 보장

Kubernetes의 허용 웹훅 또는 웹훅은 컨트롤 플레인에 대한 요청을 유지하기 전에 Kubernetes 클러스터에서 요청을 검증하거나 변형하는 데 사용할 수 있는 허용 컨트롤러의 한 유형입니다. 제3자 애플리케이션은 일반적으로 시스템에 중요한 리소스 및 네임스페이스에서 작동하는 웹훅을 사용합니다. 잘못 구성된 웹훅은 컨트롤 플레인 성능과 신뢰성에 영향을 줄 수 있습니다. 예를 들어 제3자 애플리케이션에서 만든 웹훅이 잘못 구성된 경우 GKE가 관리형 kube-system 네임스페이스에서 리소스를 만들고 수정하지 못하게 되어 클러스터 기능이 저하될 수 있습니다.

Google Kubernetes Engine(GKE)은 클러스터를 모니터링하고 추천자 서비스를 사용하여 플랫폼 사용량을 최적화하는 방법을 안내합니다. 클러스터의 안정성과 성능을 유지하려면 다음 시나리오에 대한 GKE의 권장사항을 참조하세요.

  • 작동하지만 사용 가능한 엔드포인트가 없는 웹훅
  • 시스템에서 중요한 리소스와 네임스페이스를 작동할 때 안전하지 않다고 간주되는 웹훅

이 안내에 따라 잘못 구성되었을 수 있는 웹훅을 확인하고 필요한 경우 업데이트하는 방법을 확인할 수 있습니다.

통계 및 추천을 관리하는 방법에 대한 자세한 내용은 통계 및 추천으로 GKE 사용 최적화를 참조하세요.

클러스터에 영향을 미칠 수 있는 잘못 구성된 웹훅 식별

클러스터의 성능과 안정성에 영향을 미칠 수 있는 웹훅을 식별하는 통계를 확인하려면 안내에 따라 통계 및 추천을 봅니다. 다음과 같은 방법으로 통계를 확인할 수 있습니다.

  • Google Cloud 콘솔을 사용합니다.
  • Google Cloud CLI 또는 Recommender API를 사용하여 하위 유형 K8S_ADMISSION_WEBHOOK_UNSAFE 및 K8S_ADMISSION_WEBHOOK_UNAVAILABLE으로 필터링하기

통계를 통해 웹훅을 식별한 후 안내에 따라 감지된 웹훅 문제를 해결합니다.

GKE에서 잘못 구성된 웹훅을 감지하는 경우

클러스터에 다음 기준 중 하나가 적용되면 GKE에서 통계와 추천을 생성합니다.

감지된 웹훅 문제 해결

다음 섹션에는 GKE가 잘못 구성되었을 수 있는 웹훅의 문제 해결을 위한 안내가 포함되어 있습니다.

안내를 구현하고 웹훅이 올바르게 구성되면 24시간 이내에 권장사항이 해소되어 더 이상 콘솔에 표시되지 않습니다.

권장사항을 구현하지 않으려면 닫기를 선택하세요.

사용 가능한 엔드포인트가 없다고 보고하는 웹훅

웹훅에서 사용 가능한 엔드포인트가 없다고 보고하는 경우 웹훅 엔드포인트를 지원하는 서비스에 실행되고 있지 않은 포드가 하나 이상 있습니다. 웹훅 엔드포인트를 사용하려면 다음 안내에 따라 이 웹훅 엔드포인트를 지원하는 서비스의 포드를 찾아 문제를 해결하세요.

  1. 통계 및 권장사항 보기를 통해 한 번에 한 통계씩 선택하여 문제를 해결합니다. GKE는 클러스터당 통계 하나를 생성하며 이 통계에는 조사해야 하는 손상된 엔드포인트가 있는 웹훅이 하나 이상 나열됩니다. 이러한 각 웹훅의 경우 통계에는 서비스 이름, 손상된 엔드포인트, 엔드포인트가 마지막으로 호출된 시간도 명시됩니다.

  2. 웹훅과 연결된 서비스의 제공 포드를 찾으세요.

    콘솔

    통계 사이드바 패널에서 잘못 구성된 웹훅 테이블을 확인합니다. 서비스 이름을 클릭합니다.

    kubectl

    다음 명령어를 실행하여 서비스를 설명합니다.

    kubectl describe svc SERVICE_NAME -n SERVICE_NAMESPACE

    SERVICE_NAME 및 SERVICE_NAMESPACE를 각각 서비스의 이름과 네임스페이스로 바꿉니다.

    웹훅에 나열된 서비스 이름을 찾을 수 없는 경우 구성에 나열된 이름과 서비스의 실제 이름 간의 불일치로 인해 사용할 수 없는 엔드포인트가 생길 수 있습니다. 엔드포인트 가용성을 수정하려면 웹훅 구성의 서비스 이름이 올바른 서비스 객체와 일치하도록 업데이트합니다.

  3. 이 서비스의 서빙 포드를 검사합니다.

    콘솔

    서비스 세부정보의 제공 포드에서 이 서비스를 지원하는 포드 목록을 확인하세요.

    kubectl

    배포 또는 포드를 나열하여 실행되고 있지 않은 포드를 식별합니다.

    kubectl get deployment -n SERVICE_NAMESPACE

    또는 다음 명령어를 실행합니다.

    kubectl get pods -n SERVICE_NAMESPACE -o wide

    실행되지 않고 있는 포드의 경우 포드 로그를 검사하여 포드가 실행되고 있지 않은 이유를 확인합니다. 포드의 일반적인 문제에 대한 안내는 배포된 워크로드 문제 해결을 참조하세요.

안전하지 않다고 간주되는 웹훅

웹훅이 시스템 관리 네임스페이스의 리소스 또는 특정 유형의 리소스를 가로채는 경우 GKE는 이를 안전하지 않은 것으로 간주하여 이들 리소스를 가로채지 않도록 웹훅을 업데이트하도록 권장합니다.

  1. 안내에 따라 통계와 추천을 보고 한 번에 통계를 하나씩 선택하여 문제를 해결합니다. GKE는 클러스터당 통계 하나만 생성하며 이 통계에는 각각 웹훅을 하나 이상 나열하는 웹훅 구성이 하나 이상 나열됩니다. 나열된 웹훅 구성마다 통계에는 구성이 신고된 이유가 명시됩니다.

  2. 웹훅 구성을 검사합니다.

    콘솔

    통계 사이드바 패널에서 테이블을 확인합니다. 각 행에는 웹훅 구성 이름과 이 구성이 신고된 이유가 표시됩니다.

    각 구성을 검사하려면 이름을 클릭하여 GKE 객체 브라우저 대시보드에서 이 구성으로 이동합니다.

    kubectl

    다음 kubectl 명령어를 실행하여 웹훅 구성을 가져오고 CONFIGURATION_NAME을 웹훅 구성 이름으로 바꿉니다.

    kubectl get validatingwebhookconfigurations CONFIGURATION_NAME -o yaml

    이 명령어에서 아무것도 반환하지 않으면 validatingwebhookconfigurations를 mutatingwebhookconfigurations로 바꿔 명령어를 다시 실행합니다.

    webhooks 섹션에 웹훅이 하나 이상 나열됩니다.

  3. 웹훅이 신고된 이유에 따라 구성을 수정합니다.

    kube-system 및 kube-node-lease 네임스페이스 제외

    scope가 *이면 웹훅이 신고됩니다. 또는 범위가 Namespaced이고 다음 조건 중 하나가 적용되면 웹훅이 신고됩니다.

    • 다음 예시와 같이 operator 조건은 NotIn이고 values는 kube-system과 kube-node-lease를 생략합니다.

      webhooks:
- admissionReviewVersions:
  ...
  namespaceSelector:
    matchExpressions:
    - key: kubernetes.io/metadata.name
      operator: NotIn
      values:
      - blue-system
  objectSelector: {}
  rules:
  - apiGroups:
    ...
    scope: '*'
  sideEffects: None
  timeoutSeconds: 3

      웹훅이 특정 네임스페이스에서만 작동하도록 scope가 *가 아닌 Namespaced로 설정되어 있는지 확인합니다. 또한 operator가 NotIn이면 values에 kube-system 및 kube-node-lease를 포함합니다(이 예시에서는 blue-system).

    • 다음 예시와 같이 operator 조건은 In이고 values는 kube-system과 kube-node-lease를 포함합니다.

      namespaceSelector:
    matchExpressions:
    - key: kubernetes.io/metadata.name
      operator: In
      values:
      - blue-system
      - kube-system
      - kube-node-lease

      웹훅이 특정 네임스페이스에서만 작동하도록 scope가 *가 아닌 Namespaced로 설정되어 있는지 확인합니다. operator가 In이면 values에 kube-system 및 kube-node-lease를 포함하지 마세요. 이 예시에서는 operator가 In이므로 blue-system만 values에 있어야 합니다.

    일치하는 리소스 제외

    웹훅은 다음 예시와 같이 리소스에 nodes, tokenreviews, subjectaccessreviews 또는 certificatesigningrequests가 나열된 경우에도 신고됩니다.

    - admissionReviewVersions:
...
  resources:
  - 'pods'
  - 'nodes'
  - 'tokenreviews'
  - 'subjectaccessreviews'
  - 'certificatesigningrequests'
  scope: '*'
sideEffects: None
timeoutSeconds: 3

    리소스 섹션에서 nodes, tokenreviews, subjectaccessreviews, certificatesigningrequests를 삭제하세요. resources에서 pods를 유지할 수 있습니다.

시스템에 중요한 구성요소를 차단하는 웹훅

ClusterRoles 및 ClusterRoleBindings를 생성하거나 업데이트하는 요청을 가로채는 웹훅은 이러한 중요한 시스템 리소스를 조정하는 컨트롤 플레인의 기능을 방해할 수 있습니다. 예를 들어 클러스터 업그레이드 중에 kube-apiserver가 시스템 역할을 업데이트해야 할 수 있습니다. 사용할 수 없거나 잘못 구성된 웹훅이 이 업데이트를 차단하면 kube-apiserver가 정상 상태가 되지 않아 클러스터 업그레이드가 차단됩니다.

GKE는 웹훅이 ClusterRoles 및 ClusterRoleBindings를 가로채는지 감지하지 않으므로 이 시나리오에 대한 통계가 생성되지 않습니다.

다음 예시에서는 ClusterRoles를 가로채는 문제가 있는 웹훅 구성을 보여줍니다.

-   admissionReviewVersions:
  ...
  resources:
  -   'clusterroles'
  -   'clusterrolebindings'
  scope: '*'
sideEffects: None
timeoutSeconds: 3

이러한 상황을 방지하려면 웹훅이 system: prefix 설정이 있는 ClusterRoles 및 ClusterRoleBindings 요청을 가로채지 않아야 합니다.

허용 교착 상태

웹훅이 실패 시 닫히도록 구성되면 클러스터가 자동으로 복구될 수 없는 상황이 발생할 수 있습니다. 예를 들어 클러스터의 모든 노드가 삭제되면 웹훅도 다운됩니다. 새 노드를 추가하려면 승인 유효성 검사가 필요하므로 웹훅을 사용하여 요청을 승인할 수 있어야 합니다. 이렇게 하면 클러스터의 컨트롤 플레인이 복구되지 않을 수 있는 순환 종속성이 생성됩니다.

GKE는 승인 교착 상태 시나리오를 감지하지 않으므로 이 시나리오에 대한 통계가 생성되지 않습니다. 하지만 웹훅 포드가 다운되면 허용 교착 상태가 발생할 수 있으며, 이 경우 GKE는 웹훅에 사용 가능한 엔드포인트가 없음을 감지하고 K8S_ADMISSION_WEBHOOK_UNAVAILABLE 통계를 생성합니다.

이 문제를 완화하려면 ValidatingWebhookConfiguration를 삭제하여 순환 종속성을 중단하고 클러스터가 복구되도록 하면 됩니다.

클러스터 컨트롤 플레인 가용성

웹훅이 fail closed로 구성되면 Kubernetes 컨트롤 플레인의 가용성이 웹훅의 가용성에 따라 달라집니다. 컨트롤 플레인의 가용성을 개선하려면 다음을 고려하세요.

GKE는 웹훅으로 인해 발생하는 클러스터 컨트롤 플레인 가용성 문제를 감지하지 않으므로 이 시나리오에 대한 유용한 정보가 생성되지 않습니다.

  • 웹훅의 범위 제한: 웹훅이 민감한 프로세스를 방해하지 않도록 웹훅에서 검증하지 않도록 중요한 리소스를 제외할 수 있습니다. 네임스페이스 또는 특정 종류의 리소스를 제외할 수 있습니다. 하지만 명확하지 않은 종속 항목에 주의하세요. 예를 들어 ConfigMap는 Kubernetes에서 리더 선출을 위한 중요한 리소스가 될 수 있습니다.

  • 웹훅 배포 강화: 여러 포드에서 웹훅을 실행하면 복원력과 가동시간이 증가할 수 있습니다. 노드 선택기를 사용하여 포드를 여러 장애 도메인에 분산할 수 있습니다.

다음 단계