쿠버네티스(k8s) 개념 정리

[쿠버네티스]

- 구성 : 클러스터 -> Namespace ->Service -> Node(WorkerMachine) -> Pod(컨테이너화된 애플리케이션의 모음)

* Container : Pod안에 실제 app.

 

기본 오브젝트 (Basic Object)

쿠버네티스에 의해서 배포 및 관리되는 가장 기본적인 오브젝트는 컨테이너화되어 배포되는 애플리케이션의 워크로드를 기술하는 오브젝트로 Pod,Service,Volume,Namespace 4가지가 있다.

 

간단하게 설명 하자면 Pod는 컨테이너화된 애플리케이션, Volume은 디스크, Service는 로드밸런서 그리고 Namespace는 패키지명 정도로 생각하면 된다. 그러면 각각을 자세하게 살펴보도록 하자.

Pod

Pod 는 쿠버네티스에서 가장 기본적인 배포 단위로, 컨테이너를 포함하는 단위이다.

쿠버네티스의 특징중의 하나는 컨테이너를 개별적으로 하나씩 배포하는 것이 아니라 Pod 라는 단위로 배포하는데, Pod는 하나 이상의 컨테이너를 포함한다.

출처: https://bcho.tistory.com/1256 [조대협의 블로그]

---

[Cluster 란]

 

a) Cluster 구성도

클러스터 구성도

클러스터 구성도(2)

---

클러스터 아키텍처 구성예시

b) 개념 

- Cluster는 쿠버네티스의 여러 리소스를 관리하기 위한 집합체를 말한다.

기본적으로 클러스터에는 작업자 노드와 마스터 노드가 포함되며 마스터 노드는 어느 애플리케이션을 실행하고 애플리케이션이 어느 컨테이너 이미지를 사용할지와 같이 클러스터를 원하는 상태로 유지 관리한다. 작업자 노드는 애플리케이션과 워크로드를 실제로 실행함.

---

[Namespace 란]

a) Namespace 구성도

네임스페이스 설정 예시

b) 개념 

- 네임스페이스는 한 쿠버네티스 클러스터내의 논리적인 분리단위라고 보면 된다. (가상 클러스터 개념)

Pod,Service 등은 네임 스페이스 별로 생성이나 관리가 될 수 있고, 사용자의 권한 역시 이 네임 스페이스 별로 나눠서 부여할 수 있다.

즉 하나의 클러스터 내에, 개발/운영/테스트 환경이 있을때, 클러스터를 개발/운영/테스트 3개의 네임 스페이스로 나눠서 운영할 수 있다. 네임스페이스로 할 수 있는 것은

• 사용자별로 네임스페이스별 접근 권한을 다르게 운영할 수 있다.
• 네임스페이스별로 리소스의 쿼타 (할당량)을 지정할 수 있다. 개발계에는 CPU 100, 운영계에는 CPU 400과 GPU 100개 식으로, 사용 가능한 리소스의 수를 지정할 수 있다.
• 네임 스페이스별로 리소스를 나눠서 관리할 수 있다. (Pod, Service 등)

 

주의할점은 네임 스페이스는 논리적인 분리 단위이지 물리적이나 기타 장치를 통해서 환경을 분리(Isolation)한것이 아니다. 다른 네임 스페이스간의 pod 라도 통신은 가능하다.

물론 네트워크 정책을 이용하여, 네임 스페이스간의 통신을 막을 수 있지만 높은 수준의 분리 정책을 원하는 경우에는 쿠버네티스 클러스터 자체를 분리하는 것을 권장한다.

---

[Service 란]

a) Service 구성도

SERVICE 구성도

b) 개념 

- Pod와 볼륨을 이용하여, 컨테이너들을 정의한 후에, Pod 를 서비스로 제공할때, 일반적인 분산환경에서는 하나의 Pod로 서비스 하는 경우는 드물고, 여러개의 Pod를 서비스하면서, 이를 로드밸런서를 이용해서 하나의 IP와 포트로 묶어서 서비스를 제공한다.

- Pod의 경우 보통 1개로 운영하지 않고, 여러개의 Pod을 띄워서 로드밸런싱을 제공해줘야 한다.
이때, 이러한 역할을 해주는 리소스가 Pod들 앞단에 하나 더 존재해야하는데, 서비스가 이러한 역할을 한다.
서비스는 지정된 IP로 생성이 가능하고, 여러 Pod를 묶어서 로드 밸런싱이 가능하며, 고유한 DNS 이름을 가질 수 있다.

서비스가 Pod 들을 묶을 때는 레이블과 셀렉터 라는 개념을 사용.

 

---

[Node 란]

a) Node 구성도

 

NODE의 구성도

b) 개념 

