240405 k9s로 리소스 관리, Kubernetes 엔진 구조, Kubernetes CNI

네트워크 캠퍼스/쿠버네티스

240405 k9s로 리소스 관리, Kubernetes 엔진 구조, Kubernetes CNI

gayeon_ 2024. 4. 5. 17:20

k9s로 리소스 관리해 보기

k9s는 CLI를 이용해서 리소스 관리를 돕는 도구다.

터미널 기반의 UI를 제공해 kubectl이라고 매 명령마다 적지 않아도 된다.

UI를 제공하기는 하기때문에 손쉽게 다룰수 있다.

먼저 master에 설치파일을 받았다.

압축을 풀어준다.

명령어를 배치할 수 있는 절대경로를 확인한 다음에

k9s를 확인된 경로인 /usr/local/bin 경로 하위로 옮겼다.

그리고나서 k9s를 실행하면 위와 같이 뜬다.

방향키로 하단 pod창에서 생성된 pod들에 대한 정보를 확인할 수 있다.

kubectl get po(d) -A 처럼 사용할 수 있다.

종료는 :q

를 입력하면 된다.

k9s 정보를 확인했다.

k9s로 돌아와보면 방향키로 pod들에 대한 정보를 확인할 수 있고

상단에는 pod를 지목했을 때 쓸 수 있는 옵션이 적혀있다.

?를 입력하면 더 많은 명령어를 볼 수 있다.

:로 추가 명령어를 작성할 수 있다.

ex) namespace 확인 시 :ns 입력

Kubernetes 엔진 구조 이해하기

쿠버네티스 기초적 구조

쿠버네티스에는 하나 이상의 Control plane(마스터 노드로)이 있고

해당 노드의 제어를 받는 Data plane(워커 노드)이 있다.

노드는 위와 같이 조회할 수 있다.

get으로 조회하는 요소는 no 와같이 축약해 적어도 동작한다.

쿠버네티스 설치 시 위와 같이 manifests 폴더 내에 Control plane 구성에 필요한 yaml파일이 자동으로 세팅되고

그것을 통해 마스터 노드가 필수적으로 돌려야 하는 설계구조가 완성된다.

pod 구성에 필요한(컨테이너 구성에 필요한) 선언적 파일이다.

클러스터의 종류

단일 클러스터로 구조를 정할수도 있지만 (컨트롤 플레인에 여러개의 데이터 플레인)

멀티클러스터 형태의 구성도 가능하다. (여러 단일 클러스터를 분배필터 1개가 관리)

각 영역의 역할

컨트롤 플레인은 전체 클러스터를 관리하고 API 트래픽을 이용해 사용자가 요구하는 형태로 전체 노드의 구조를 유지한다.

각 노드는 Control plane과 통신하는 kubelet daemon을 이용해 containerd, docker등을 이용해서 컨테이너를 생성한다.

(구조는 노션에서)

이렇게 etcd 자체에 대한 접근도 가능하다.

exit로 빠져나온다.

각 노드들은 kubelet을 통해 네트워킹을 하게 된다.

이 때 CNI를 사용한다.

또한 현재 우리 설정에서는 Kubelet을 활용해 containerd를 생성하게 된다.

그리고 k-proxy가 노드의 가동상태를 감시하게 도와준다.

kubectl api-resources

로 pi통신 간 사용할 수 있는 자원을 조회한다.

선언형 : yaml코드에 작성해서 사용

명령어 : 터미널에서 바로 명령어를 쳐서 사용

EKS등의 클라우드 업체에서 제공하는 쿠버네티스 제어 서비스는

보통 Control plane을 클라우드 서비스에서 대시보드만으로 추가할 수 있게 해 주고

Data plane을 직접 만들어서 생성된 Control plane에 연동하도록 도와주는 경우가 많다.

따라서 Control plane의 구조에 대해 잘 알고 있어야 해당 서비스도 잘 다룰수 있다.

pstree

pstree를 조회해보면 containerd가 보이고 하위에는 containerd-shim이 있다.

그 하위에는 apiserver, controller, scheduler 등이 보인다.

쿠버네티스의 노드

노드는 하나의 클러스터에 소속된 단일 인스턴스 내지는 서버를 의미한다.

노드를 기반으로 pod를 실행할 수 있다.

pod 내부에 비로소 우리가 실행시키는 최소 단위인 컨테이너가 존재한다.

Control plane은 Worker node와 그 위에서 실행되는 pod를 관리한다.

동일한 컨테이너를 Pod를 다르게 실행할 수 있으므로 결국 내결함성 + 고가용성이 보장된다.

이런 노드들은 kube-controller-manager에 의해 5초마다 노드상태를 체크해 api서버에 전송한다.

이런 상호 체크에 관련된 파라미터는 원하는 값으로 변경 가능하다.

노드 내부 요소들

kubelet

Control plane, Data plane에 모두 존재
pod를 실행, 생성, 변경, 삭제 하기 위해 Control plane의 api서버와 통신 수행
container runtime을 사용해서 image를 가져와 컨테이너로 띄우는 작업 수행

containerd

컨테이너를 유지하고 통신하도록 지원, 라이프사이클에 관여

kube-proxy

pod를 외부에 노출시키는것이 목표.

kubectl get po -A -o wide

를 입력하면 pod를 노출시키기 위한 kube-proxy가 4개 돌아가고 있다.

kube-proxy의 최고 우측을 보면 각 하나씩 배분된것을 볼 수 있다.

같은 pod를 여러 노드에 나눠서 띄우는 특성상 당연히 내부적으로 교환이 필요하다.

그렇기 때문에 아이피를 할당해놓고 dns를 제공하는데 이것을 coredns라고 한다.

coredns의 정체도 역시 kubectl get pod -A로 확인할 수 있다.

올라가는 node는 랜덤이다.

kube-dns서비스를 확인했다.

DNS에는 우리가 생성한 모든 자원이 등록되고 추후 내부적으로 통신이 가능한 상태가 된다.

redis pod를 하나 생성한 뒤 서비스를 노출시킨다.

그리고 양쪽에 대한 조회를 해보니 2개의 아이피가 할당되어 있다.

그리고 busybox를 이용해 nslookup으로 조회할 것이다.

busybox는 도커에서도 썼던 경량화된 리눅스 컨테이너다.

해당 아이피 주소로 nslookup을 날려준다.

위와 같이 10.96.0.10 이라는 kube-dns의 아이피를 통해서 접속되는 것을 볼 수 있다.

Kubernetes CNI와 어플리케이션 배포 과정 체험하기

CNI

CNI는 Interface(명세) CNI 기준에 맞는 구현체를 실제 기술로 활용하게 된다.
이 과정에서 k8s는 기본적으로 kubenet이라는 자체 네트워크 구현체를 제공하지만 너무 기능이 빈약하기 때문에 따로 개발된 구현체를 주로 활용한다.
이 실습에서는 calico라는 구현체를 선택해서 사용한다.

이런 명세를 정의하게된 계기는 각 노드별로 부여받는 IP대역이 다르지 않고 하나의 큰 대역을 활용해서 배정받기 때문에 자칫 잘못하다가는 POD들끼리 같은 IP를 부여받는 일이 생길수도 있다.

이를 방지하기 위해서 절대 중복되지 않는 유일한 값을 나눠주기 위해 CNI가 필요하다.

또한 삭제시에도 IP를 회수하는 규칙이 필요하기 때문에 이런 표준을 정의해놓게 되었다.