내 클러스터의 기본 승인 제어기는 무엇입니까?

kube-apiserver 컴포넌트 참조 정보에서 클러스터 버전별 기본 허가 제어기의 순서를 검토하십시오.

승인 제어기를 직접 작성할 수 있습니까?

예, 자세한 내용은 Kubernetes 문서를 참조하세요.

Kubernetes 문서에 기록되어 있는 바와 같이, 제어 플레인에 의해 처리되는 오퍼레이션에 허가 제어기를 사용할 수 있습니다. 사용자 정의 허가 제어기를 구성할 때는 주의하십시오. 사용자 정의 허가 제어기로 인해 클러스터에서 발생하는 변경사항은 모두 사용자의 책임입니다.

웹훅 사용에 대한 우수 사례는 무엇입니까?

가능한 한 웹훅 사용을 피하십시오. 대신 및 MutatingAdmissionPolicy (기본적으로 ValidatingAdmissionPolicy 활성화된 경우)를 대안으로 사용하십시오.

웹훅을 사용해야 하는 경우, 웹훅을 구성할 때 다음 모범 사례와 고려 사항을 염두에 두십시오.

• 뮤팅 웹훅을 사용하여 다른 컨트롤러 또는 운영자가 소유한 리소스를 뮤팅하지 마세요. 이렇게 하면 리소스 소유자와 웹훅 사이에 무한 재조정 루프가 발생할 수 있습니다. 웹훅은 리소스 데이터에 metadata.ownerReferences 이 설정되어 있는지 확인하여 리소스 소유권을 확인할 수 있습니다. 예를 들어, Kubernetes 리플리카셋 리소스는 Kubernetes 배포 리소스에 의해 소유되며 웹훅으로 절대 변경되어서는 안 된다.

• 한 팟(Pod)이 작동을 중지해도 웹훅이 리소스의 요청을 계속해서 처리할 수 있도록 복제본 팟(Pod)을 작성하십시오. 가능한 경우에는 구역 전체에 복제본 팟(Pod)을 분산시키십시오.

• 웹훅이 실패하거나 연결 실패 또는 제한시간 초과를 무시하는지 여부와 같은 적절한 failurePolicy 옵션을 설정하십시오. 웹훅이 제한시간 초과 시 연결 오류를 무시하도록 하려면 failurePolicy 를 Ignore 로 설정할 수 있습니다. 이는 웹훅이 요청을 거부하는 경우 apiserver 의 작동 방식을 변경하지 않습니다.

• timeoutSeconds 간격을 검토하십시오. v1beta1.admissionregistration.k8s.io API를 사용하는 이전 웹훅의 기본 제한시간은 30초입니다. v1 API는 기본값 10초를 사용합니다. 웹훅 실패 정책이 무시이고 현재 timeoutSeconds 가 30인 경우 제한시간을 10초로 줄이는 것을 고려하십시오.

  동일한 리소스에 대해 여러 개의 변형 웹훅이 동시에 작동하도록 허용하지 마십시오. 변형된 웹훅은 순차적으로 실행됩니다. 단일 변경 웹훅은 타임아웃 및 실패 정책 관점에서 예상대로 작동할 수 있지만, 동일한 리소스에 대해 작동하는 추가 변경 웹훅과 결합될 경우, 변경 웹훅들이 모든 웹훅 실행에 할당된 총 컨텍스트 타임아웃을 초과할 수 있습니다.

• 웹훅에 대해 적절한 CPU 및 메모리 리소스 요청 및 한계를 설정하십시오.

• 웹훅 컨테이너가 실행 중이고 요청을 처리할 준비가 되었는지 확인하는 데 도움이 되는 활성 및 준비 상태 프로브를 추가하세요.

• 가능한 경우 웹훅 팟(Pod)이 서로 다른 작업자 노드 및 구역에서 실행되도록 하기 위해 팟(Pod) 반친화성 스케줄링 규칙을 설정합니다. 대신 팟(Pod)토폴로지 를 사용할 수 있습니다. 그러나 웹훅 파드를 예약할 수 있는 위치를 제한할 수 있는 오염이나 강제 선호도는 피하세요.

• 다른 팟(Pod)이 웹훅 팟(Pod)으로부터 리소스를 가져갈 수 없도록 팟(Pod) 우선순위 설정을 system-cluster-critical로 설정하십시오.

• 적절한 네임스페이스로 웹훅 범위를 지정합니다. kube-system, ibm-system, ibm-operators, calico-apiserver, calico-system, tigera-operator, openshift-* 네임스페이스와 같이 클러스터에 기본적으로 설정된 시스템 크리티컬 네임스페이스에서 실행되는 리소스를 처리하는 웹훅을 사용하지 마세요.

• namespaceSelector 옵션을 검토하십시오. 특정 중요한 네임스페이스 (예: kube-system) 에 레이블을 추가할 수 있으므로 이러한 경우에는 웹훅이 호출되지 않습니다. 이 설정을 "옵트 아웃" 스타일 구성이라고 합니다. 또는 특정 레이블이 있는 네임스페이스에 대해서만 웹훅이 호출되도록 namespaceSelector 옵션을 구성할 수 있습니다. 이 설정을 "옵트 인" 구성이라고 합니다. 웹훅의 용도에 따라 모든 네임스페이스에 대해 웹훅을 호출하는 것이 중요할 수 있습니다. Kubernetes 문서 에서 namespaceSelector 구성 옵션을 검토하고 웹훅 구성을 조정하십시오.

• 클러스터의 워커 노드가 웹훅 애플리케이션을 실행하기에 적합한 크기인지 확인하세요. 예를 들어, 팟(Pod)이 작업자 노드가 제공할 수 있는 것보다 더 많은 CPU 또는 메모리를 요청하는 경우에는 해당 팟(Pod)이 스케줄되지 않습니다.

허가 제어기를 사용하는 다른 앱 유형에는 어떤 것이 있습니까?

많은 클러스터 추가 기능, 플러그인, 기타 서드파티 확장이 허가 제어기를 사용합니다. 흔한 예를 몇 가지 들면 다음과 같습니다.

• Portieris
• Istio

clientConfig:
   caBundle: #CA_BUNDLE_BASE64#
   service:
      name: admission-webhook
      namespace: default
      path: /validate
      port: 443

clientConfig:
   caBundle: #CA_BUNDLE_BASE64#
   url: https://#WEBHOOK_URL#:443/validate

실행이 중단된 웹훅에 대한 도움이 필요합니다. 어떻게 해야 합니까?

웹훅 문제점 해결에 대한 도움말을 보려면 웹훅 디버깅 또는 중단된 웹훅으로 인해 클러스터가 업데이트할 수 없음 을 참조하십시오.