쿠버네티스 구성 요소의 기능 검증

쿠버네티스 구성 요소의 기능 검증

쿠버네티스의 구성 요소를 좀 더 이해하기 쉽게 구성 요소들의 역할과 의미를 확인해보겠습니다.

kubectl

쿠버네티스 클러스터의 외부에서 쿠버네티스 클러스터에 명령을 내릴 수 있습니다.

1. 슈퍼푸티 세션 창에서 w3-k8s를 더블클릭해 터미널에 접속 합니다.

그리고 kubectl get nodes 명령어를 실행합니다.

명령을 실행하면 쿠버네티스의 노드들에 대한 정보가 표시되지 않습니다. why?? 쿠버네티스 클러스터의 정보를

kubectl이 알지 못하기 때문입니다. 파드 생명주기로 쿠버네티스 구성 요소를 보면 kubuctl은 API 서버를 통해 쿠버네티스에 명령을 내립니다. 따라서 kubectl이 어디에 있더라도 API 서버의 접속 정보만 있다면 어느 곳에서든

2. 쿠버네티스 클러스터의 정보(/etc/kubenetes/admin.conf)를 마스터 노드에서 scp(Secure copy) 명령으로

w3-k8s의 현재 디렉터리(.)에 받아옵니다.

3. kubectl get nodes 명령에 추가로 쿠버네티스 클러스터 정보를 입력받는 옵션(--kubeconfig)과

마스터 노드에서 받아온 admin.conf를 입력하고 실행합니다.

kubelet

쿠버네티스에서 파드의 생성과 상태 관리 및 복구 등을 담당하는 매우 중요한 구성 요소 입니다.

따라서 kubelet에 문제가 생기면 파드가 정상적으로 관리되지 않습니다.

1. 일단 기능을 검증하기 위해 파드를 배포합니다.

m-k8s(마스터노드)에서 kubectl create -f ~/_Book_k8sInfra/ch3/3.1.6/nginx-pod.yaml 명령으로 nginx 웹 서버 파드를 배포합니다. 여기서 -f 옵션은 filename을 의미 합니다.

즉, 파드의 구성 내용을 파일로 읽어 들여 1개의 파드를 임의의 워커 노드에 배포하는 것 입니다.

2. kubectl get pod 명령으로 배포된 파드가 정상적으로 배포된 상태(Running)인지 확인 합니다.

3. kubectl get pods -o wide 명령을 실행해 파드가 배포된 워커 노드를 확인 합니다.

-o는 output의 약어로 출력을 특정 형식으로 해 주는 옵션 이며, wide는 제공되는 출력 형식 중에서 출력 정보를

더 많이 표시해 주는 옵션 입니다.

4. 배포된 노드인 w3-k8s에 접속해 systemctl stop kubelet으로 kubelet 서비스를 멈춥니다.

5. m-k8s에서 kubectl get pod로 상태를 확인 하고, kubectl delete pod nginx-pod 명령을 입력해서

파드를 삭제 합니다.

6. 다시 kubectl get pod 명령을 실행해 파드의 상태를 확인 합니다.

결과를 보면 nginx-pod를 삭제(Terminating)하고 있습니다. 하지만 kubelet이 작동하지 않는 상태라 파드는

삭제되지 않습니다.

7. 내용을 확인했으면, w3-k8s에서 systemctl start kubelet을 실행해 kubelet을 복구 합니다.

8. 그 후, m-k8s에서 kubelet get pod 명령을 실행해 nginx-pod가 삭제됐는지 확인 합니다.

kube-proxy

kubelet이 파드의 상태를 관리한다면 kube-proxy는 파드의 통신을 담당 합니다.

내려받은 config.sh 파일에는 br_netfilter 커널 모듈을 적재하고 iptables를 거쳐 통신하도록 설정되어 있습니다.

그런이 이 설정이 정상적으로 작동하지 않는다면?

즉, kube-proxy에 문제가 생기면 어떻게 될지 알아보겠습니다.

1. 마스터 노드인 m-k8s에서 다시 파드를 배포 합니다.

그리고 kubectl get pod -o wide 명령으로 파드의 IP와 워커 노드를 확인 합니다.

2. curl로 파드의 전 단계에서 확인한 파드의 IP로 nginx 웹 서버 메인 페이지 내용을 확인 합니다.

4. 앞의 배포 명령에 나온 노드인 w2-k8s에 접속해 modprobe -r br_netfilter 명령으로 파드가 위치한

워커 노드에서 br_netfilter 모듈을 제거 합니다. 그리고 네트워크를 다시 시작해 변경된 내용을 적용 합니다.

이렇게 kube-proxy에 문제가 생기는 상황을 만듭니다.

5. m-k8s에서 다시 한 번 curl로 파드의 nginx 웹 서버 페이지 정보를 받아옵니다.

아마 파드에서 정보를 받아오지 못할 것입니다.

6. kubectl get pod -o wide를 실행해 파드 상태를 확인 합니다.

파드의 노드 위치와 IP가 변경되지 않았는지, 작동 상태에 문제가 없는지 확인합니다.

문제가 없어 보이지만, kube-proxy가 이용하는 br_netfilter에 문제가 있어서 파드의 nginx 웹 서버와의

통신만이 정상적으로 이루어지지 않는 상태 입니다.

7. 정상적으로 파드의 nginx 웹 서버 페이지 정보를 받아올 수 있는 상태로 만들기 위해,

워커노드에서 modprobe br_netfilter 명령을 실행해 br_netfilter를 커널에 적재하고 시스템을 다시 시작하여 적용 합니다.

8. m-k8s에서 파드의 상태를 확인하면 파드가 1회 다시 시작했다는 의미로 RESTARTS가 1로 증가하고

IP가 변경된 것을 확인 할 수 있습니다.(밑의 이미지에는 RESTARTS가 2로 되어있는데, 재시작을 한번 더 해서

그렇습니다.

9. 바뀐 IP로 curl 명령을 실행해 파드로부터 정보르 정상적으로 받아오는지 확인하고,

확인이 됐으면 배포한 파드를 삭제 합니다.

참조 - 컨테이너 인프라 환경 구축을 위한 쿠버네티스/도커 (조훈, 심근우, 문성주 지음)

from http://puzzle-moon.tistory.com/85 by ccl(A) rewrite - 2021-12-29 22:00:59