사용하면서 혼돈이 많이 생기는 부분이다 이게 GCE나 EC2를 쓰면 용어 매칭이 쉬운데 k8s를 위한 별도의 메뉴가 아닌 기능을 통합하다보니 용어가 조금 혼동스럽게 구성이 되었다.
특히 Load Balancer 부분은 Service로 매핑되고 퍼블릭 k8s에서 제공하는 Type LoadBalancer는 미지원한다.
그리고 모든 Resource들은 Deploy, Delete, Scale, Rollout(Undo, Pause, Resume)을 지원하며 Versioning이 지원된다. Versioning은 여기에 설명된 대로 strategy.spinnaker.io/versioned annotation을 통해 manifest별로 재정의가 가능하다.
Spinnaker Server Group으로 분류 된 항목은 모두 Spinnaker의 클러스터 탭에 표시가 된다. 가능한 경우 모든 포드가 표기되지만, 해당 Workloads 이외의 CRD(Custom Resource Definition)는 halconfig에서 아래와 같이 customResources config를 추가하면 deploy는 가능하나 Spinnaker UI에서 보이지는 않는다.
Jenkins와 연동하면서 가장 어이없이 헤맨부분은 아래 그림처럼 되어있어야 하는데 Security Realm을 Jenkins Default admin 계정만을 가지고 integration 하려다가 계속 실패하였다. Delegate to servlet container 말고 Jenkins 자체 사용자 DB로 별도 계정을 생성하고 아래 그림처럼 설정을 해야한다.
위 설정 이후 아래와 같이 Spinnaker UI에서 Jenkins API연동이 가능하다.
오늘은 여기까지만 하고 다음글에서는 배포전략이나 Network Policy 연동등을 상세히 적어볼 예정이다.
Kubernetes(이하 k8s)기반 개발 과제를 수행하다보니 Custom Resource를 사용할수 밖에 없는 상황들이 발생하였다.
그런 와중에 istio와 같은 Service Mesh Layer를 리서치하던 중에 튀어나온 MutatingAdmissionWebhook 용어를 이해하기 위에 조사한 내용을 정리해본다.
$ kubectl create -f deployment/nginxconfigmap.yaml kubectl create -f deployment/configmap.yaml kubectl create -f deployment/deployment.yaml kubectl create -f deployment/service.yaml kubectl create -f deployment/mutatingwebhook-ca-bundle.yaml configmap "nginx-configmap" created configmap "sidecar-injector-webhook-configmap" created deployment.extensions "sidecar-injector-webhook-deployment" created service "sidecar-injector-webhook-svc" created mutatingwebhookconfiguration.admissionregistration.k8s.io "sidecar-injector-webhook-cfg" created
webhook deployment 확인
$ kubectl get pods NAME READY STATUS RESTARTS AGE sidecar-injector-webhook-deployment-796955558f-js6bb 1/1 Running 0 3m $ kubectl get deployment NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE sidecar-injector-webhook-deployment 1 1 1 1 3m
default 네임스페이스에 sidecar-injector 라벨링을 한다. 이렇게 하면 해당 네임스페이스에 생성되는 모든 app에 자동으로 injection하게 됨
$ kubectl get namespace -L sidecar-injector NAME STATUS AGE SIDECAR-INJECTOR agones-system Active 1d default Active 19d enabled ibm-cert-store Active 19d ibm-system Active 19d ingress-test Active 6d kube-public Active 19d kube-system Active 19d spinnaker Active 12d xonotic Active 1d
결국 위에서 언급한것 처럼 MutationWebhook은 istio RouteRule같은 별도의 CustomResource등을 injection 하거나 agones 등과 같이 게임서버외에 client sdk 통신을 위한 injection 형태로 기존 resource에 추가적인 변경(mutation) 또는 검증(validation)등의 추가적인 작업을 kube-api의 컴파일없이 가능하다는데 목적이 있다고 볼 수 있다. 추가적으로 기능에 대한 내용은 이후 다시 정리해볼 예정이다.