데이터센터프로그래밍19(1)

19-Controllers(이론)

🟤 환경 설정 : minikube & kubectl 설치

# minikube 설치
curl -Lo minikube https://storage.googleapis.com/minikube/releases/latest/minikube-linux-amd64 \&& chmod +x minikube
# minikube 설치
sudo mkdir -p /usr/local/bin/
# minikube 설치
sudo install minikube /usr/local/bin/
# 버전 확인
minikube version
# 버전 결과 : minikube version: v1.25.2
# Start a cluster using the docker driver:
minikube start --driver=docker
# 상태 확인
minikube status
# sudo docker ps
sudo docker ps
# 특정 k8s 버전 실행
minikube start --kubernetes-version=v1.23.1
# kubectl 설치 
curl -LO "https://storage.googleapis.com/kubernetes-release/release/$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)/bin/linux/amd64/kubectl"
# kubectl 설치
chmod +x ./kubectl
# kubectl 설치
sudo mv ./kubectl /usr/local/bin/kubectl
# 테스트
kubectl version

® 참고문헌: [minikube 설치] https://minikube.sigs.k8s.io/docs/drivers/docker/
® 참고문헌: [리눅스에 kubectl 설치 및 설정] https://kubernetes.io/ko/docs/tasks/tools/install-kubectl-linux/

🟤 오늘 학습할 내용

• Controllers가 무엇인지?
• Labels & Selectors가 무엇인지?

🟤 Controllers란?

• 도커에서는 CLI comand를 사용하여 도커 띄우기와 같은 실습을 했었다 (명령어를 손으로 치면서 실습을 함).
• 쿠버네티스는 1억개의 컨테니어를 실행할 수 있으며, 회사에서도 많이 사용하고 있다.
• 😀 따라서, 사람들이 수작업으로 하고 있는 일들이 줄어들어야 하며, 자동화가 되어야 한다.
• 쿠버네티스 안에는 응용프로그램이 많고, 응용프로그램들이 운영자가 요구한 대로 자동화 시스템으로 최대한 제공하도록 한다.
  ex. 내가 원하는 것을 yaml 파일(desired state)에 작성하고, 쿠버네티스에게 실행을 부탁하면, 환경생성, 유지, 관리 등을 해준다.

🟤 Pod Concept?

• Infrastructure as code = desired state
• 도커 compose 파일과 컨테이너 or volume 사이의 중간을 쿠버네티스에서는 Pod 이라고 함
• Pod 안에는 컨테이너 & volume이 있어서 의미있는 한 덩어리
  

🟤 Label (1)

• simple-pod.yaml 파일(컨테이너 2개, volume 1개)을 하나 생성했다고 가정했다고 하자!
• 아래의 코드는 key/value 값이 포함되었다 (의미있는 값을 전달)

"metadata": {
"labels": {
"key1" : "value1",
"key2" : "value2"
}
}

🟤 Label (2)
: (1) key 값을 주고, key에 해당하는 value를 주는 것이다.
: (2) 명령(부탁)이 전달되기를 바라는 subsets of objects

• 😀 즉, Label은 언제 붙을 수 있을까?
  : objects가 만들어지는 creation time & 서비스가 운영 중일 때
• Label의 형태는 key/value 값으로 되어있음
• key 값은 unique 해야 됨 (의미는 아래의 코드를 통해 설명 : containes에 name으로 정의되어 있는 그 안에서 port는 2번 나올 수 없음)

# containes에 name으로 정의되어 있는 그 안에서 port는 2번 나올 수 없음
cotainers:
-name: nginx
ports:
- containerPort: 80

🟤 Example Labels

• key 값에 value를 주는 것과 특정 군을 추출하는 것과 문법이 동일하니까 똑같은 것이 아닐까?

"release" : "stable", "release" : "canary"
"tier" : "frontend", "tier" : "backend" 

• key 값에 value를 주는 것과 특정 군을 추출하는 것 둘을 구분하는 이유는?
  : ex. 시스템 configration을 주는데, 2번 시스템 configration에 A라는 값은 X였으면 좋겠다.. (= key 값에 value를 주는 것)
  : ex. 지금 돌아가는 SW 중에서 특별히 골라서 무언가 하려는 경우, "Grouping"이라고 함 (= 특정 군을 추출하는 것)

🟤 Pods Selection using Label in Service (1)