- Node는 클러스터의 관리 대상으로 등록된 도커 호스트로, 도커 컨테이너가 배치되는 대상이다. 그리고 쿠버네티스 클러스터 전체를 관리하는 서버인 마스터가 적어도 하나 이상 있어야한다. 여기서 하나 이상이라는 말은 클러스터가 작동하기 위한 최소 조건이지만 실제 프러덕 환경에서는 절대 하나로 클러스터를 구성하지 않는다. 최소 3개 이상의 마스터 노드를 갖는 것이 좋다.

출처: https://coding-start.tistory.com/308 [코딩스타트]

 

 

c) Master 노드 구성 사항

컴포넌트	역할
kube-apiserver	쿠버네티스 API를 노출하는 컴포넌트이다. kubectl로부터 리소스를 조작하라는 지시를 받는다.
etcd	고가용성을 갖춘 분산 키-값 스토어이다. 쿠버네티스 클러스터의 백킹 스토어로 사용된다.
kube-scheduler	노드를 모니터링하고 컨테이너를 배치할 적절한 노드를 선택한다.
kube-controller-manager	리소스를 제어하는 컨트롤러를 실행한다.

출처: https://coding-start.tistory.com/308[코딩스타트]

---

[Pod 란]

a) Pod 구성도

Pod의 구성도

b) 개념

-여러개의 컨테이너를 포함하고 있다. pod 단위로 ip를 나누며 쿠버네티스의 가장 기본적인 배포 단위(컨테이너)이다.
우리가 알고있는 도커 컨테이너와는 조금 다른게, 하나의 Pod는 하나 이상의 컨테이너를 포함할 수 있는 구조이다.
즉 웹서버를 구성한다고 할 때 nginx pod, spring-boot pod, mysql pod 를 각각 띄워야 하는 것이 아니라 이 컨테이너들을 모두 하나의 pod에 넣을 수 있다는 의미이다.

 

---

[쿠버네티스 주요 개념]

• 노드 : 컨테이너가 배치되는 서버 (쿠버네티스 리소스에서 가장 큰 개념)
• 네임스페이스 : 쿠버네티스 클러스터 안의 가상 클러스터, (PC의 하드디스크에 있는 폴더와 비슷한개념.)
• 파드 : 컨테이너의 집합 중 가장 작은 단위로, 컨테이너의 실행 방법을 정의한다.
• 잡 : 한번만 실행되고 완료된 이후에는 다시 시작하지 않는 파드.
• 레플리카세트 : 같은 스펙을 갖는 파드를 여러 개 생성하고 관리하는 역할을 한다. 레플리카= 파드
• 레플리카 컨트롤러 : https://lascrea.tistory.com/198
• 디플로이먼트 : 레플리카 세트의 리비전(변경로그)을 관리한다. 레플리카 세트가 자신이 올려야하는 파드들을 확인하고 이상있으면 다시 켜거나 죽인다. Deployment 오브젝트의 목적은 'ReplicaSet을 만드는 것' 이고, ReplicaSet 오브젝트의 목적은 'Matchlabel에 대응하는 Pod를 생성하는 것' 이다. 일종의 관리 프로그램(주기적으로 프로그램이 죽었는지 살아있는지 판단해서 죽어있으면 살리는 역할을함. ex)systemd, runit, supervisord)  
  *주의 : 기본적으로 쿠버네티스는 APP을 오래 실행되고 신뢰할수있도록 설계되어있기 때문에, 디플로이먼트는 컨테이너가 작업을 마치고 종료되거나 kubectl로 컨테이너를 종료하는 경우에도 재시작을 시킨다. 그리고 클러스터단위로 존재하는듯하다.
• 디플로이먼트 매니패스트 : 쿠버네티스를 제어하기 위해서 kubectl run 명령어를 사용하지 않아도된다. 리소스 매니패스트(리소스에 대한 의도한 상태의 스펙)를 직접 생성하고 수정하면 된다. 명령어를 실행하여 변경 사항을 적용하는 대신에 매니페스트 파일을 소스 제어에 보관하고 수정한 후 쿠버네티스가 이를 반영하도록 요청하면된다. (Ex) json형식이나 yaml형식으로 사용한다.)
  
