CKA-4일차

📍 CKA 4일차
📍 Udemy-Certified Kubernetes Administrator (CKA) with Practice Tests 36-48

---

36. Service Cluster IP

서비스나 계층 간의 연결을 확립하는 올바른 방법은 무엇일까?
파드는 모두 할당된 IP 주소를 가진다. 하지만 이 IP들은 정적이 아니기 때문에 언제든 철거될 수 있고 새로운 파드는 계속 만들어지니 내부 통신에 이 IP 주소에만 의존할 수는 없다.

쿠버네티스 서비스를 통해 파드를 하나로 묶고 하나의 인터페이스를 통해 단체 파드에 접속할 수 있다. 요청은 무작위적으로 하나의 파드에 전달된다.
다양한 서비스 간의 통신에 영향을 주지 않고 각 계층은 필요한 대로 확장 또는 이동할 수 있다.
각각의 서비스는 클러스터 내부에서 IP와 그에 할당된 이름을 갖고 있다. 다른 파드가 서비스에 접근하기 위해서는 그 이름을 사용해야 한다.
이러한 서비스 유형이 ClusterIP이다.

정적 파일을 통해 ClusterIP를 생성할 수 있다.
type은 ClusterIP이다. 사실 ClusterIP는 기본값이기 때문에 지정하지 않더라도 자동으로 ClusterIP로 추정된다.
targetPort는 실행 중인 파드가 노출되는 포트이다.
port는 서비스가 노출되는 포트이다.
서비스를 ports에 연결하려면 selector를 사용해야 한다.

---

37. Services - LoadBalancer

nodePort가 있는 서비스는 노드 포트에서 트래픽을 수신해 트래픽을 각각의 파드로 라우팅하는 것을 돕는다.
사용자는 노드의 IP와 nodePort를 이용해서 앱에 접근할 수 있다.
하지만 사용자는 클러스터된 작업자 노드들을 아우르는 단일 URL을 통해 앱에 접근하길 원한다.

이를 위한 한 가지 방법은 부하분산기 목적으로 새 VM을 만들고 적절한 LoadBalancer를 구성하는 것이다.

모든 외부 부하 분산을 설정하고 그것을 유지하는 것은 쉽지 않은 작업이다.
구글 클라우드, AWS, Azure와 같이 지원되는 클라우드 플랫폼에 있다면 해당 클라우드 플랫폼의 네이티브 LoadBalancer와의 통합을 지원한다.
서비스의 type을 LoadBalancer로 설정하면 서비스가 부하분산 역할을 수행한다.
그러나 LoadBalancer type을 지원하지 않는 환경에서 설정한다면 NodePort로 설정하는 것과 같은 효과를 갖게 된다.

---

38. Practice Test - Services

쿠버네티스가 만든 기본 ClusterIP 서비스를 갖고 있다.

---

40. Namsepaces

이 집들은 쿠버네티스의 네임스페이스와 일치한다.

클러스터가 처음 설정되면 쿠버네티스가 자동으로 Default Namespace를 생성한다.

사용자들로부터 분리하고 실수로 이 서비스들이 삭제되거나 수정되는 것을 막기 위해 쿠버네티스는 클러스터 시작 때 kube-system이란 이름의 Namespace를 생성한다. kube-system 네임스페이스에는 쿠버네티스의 내부 목적을 위한, 네트워킹 솔루션이나 DNS 서비스에 요구되는 파드와 서비스 세트들이 존재한다.
쿠버네티스가 만든 또 다른 네임스페이스는 kube-public이다. kube-public 네임스페이스에는 모든 사용자가 사용할 수 있어야 할 리소스가 생성된다.

새로운 네임스페이스를 생성할 수 있다.
각각 다른 이름 공간 덕분에 개발 환경에서 작업하는 동안 다른 네임스페이스의 리소스를 실수로 수정하지 못한다.

