파드 배포 중심으로 쿠버네티스 구성요소 살펴보기

• kubectl get nodes : 쿠버네티스 클러스터에 생성된 노드정보들을 조회가능
• kubectl get pods -all-namespaces : 모든 네임 스페이스에서 파드를 수집해 보여준다.

설치된 쿠버네티스 구성요소들을확인가능 (기본 네임스페이스인 deafault 외에 모든것을 표시)

• 쿠버네티스 클러스터를 이루는 구성요소들은 파드형태로 이루어져 있다.

쿠버네티스 구성요소 이름 생성 규칙

• 동시에 여러개가 존재하는 경우 중복된 이름을 피하기위해 뒤에 해시코드가 삽입된다.

파드 배포 순서

마스터 노드

1. kubectl: 쿠버네티스 클러스터에 명령을 내리는 역할을 한다.
   1. 바로 실행되는 명령 형태인 binary로 배포되어 마스터노드에 있을필요는 없다.
2. API서버
   1. 쿠버네티스 클러스터의 중심역할을 하는 통로
3. etcd
   1. 구성 요소들의 상태값이 모두 저장되는곳
   2. 분산저장이 가능한 key-value 저장소이다, 복재하여 여러 곳에 저장해 두면 하나의 etcd에서 장애가 나더라도 시스템의 가용성을 확보할 수 있다.
4. 컨트롤러 매니저
   1. 쿠버네티스 클러스터의 오브젝트 상태를 관리한다.
   2. 워커노드에서 통신이 되지 않는경우, 상태체크와 복구는 컨트롤러 매니저에 속한 노드 컨트롤러에서 이루어진다.
   3. 다양한 상태값을 관리하는 주체드링 컨트롤러 매니저에 소속돼 각자의 역할을 수행한다.
5. 스케줄러
   1. 노드의 상태와 자원, 레이블, 요구조건등을 고려해 파드를 어떤 워커 노드에 생성할 것인지를 결정하고 할당한다.
   2. 파드가 워커 노드에 할당되는 일정을 관리하는 역할도 한다.

워커 노드

1. kubelet
   1. 파드의 구성내용을 받아서 컨테이너 런타임으로 전달하고, 파드 안의 컨테이너들이 정상적으로 작동하는지 모니터링
2. 컨테이너 런타임
   1. 파드를 이루는 컨테이너의 실행을 담당한다.
   2. 파드 안에서 다양한 종류의 컨테이너가 문제없이 작동하게 만드는 표준 인터페이스
3. 파드
   1. 한 개 이상의 컨테이너로 단일 목적의 일을 하기 위해서 모인 단위
   2. 웹서버 역할을 할 수도 있고 로그나 데이터를 분석할 수도 있다.
   3. 파드는 언제라도 죽을 수 있는 존재다. ⇒ 여러가지 대안을 제공

선택 가능한 구성요소

1. 네트워크 플러그인
   1. 쿠버네티스 클러스터의 통신을 위해 필요하며,일반적으로 CNI로 구성한다.
2. CoreDNS
   1. 클라우드 네이티브 컴퓨팅 재단에서 보증하는 프로젝트, 빠르고 유연한 DNS 서버
   2. 쿠버네티스 클러스터에서 도메인 이름을 이용해 통신하는데 사용한다.

사용자가 배포된 파드에 접속할때

• kube-proxy: 쿠버네티스 클러스터는 파드가 위치한 노드에 kube-proxy를 통해 파드가 통신할 수 있는 네트워크를 설정한다.
  • 실제 통신은 br_netfilter와 iptables로 관리한다.
• 파드: 이미 배포된 파드에 접속하고 필요한 내용을 전달받는다.(파드가 어떤 워커노드에 위치하는지 신경안써도됨)

파드의 생명주기로 쿠버네티스 구성 요소 살펴보기

파드의 생명주기

1. kuebectl을 통해 API 서버에 파드 생성을 요청한다.
2. API 서버에 전달된 내용이 있으면 API 서버는 etcd에 전달된 내용을 모두 기록해 클러스터의 상태값을 최신으로 유지한다. 각요소가 상태를 업데이트할 때마다 모두 API 서버를 통해 etcd에 기록된다.
3. API 서버에 파드 생성이 요청된 것을 컨트롤러 매니저가 인지하면 컨트롤러 매니저는 파드를 생성하고, 이상태를 API 서버에 전달한다.
4. API 서버에 파드가 생성됬다는 정보를 스케줄러가 인지하고, 스케줄러는 생성된 파드를 어떤 워커노드에 적용할지 조건을 고려해 결정하고 해당 워커 노드에 파드를 띄우도록 요청한다.
5. API 서버에 전달된 정보대로 지정한 워커 노드에 파드가 속해 있는지 스케줄러 가 kubelet으로 확인한다.
6. kubelet에서 컨테이너 런타임으로 파드 생성을 요청한다.
7. 파드가 생성된다.
8. 파드가 사용 가능한 상태가 된다.

• 쿠버네티스는 작업을 순서대로 진행하는 워크플로(작업절차) 구조가 아니라 선언적인 시스템 구조를 가지고 있다.
• 추구하는 상태를 선언하면 현재 상태와 맞는지 점검하고 그것에 맞추려고 노력하는 구조로 돼있다.
• 추구하는 상태를 API 서버에 선언하면 다른 요소들이 API 서버에 와서 현재상태와 비교하고 그에 맞게 상태를 변경하려고 한다.
• API는 현재 상태 값을 가지고 있는데, 이것을 보존하기 위해 etcd가 필요하다.
• 마스터 노드는 선언적 시스템으로 설계된 반면, 워커 노드는 워크플로 구조에 따라 설계되있다.
• 상태변경 ↔ 감시 ↔ 차이발견

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

kubectl

• 쿠버네티스 외부에서 쿠버네티스 클러스터에 명령을 내릴 수도 있다.
• kubectl이 어디에 있더라도 API 서버의 접속 정보만 있으면 어느 곳에서든 쿠버네티스 클러스터에 명령을 내릴 수 있다.

kubelet

• 파드의 생성과 상태 관리 및 복구 등을 담당
• kubectl get pod 배포된 파드가 정상적으로 배포된 상태인지 확인
• kubectl get pods -o wide 파드가 배포된 워커 노드 확인
• systemctl stop kubelet kubelet 서비스를 멈춘다.
• systemctl start kubelet kubelet 서비스를 시작.
• kubectl delete pod pod이름 파드 삭제

kube-proxy

• 파드의 통신을 담당한다.
• br_netfilter 커널 모듈을 적재하고 iptables를 거쳐 통신
• curl(client URL)로 파드의 IP로 nginx 웹서버 메인 페이지 내용을 확인한다.
• systemctl restart network : 네트워크를 다시 시작
• modprobe br_netfilter : br_netfilter 적재
• modprobe -r br_netfilter : br_netfilter 제거

putty - networkError connection refused
방화벽 문제였다.
VM Box에서 iptable에 22번포트 방화벽 해제해줌
# iptables -A INPUT -p tcp -m tcp --dport=22 -j ACCEPT
https://jootc.com/p/201806061218