CKA

Kube-API Server

: 쿠버네티스 클러스터의 기본 관리 구성 요소

kubectl 명령어를 실행 할 때 Kube-API Server에 연결

요청을 인증하고 검증 한 뒤 ETCD 클러스터에서 데이터를 가져와 요청한 정보를 반환 하거나 업데이트 하는 역할을 한다.

예를 들어 Pod 를 생성 하는 경우, 인증을 거쳐 검증이 끝난 뒤에 API 서버는 Pod 객체를 생성하지만 노드에 할당 하지는 않는다. 이 정보는 ETCD 서버에 업데이트 되고, 사용자는 Pod 가 생성 되었음으로 알게 된다.

스케줄러는 API서버를 지속적을 모니터링 하면서 노드가 할당되지 않은 새 Pod 가 있음을 인식한다. 스케줄러는 새 Pod 를 배치할 적절한 노드를 식별하고 이를 Kube-API Server에 다시 전달 한다. 그러면 API 서버는 ETCD 클러스터에 정보를 업데이트 한다.

API 서버는 그 정보를 해당 작업 하려는 노드의 kubelet 에 전달한다. kubelet 은 그 노드에서 Pod를 생성하고, 컨테이너 런타임 엔진에 애플리케이션 이미지를 배포 하도록 지시한다. 이후 완료 되면 kubelet 은 상태를 API 서버에 다시 업데이트하고, API 서버는 ETCD 클러스터에 다시 데이터를 업데이트 한다.

kubeadmin 도구를 사용 해 설정 한 경우,

kubeadmin-apiserver를 마스터 노드의 kube-system 네임 스페이스에 Pod으로 배포 Pod 정의 파일은 /etc/kubernetes/manifest 폴더에 위치

kubectl get pods -n kube-system
# Pod 를 확인
cat /etc/kubernetes/manifests/kube-apiserver.yaml
# Pod 정의 파일 경로로 이동하여 확인
Bash
복사

kubeadmin을 사용하지 않은 경우,

cat /etc/systemd/system/kube-apiserver.service
# kube-apiserver 서비스를 확인하여 옵션을 확인
ps -aux | grep kube-apiserver
# 프로세스 목록을 출력 했을 때 사용 한 옵션을 확인
Bash
복사

Kube Controller Manager

Kubernetes 의 용어로 컨트롤러란 여러 구성 요소의 상태를 지속적으로 모니터링하고 시스템 전체를 원하는 상태로 유지하기 위해 작동하는 프로세스

예를 들어, 두 가지의 예시를 보일 수 있음.

노드 컨트롤러 : 노드의 상태를 모니터링 하고 애플리케이션이 계속 실행 되도록 필요한 조치를 취하는 역할을 함.

복제 컨트롤러 : 레플리카 셋의 상태를 모니터링 하고 항상 원하는 수의 POD가 세트 내에 존재하는지 확인하는 역할을 함.

여러 컨트롤러들은 Kubenetes Controller Manager 라는 단일 프로세스로 패키지 된다.

Kubernetes 릴리스 페이지에서 다운로드하여 압축을 풀고 서비스로 실행할 수 있음.

KubernetesDownload Kubernetes

wget https://dl.k8s.io/v1.31.1/bin/linux/amd64/kube-controller-manager
Bash
복사

kube-controller-manager.service 에 다양한 옵션을 적용 할 수 있는데, 어떤 컨트롤러만 활성화 시킬지, node-monitor-period, node-monitor-grace-period, pod-eviction-timeout 에 대한 옵션을 줄 수 도 있음.

kube admin 도구를 사용 했을 경우

Kube Controller Manager를 마스터 노드의 Kube system 네임스페이스에 POD로 배포

kubectl get pods -n kube-system
# Pod 를 확인
cd /etc/kubernetes/manifests/kube-controller-manager.yaml
# 정의 파일에서 옵션을 확인
Bash
복사

kube admin 도구를 사용 하지 않았을 경우

cat /etc/systemd/system/kube-controller-manager.service
# 서비스 디렉터리의 서비스를 확인 하여 옵션을 검사
ps -aux | grep kube-controller-manager
# 프로세스 목록을 출력 했을 때 사용 한 옵션을 확인
Bash
복사

Kube Scheduler

Kubernetes 스케줄러는 Pod를 노드에 스케줄링하는 역할을 담당

스케줄러는 단지 어떤 Pod가 어느 노드에 배치될지 결정만 함.

실제로 Pod 에 노드를 배치 하는 일은 kubelet 이 함.

그럼 스케줄러는 어떻게 Pod 가 노드에 배치 될지 결정을 할 까?

조건에 맞지 않은 노드들은 필터링