이런 네임스페이스는 각각의 고유한 정책(누가 뭘 할 수 있는지 정의)을 가질 수 있다.
이런 네임스페이스 각각에 리소스 할당량을 할당할 수도 있다.

• db-service: 같은 네임서비스 내에서 db-service 이름 만으로 서비스에 접근 가능
• db-service.dev.svc.cluster.local: dev 네임스페이스에 있는 db-service에 접근.

이게 가능한 이유는 서비스가 생성될 때 DNS 항목이 자동으로 이 포멧에 추가되기 때문이다.

서비스의 DNS 이름을 자세히 보면, cluster.local은 클러스터의 기본 도메인 이름이다.
svc는 서비스를 위한 하위 도메인이며 서비스 이름과 네임스페이스 다음에 위치한다.

이제 네임스페이스의 운영 측면을 살펴보자.
kubectl get pods는 모든 파드를 열거하는데 사용되지만 default namespace에 있는 것만 열거한다.
또 다른 네임스페이스에 있는 파드를 열거하려면 명령 안에 네임스페이스 옵션을 사용해야 한다.
kubectl get pods --namespace=kube-system 이 경우에는 kube-system 네임스페이스를 지정했다.

파드 정의 파일을 이용해 파드를 만들 때 파드는 default namespace에 생성된다.
또 다른 네임스페이스에 파드를 생성하려면 네임스페이스 옵션을 사용하면 된다.

이 파드가 항상 dev 네임스페이스에서 생성되도록 하고 싶다면 커맨드라인에서 네임스페이스를 지정하지 않더라도 네임 스페이스 정의를 파드 정의 파일로 옮길 수 있다.
이 경우, metadata 영역 아래에 namespace: dev를 추가하면 된다.

다른 개체처럼 네임스페이스 역시 정의 파일을 통해 만들 수 있다.

네임스페이스를 만드는 또다른 방법은 kubectl 명령을 통해 네임스페이스를 만든 다음 네임스페이스 이름을 입력하는 것이다.

명령어를 실행하면 현재 네임스페이스의 개체들을 확인할 수 있다.
다른 네임스페이스에서 개체들을 확인하기 위해서는 네임스페이스 옵션을 사용해야 한다.
하지만 다른 네임스페이스로 영구적으로 전환하기 위해서는 kubectl config set-context 명령을 사용해서 현재 컨텍스트를 다른 네임스페이스로 설정해야 한다.

커맨드를 자세히 보면 이 커맨드는 먼저 현재 context를 식별하고 원하는 네임스페이스를 현재 context에 설정한다.
context는 같은 관리 시스템에서 여러 클러스터와 여러 환경을 관리하기 위해 사용된다.

네임스페이스에서 리소스를 제한하려면 리소스 할당량(Resource Quota)를 생성해야 한다.
Resource Quota도 정의 파일을 통해 생성 가능하다.
정의 파일에 할당량을 생성할 네임스페이스를 명시하고 한도를 설정한다. 10개의 파드, CPU 유닛, 10GB 메모리 등을 설정할 수 있다.

---

41. Practice Test - Namespaces

---

42. Solution - Namespaces

단축키를 기억하자!

---

43. Imperative vs Declarative

IaC(Infrastructure as Code) 세계에서는 명령적 접근법(Imperative)과 선언적 접근법(Declarative)으로 나뉜다.

IaC에서 인프라 프로비저닝에서 접근법의 예는 다음과 같다.
명령적 접근법에서는 무엇이 요구되는지, 어떻게 작업을 수행하는지에 대해 나와 있다.

선어적 접근법에서는 요구사항을 선언한다. 인프라를 갖추기 위해 필요한 모든 작업은 시스템이나 소프트웨어에 의해 수행되기 때문에 차근차근 설명하지 않아도 된다. ansible, chef, puppet, terraform과 같은 오케스트레이션 도구는 이 범주에 속한다.

