1. Cluster Architecture

master node -> worker nodes에 대한 관리 / 계획 / 스케줄 / 노드 모니터링
worker node -> 컨테이너로 애플레케이션 호스트

master node에는 control plane이 존재

Master Node (Control Plane 컴포넌트)

ETCD Cluster

kube-scheduler

컨테이너에 필요한 자원 요구량, 워커 노드의 스펙, node afiinity role, taint, toleration 등을 고려하여 컨테이너를 노드에 할당

Controller Manager (Node-Controller, Replication-Controlelr)

node-controller -> 노드에 대한 관리, 클러스터에 노드 할당, 노드가 이용불가능한 상태일때 이를 지움
replication-controller -> 지정해둔 replicaset 만큼의 컨테이너를 유지한다.

kube-apiserver

controller 간의 소통
클러스터 안에 잇는 모든 컨포넌트 간의 소통 담당

워커노드에있는 애플리케이션 부터
마스터노드에 있는 control plane 컴포넌트까지 모든 컨테이너로 배포될 수 있다. 따라서 컨테이너 런타임 엔진 (대표적으로 도커)가 워커노드와 마스터노드에 모두 있다.

Worker Node

kubelet

노드에 존재하는 에이전트로 노드안에 컨테이너를 생성하고 지우기도 하고, 노드의 상태를 통신하는 역할도 한다
노드간의 통신도 담당 (?)
모든 노드에는 kubelet에 존재하여 노드와 컨테이너 상태를 kube-apiserver를 통해 통신한다.

kube-proxy

클러스터 안에있는 서비스간의 통신을 담당.

2. ETCD

3. Kube-apiserver

kube-apiserver 옵션확인

kubeadm) cat /etc/kubernetes/manifests/kube-apiserver.yaml

??) cat /etc/systemd/system/kube-apiserver.service

ps -aux | grep kube-apiserver

4. kube-Controller Manager

--node-monitor-period=5s
--node-monitor-grace-period=40s
--pod-eviction-timeput=5m0s

kubectl get pods -n kube-system

kubeadm) cat /etc/kubernetes/manifests/kube-controller-manager.yaml

non-kubeadm) cat /etc/systemd/system/kube-controller-manager.service

ps -aux | grep kube-controller-manager

5. Kube Scheduler

kube-scheduler는 어떤 pod가 어떤 node르 스케줄링 될지만 정하고, 실제 할당은 각 node에 있는 kubelet이 수행한다.

*pod를 node에 할당하는 프로세스
1) 요구 자원 스펙에 못미치는 node를 피터링한다.
2) rank nodes
pod를 할당하고 남은 양이 많은 순으로...(?) 커스터마이즈 가능 (?)
3) 이외에
Resource Requirements and Limits
Taints and Tolerations
Node Selectors/Affinity
를 고려하여 스케줄링 한다.

kubeadm 툴을 이용하여 kube Schduler을 설치한 경우,
kubeadm은 마스터노드의 kube-system 네임스페이스에 Pod로 배포한다.

• kube-scheduler 옵션 확인 방법

kubeadm) cat /etc/kubernetes/manitests/kube-scheduler.yaml

ps -aux | grep kube-scheduler

6. kubelet

1) kubelet -> kube-apiserver -> kube-sceduler

kube-apiserver를 통해 노드를 레지스터 한다.

2) kube-scheduler의 결정에 따라 노드에 파드를 생성한다.

3) 노드와 파드를 모니터링하고 일정시간 간격으로 kube-apiserver에 전달한다.

다른 컴포넌트와 다르게 kubeadm은 kubelet을 배포하지 않는다. 워커 노드에 항상 수동으로 배포해야한다.

kubelet의 옵션을 확인하려면 워커 노드에서
ps -aux | grep kubelet으로 확인한다.

7. kube-proxy

클러스터 안의 파드는 모두 통신가능

파드의 아이피는 항상 바뀜

데이터베이스 애플리케이션을 클러스터에 노출시키기 위해 service사용

service도 아이피를 가지고 있음

서비스는 컨테이너가 아니다, virtual component in k8s memory

하지만 서비스에서 각노드로 통신이 가능하다 이것이 가능한 이유는 kube-proxy가 존재하기 때문...하 모르겠당ㅇㅅㅇ

kube-proxy는 각 노드에 있는 일종의 프로세스이다.
kube-proxy는 새로운 서비스가 생성되는지 항상 감시하고, 서비스가 새로감지되면 서비스로 백에드 파드로 트래픽을 포워딩할 룰(iptable rules)을 생성한다.

kubectl get pods -n kube-system
kubectl get daemonset -n kube-system
(kube-proxy는 daemonset으로 각가의 노드에 생성된다.)

8. POD

• 컨테이너는 노드에 바로 배포되지 않고 pod라는 오브젝트안에 넣어서 배포된다.

• pod는 쿠버네티스에서 생성할 수 있는 가장 작은 컴포넌트다.

• Scale out, Scale in시, 컨테이너가 생성되는 것이아니라 pod가 생성된다.

• 애플리케이션 컨테이너와, helper 컨테이너를 하나의 pod가 배포할 수 있다. 같은 네트워크와 스토리지를 사용한다.

