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

예, 자세한 정보는 Kubernetes 및 Red Hat OpenShift 문서를 참조하십시오.

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초로 줄이는 것을 고려하십시오. OpenShift 클러스터의 경우, 제어 플레인 컴포넌트에는 종종 13초의 자체 제한시간이 있습니다.

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

• 웹훅에 대해 적절한 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

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

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

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