• 쿠버네티스에서 Pods는 mortal이다 (살수도 있고, 죽을 수도 있는 것).
• 만약, 3개의 Pods를 띄우는 것(desired state)을 쿠버네티스에게 요청을 했으나, 3개가 요청한 순간에 만들어지고, 언젠가 이 서비스를 종료할 것이다. 그렇다면, 처음 만든 Pods 3개가 종료시점 까지 유지가 될까?
  : Pods 3개가 유지될 수도 있고, 그렇지 않을 수도 있다.
• *Pods가 IP address를 각각 할당을 받는데, Pods의 IP address가 유지가 될까? IP address 네트워크 confiration의 일종이기 때문에 불가능 할 때도 있다. IP address가 죽고, 새로운 것이 생성된다.
• 쿠버네티스는 IP address 보단, Label을 많이 사용한다.

🟤 Pods Selection using Label in Service (2)

• Pods이 3개(여러개)가 있는 서비스가 있을 때, Pods들이 쿠버네티스에게 요청을 했다고 가정해보자.
• 중간에 Pods 1개가 죽고, 새로운 Pods가 생성 될 수 있다.
• IP address를 통해 Pods를 구분한다는 것은 힘든 일이다.
• 서로 Pods들이 통신을 해야할 때, IP address들이 바뀐다.
• 😀 따라서, 바뀌는 IP address를 추적하고 관리하는 것은 힘들다. 또한, 도커는 컨테이너들에 대한 이야기였지만, 쿠버네티스는 다양한 역할(Pods들을 감싸고, 네트워크와의 관계를 유지하는 서비스, controllers 등)을 수행한다.
• 서버에 요청을 하면 그 일을 받아서 load balancing + 추가적인 작업을 수행한다.
• 만약, Pods 죽고 새로운 Pods가 생성 될 때, IP address가 바뀌면, IP address를 load balancing에 등록, 서비스 관리 등 힘들다.
• 서비스가 Pods를 알아보았을 때도 IP address를 사용하지 않고, label을 사용한다.
• 아래의 그림을 보면, label이 app:myapp인 경우, load balancing을 해주겠다는 의미이다.
  

🟤 ReplicaSet (1) : controllers

• ReplicaSet이라고 부르는 SW가 쿠버네티스 안에 있다.
• ReplicaSet의 기능은 어플리케이션을 만들어서 쿠버네티스에게 요청을 하면,
  : replica(의미: 컨테이너를 N개 실행해줘~)와 같은 의미라고 볼 수 있으며 도커에서는 컨테이너를 N개 띄우는 단순 목적이었다.
  : 쿠버네티스에서는 ReplicaSet이라고 부르는 controllers SW가 돌고 있는 것이다 (쿠버네티스 안에 있는 ReplicaSet에게 요청을 한 것이다).
  : ex. Pods를 3개 유지해주세요~
  : ex. yaml 파일에 특정 Pods를 N개 동작 시켰으면 좋겠다라고 요청하면, 그 요청을 받아서 쿠버네티스에 있는 ReplicaSet이 N개 유지해줄게~

🟤 ReplicaSet (2) : controllers

• ReplicaSet을 통해 N개를 만들 것인데, IP address를 사용하기 보단 label을 붙여서 이름을 정할 것이니, ReplicaSet에서는 Pods이 여러개로 정해질 것이다 (어떻게 이름을 붙여줄 것인지 요청한 것을 받아들이고, 아닌 경우는 스스로 알아서 할 것이다).
• ReplicaSet을 yaml 파일로 만들어서 요청을 할 때, Pods이 몇개(desired state)? 할 것인지 명시하면, 요청한대로 동작을 할 것이다.
• ReplicaSet의 역할 : controllers는 원하는 desired number에 해당하는 Pods를 생성, 모니터링, 유지하고, 필요시에 죽은 Pods를 새롭게 생성하는 일을 하게된다.
• ReplicaSet를 만들고 유지할 때, yaml 파일에 필요한 부분들에 대해서 적절하게 적용할 것이다 (Pods에 해당하는 yaml 파일을 가지고 새로운 Pods를 만든 후에 운영을 할 것이다).

🟤 Set-based Requirement