쿠버네티스에서 인프라를 관리하는 명령적 방법은 파드를 생성하기 위해 kubectl 실행 명령을 사용하는 것이다. 개체를 생성, 업데이트, 삭제함으로써 인프라를 요구에 정확히 어떻게 적용할지 얘기하고 있다.

선언적 접근은 쿠버네티스 클러스터에서 응용 프로그램과 서비스의 예상 상태를 정의하는 파일을 만들고 단일 kubectl apply 명령을 사용하는 것이다. 쿠버네티스는 구성 읽어서 인프라를 예상 상태로 가져오기 위해 뭐가 필요한지 스스로 결정할 수 있다. 단일 kubectl apply 명령은 기존 구성을 보고 시스템에 어떤 변화가 필요한지 알아낸다.

좀 더 자세히 알아보자면, 명령적 접근에는 두 가지 방법이 있다.
첫번째는 Imperative Commands를 사용하는 것이다. 새 개체를 생성하기 위한 실행, 생성, 노출 명령과 기존 개체를 업데이트하기 위한 편집, 스케일, 셋 명령 같은 것이다.
YAML 파일을 다룰 필요가 없기 때문에 개체 생성과 수정을 신속하게 할 수 있다. 하지만 기능에 한계가 있어 고급 유스케이스를 위해 길고 복잡한 명령을 만들어야 한다.
또한 이 명령은 한 번 실행되고 잊혀진다. 명령어를 실행한 사용자의 세션 히스토리에서만 볼 수 있다.

그래서 크고 복잡한 환경에서 Imperative Commands를 다루는 것은 어렵다.
이런 경우, Imperative Object Configuration File로 개체를 관리하는 것이 도움된다.
개체 정의 파일 생성 또는 구성 파일 또는 manifest file이라고도 불리는 이 파일들은 YAML 포캣에서 개체가 정확히 어떻게 보여야 하는지를 적는데 도움을 준다. 그리고 개체를 생성하기 위해 kubectl 명령을 사용한다.

변화가 필요한 경우, 예를 들어 이미지를 다른 버전으로 수정해야하는 경우, 여러 가지 방법이 있다.
한 가지 방법은 kubectl edit 명령을 이용해 개체 이름을 명시하는 것이다. 명령이 실행되면 YAML 정의 파일이 열린다. 객체를 생성할 때 사용되었던 것과 비슷하지만 상태 필드 등의 추가적인 필드가 있다. 상태 필드는 파드의 상태를 저장하는 데에 사용된다. 개체를 생성하는 데 사용한 파일이 아니다. 쿠버네티스 메모리 내의 파드 설정 파일과 유사하다. 이 파일을 수정하고 저장하면 파일의 변화가 라이브 개체에 적용될 것이다. 하지만 kubectl edit 명령으로 변경한 건 어디에도 기록되지 않는다. 수정이 적용되고 나면 변경 전과 동일한 로컬 정의 파일만 남는다.

따라서, kubectl edit 명령을 사용할 경우, 개체 정의 파일이 함께 변경되지 않기 때문에 변경 여부를 알기 어렵다. 그렇기 때문에 kubectl edit 명령은 앞으로 개체 정의 파일을 사용하지 않을 때에만 사용하는 것이 좋다. 더 나은 방법은 개체 정의 파일의 로컬 버전을 편집하는 것이다.

개체 정의 파일을 변경하고 kubectl replace 명령을 실행하여 개체를 업데이트할 수 있다. 이렇게 하면 변경 사항이 기록되고 변경 심사 과정의 일부로 추적할 수 있다. 만약 개체를 완전히 삭제하고 재생성하고 싶다면, --force 옵션이 적용된 같은 명령을 사용하면 된다.
이건 여전히 명령적인 접근법이다. 개체들을 생성하고 업데이트하는 방법을 쿠버네티스에게 지시했기 때문이다.