스케줄러는 노드들을 순위별로 평가하여 Pod에 가장 적합한 노드를 식별
스케줄러는 0에서 10까지의 점수를 매기는 우선순위 함수를 사용

kube-scheduler 바이너리를 kubernetes 릴리스 페이지에서 다운로드 하고 압축을 풀어 서비스로 실행

KubernetesDownload Kubernetes

wget https://dl.k8s.io/v1.31.1/bin/linux/amd64/kube-controller-manager
Bash
복사

이때, 서비스로 실행 할 때, 스케줄러 구성 파일을 지정해야 한다.

옵션 확인 방법

cat /etc/kubernetes/manifests/kube-scheduler.yaml
ps -aux | grep kube-controller-manager
Bash
복사

Kubelet

Pod 와 그 안의 컨테이너 상태를 모니터링 하며, 그 상태를 kube API 서버에 정기적으로 보고

노드에 컨테이너나 Pod 를 적재하라는 지시를 받았을 때, 컨테이너 런타임 엔진(Docker)에게 필요한 이미지를 가져와 인스턴스를 실행 하도록 요청

kubelet 은 계속 해서 Pod 와 그 안의 컨테이너 상태를 모니터링 하며, 그 상태를 kube API 서버에 정기적으로 보고

kubeadm - kubelet 을 자동으로 배포 하지 않음 - 수동으로 설치 필요

wget  https://dl.k8s.io/v1.31.1/bin/linux/amd64/kubelet
Bash
복사

설치 프로그램을 다운로드 하고 압축을 풀어 서비스로 실행

옵션 확인

ps -aux | grep kubelet
Bash
복사

실행 중인 프로세스를 확인

Kube-Proxy

kube-proxy는 Kubernetes 클러스터의 각 노드에서 실행되는 프로세스

프로세스의 역할은 새로운 서비스를 찾고, 새로운 서비스가 생성될 때마다 각 노드에 적절한 규칙을 만들어서 해당 서비스로 향하는 트래픽을 백엔드 Pod로 전달하는 것

이 작업을 수행하는 한 가지 방법은 iptables 규칙을 사용

이 경우, 클러스터의 각 노드에 iptables 규칙을 생성하여 서비스의 IP(예: 10.96.0.12)로 향하는 트래픽을 실제 Pod의 IP(예: 10.32.0.15)로 전달

바이너리 파일

wget https://dl.k8s.io/v1.31.1/bin/linux/amd64/kube-proxy

kubectl get deamonset -n kube-system
Bash
복사

다운로드 후 서비스로 실행

Kubernetes 객체

- pods, replicas, deployments, services

객체를 생성 하기 위해서는 yaml 파일을 사용한다

Kubernetes 정의 파일에는 항상 네 가지 최상위 필드가 포함

•

API 버전, kind, metadata, spec

이들은 최 상위 또는 루트 수준의 필드로, 반드시 구성 파일에 포함

API 버전

•

생성하려는 객체에 따라 올바른 API 버전

◦

 POD : v1

◦

Service : v1

◦

ReplicaSet : apps/v1 

◦

Deployment : apps/v1

kind

•

생성하려는 객체의 종류

metadata

•

객체의 이름, 라벨 등의 데이터 (딕셔너리 형태로 제공)

◦

name  : 이름

◦

labels : 키-쌍 의 형태로 추가

spec

•

객체에 대한 추가 정보를 Kubernetes에 제공 (딕셔너리 형태로 제공)

◦

containers

▪

리스트 또는 배열

▪

여러 컨테이너를 가질 수 있기 때문에 리스트 형식

# pod-definition.yml

apiVersion : v1
kind : Pod
metadata:
	- name : 
	- labels :
				app : myapp
				type : frond-end			
spec:
	containers:
		- name : nginx-container
			image: nginx
YAML
복사

kubectl create -f pod-definition.yaml
# Pod 생성

kubectl get pods
# Pod 목록

kubectl describe pod
# Pod 자세한 사항
Bash
복사

replicas

동일한 Pod를 여러 개 실행해 두어 한 개가 실패해도 다른 Pod에서 애플리케이션을 계속 실행할 수 있도록 한다.

단일 Pod의 여러 인스턴스를 실행하여 고가용성을 제공

단일 Pod 여도 Replication Controller 는 기존 Pod 가 실패 했을 때 자동으로 Pod 를 생성 하여 지정 된 개수의 Pod 가 항상 실행 되도록 보장

API 버전의 경우 생성 하려는 항목에 따라 다름.

Replication Controller 는 Kubernetes API 버전 V1을 지원, Kind는 Replication Controller 로 설정 Metadata 는 pod 와 동일, Spec 섹션의 경우 중요한데, 이는 생성하려는 객체의 내부를 정의함

Spec 아래에 template 섹션을 생성하여 Replication Controller 가 복제에 사용 할 Pod 템플릿을 제공

