[k8s] 쿠버네티스 찍먹 - 2

이 글은 아래의 의존성을 가진다.

2023.03.01 - [Backend MLOps/On-premise setting] - [k8s] 쿠버네티스 찍먹 - 1

[k8s] 쿠버네티스 찍먹 - 1

 

이제는 책에서 안내해 준 깃헙 저장소로 이동한다.

그리고 미리 작성된 vagrantfile과 각종 쉘 스크립트, yaml파일을 가져온다.

 

이전 글에서 설명한 vagrantfile의 버그픽스 부분을 주어진 자료에서 수정하고 4대의 가상머신을 올린다.

 

본 책에서는 여러가지 에러사항을 만들고 그에 따라 어떤 현상이 발생하는지

예컨데 프록시 서버를 죽이면 어디서 데드락이 발생하는지 등을 설명한다.

 

 

// kubectl

쿠버네티스는 크게 관리자 격인 마스터 노드와 실재로 배포가 진행되는 워커노드가 있는데

마스터 노드의 API서버를 통해서 거의 모든 일을 진행한다.

이때 API서버와 통신하는 방법이 kubectl을 사용하는 것이며

전송된 모든 "상태"는 etcd에 저장된다.

이때 선언한 "추구하는 상태"는 모든 워커노드들의 표준이 되며

API서버의 능동적인 상태 설정이 아닌 워커노드들의 능동적 상태 교정을 통해서

선언된 "추구하는 상태"와 동일한 상태를 워커노드들이 유지하도록 한다.

 

따라서 kubectl의 경우 API 서버와 통신하는 수단이기 때문에

반드시 마스터노드에 존재할 필요가 없고

다만 어느 곳에 존재하든 마스터 노드의 API 서버와 통신만 연결되어 있으면 된다.

따라서 kubectl은 팟들의 상태를 스스로 감시하는 것이 불가능 하다.

 

현재는 kubectl이 모든 노드에 존재하지만

마스터 노드의 API서버와 통신하도록 설정된 것은

마스터 노드 내부의 kubectl이 유일하다. 

따라서 마스터 노드를 제외한 모든 노드들에서는

서버와 접속하는 것이 불가능하다는 에러를 띄운다.

같은 클러스터 내부에 있어도 kubectl의 접근권한에 따라 다른 결과가 나온다.

 

// kubelet

kubelet의 경우는 파드의 생성, 복구, 상태 관리 등 라이프사이클을 관리하는 도구이다.

책에서는 워커노드에서 이 kubelet이 죽는 경우 마스터노드에서 상태를 수정하려 하면 데드락이 걸리는 현상을 보여준다.

실재로 제공된 코드들에서도 알 수 있듯

각 가상머신을 부팅할 때 kubectl, kubelet, kubeadm 을 모든 노드에서 다운로드하고

그 즉시 kubelet을 실행하여 사용가능한 상태로 만들어 준다.

 

// kubeadm

kubeadm은 쿠버네티스를 사용하는 많은 방식(어떻게 표현하는게 맞는건지 아직 이해하지 못했다)중 하나로

쿠버네티스의 마스터노드를 시작하여 클러스터를 만들고

워커노드를 마스터노드에 등록시키는 과정을 가능하게 해준다.

 

// 파드 배포

파드를 배포하는 과정은

1. kubectl을 이용해서 마스터노드의 API서버와 통신

2. 입력된 상태를 API서버가 etcd에 기록

3. etcd는 기록이 완료되었음을 API서버에 보고

4. 마스터 노드의 컨트롤 메니져가 최신 기록 상태의 파드를 생성

5. 정상적으로 생성되었다면 스케줄러가 최신 상태를 임의의 워커노드에 적용

6. kubelet이 상태를 수정

으로 진행된다고 한다.

하지만 명령은 1 만 수행하면 된다.

 

파드는 nginx의 배포용 이미지를 기반으로한 컨테이너로 파드의 모든 정보는 yaml파일로 저장되어 있다.

배포가 되었다.