만약 생성 명령을 실행했을 때 개체가 이미 존재한다면, 이미 존재한다는 오류로 실패할 것이다.
마찬가지로 개체를 업데이트할 때는 개체가 존재하는지를 먼저 확인해야 한다.
개체가 존재하지 않으면 오류 메시지로 kubectl replace 명령이 실패한다.
명령적 접근은 관리자에게 매우 까다롭다. 항상 현재 환경설정을 인지하고 변경하기 전에 확인해야 하기 때문이다.

선언적 접근은 우리가 작성한 동일한 개체 정의 파일을 사용한다.
kubectl create, kubectl replace 명령을 사용하는 대신 kubectl apply 명령을 사용한다.
kubectl appply 명령은 이미 존재하지 않는 개체를 만들 만큼 영리하다.
또한 개체 정의 파일이 여러 개일 경우, 단일 파일 대신 디렉터리를 경로로 지정할 수도 있다. 그래야 모든 개체들이 한 번에 만들어진다.
변화가 필요하면 개체 정의 파일을 업데이트하고 kubectl apply 명령을 다시 실행하면 된다. 이번에는 개체가 존재한다는 것을 알기 때문에 새로 개체를 만들지 않고 기존의 개체만 업데이트한다. 그래서 개체가 이미 존재한다거나 업데이트가 적용될 수 없다는 오류를 내지 않는다.
개체 정의 파일을 업데이트하고 kubectl apply 명령을 사용하면 kubectl apply 명령이 알아서 나머지를 처리해준다.

다음은 시헙에 대한 몇가지 팁이다.
시험적 관점에서 보면 명령적 접근을 써서 최대한 시간을 절약해야 한다.
복잡한 요구사항이 있다면 개체 정의 파일을 수정하고 kubectl apply 명령을 사용하는 것이 적합할 수도 있다.

---

44. Certification Tips - Imperative Commands with Kubectl

Imperative commands를 통해 빠르게 개체 정의 파일 템플릿을 생성할 수 있다.

• --dry-run=client 옵션: 리소스를 생성하지 않고 리소스를 생성할 수 있는지 여부와 명령이 올바른지 여부를 알려준다.
• -o yaml 옵션: 리소스 정의를 YAML 형식으로 화면에 출력한다.

위의 두 옵션을 함께 사용하여 리소스 정의 파일 템플릿을 빠르게 생성할 수 있다.

<예시>

POD

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

Deployment

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 with 4 Replicas

kubectl create deployment nginx --image=nginx --replicas=4

또는 kubectl scale 명령을 통해서도 가능하다.
kubectl scale deployment nginx --replicas=4

Another way to do this is to save the YAML definition to a file and modify
kubectl create deployment nginx --image=nginx --dry-run=client -o yaml > nginx-deployment.yaml

Service

Create a Service named redis-service of type ClusterIP to expose pod redis on port 6379

kubectl expose pod redis --port=6379 --name redis-service --dry-run=client -o yaml
위의 방법은 자동으로 pod의 label을 selector로 사용한다.

또는

kubectl create service clusterip redis --tcp=6379:6379 --dry-run=client -o yaml
위의 방법은 pod의 label을 selector로 사용하지 않고, 대신 선택자를 app=redis로 가정한다. selector를 옵션으로 저달할 수 없다. 따라서, pod에 다른 label이 있는 경우 제대로 작동하지 않는다. 이 경우, 서비스를 생성하기 전에 서비스 정의 파일을 생성해서 selector를 수정해야 한다.

Create a Service named nginx of type NodePort to expose pod nginx's port 80 on port 30080 on the nodes
kubectl expose pod nginx --type=NodePort --port=80 --name=nginx-service --dry-run=client -o yaml
위의 방법은 자동으로 pod의 label을 selector로 사용한다. 그러나 node port를 명시할 수 없다. node port를 명시하기 위해서는 서비스를 생성하기 전에 서비스 정의 파일을 생성하고 node port를 명시해야 한다.

또는

kubectl create service nodeport nginx --tcp=80:80 --node-port=30080 --dry-run=client -o yaml
위의 방법은 pod의 label을 selector로 사용할 수 없다.