Spec에 replicas 속성을 추가 하고, 원하는 개수를 입력.

Replication Controller VS Replica Set

목적은 같지만 완전히 동일 한 것 은 아님

Replication Controller 는 이전 기술로, 현재는 Replica Set 이 권장 된다.

replicaset 의 API 버전은 apps/v1

selector 의 대한 정의에 따라 차이가 있음.

selector 섹션은 Replica Set이 관리할 Pod 를 식별하는데 도움을 줌.

Replica Set 은 생성 시점에 selector 에 지정된 라벨과 일치하는 기존 Pod 도 관리 할 수 있음.

따라서, Replica Set 의 selector 는 match labels 필터를 사용하여 Pod 라벨과 일치 시킨다

kubectl scale —-replicas=<새로운 수><파일명>

kubectl scale rs <replicaset> —replicas=<새로운수>

kubectl scale 명령어를 사용 하면 파일 내의 replicas 수는 업데이트 되지 않음

kubectl create -f <파일명> 은 정의 파일을 사용하여 Replica Set 이나 기타 객체를 생성하는데 사용.

Deployment

순차적 업데이트, 변경 취소(롤백), 일시정지 및 재개와 같은 기능을 제공

Deployment 정의 파일의 내용은 ReplicaSet 정의 파일과 거의 동일하며, kind가 Deployment로 설정되는 점만 다름.

파일 내용에는 API 버전(apps/v1), 메타데이터(name과 labels), 그리고 spec(template, replicas, selector)이 포함됨.

template에는 Pod 에 대한 내용이 정의 됨

Deployment 정의 파일을 실행 kubectl create -f <파일명>

생성된 Deployment를 확인kubectl get deployment

Deployment는 자동으로 ReplicaSet을 생성함. kubectl get replicaset 명령어를 실행하면 Deployment 이름을 딴 새 ReplicaSet을 확인할 수 있음.

ReplicaSet은 결국 Pod를 생성하므로, kubectl get pods 명령어를 실행하면 Deployment 및 ReplicaSet 이름을 가진 Pod들을 확인할 수 있음.

지금까지는 ReplicaSet과 Deployment의 차이점이 크지 않지만, Deployment가 새로운 Kubernetes 객체를 생성했다는 점에서 차이가 있음.

마지막으로, 생성된 모든 객체를 한 번에 보려면 kubectl get all 명령어를 실행 하면 됨, Deployment가 생성되었고, 이어서 ReplicaSet과 Deployment의 일부로 생성된 세 개의 Pod가 표시 됨.

Service

여러 Pod 그룹 간의 연결을 가능하게 하고 마이크로 서비스 간의 느슨한 결합을 가능하게 함

NodePort 서비스를 통해 노드의 포트를 수신하여 Pod 로 요청을 전달함

이외에도 노드의 포트를 통해 내부 포트를 접근 가능하게 함

노드의 포트를 Pod 의 포트와 매핑 하여 외부에서 접근 할 수 있도록 함.

예를 들어, 웹 서버가  실행된 포트가 80이라고 가정 할 때 이걸 targetPort 라고 부름. 서비스가 요청을 전달하는 대상 포트.

서비스 자체의 포트로, port 라고도 함.  이때 서비스는 클러스터 내에서 자체 IP 주소 ( ClusterIp) 를 가지며 이를 통해 클러스터 내에서 가상서버 처럼 작동.

웹 서버에 접근 할 때 사용하는 포트로 nodePort 라고도 함. 주로 30000 ~ 32767 사이 범위 내에서 할당

Cluster IP 서비스를 이용해 클러스터 내에서 가상 IP 를 생성해 서버 간의 통신을 가능하게 함

LoadBalancer 는 지원되는 클라우드 제공 업체에서 애플리케이션 용 로드밸런서를 설정

서비스를 생성 하려면 API 버전은 v1, kind 는 Service, metadata 에서는 이름을 지정함.

spec 섹션에서는 실제 구성을 정의함, type 에는 생성 할 서비스 유형을 지정함. ports 에는 targetPort, port, nodePort 정보를 입력, 배열 값이 들어갈 수 있고 대시로 표시 함.

ReplicaSet 에서 했던 것 처럼 labels 와 selectors를 사용하여 연결, Pod 의 label을 서비스 정의 파일의 selector 섹션에 추가 하면 Pod 와 연결 됨

kubectl create -f <정의파일> 로 실행 하면 된다.

확인 하기 위해서는 kubectl get services를 실행 하자.

서비스는 알고리즘을 통해 여러 Pod 간에 부하를 분산 시킨다

