[CKA] Kubernetes Core Concepts

Cluster Architecture

Master Node

• 관리, 계획, 스케쥴, 모니터링 노드

Worker Node

• 컨테이너에서 실제 애플리케이션을 실행하는 노드

ectd

• key-value 형태로 정보를 저장하는 데이터베이스
• 단순하고 안전하며 신뢰형의 분산형 key-value 데이터베이스

./ectdctl set key1 value1 # key, value 저장
./ectdctl get key1 # key1 데이터 검색
./etcdctl # man page

• kubectl get 명령어를 통해 보이는 모든 정보는 etcd 서버에서 가져오는 것이다.

Setup kubeadm

• 네임스페이스로 구분지은 pod 대한 정보 호출

kubectl get pods -n kube-system # kube-system namespace의 pods 호출

• 쿠버네티스에 저장된 모든 키 리스트업

kubectl exec etcd-master -n kube-system etcdctl get / --prefix -keys-only

Kube-API Server

1. Authenticate User
   1. 유효한 인증인지 확인
2. Validate Request
   1. 유효한 요청인지 확인
3. Retrieve data
   1. ETCD에 데이터를 검색
4. Update ETCD
   1. ETCD 데이터 업데이트
5. Scheduler
   1. kube-api server → 워커 노드의 kubelet과 통신하며 적절한 worker node에 배치
   2. kubelet → create pod on the node
   3. 완료되면, kubelet → 완료된 상태를 API 서버에 호출하며 업데이트 → API 서버는 ETCD Cluster에 데이터 업데이트
6. Kubelet

Kube Controller manager

쿠버네티스에서 kube controller manager는 많은 것을 관리한다. 컨트롤러는 모니터링하고 필요한 액션을 취한다.

컨트롤러는 지속적으로 다양한 컴포넌트들의 상태를 모니터링하고 전체 시스템을 원하는 작동 상태로 만들기 위해 동작한다.

즉, 다음과 같은 역할을 수행한다.

• Watch Status
• Remediate Situation
• Node Monitor Period = 5s
  • kube-api server와 통신하며 5초 주기로 노트의 상태를 체크
• Node Monitor Grace Period = 40s
• POD Eviction Timeout = 5m

Kube Scheduler

스케쥴러는 pod와 node를 결정하는 역할을 한다. 주의해야할 점은 스케쥴러가 실제로 node 위에 pod를 구성하는 것은 아니다. 그 역할은 kubelet이 수행한다.

스케쥴러는 pod가 어디로 가는지만 결정한다.

스케쥴러가 왜 필요할까?

• 화물선이나 컨테이너가 많은 상황을 가정했을 때, 올바른 컨테이너가 올바른 화물선 위에 위치하는지를 확인하고 싶을 것이다. 화물선마다 용량, 남은 용량 등이 모두 다를 것이기 때문이다.

어떻게?

• 스케쥴러는 포드에 가장 적합한 노드를 식별하기 위해 두 단계를 거친다.
• 첫번째로, 스케쥴러는 포드의 프로필이 맞지 않는 노드를 필터링한다.
  • e.g) CPU: 10 이필요한데 이보다 작은 클러스터에 넣을 수는 없지 않은가
• 이제 스케쥴러는 최적 맞춤을 식별하기 위해 노드의 순위를 매긴다.
  • 스케쥴러는 배치 후 노드에서 사용 가능한 리소스의 양을 계산한다.
  • e.g) 10이 필요한데 한 노드는 12, 한 노드는 16의 용량을 적재할 수 있다면 배치 후에는 2, 6의 잔여량이 남는다. 6이 남는 두번째 노드가 더 높은 랭킹이 매겨진다.
• 물론 스케쥴러는 커스터마이징이 가능하고, 직접 작성할 수도 있다.

Kubelet

• 화물선의 선장역할을 한다. 모든 활동을 리드한다.
• Register Node
• Create PODs
• Monitor Node & PODs

다른 컴포넌트와의 차이점

kubeatm을 사용하여 클러스터를 배포하더라도 kubelet은 자동으로 배포되지 않는다. 이것이 다른 컴포넌트와의 차이점이다.

