쿠버네티스 CORE CONCEPT

 

ETCD란?

 

• key-value 형태로 데이터가 저장되는 storage
• HA(high availability) 구조에 특화되어 있으며, 3, 5, 7개 단위로 구성
• kubernetes의 모든 데이터는 여기에 저장 및 기록
• ETCD(database) 는 타 데이터 베이스와 다르게 Watch 기능을 제공
  • Watch란?
    • Server가 Watch하고 있는 데이터에 crud가 발생할 경우, DB가 Server에게 Notification을 제공

 

 

 

쿠버네티스 구조도 및 동작 원리

• kubectl은 Server N 에 존재해야 하고, kubeconfig를 물고 있어야 한다
• kubectl은 인증서를 읽어다가 API Server와 통신한다
• 마스터 컴포넌트는 api server, controller, scheduler , etcd를 디폴트로 갖으며 pod형태로 동작한다
• 각 노드에는 kubelet이라는 바이너리 형태의 쿠버네티스 리소스가 존재하며 , kube proxy, cri와 협업하여 pod를 생성하는 역할을 한다.

 

• pod 생성요청은 etcd에 저장
• 스케쥴러는 etcd를 watch하는 상태, etcd가 스케쥴러에게 노티를 준다
• 스케쥴러가 nodeName이 공란 이면 내부 알고리즘이 돌아서 어느 워커로 지정할지 계산 후 저장
• 각 kubelet은 api server와 통신해서 etcd를 watch한다
• worker1이 쓰였다면 kubelet은 cri와 협업하여 pod를 생성하고 상태를 api server와 통신하여 etcd에 저장한다
• pod의 상태정보를 주기적으로 전달한다.

 

 

Yaml이란?

• 타 시스템 간에 데이터를 주고 받을때 활용되는 데이터 포맷 중 하나
  • 그 외 데이터 포맷으로는 json, xml 등등..

 

명령어)

생성

kubectl apply -f myPod.yaml

 

삭제

kubectl delete -f myPod.yaml

 

조회

kubectl get pod

 

현재 정의되어 있는 pod의 status를 보여줌

kubectl describe pod my-nginx

 

수정

kubectl edit pod my-nginx

 

어떤 노드에 떳는지 확인

kubectl get po -o wide

 

 

Pod 요청시 내부 컴포넌트 동작 FLOW

 

Kubelet 역할 총 정리

• /etc/kubernetes/manifests 디렉토리를 주기적으로 read
  • pod형태의 yaml 파일 apply
• master mode의 api server에게 주기적으로 health check ping
• master node의 api server를 거쳐 etcd의 pod정보 watch
  • nodeName이 본인이면, pod를 생성
  • 이후 pod의 crud status는 계속 업데이트 된다

 

 

pod 생성 방식 2가지

1) /etc kubernetes /manifests 디렉토리에 Pod.yaml 생성

• kubelt이 주기적으로 읽어서 띄우는 pod
• static pod라고 부른다.
• edit명령어로 수정이 불가하다 (kubectl edit 명령어 불가)

2) kubectl apply f Pod.yaml

• api서버를 거쳐서 pod를 생성, 스케쥴러가 관여해서 nodename을 지정하고 kublet이 eted에 있는것을 watch해서 사용한다
• api를 거쳐서 배고한것이고 api를 통해서 수정이 가능하다

 

 

 

Api Server에서 ETCD 까지의 FLOW 

- pod.yaml이 날라가면 인증/인가를 완료하고 admmission control을 거쳐서 etcd에 떨어진다

 

 

 

Admission Control

mutating adminssion controllers

• 리소스의 yaml 데이터를 추가하거나 변경한다.
• 순차적으로 적용하여 최종 완료되면 object schema validation 으로 넘어간다

object schema validation

• 오브젝트 스키마 문법적으로 오류가 없고, 유효한지 체크하는 부분

validating adminssion controllers

• cpu, memory 리소스 제한 , 데이터 유효성 검사 관련 체크
• 이 부분이 완료된 후에 etcd로 꽂힌다.

 

 

 

노드할당

cpu 5인 core pod를 할당할때

• 노드 필터링 수행
• 가용 노드 중 여분 자원이 높은 곳일수록 우선순위가 높게 지정
• Node Selector (Node Affinity) 로 노드 직접 지정
• Taint Tolerance 기능 활용

 

 

Label과 Selector

• 이름은 my-nginx이고 label은 app=myapp, type=front-end
• kubernetes는 리소스들을 별도 식별자들로 필터링 및 그룹화 한다
• 라벨은 필터링 및 그룹화 기능 중 한가지

ex) kubectl get pods -l app=mypp, type=front-end

 

 

 

Service

정의

• 파드는 유동적으로 생성 삭제 될 수 있기 때문에 접속 정보가 고정되지 않음 이러한 파드에 안정적으로 접속 가능하도록 해주는 오브젝트
  • POD를 이어주는 매개체 역할을 담당
  • SELECTOR를 이용해서 접근가능하게끔 도와주는 객체

ClusterIP

• 파드 앞에 서비스오브젝트가 배치되고, 클러스터 아이피이다
• 파드처럼 내부 아이피를 갖고있다.

NodePort

• 외부에서 접근가능한 포트를 연다. 30000번대 포트
• 호스트 서버의 포트를 열어서 받을 수 있게 설정한 것이다

 

 

 

Kubernetes Controller

 

 

Replicaset

내가 생성한 pod에 장애가 발생해도 알아서 다시 생성되는 방법?

• controller 를 기반으로 pod를 관리하는 쿠버네티스 리소스
• 내부 pod의 개수 설정한 값 대로 pod를 관리하는 쿠버네티스 리소스

명령어)

myreplicaset.yaml 정의

kubectl apply -f myreplicaset.yaml

 

생성된 pod 강제 삭제

kubectl delete pod [podName]

 

의문점

replicaset은 이미지 정보를 바꾸면(base 이미지 업데이트) 띄워져있는 모든 pod가 동시다발적으로 내려가고 다시 올라온다.

무중단 서비스를 제공하는 방법은 없을까?

그래서 나온것이 Deployment 개념.

 

 

 

 

Deployment

• 이미지 업데이트 하는 순간에도 무중단 서비스를 제공하겠다.
• Rolling update 지원

• mydeployment.yaml 정의
• kubectl apply -f mydeployment.yaml
• deployment 확인
• replicaset 확인
• replicaset으로 생성된 pod확인
• 생성된 pod 강제 삭제
  • kubectl delete pod [podName]

 

 

 

Job

• 실행된 후에 종료해야 하는 성격의 작업을 실행하는 것
• 컨테이너를 구동하고 작업이 끝나면 컨테이너를 종료

 

Cronjob

• Job을 주기적으로 실행시키는 것을 목적
• Cronjob - job

 

 

Operator Pattern