[Kubernetes] CRD, Controller

 

 

 

YAML 쓸 때 항상 kind: 로 이게 쿠버의 무슨 리소스를 지정하는지 명시하는데 Custom Resource Definition을 사용하면 쿠버에 새로운 kind를 등록할 수 있다. 

 

HTML 처음 배울 때 <span> 이런거 말고 나만의 태그를 만들수는 없나 생각했었고 WEb Components가 그걸 가능하게 해줬는데 쿠버에서는 CRD를 통해 구현할 수 있음. 

 

kind: Database    
metadata:
  name: my-db
spec:
  engine: postgres
  version: "15"
  storage: 10Gi

 

 

이렇게 설정해주면 쿠버의 API가 확장되니 kubectl으로 k get databases 같은 명령어를 실행할 수 있게 된다. 

 

CRD만 만들면 아무 일도 안 일어난다. 그냥 데이터 형식을 정의한거니까.. 

실제로 일할 컨트롤러를 만들어주자. 이 컨트롤러 역할은 Operator가 수행한다. 

 

kind: Database 같은 리소스가 생기는지 감시하고 생겨났다면 명세에 정의된대로 postgres Pod Service PVC를 만들어준다.

 

사실 Deployment, ReplicaSet, Pod 의 관계랑 똑같음.

kind: Database를 만들면 Operator가 그걸 보고 Pod Service PVC 만들고 문제 생기면 복구함. 

 

Operator를 실제로 구현할 필요는 없고 이미 설치된 CRD를 잘 다룰 수 있으면 된다. 

 

k get crd                          # 클러스터에 등록된 CRD 목록
k describe crd <이름>               # 그 CRD의 스펙 확인
k api-resources                    # 사용 가능한 모든 리소스 종류 (CRD 포함)
k get <커스텀리소스>                 # 커스텀 리소스 조회

 

 

 

DB 백업, 장애 복구, 버전 업그레이드 같은 서비스 운영을 코드로 자동화하는게 Operator의 목적이다. 

추상화가 목적임. Helm은 만들어주고 끝이지만 Operator는 계속 모니터링해서 감시해준다. 

단순 설치는 Helm으로 하고 운영이 복잡한 시스템에서는 Operator를 사용한다. 

 

 

 

---

 

 

 

Pod를 관리하는 세 가지 컨트롤러는 이미지로 정리 

 

 

 

 

 

 

 

---

 

 

 

kubeconfig에는 kubectl이 어떤 클러스터에 어떤 자격으로 접속할지를 저장한다.

~/.kube/config 에는 어떤 클러스터가 있는지, 어떤 자격증명이 있는지를 저장함.

 

k config get-contexts              # 컨텍스트 목록 (현재 것은 * 표시)
k config current-context           # 지금 어느 컨텍스트?
k config use-context <이름>         # 컨텍스트 전환
k config set-context --current --namespace=<ns>   # 현재 컨텍스트의 기본 namespace 변경

 

 

k config use-conext 명령어로 접속할 클러스터를 미리 정하고 접근해야 함.