kubelet은 항상 수동으로 워커 노드에 설치해주어야한다.

Kube Proxy

쿠버네티스의 클러스터 내부에서 모든 pod는 다른 pod와 통신할 수 있다. 이는 pod 네트워킹 솔루션을 클로스터에 배포함으로써 달성된다.

pod 네트워크는 모든 pod가 연결되는 클러스터의 모든 노드에 걸쳐 있는 내부 가상 네트워크이다. 이를 통해 네트워크는 다른 pod와 통신을 할 수 있게 된다.

첫번째 node에 web app을 배포하고, 두번째 node에 데이터베이스 애플리케이션을 배포한 경우, 웹앱은 데이터베이스 pod의 IP 주소를 사용함으로써 간단하게 데이터베이스에 접근할 수 있다.

이를 위한 더 좋은 방법이 바로 service이다. 서비스를 생성하여 데이터베이스 애플리케이션과 클러스터를 연결할 수 있다.

how?

그래서 서비스가 무엇이고, 어떻게 IP를 얻는데?

• 서비스는 실제 존재하는 것이 아니기 때문에 포드 네트워크에 합류할 수 없다. 서비스는 메모리로 존재하는 가상 요소이다. 그리고 클러스터 전체에서 서비스에 엑세스 할 수 있어야한다.
• 이것이 바로 kube-proxy가 필요한 이유이다.
• kube-proxy는 쿠버네티스 클러스터의 각 노드에서 실행되는 프로세스이다.
  • 이 역할은 새로운 서비스를 찾는 것이며, 새 서비스가 생성될 때마다 각 노드에 적절한 규칙을 생성하여 해당 서비스에 대한 트래픽을 백엔드 pod로 전달한다.

ReplicaSets

어플리케이션이 있다고 하자. 이 어플리케이션이 만약 어떤 이유로 인해서 충돌이 발생하거나 pod가 fail이 발생했다면 어플리케이션을 사용하는 유저는 더이상 어플리케이션에 접근할 수 없게 된다.

이러한 일을 예방하기 위해서 동시에 여러개의 pod를 띄운다. 이렇게 하면 pod 하나에서 문제가 발생하더라도 다른 pod로 여전히 사용자는 접근할 수 있기 때문이다.

• replication controller는 쿠버네티스 클러스터에서 single pod instance를 여러개 띄울 수 있게 도와주는 컨트롤러다.
• replication contoller는 지정된 수만큼의 pod가 항상 실행되고 있는지를 확인한다.
• replication controller는 load balancing과 scaling도 기능도 담당한다.

Replication Controller ? Replica Set?

위의 두가지 개념에 대해서 혼선이 발생하지 않도록 하자.

공통점

• 같은 목적을 가지고 있다.

차이점

Replication Controller

• replica set로 기술이 교체되기 전의 기술

replica set

• 최근 replication을 생성할 때 추천되는 방식
• 리소스를 모니터링하고, 문제가 발생하였을 때 새로운 리소스를 배포하기 위해 사용
• selector 에 대한 정의가 필요하다.
  • selector: replicaSet가 하위에 속하는 파드를 식별하는데 도움이 된다.
  • 그렇다면 하위에 있는 pod를 식별해야하는 이유는 무엇일까?
    • 생성되지 않은 부분도 관리할 수 있기 때문
  • 상위에 정의안 Lable 값을 입력해주어야 한다.

Labels and Selector

그럼 쿠버네티스에서는 label과 selector를 왜 사용할까?

• 이미 생성된 인스턴스가 존재할 경우 기존 인스턴스를 모니터링 하는데 사용할 수 있다.
• label을 생성하면 아주 많은 리소스가 생성되었을 때, 그리고 리소스가 front-end, back-end, database 등 여러개로 나뉘어져있을 때 front-end와 관련된 리소스를 손쉽게 필터링하여 모니터링 할 수 있다.

Scaling

스케일링 하는 방법은 여러가지 방법이 있다.

