CKA-3일차

📍 CKA 3일차
📍 Udemy-Certified Kubernetes Administrator (CKA) with Practice Tests 28-35

---

28. Recap-ReplicaSets

쿠버네티스의 두뇌는 컨트롤러이다.
컨트롤러를 쿠버네티스를 모니터링하고 그에 따라 반응하는 프로세스이다.

복제 컨트롤러는 쿠버네티스 클러스터에 있는 단일 파드의 다중 인스턴스를 실행하도록 도와준다.
복제 컨트롤러는 고가용성(high availability)을 제공한다.
파드가 하나뿐이어도 복제 컨트롤러를 사용할 수 있다.
복제 컨트롤러는 기존의 파드가 고장 났을 때 자동으로 새 파드를 불러온다.
따라서 복제 컨트롤러는 특정 파드가 항상 실행되도록 보장한다.

복제 컨트롤러가 필요한 또 다른 이유는 로드밸런싱 때문이다.
사용자 수가 증가하면 파드를 하나 더 설치해 두 부분의 하중을 균형잡는다.
복제 컨트롤러는 여러 노드로 뻗어 있어서 서로 다른 노드의 여러 파드에 걸쳐 부하를 분산하는데 도움이 되고 수요가 증가하면 앱 스케일도 조정할 수 있다.

Replication Controller와 Replica Set은 비슷한 용어이다.
둘 다 용도는 같지만 똑같지는 않다.
Replication Controller는 구식 기술로 Replica Set로 대체되고 있다.
Replica Set은 복제를 설정하는 새로운 권장 방법이다.
하지만 앞에서 다룬 내용은 이 두 기술 모두 적용할 수 있다.
각각 작동 방식에 미세한 차이가 있다.

복제 컨트롤러 정의 파일을 만들어서 복제 컨트롤러를 생성할 수 있다.
template 영역은 컨트롤러가 복제본을 만들기 위해 사용할 파드 템플릿을 명시한다. pod의 정의 파일에서 참고할 수 있다.
replicas 영역에는 복제품 개수를 작성한다.

Replica Set정의 파일을 만들어서 Replica Set을 생성할 수 있다.
복제 컨트롤러와 다르게 apiVersion이 apps/v1이다.
복제 컨트롤러와 Replica Set엔 큰 차이점이 있다.
Replica Set에는 selector를 정의해야 한다.
selector 영역은 Replica Set 밑에 놓인 파드를 식별할 수 있게 해준다.
selector 영역을 명시해야 하는 이유는 Replica Set은 Replica Set의 일부로 만들어지지 않은 파드도 관리할 수 있기 때문이다.
가령, Replica Set은 selector에 지정된 label과 일치하는 Replica Set을 만들기 전에 만들어진 pod를 고려한다.

복제 컨트롤러의 경우, selector가 필수 필드는 아니지만 사용 가능하다.
위의 사진처럼 selector를 생략할 경우, 파드 정의 파일에서 제공된 레이블과 동일하다고 추정한다.

왜 label과 selector가 필요할까?
Replica Set은 이미 생성된 기존 파드를 모니터하는데 사용된다.
Replica Set의 역할은 파드를 모니터하고 하나가 고장나면 새 파드를 배포한다.
클러스터에는 다른 응용 프로그램을 실행하는 파드가 수백 개이다.
이때 생산 중인 pod에 라벨을 붙이는 것이 유용하다.
selector에 template의 metadata에 명시한 label을 명시하면 필터된다.
이렇게 하면 Replica Set이 어느 파드를 모니터하는지 알 수 있다.

Replica Set을 어떻게 6개로 업데이트할까?
방법 1. 정의 파일의 replicas를 6개로 업데이트한다. 그런 다음 kubectl 명령어를 통해 변경사항을 적용한다.

방법 2. 매개변수를 통해 replicas를 6개로 지정한다. 정의 파일이나 이름을 명시한다.

그러나 파일 이름을 입력으로 사용하면 파일에서 자동으로 replicas가 업데이트되지 않는다.
다시 말해 정의 파일의 replicas는 여전히 3이다.
부하에 따라 자동으로 스케일링할 수 있는 옵션이 존재한다. 이는 나중에 배울 예정이다.

사용한 명령을 복습해보자.

---

29. Practice Test-ReplicaSets

---

30. Practice Test-ReplicaSets-Solution

kubectl explain resource명을 통해 resource 정의 파일에 대한 정보를 얻을 수 있다.

복제본 수를 바꾸는 방법에는 다음 두 가지가 있다.

---

31. Deployments

Deployment를 통해 우리는 하부 인스턴스를 매끄럽게 업그레이드할 수 있다.

Deployment를 만들기 위해 Deployment 정의 파일을 만들면 된다.

생성된 모든 객체를 한번에 보기 위해서는 큐브 컨트롤을 실행하고 다음 명령어를 입력하면 된다.

---

32. Certification Tip!