• pod 개념이 없다면 새로운 컨테이너를 만들때마다 helper컨테이너도 같이만들어주고 둘 사이의 네트워크르르 이어주어야 한다. 하지만 pod 개념이 존재하므로 이를 한꺼번에 처리가능하다.

명령어

kubectl run nginx --image nginx
(해당 이미지를 사용하여 파드 생성)

kubectl get pods
(파드 리스트 확인)

외부 사용자가 pod의 nginx에 접근하려고 하면 따로 네트워크를 설정해주어야 함.

YAML

yaml파일을 통해 pod만들기

yaml파일에서
-apiVersion (string)
-kind (string)
-metadata (dictionary) : object게 관한 정보
-spec (dictionary)
은 필수 항목이다.

kind에는
POD/v1
Service/v1
ReplicaSet/ apps/v1
Deployment/ apps/v1
등이 가능하다.

! pod-difinition.yml
metadata:
name: myapp-pod
labels:
app: myapp
env: test
spec:
containers:
- name: nginx-controller
image: nginx
- name: backend-container
image: redis

containers는 list/array이다. -로 시작하는건 배열의 첫번째 항목이라 할 수 있다.
containers라는 배열안에 각각의 컨테이너가 dictionary형태로 정의되어있다.

kubectl create -f pod-definitions.yml

kubectl get pods

kubectl describe pod myapp-pod

9. Replication Controller(ReplicaSets)

Replication Controller의 역할

1) 최소 지정한 n개의 pod가 노드에 떠있도록 유지하여, 사용자가 서비스에 엑세스할 수 없는 일을 방지한다.

2) Load Balncing & Scaling
트래픽이 많아지면 pod를 수를 증가시켜 트래픽을 분산한다.

한쪽 워커 노드에 자원을 다 사용하면 클러스터내에 있는 다른 워커 노드에 pod를 생성한다. replication controller가 다수 node에 걸쳐있다고 생각할 수 있다.

Replication Controlelr VS Replica Set

replication controlelr가 더 오래된 개념이고, Replica set이 더 최근에 등장한 개념으로 Replica Set을 사용하는 것이 권고되고 있다.

replication controller와 다르게 ReplicaSet 정의 시, version은 app/v1을 사용하고 selector 정의 항목이 존재한다.

Replication Controller yaml 생성

kubectl create -f replication-contoller.yml
kubectl get replicationController
kubectl get pods

ReplicaSet yaml 생성

kubectl create -f replicaset-definition.yml
kubectl get replicaset
kubectl get pods

Scale

replicaset-definition.yml 파일에서 replcias 수 수정
Kubectl replace -f replicaset-definition.yml

kubectl scale --replicas=6 -f replicaset-definition.yml
( 파일 명을 지정하더라도 파일 내용 중 replicat수가 저절로 수정되지 않는다.)

kubectl dscale --replicas=6 replicaset myapp-replicaset
( type / name )

replicaset 관련 명령어

kubectl delete replicaset myapp-relicaset
( 해당 하는 pod도 모두 지운다.)

10. Deployments

컨테이너 < 파드 < Replica Set < Deployment 순으로 하위 개념을 포함하는 형태라고 할 수 있다.

명령어

kubectl create -f deployment-definition.yml

kubectl get deployments

kubectl get replicaset

kubectl get pods

kubectl get all

11. Namespaces

쿠버네티스에 의해 자동으로 만들어지는 namespaces는
Default, kube-system, kube-public이 있다.

1) Default
2) kube-system
유저가 실수로 삭제하는 것을 방지하기 위해, Kube-system 이라는 namespaces에 DNS, 네트워크 관련 오브젝트들이 존재한다.
3) kube-public
모든 유저가 접근할 수 있는 자원들

각 네임스페이스는 누가 무엇을 할수 있는지에 대한 pilicy를 가지고 있고 resource limit이 존재한다.

다른 네임스페이스 있는 오브젝트에 접근할 때는 다음과 같은 이름규칙을 사용한다.

db-service.dev.svc.cluster.local
(service name / namespace / service / domain)

kubectl 명령어와 네임스페이스 지정

kubectl get pods (default 네임스페이스에 존재하는 파드 리스트 조회)

kubectl get pods --namespac=kube-system
(kube-system 네임스페이스에 존재하는 파드 리스트 조회)

kubectl create -f pod-definition.yml

kubectl create -f pod-definition.yml --namespace=dev
(dev 네임스페이스에 파드 생성 / 항상 Dev 네임스페이스에 파드를 배포하기 위해서는 pod 정의 yml 파일 내 metadata 영역에 네임스페이스를 지정할 수 있다.)

네임스페이스 생성

1) yml 파일

kubectl create -f namespace-dev.yml

2) 명령어

kubectl create namespace dev

네임스페이스 이동

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

(kubectl config current-context)
현재 컨텍스트 가져옴

kubectl get pods (dev 네임스페이스의 파드 리스트 가져옴)

kubectl get pods --all-namespaces (모든 네임스페이스의 파드 리스트 가져옴)

네임스페이스 Quota

kubectl create -f compute-quota.yml

12. Services

파드 그룹간 네트워크 통신이 가능하도록 한다.

MSA환경에서 커플링을 없애는 역할을 한다.