• 쿠버네티스에서 label은 subgroup, Set, 자신이 원하는 카테고리를 많이 뽑아낸다.
• 명령어 or yaml 파일 안에 다음과 같이 나타난다.
• 설명 : label이 production or qa인 경우, 혹은 frontend or backend가 아닌 경우, partition or partition이 아닌 경우와 같은 표현을 사용한다.
• infrastructure as code의 코드의 의미가 프로그래밍을 하는 것처럼 느껴지지만, 단!! 작업을 하는 것을 구현하는 것이 아니라, 실행되고 있는 것을 유지 & 관리하는 입장에서 사용한다.

environment in (production, qa)
tier notin (frontend, backend)
partition
!partition

🟤 Equality-based Requirement

• 설명 : environment가 production인 경우, or tier가 frontend가 아닌 경우를 보여주는 아래의 코드이다.

environment = production
tier != frontend

🟤 Label based Selection Example

• yaml 파일 안에 들어가는 내용과 명령어로 쳐야하는 경우가 다를 수 있다.

kubectl get pods -l environment=production, tier=frontend
# 코드설명
kubectl get pods(pods의 정보를 가져옴) -l(라벨을 주는 것) environment=production, tier=frontend
# environment=production, tier=frontend인 경우, 라벨을 줘서 pods의 정보를 보여줘~

🟤 ReplicaSet Example

• ReplicaSet: 특정 pods를 여러개 띄우는 역할

🟤 Service Distribution in ReplicaSet

• Docker image Repository에서 컨테이너를 띄울 것이고, ReplicaSet의 역할은 yaml 파일을 기술해서 주면, 원하는 개수만큼(3개) 띄워준다 (이미지, port number).
• pods를 띄운 후, 접속 or 정보를 보고자 할 때, label을 사용해야 한다.
  

🟤 Service Distribution in ReplicaSet (blue/green)

• ReplicaSet이라는 것이 왜 label을 사용하는 것이 중요하고, ReplicaSet이라는 이름을 붙인 것은 어떤 역할을 할까?
• 나중에 서비스를 버전 up & down하는 도커와 마찬지의 기능을 하지만, 보다 안정적으로 실행된다.
• 아래의 그림 설명 : replication controller에 의해서 pods를 3개 띄워서 서비스를 하고 있다고 가정하자. 그런데 서비스를 변경해야 하는 경우, 서비스들을 중지하고 새로운 서비스로 돌려야한다. 도커에서는 이미지 업데이트를 실행했지만, 쿠버네티스의 경우는 버전1로 실행되고 있는 SW(replication controller로 실해되고 있을 때)를 새로 만드는 것이다.
  

🟤 Service Distribution in ReplicaSet (Rolling-1)

• 아래의 그림 설명 : replication controller가 3개의 서비스를 운영하고 있다. Service가 대장역할을 하면서 외부의 ip를 받아준다.
• Rolling이라는 기법을 사용하면, 서비스가 천천히 바뀌는 것인데, 서비스가 3개에 대해서 제공을 하고 controller가 3개를 다루면서 1개씩 바꾸는 것이 가능하다.
• 😀 즉, replication controller를 새롭게 만들어서 new가 1개 만들어졌으니 3개가 일을 하는데 부담이 없고, 서비스가 new로 바꾸면 새로들어온 서비스는 new를 포함한 3개에 뿌려진다.
  : x인 pods는 새로운 일은 하지않고, 기존의 pods가 멈출 때까지 기다리렸다가 지우는 역할을 한다.
• 3개가 유지되어야 함으로 1개를 새로 만들고, 1개를 지운다.
  

🟤 Service Distribution in ReplicaSet (Rolling-2)

• Rolling up이 될 수 있고, 기존 버전으로 돌아가는 Rolling back이 될 수 있다.
• ReplicaSet에 의해 실행되는 replication controller는 똘똘한 어플레케이션이다.
• 1개 지우고 실행하는 것이 IP address 보고 연결하는 것이 아니라, label을 보고 있다.
  

🟤 Service Distribution in Deployment(FFS)

• 아래의 그림 설명 : 서비스를 1개 실행하는데, replication controller v1으로 실행하고 있다가 서비스 무중단 상태에서 v2 로 올라갈 수 있고, Rolling back도 가능하다.
  

💗 정리
🐷 Controllers는 프로그래밍 하듯이 조건을 주고, 원하는 것만 제어를 하는 것이 label의 힘이다💪!!
🐷 쿠버네티스에서 IP address가 명령어 or yaml 파일에 등장하는 경우는 거의 없다.