쿠버네티스 configuration 파일

명령적 접근 방식 vs 선언적 접근 방식

명령적 접근 방식일 경우 deployment 및 서비스 구성을 위해 명령어 반복하여 직접 작성해야 한다. 이러한 수고로움을 해소하기 위해 쿠버네티스는 리소스 정의 파일을 생성할 수 있다.

 

-Deployment 정의 파일 예시

apiVersion - 쿠버네티스 버전

kind - 생성하려는 쿠버네티스 객체 종류

metadata - 객체 정보 지정-> name 등 -> reference 문서 참고

spec - deployment의 사양

-> replicas - pod 실행 수

-> templete - pod를 정의

      -> metadata - pod 객체의 metadata -> name, lables 등

-> containers - pod의 컨테이너 정의, 하나의 pod에 여러 컨테이너를 가질 수 있으므로 '-'를 사용

      -> image - 컨테이너에 사용할 image 지정

-> imagePullPolicy : 이미지 재빌드 시 새로운 태그를 지정해야 쿠버네티스가 새로운 이미지를 다운로드 하지만 태그를 지정하지 않고 매번 새로운 이미지를 찾아 업데이트하고 싶다면 'Always'로 지정

 

selector - 제어할 pod를 선택

deployment를 위한 다양한 유형의 selector가 있는데, 대표적으로 두가지 유형을 사용한다.

matchLables 나 matchExpressions 으로 지정할 수 있다.

deployment에 의해 제어되어야 하는 pod 레이블의 키-값을 그 아래에 중첩하여 작성한다.

 

*쿠버네티스 reference 문서 : https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.26/#deployment-v1-apps

 

클러스터에 작성한 yaml 파일 적용 명령어 : kubectl apply -f={적용하려는 filename}

 

 

-Service 정의 파일 예시

Service 객체의 selector는 Deployement의 객체의 selector와  약간 다르게 작동한다. Deloyment의 selector는 matchLables가 있었고 연결하려는 레이블의 키-값 쌍이 있었다. 하지만 service의 selector는 matchLables 나 matchExpressions가 없으며 직접 레이블을 키-값으로 지정해야 한다. 이러한 레이블을 가진 pod들은 해당 service에 의해 외부에 노출된다.

port - 노출하고자 하는 외부 세계의 포트

tagertPort - 수신하려는 port

 

 

 

여러 파일을 하나의 파일로 병합할 수도 있다. -> '---' 로 구분하여 한 파일에 작성

service와 deployment를 동일한 파일에 작성하는 경우, service를 먼저 배치하는 것이 좋다. 리소스는 위에서 아래 순으로 생성된다.

참고 : selector는 동적으로 추가된다. 클러스터는 살아있는 유기체이다. service가 생성 될 때 한 번에 생성되고 분석되지 않는다. 애플리케이션에서 생성되고 제거되는 모든 부분을 지속적으로 모니터링하여 selector의 레이블과 일치하는 새로운 부분이 생성되면 service에 동적으로 추가된다. 때문에 pod이 생성되기 전에 service가 먼저 생성되더라도 문제가 되지 않는다.

 

- pod와 container의 health check

Pod를 통해 해당 container가 잘 작동하고 있는 체크하는 기능을 추가할 수 있다.

livenessProbe 키 추가 - httpGet, path, port, headers, periodSeconds, initialDelaySeconds 등을 지정하여 컨테이너가 구동 동되어 실행 중인지를 검사한다.