Passwd

Operator Framework Custom Resource Definition(사용자 정의 리소스 정의, CRD)와 Cutom Resource를 관리하는 Custom Controller(사용자 정의 컨트롤러)는 별개의 객체이다. 또한, Custom Resource를 사용하기 위해서는 CRD와 Custom Controller를 수동으로 생성 및 배포해야 한다. Operator Framwork는 이 두 개의 객체를 단일 객체로 배포할 수 있도록 패키징 한 것이다. 즉, Operator를 배포함으로써 내부적으로 CRD 및 리소스를 생성하고 Controller를 Deployment로 배포할 수 있다. Operator와 관련된 정보는 아래 hub에서 찾을 수 있다. https://operatorhub.io/ ..

Controllers는 ETCD에 저장된 객체의 상태를 모니터링하고, 객체를 생성/수정/삭제한다. 또한, 반복해서 동작하는 프로세스 또는 코드이며 지속적으로 쿠버네티스 클러스터를 모니터링하면서 특정 객체의 이벤트를 감지한다. 그중 Custom Controllers는 사용자 정의 리소스(Custom Resources)를 관리하는 컨트롤러에 해당한다. Custom Controllers 코드 작성은 필요하지만, 인증과 같은 공통 태스크 처리를 구현한 클라이언트 라이브러리를 사용하면 되기 때문에 API 호출 맟 요청/응답을 직접 구현할 필요는 없다. 클라이언트 라이브러리 https://kubernetes.io/ko/docs/reference/using-api/client-libraries/ 구축 방법 1. 개발..

Resources Kubernetes는 pod, deployment와 같은 리소스를 생성하고, 해당 정보는 ETCD에 저장한다. 즉, 리소스를 생성하고 삭제하는 작업은 ETCD에 리소스를 생성하고 삭제하는 것과 동일하다. Controllers 실질적으로 Resource 생성 및 관리를 수행하는 주체로, Deployment 리소스를 관리하는 Controller는 Deployment Controller에 해당한다. 백그라운드로 실행되는 프로세스이며, 관리하는 리소스를 지속적으로 모니터링하며 설정 정의된 상태를 유지한다. Controller는 GO로 개발되어, Kubernetes에 기본 내장되어 있어 별도로 생성할 필요가 없다. Custom Resources Kubernetes 기본 리소스 외의 사용자 정의 ..

하나의 API Group은 여러 개의 API Version을 지원한다. 그렇다면 여러 버전을 지원해야 하는 이유는 무엇이며, 몇 가지 버전을 지원해야 하는가? 더 이상 사용하지 않는 오래된 버전은 어느 시점에 제거할 수 있는가? 이 글에서는 위와 같은 부분을 위한 Kubernetes API Deprecations(지원 중단 정책)에 대해 정리한다. Deprecations 정책 1. API 요소는 API Group의 버전을 증가시키는 방법으로만 제거할 수 있다. 즉, v1alphav1의 요소는 v1alphav2 이상의 버전에서 삭제할 수 있다. 2. API 개체는 일부 버전에 존재하지 않는 전체 REST 리소스를 제외하고, 특정 릴리스의 API 버전 간에 정보 손실 없이 변경할 수 있어야 한다. 즉, v1..

각 API Group의 버전은 크게 세 가지 버전이 존재하며 그 종류는 아래와 같다. 버전 /v1alpha1 : alpha 개발 후 Kubernetes에 처음으로 release 된 API다. 테스트 부족으로 치명적인 버그가 존재할 수 있다. 예고 없이 삭제될 수 있으며 이후 release에서 사용할 수 있다는 보장 자체가 없다. 기본적으로 활성화되지 않아 사용을 위해서는 내부적으로 활성화가 필요하다. API Group 테스트 및 피드백에 관심이 있는 사용자를 위한 API다. /v1beta1 : beta alpha 버전의 주요 버그 수정 및 end to end 테스트가 완료된 API 버전이다. /v1으로 이동될 가능성이 존재해 기본적으로 활성화되어 있으나, 마이너한 버그는 여전히 존재할 수 있기 때문에 피..

Validating Admission Controller 요청을 검증하는 검증 승인 컨트롤러 예시 ) NamespaceExist NamespaceLifecycle 요청 내용의 네임스페이스가 존재하는지 확인하고 없으면 요청을 거부한다. Mutating Admission Controller 요청 수행 전에 요청 내용을 변경할 수 있다. 예시 ) DefaultStorageClass : 기본 활성화 플러그인으로, PVC 생성 요청을 확인하여 PVC에 StorageClass 설정이 존재하는지 확인한다. StorageClass 설정이 없는 경우, default StorageClass로 구성하도록 StorageClasss 설정을 수정한다. Admission Controller는 요청을 검증하는 Validating a..

kube-apiserver에 요청이 도착하면, 요청을 수행하고 그 정보를 ETCD database에 저장된다. 요청을 수행하기 전에는 인증 과정(Authentication)이 필요하다. kubectl을 통해 요청이 전송되었다면 인증서가 구성된 kubeconfig 파일의 정보를 이용해 사용자를 식별하고, 유효한 사용자인지 확인한다. 인증 과정 후에는 사용자가 요청한 작업을 수행할 수 있는 권한이 있는지 확인하는 권한 부여 과정(Authorizaition)을 거치며, 이 과정에는 보통 역할 기반 접근 제어(RBAC)를 사용한다. RBAC 여러 개체의 제어를 허용하거나 거부하는 역할을 사용자에게 부여하여 접근을 제한하는 방법이다. 특정 리소스(resourceName)만을 허용하거나 특정 네임스페이스의 접근만을..

Namespace Scope Resource Role과 RoleBinding 객체는 namespace 내에 생성되어 해당 namespace 내 자원에 대한 접근만을 제어한다. 생성 시 namespace를 지정하지 않으면 default namespace에 생성된다. namespace 내에 생성되는 자원은 Role, RoleBinding 외에도 Pod, ReplicaSet, Deployment, Job, Service, Secret 등이 존재하여, 그 외 해당되는 자원은 아래 명령어로 확인할 수 있다. Namespace Scope Resource 확인 kubectl api-resources --namespaced=true Cluster Scope Resource 특정 namespace에 한정되지 않는 clu..

Role Based Access Control을 사용하기 위해서는 권한 집합을 정의한 role과 user의 role을 정의하는 roleBinding을 생성해야 한다. Role Role을 정의하는 yaml 형식의 파일은 아래와 같으며, create 명령으로 생성할 수 있다. 하나의 Role은 여러 규칙을 가질 수 있으며, 하나의 규칙은 접근을 허용할 apiGroup과 resources, 그리고 자원에 허용할 작업을 나타내는 verbs으로 이루어져 있다. apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: name: developer rules: - apiGroups: [""] resources: ["pods"] # 권한을 부여할 자원 verbs: ..

Authorization 사용자가 클러스터에 접근하여 할 수 있는 것을 정의한다. 예시 ) 관리자 : Pod, Node, Deployment와 같은 객체 확인/생성/삭제 개발자 : 클러스터 구성 수정 제한, 애플리케이션 Deployment 접근 허용 Service Account : 외부 애플리케이션 접근 허용 여러 조직 또는 팀과 클러스터 공유 시, 클러스터를 네임스페이스로 분리하여 접근 통제 권한 부여 메커니즘 Node authorization kubelet은 apiserver에 접근하여 service, endpoint, node, pod의 정보를 읽거나 node 상태와 같은 정보를 apiserver에 전달한다. 이러한 요청은 node authorizer에 의해 처리되며, 사용자 이름이 system:n..