실제 시험에서 yaml 파일을 찾고 수정하기에는 시간이 빠듯하다. 따라서 다음 예시들처럼 kubectl 명령어를 사용하는 것이 좋다.

Create an NGINX Pod
kubectl run nginx --image=nginx

Generate POD Manifest YAML file (-o yaml). Don't create it(--dry-run)
kubectl run nginx --image=nginx --dry-run=client -o yaml

Create a deployment
kubectl create deployment --image=nginx nginx

Generate Deployment YAML file (-o yaml). Don't create it(--dry-run)
kubectl create deployment --image=nginx nginx --dry-run=client -o yaml

Generate Deployment YAML file (-o yaml). Don't create it(--dry-run) with 4 Replicas (--replicas=4)
kubectl create deployment --image=nginx nginx --dry-run=client -o yaml > nginx-deployment.yaml

Save it to a file, make necessary changes to the file (for example, adding more replicas) and then create the deployment.
kubectl create -f nginx-deployment.yaml

OR

In k8s version 1.19+, we can specify the --replicas option to create a deployment with 4 replicas.
kubectl create deployment --image=nginx nginx --replicas=4 --dry-run=client -o yaml > nginx-deployment.yaml

---

33. Practice Test-Deployments

Create a new Deployment with the below attributes using your own deployment definition file.

Name: httpd-frontend;
Replicas: 3;
Image: httpd:2.4-alpine

My Answer: kubectl create deployment httpd-frontend --replicas=3 --image=httpd:2.4-alpine

---

35. Services

서비스는 애플리케이션 안팎의 다양한 구성 요소 간의 통신을 가능하게 한다.
쿠버네티스 서비스는 애플리케이션을 다른 애플리케이션 또는 사용자와 연결하는 데 도움을 준다.
다양한 파드 그룹 간의 연결을 가능하게 하는 것이 서비스이다.

서비스는 프론트엔드 응용 프로그램을 사용자가 사용할 수 있게 하며 백엔드와 프론트엔드 파드 간의 통신을 돕고 외부 데이터 소스와의 연결을 설정하는데 도움을 준다.

서비스의 종류에는 NodePort, ClusterIP, LoadBalancer가 있다.
NodePort는 노드의 포트에 귀 기울여 해당 노드에서 웹 응용 프로그램을 실행 중인 파드의 포트로 요청하는 것이다.
ClusterIP는 서비스 안에서 가상 IP를 만들어 다양한 서비스 간의 통신을 가능하게 한다.
LoadBalancer는 부하 분산을 지원한다.

서비스는 노드의 포트와 파드의 포트를 매핑함으로써 도움을 준다.
1. TargetPort: 웹서버가 실행 중인 파드의 포트이다. 대상 포트(Target port)라고 불린다.
2. Port: 서비스 자체의 포트이다. 서비스는 노드 안의 가상 서버와 같기 때문에 클러스터 내부에 고유한 IP 주소를 가진다. 이는 클러스터 IP라고 불린다.
3. NodePort: 노드의 포트이다. 외부에서 웹 서버에 접근할 때 사용하는 포트이다. 노드 포트는 유효 범위인 30,000에서 32,767까지를 포트번호로 가질 수 있다.

정의 파일을 작성해서 서비스를 생성할 수 있다.
서비스 spec 영역에는 type과 port가 있다.
type은 우리가 만드는 서비스 유형을 가리킨다. ClusterIP, NodePort, LoadBalancer가 올 수 있다.
포트 영역 중 첫번째 포트는 targetPort이다. targetPort를 지정하지 않으면 port와 동일하다고 여겨진다. 다음으로 port는 서비스 객체의 포트이다. 세번째는 nodePort이다. 유효한 범위 내의 아무 숫자나 설정 가능하다. 노드 포트를 명시하지 않을 경우 30,000에서 32,767 사이의 유효 범위에 있는 자유 포트가 자동으로 할당된다.
하나의 서비스에 여러 개의 포트가 매핑될 수 있기 때문에 포트는 배열이다.

label과 selector를 이용해 서비스와 파드를 매핑할 수 있다.
파드 정의 파일에서 명시된 라벨을 가져와서 selector 영역에 명시하면 서비스와 파드를 연결할 수 있다.
curl http://<노드 IP>:<NodePort> 명령어를 통해 웹 서비스에 접근할 수 있다.

하나의 서비스에 여러 파드가 연결되어 있더라도 서비스는 내장된 부하 분산 장치로 작용해 부하를 분산시킨다.
서비스를 생성할 때 쿠버네티스는 자동으로 서비스를 생성해 클러스터 내 모든 노드를 가르지르고 목표 포트를 클러스터 내 모든 노드의 같은 포트에 매핑한다.
단일 노드 위에 단일 파드든 다중 노드 위에 다중 파드든 서비스는 정확히 똑같이 생성된다.
파드를 제거하거나 추가하면 서비스는 자동으로 업데이트된다. 매우 유연하고 적응적이다.
서비스는 일단 생성되면 일반적으로 추가적인 구성 변경을 할 필요가 없다.