• 서비스 : 파드의 집합에 접근하기 위한 경로를 정의한다.(ex) 엔드포인트 포드포워딩)
• 스케줄러 : 디플로이먼트가 파드를 생성하고 쿠버네티스는 요청된 파드를 실행한다. 이때 쿠버네티스 스케줄러는 이과정을 책임지는 컴포넌트로 디플로이먼트가 관련된 레플리카셋을 통해 새로운 레플리카가 필요하다고 결정하면, 쿠버네티스 DB에 파드 리소스를 직접 생성하고 동시에 이 파드는 스케줄러 수신함과 같은 대기열에 추가된다. 스케줄러의 역할은 대기열에서 스케줄링되지 않은 파드를 찾아 배치하고 실행할 노드를 찾는 것이다. *과정 참고 : 위의 작업을 수행하기전에 적절한 노드를 선택하기 위해 파드 리소스 요청을 포함한 몇 가지 사항을 기준으로 삼는데 파드가 노드에 스케줄링되면 노드에서 실행중인 kublet이 실제로 컨테이너를 실행한다. 파드를 삭제했을 때 상태 변화를 감지하고 새로운 파드로 교체한것은 kubelet이다. Kubelet은 보고있는 파드가 현재 노드에서 실행 중이여야 한다는 것을 안다. 현재 노드에서 보고있는 파드를 찾지 못한다면 새로운 파드를 실행한다.(만약 노드 전체가 종료되면 어떻게 될까? 해당 노드의 파드는 스케줄링되지 않은 상태가 되고 스케줄러 대기열로 돌아가 다른 노드에 재할당된다.)
• 컨트롤러 : 디플로이먼트 리소스를 관리하는 역할로 리소스가 존재하고 작동하는지 확인하여 만약 디플로이먼트 리소스가 특별한 이유 없이 레플리카 수를 채우지 못한 채 실행중이라면, 컨트롤러는 새로운 레플리카를 생성한다.
• 컨트롤 플레인 : 클러스터의 두뇌 역할을 하며 컨테이너 스케줄링, 서비스 관리, API 요청 처리등의 작업을 수행한다.
• 컨텍스트 : 클러스터, 사용자, 네임스페이스의 조합.(북마크의 개념과 비슷)
• 인그레스 : 서비스를 쿠버네티스 클러스터 외부로 노출시킨다.
• 컨피그맵 : 설정 정보를 정의하고 파드에 전달한다.
• 퍼시스턴트 볼륨 : 파드가 사용할 스토리지의 크기 및 종류를 정의.
• 퍼시스턴트볼륨 클레임 : 퍼시스턴트 볼륨을 동적으로 확보.
• 스토리지클래스 : 퍼시스턴트 볼륨이 확보하는 스토리지의 종류를 정의.
• 스테이트풀세트 : 같은 스펙으로 모두 동일한 파드를 여러 개 생성하고 관리한다.
• 잡 : 상주 실행을 목적으로 하지 않는 파드를 여러개 생성하고 정상적인 종료를 보장한다.
• 크론잡 : 크론 문법으로 스케줄링되는 잡.
• 시크릿 : 인증 정보 같은 기밀 데이터를 정의한다.
• 롤 : 네임스페이스 안에서 조작 가능한 쿠버네티스 리소스의 규칙을 정의한다.
• 롤바인딩 : 쿠버네티스 리소스 사용자와 롤을 연결 짓는다.
• 클러스터롤 : 클러스터 전체적으로 조작 가능한 쿠버네티스 리소스의 규칙을 정의한다.
• 클러스터롤바인딩 : 쿠버네티스 리소스 사용자와 클러스터롤을 연결 짓는다.
• 서비스 계정 : 파드가 쿠버네티스 리소스를 조작할 때 사용하는 계정.
• 헬름 : (ex)임의의 변수 container.name 과 container.port와 같은 값을 변수로 정의하고 필요할 때마다 YAML 파일에서 사용할수있다.)
• 활성 프로브 : 컨테이너가 살아 있는지(작동하는지) 확인하는 헬스 체크를 컨테이너 스팩에 활성 프로브로 지정할수있다. (종류가 여러개 ex) httpGet, tcpSocket exec 프로브)

 

[위 내용 요약]

• 파드는 쿠버네티스의 기본 작업 단위로 스케줄링이 될 단일 컨테이너나 컨테이너의 그룹을 지정한다.
• 디플로이먼트는 파드를 선언적으로 관리하는 고수준 쿠버네티스 리소스다. 배포, 스케줄링, 업데이트 작업을 수행하며 필요하다면 파드를 재시작한다.
• 서비스는 쿠버네티스의 로드 밸런서나 프록시에 해당하며 IP 주소나 DNS 이름을 통해 트래픽을 일치하는 파드로 라우팅한다.
• 쿠버네티스 스케줄러는 노드에서 아직 실행되지 않는 파드를 감시하고 적합한 노드를 찾은 다음 해당 노드의 kubelet이 파드를 실행하도록 지시한다.
• 디플로이먼트와 같은 리소스는 쿠버네티스의 내부 데이터베이스에 레코드로 표시된다. 외부적으로 이러한 리소스는 YAML 형식의 텍스트 파일 (매니페스트라고 함)로 표현된다. 매니패스트는 리소스의 의도한 상태를 선언한다.
• kubectl은 쿠버네티스와 상호작용하기 위한 주요 도구로 매니페스트를 적용하고 리소스를 조회, 변경, 삭제하는 등의 많은 작업을 수행할 수 있다.
• 헬름은 쿠버네티스 패기키 매니저로 쿠버네티스 애플리케이션을 쉽게 구성하고 배포할수 있게 해준다. 직접 원시 YAML 파일을 관리할 필요 없이 하나의 값 세트(애플리케이션 이름이나 수신 포트와 같은)나 템플릿의 세트를 사용하여 쿠버네티스 YAML 파일을 생성할 수 있게 해준다.