따라서, 위의 두 방법은 둘 다 어려움을 갖고 있다. kubectl expose는 node port를 명시할 수 없고 kubectl create는 pod의 label을 선택할 수 없다.
필자의 경우, kubectl expose 명령을 추천한다. node port를 명시해야 하는 경우, 정의 파일을 생성해서 node port를 추가하면 된다.

---

45. Practice Test - Imperative commands

---

46. Solution - Imperative Commands

kubectl expose 명령을 사용했더니 label 'tier=db'를 자동으로 탐지하고 selector로 지정했다.

--expose 옵션 사용 시, 주의사항은 다음과 같다.

--expose=true로 설정했더니 pod와 함께 service가 생성되었다.

---

47. Kubectl Apply Command

kubectl apply 명령의 적용 원리에 대해 알아보자.
kubectl apply 명령은 local file과 last applied configuration, kubernetes live object configuration를 고려한다.
개체를 만들기 위해 어떤 방법을 사용하든지 상관없지만 kubectl apply 명령을 적용하면 그 이상의 작업을 수행한다.
우리가 작성한 YAML 형식의 로컬 개체 정의 파일은 json 형식으로 변환된다. 그리고 마지막으로 적용된 구성(last applied configuration)으로 저장된다.

오브젝트에 대한 업데이트는 세 가지를 모두 비교하여 쿠버네티스 라이브 개체에 어떤 변화가 있는지 확인한다.
예를 들어, nginx 이미지를 1.19버전으로 업데이트 하고 kubectl apply 명령을 사용한다면 로컬 파일의 1.19 값은 라이브 개체 설정 값과 비교된다.
차이가 있다면 라이브 개체 설정값은 새 값으로 업데이트된다.

어떠한 변화가 있더라도 마지막으로 적용되는 json 형식의 환경 설정(last applied configuration)은 항상 최신으로 업데이트된다.
그래서 항상 '최신'이다.

그럼 마지막으로 적용된 환경 설정(last applied configuration)이 왜 필요할까?
필드가 삭제되면, 예를 들어 'type' label이 삭제되면 kubectl apply 명령이 실행되었을 때 마지막으로 적용된 환경 설정(last applied configuration)에 label이 존재하는 것을 확인할 수 있다.
하지만 로컬 파일에서 이미 label을 삭제했기 때문에 로컬 정의 파일에는 label이 존재하지 않는다. 이에 따라, live object configuration에서 'type' label이 제거된다.
즉, 마지막으로 적용된 환경 설정(last applied configuration)에만 해당 label이 존재하는 것은 이전 단계에서 혹은 마지막으로 kubectl apply 명령을 실행했을 때 그 특정 필드가 거기 있었고 지금은 제거되고 있는 것을 의미한다.
마지막으로 적용된 환경 설정(last applied configuration) 파일은 로컬 파일에서 어떤 필드가 제거되었는지 알아내는 것을 돕는다.
이 내용은 공식 문서에서 상세히 살펴볼 수 있다.

로컬 시스템에 저장된 것은 local file이다. Live Object configuration은 쿠버네티스 메모리에 저장되어 있다. last applied configuration이 저장된 json 파일은 live object configuration의 annotation 영역에 저장되어 있다.

kubectl apply 명령을 사용할 때에만 last applied configuration에 저장된다. kubectl create나 kubectl replace 등 다른 명령을 사용할 때에는 last applied configuration에 저장되지 않는다.

즉, imperative(명령적) 접근(kubectl apply 이외의 명령어)에서는 last applied configuration이 저장되지 않고, 개체가 이미 존재하는지 등을 확인하지 않아서 오류가 발생할 수 있다.

반면에, declarative(선언적) 접근(kubectl apply 명령어)에서는 last applied configuration이 저장되고, 개체가 이미 존재하는지 등을 확인하기 때문에 오류가 발생하지 않는다.