Kubernetes 변이 수용 Webhook 구축

Pod 컨테이너에 파일을 주입하는 "신기하다" 방법

$ kubectl run busybox --image=busybox --restart=Never -it --rm -- ls -l /var/run/secrets/kubernetes.io/serviceaccount/token
# output
/var/run/secrets/kubernetes.io/serviceaccount/token

Webhooks 입력

Admission webhooks are HTTP callbacks that receive admission requests and do something with them. You can define two types of admission webhooks, validating admission webhook and mutating admission webhook. Mutating admission webhooks are invoked first, and can modify objects sent to the API server to enforce custom defaults

설치

웹 훅을 구축하기 위해 우리는 매우 간단한 Go API 서버를 사용할 것이다.우리의 웹hook 구현 코드에서 가장 중요한 부분은 실제 http 처리 프로그램입니다:

많은 Kubernetes 코드와 마찬가지로 위의 코드는 https://github.com/kubernetes/api과 https://github.com/kubernetes/apimachinery의 모델 유형을 사용합니다.코드가 실제로 만든 것은:

• Http에서
반서열화 요청 AdmissionReview 입력 json
• 읽기pod규범
• 은 우리의'hello configmap'을 원본으로
을 사용하여'hello volume'볼륨을 우리의Pod에 추가합니다
• 권선을 크레인 용기에 넣는다
• 은 돌연변이를 위해 JSON Patch을 구축합니다. 부피 변화, 부피 적재 변화를 포함하고 보상으로 용기에'helloadded=true'탭을 추가합니다.
• json 응답 구축, 저희가 요청한 변경 사항 포함

나는 또한 처리 프로그램 here에 단원/기능 테스트를 제공하여 예상한 기능을 완성할 수 있도록 하였다

A small complication: TLS

저희 웹hook API 서버는 TLS를 통해 웹hook에 서비스를 제공해야 합니다. Kubernetes 집단 내부에 설치하려면 인증서를 생성해야 합니다.내가 발견한 방법 중 하나는 New Relic의 작은 소프트웨어를 통해 웹 훅 인증서 생성을 처리할 수 있다는 것이다.I forked 환매 협의는 약간의 변경을 진행할 수 있고 작업 배치로 사용할 수 있다:

More YAML

webhook API 서버를 위한 용기 이미지를 구축하여 용기 저장소로 전송한 후, 우리는 배치를 사용하여 그것을 집단에 배치합니다

와 집단 서비스:

그리고 MutatingWebhookConfiguration을 만들고 Kubernetes API 서버에 웹 훅을 등록할 수 있습니다:

마지막 목록에서 Kubernetes는 이름 공간 (Mutating Webhook Configuration의 이름 공간을 배치합니다) 에서 탭'hello=true'와 일치하는 모든 Pod 생성 요청을 경로가'/mutate'인 서비스hello webhook 서비스로 보내도록 요구합니다.일치 라벨은 선택할 수 있습니다. 이 예에 포함하고 싶을 뿐입니다. 그러면 우리는 변이한 웹 훅을 돌아갈 수 있습니다

마지막 파일의 "clientConfig"부분에 docs에서 지정한 "caBundle"키가 왜 없는지 알고 싶다면, 우리가 이전에 정의한 웹 훅 인증서 설정 작업이 자동으로 이 키를 추가하기 때문입니다.

The Webhook in Action

우리의 프로젝트는 현재 집단에 배치할 준비가 되어 있습니다. Makefile과 Kustomize 기교만 사용하면:

$ make k8s-deploy
# output
kustomize build k8s/other | kubectl apply -f -
configmap/hello-configmap created
service/hello-webhook-service created
mutatingwebhookconfiguration.admissionregistration.k8s.io/hello-webhook.leclouddev.com created
kustomize build k8s/csr | kubectl apply -f -
serviceaccount/webhook-cert-sa created
clusterrole.rbac.authorization.k8s.io/webhook-cert-cluster-role created
clusterrolebinding.rbac.authorization.k8s.io/webhook-cert-cluster-role-binding created
job.batch/webhook-cert-setup created
Waiting for cert creation ...
kubectl certificate approve hello-webhook-service.default
certificatesigningrequest.certificates.k8s.io/hello-webhook-service.default approved
kustomize build k8s/csr | kubectl apply -f -
serviceaccount/webhook-cert-sa unchanged
clusterrole.rbac.authorization.k8s.io/webhook-cert-cluster-role unchanged
clusterrolebinding.rbac.authorization.k8s.io/webhook-cert-cluster-role-binding unchanged
job.batch/webhook-cert-setup unchanged
Waiting for cert creation ...
kubectl certificate approve hello-webhook-service.default
certificatesigningrequest.certificates.k8s.io/hello-webhook-service.default approved
(cd k8s/deployment && \
 kustomize edit set image CONTAINER\_IMAGE=quay.io/didil/hello-webhook:0.1.8)
kustomize build k8s/deployment | kubectl apply -f -
deployment.apps/hello-webhook-deployment created

간단한 busybox 이미지를 실행함으로써 우리의 목표 일치 탭인'hello=true'를 포함하여 우리의 변이 웹훅이 이 점에서 유효한지 봅시다.

$ kubectl run busybox-1 --image=busybox --restart=Never -l=app=busybox,hello=true -- sleep 3600

이 파일이 용기 파일 시스템에 존재하는지 봅시다:

$ kubectl exec busybox-1 -it -- sh -c "ls /etc/config/hello.txt"
# output
/etc/config/hello.txt

내용 좀 봅시다:

$ kubectl exec busybox-1 -it -- sh -c "cat /etc/config/hello.txt"

이제 두 번째 특수 탭'hello=true'가 없는pod를 만듭니다.

$ kubectl run busybox-2 --image=busybox --restart=Never -l=app=busybox -- sleep 3600
# output
pod/busybox-2 created
$ kubectl exec busybox-2 -it -- sh -c "ls /etc/config/hello.txt"
# output
ls: /etc/config/hello.txt: No such file or directory

예상대로 이 파일은 웹 훅의 탭 선택기와 일치하는busybox-1 용기에만 추가됩니다.busybox-2에 추가되지 않습니다

우리의 보너스 라벨'helloadded'는 busybox-1을 위한 것이지,busybox-2를 위한 것이 아니다:

$ kubectl get pod -l=app=busybox -L=hello-added
# output
NAME READY STATUS RESTARTS AGE HELLO-ADDED
busybox-1 1/1 Running 0 3m7s OK
busybox-2 1/1 Running 0 53s

우리의 변이 웹훅 유효!🎉🦄🎊

Conclusion

변이 접근 웹훅을 통해 Kubernetes를 확장하는 첫 번째 방법을 탐색했습니다.검증이 Webhook에 접근할 수 있음을 언급하지 않았지만, 자원에 대한 고급 검증(OpenAPI schemas이 허용하는 범위를 초과)이 필요하다면, Webhook

나는 이 문장이 당신의 쿠베르니토스 여행에 유용하길 바랍니다. 만약 당신에게 어떤 문제나 의견이 있으면 저에게 알려주세요.반드시 관심을 가지십시오: 다음 글에서 우리는 Kubernetes Operator