[k8s] Configuration.yaml

 

🎯 Goals

• service yaml 정의해본다.
• deployment yaml 을 정의해본다.
• 리소스 배포를 yaml 파일로 해본다.
• 전체 리소스가 담긴 1개 yaml 을 정의해본다.
• Selector & Label 사용 방법을 안다.

 

service.yaml 정의

"type 'LoadBalancer' 로 port 80 - targetPort 8080"

LB의 port 80 을 Listen 하여 Pod 의 노출된 포트 8080으로 보내주겠다.

 

deployment.yaml 정의

여기서의 template 은 PodTemplate으로 자동 지정되어있다. (kind 가 Deploymenta인 경우/)

3개의 Pod ReplicaSet 을 갖는 deployment 파일을 정의했다.

 

Deployment, Service 두개의 리소스 정의가 완료되었다면 실행해보자.

 

 

실행 결과

Pod 가 정상적으로 잘 띄워졌다.

 

 

 

로컬 환경 minikube 실행중이라면
LB Endpoint 를 알아내야한다.

External - IP Pending

로드밸런스 서비스를 정의하고 띄웠음에도 External IP 가 pending 상태로 유지되는 문제가 있는데

이를 해결하기 위해서는 다음 명령어로 서비스의 엔드포인트를 찾아내야한다.

$ minikube service [service-name]

 

 

 

통합 파일 정의

리소스별로 여러 파일을 나눠 관리할 수도 있지만, 하나의 파일로 통합관리 하는 것도 괜찮은 방법이다.

각종 리소스를 한줄의 명령어로 동시에 orchestration 할 수 있기 때문이다.

yaml 파일이 위에서 아래로 해석된다.

 

 

통합 Yaml을 쓴다면,
Service 리소스를 상단에 정의하라.

상단에 Service 를 정의해야 한눈에 외부 요청용 네트워크 정보(ex. 단일 Endpoint) 를 파악할 수 있기 때문이다.

 

반드시 따라야 하는 것은 아니나, 관례처럼 쓰인다.

 

단일 파일에 모든 리소스를 정의하면 한줄의 명령어로 모든 리소스를 제어하기 편하다는 장점이 있다.

 

CLI 한줄로  통합 파일인 both.yaml 에 정의한 deployment 와 service 를 동시에 제거되었다.

 

Selector - Label

Label

쿠버네티스에서 label 은 공통점을 갖는 혹은 공통의 제어 대상인 그룹을 묶기 위한 key-value 다.

 

구체적인 예를 살펴보자.

운영 환경에 따라 리소스를 그룹화 한다고 예를 들어보자.

• "environment" : "dev"
• "environment" : "qa"
• "environment" : "production"

위와 같이 운영환경 - 값을 label 로 두면 공통 환경의 리소스를 한번에 제어할 수 있다.

 

개발 환경 라벨이 붙은 모든 리소스 적용.

Selector

원래 이름은 Label Selector 이다.

Selector 단어 앞에 Label 을 생략하여 부른다.

이름 그대로 Selector 는 특정 라벨을 지정하여 정의된 명령을 내리기 위한 구분자다.

 

---

🔗 Reference

Service