1. yaml file의 replicas 수를 변경한다.
2. kubectl scale 커맨드를 사용한다.
   1. e.g) kubectl scale —replicas=6 -f replicaset-definition.yaml
   2. kubectl scale —replicas=6 replicaset myapp-replicaset
      1. kubectl scale —replicas=갯수 replicaset meta data name
   • 이 방식을 사용할 경우 yaml 파일의 replicas 갯수는 자동으로 업데이트 되지 않는다는 점을 주의해야한다.

Deployments

• 배포시 사용
• yaml file 구성은 replicaset과 비슷하며 kind 다름
• 다른것보다 create 명령어 사용하여 한줄로 간단한 yaml file 사용할 수 있는게 매력적이더라.

Service

서비스는 애플리케이션을 다른 애플리케이션 또는 사용자와 연결하는데 도움이 된다. 따라서 MSA에서 느슨한 결합을 가능하게 한다.

NodePort

• 서비스가 노드의 포트에서 내부 pod에 접근할 수 있도록 한다.
• target port: 실제 웹 서버가 동작하는 포트. 서비스가 요청을 80 포트로 전달하기 때문에 타겟 포트.
• port(서비스 자신의 포트)
• node port: 외부에서 웹서버에 액세스하는데 사용하는 노드 자체의 포트 30000~32767 범위에서 가짐.

ClusterIP

• 클러스터 내부에 가상 IP를 생성하여 프론트엔드, 백엔드 서버가 상호 통신을 할 수 있게 해준다.

LoadBalancer

• 클라우드 서비스에대한 로드밸런서를 프로비저닝 하는 경우

Namespaces

• 네임스페이스로 각 환경을 구분지을 수 있다.
• 네임스페이스별로 자원을 각각 할당할 수 있다.
• 네임스페이스 내에서 리소스들은 이름으로 호출할 수 있다.
• 다른 네임스페이스 접근시 다음과 같은 규칙이 있다.
  • servicename.namespacename.svc.cluster.local
    • cluster.local → default domain name of kubernetes cluster
    • svc → subdomain for service

Command

• namespace에 따른 pod status 확인

kubectl get pods --namespace=kube-system

• pod 생성시 default 아닌 name space 지정하여 생성

kubectl create(apply) -f pod-definition.yaml --namespace=dev

• yaml file의 metadata의 하위 항목으로도 생성할 수 있다.
  • 이 방법은 리소스가 항상 동일한 네임스페이스에 생성되기 때문에 좋은 방법이다.

metadata:
  name: myapp-pod
  namespace: dev

Namespace 생성

yaml file

• 다른 객체와 마찬가지로 yaml file 구성

apiVersion: v1
kin: namespace
metadata:
  name: dev

• apply 명령어로 yaml file 적용시켜주기

Command line

kubectl create namesapce dev

Namespace 변경 - context switch

• context switch. 즉, kubectl get pods를 했을 때, default가 아닌 다른 네임스페이스의 status를 default로 보고싶을 때 사용. —namespace 옵션을 주지 않고.

kubectl config set-context $(kubectl config current-context) --namespace=dev

Kubectl apply

내부적으로 어떻게 동작할까?

• apply 커맨드는 로컬 config 파일인 life 객체 정의를 고려한다.
• 따라서 명령어 실행 단계에서 객체가 존재하지 않는다면 객체를 생성한다.
• apply 명령어를 사용하여 객체를 생성하면 조금 더 많은 일을 한다.
  • 작성한 yaml file을 json 형태로 변환하고 마지막으로 적용된 configuration으로 저장한다.
  • local yaml file, 변환된 json file, kubernetes configuration file 세가지를 모두 비교하여 라이브 개체에 적용할 변경 사항을 식별한다.
  • 즉 local yaml file 변경 → kubernetes 내부의 live object configuration 변경 → json 변경의 순서로 업데이트가 이루어진다.

last updated applied configuration이 필요한 이유는? (Json으로 변환된 파일)

• 로컬 파일에서 변화가 생겼을 경우 last updated(json) file과 live object configuration file(in kubernetes) 파일을 함께 비교하여 변경 사항을 어떻게 저장할지를 결정하기 때문에 필요하다.