인스턴스를 여러 개 실행 하는 경우가 있기 때문에, 여러 Pod 가 동일한 애플리케이션을 실행 하며, 동일한 label 을 공유한다. 서비스 생성 시 label 을 selector 로 이용하면, 서비스는 해당 라벨과 일치하는 모든 Pod 를 찾아 요청을 전달할 엔드포인트로 자동 선택 한다.

따라서 , 서비스는 랜덤 알고리즘을 사용해 여러 Pod 간에 부하를 분산 시킨다

마지막으로 Pod 가 여러 노드에 분산 되어 있을 때는, 서비스는 클러스터의 모든 노드에 걸쳐 자동으로 생성 되고, 모든 노드에서 동일한 NodePort 로 매핑됨.

이렇게 될 경우엔 클러스터 내 어느 노드의 IP 를 사용 하던간에 동일한 포트로 어플리케이션을 접근 할 수 있음.

정리하면, 단이 Pod 가 있는 단일 노드, 단일 노드의 나중 Pod, 또는 다중 노드의 다중 Pod 모두에서 서비스 생성 방식은 동일.

Pod 가 제거 되거나 추가 될 때 서비스는 자동으로 업데이트 됨. 서비스가 생성 된 이후에는 일반적으로 추가 구성이 필요하지 않은 상태!

Service ClusterIP

서비스는 Pod 들을 그룹으로 묶고 해당 그룹의 Pod 에 접근 할 수 있는 단일 인터페이스를 제공함.

백엔드 Pod 들을 위해 생성 된 서비스는 모든 백엔드 Pod를 하나의 그룹으로 묶고, 다른 Pod 가 이 서비스를 접근 할 수 있는 단일 인터페이스를 제공.

요청은 서비스 하위의 Pod 들 중 하나로 랜덤 하게 전달.

각 서비스는 클러스터 내에서 고유의 IP주소와 이름을 할당 받고, 각 Pod 는 이 이름을 사용하여 해당 서비스에 접근.

이를 ClusterIP라고 함

이러한 서비스를 생성 하려면 API 버전 은 v1, kind는 Service, spec 에는 type 과 ports 를 설정. type 은 ClusterIP, ports 에서는 targetPorts와 port 을 지정. targetPort 는 백엔드가 노출 되는 포트, port 는 서비스가 노출 되는 포트

서비스를 특정 Pod 집합에 연결 하기 위해 Selector 를 사용함. Pod 정의 파일에서 라벨을 복사 하여 selector 섹션 아래에 추가.

kubectl create -f <정의파일> 로 실행 하면 된다.

확인 하기 위해서는 kubectl get services를 실행 하자.

Service LoadBalancer

NameSpace

기본 네임스페이스가 default 이나 처음 클러스터가 생성 될 때 자동으로 생성 함.

kube-system : 내부적으로 필요한 네트워크 솔루션이나 DNS 서비스와 같은 Pod 와 Service를 위해 만들어진 네임스페이스 사용자가 실수로 이 서비스를 삭제하거나 수정하는 것을 방지

kube-public : 모든 사용자에게 공개 되어야 하는 리소스를 만들기 위해 존재

동일한 클러스터를 dev 와 production 에서 사용하며 리소스를 분리 하고 싶을 때 환경에 맞게 네임스페이스를 설계 하면 됨.

고유의 정책 세트를 설정 할 수 있음. 각 네임스페이스에 할당 할 리소스의 할당량 을 지정 할 수 있음.

네임스페이스에 특정 양의 리소스를 보장하고, 허용된 한도 이상을 사용 할 수 없도록 할 수 있음.

다른 네임스페이스에 접근 하려면 <서비스이름>.<네임스페이스>.svn.cluster.local 형식으로 주소를 설정 하면 됨

자동으로 이러한 형식으로 DNS 항목이 추가됨.

서비스의 DNS 이름을 자세히 살펴보면 cluster.local 은 kubernetes 클러스터의 기본 도메인 이름 이며, svc는 서비스의 서브 도메인임.

기본적으로 기본 네임스페이스에 생성 되며, 다른 네임스페이스에 지정 하여 생성 하려면 --namespace 옵션을 사용 하면 됨

kubectl create namespace <네임스페이스 이름> 명령어를 실행.

다른 네임스페이스로 이동 하고 싶을 때는 kubectl config set-context --current --namespace=dev 명령어를 사용해 dev 네임스페이스로 전환 할 수 있음.

모든 네임스페이스의 Pod 를 확인 할 때는 --all-namespaces 옵션을 사용하여 모든 네임스페이스의 Pod 목록을 볼 수 있음.

리소스를 제한 하고 싶으면 리소스 할당량(resource quota) 을 생성.

리소스 할당량 정의 파일에서 제한할 네임스페이스를 지정하고, Pod 10 개, CPU 10개, 메모리 10GB와 같이 제한 사항을 설정.

Schedule