| Table of Contents |
|---|
K8s는 여러 컨테이너 런타임을 지원하며, 여기서는 Docker 런타임을 기본으로 설명한다.
(Docker 18.09 이상에서는 containerd를 Docker에서 기본으로 탑재한다)
그러므로, Docker에 대한 기본 개념 및 사용법을 알고 있다고 가정한다.
...
지원하는 애플리케이션의 유형을 제약하지 않는다.
소스 코드를 배포하지 않으며 애플리케이션을 빌드하지 않는다.
애플리케이션 레벨의 서비스를 제공하지 않는다.
로깅, 모니터링 또는 경보 솔루션을 포함하지 않는다. 즉, 메트릭을 수집하고 노출하는 메커니즘을 제공한다.
K8s는 단순한 오케스트레이션 시스템이 아니다. 사실, K8s는 오케스트레이션의 필요성을 없애준다. 오케스트레이션의 기술적인 정의는 A를 먼저 한 다음, B를 하고, C를 하는 것과 같이 정의된 워크플로우를 수행하는 것이다. 반면에, K8s는 독립적이고 조합 가능한 제어 프로세스들로 구성되어 있다. 이 프로세스는 지속적으로 현재 상태를 입력받은 의도한 상태로 나아가도록 한다. A에서 C로 어떻게 갔는지는 상관이 없다. 중앙화된 제어도 필요치 않다. 이로써 시스템이 보다 더 사용하기 쉬워지고, 강력해지며, 견고하고, 회복력을 갖추게 되며, 확장 가능해진다.
...
kubelet
cluster의 각 노드에서 실행되는 에이전트.
Kubelet은 파드에서 컨테이너가 확실하게 동작하도록 관리.Kubelet은 8s를 통해 생성되지 않는 컨테이너는 관리하지 않는다.
kube-proxy
kube-proxy는 cluster의 각 노드에서 실행되는 네트워크 프록시로, K8s의 서비스 개념의 구현부
kube-proxy는 노드의 네트워크 규칙을 유지 관리한다. 이 네트워크 규칙이 내부 네트워크 세션이나 cluster 바깥에서 파드로 네트워크 통신을 할 수 있도록 해준다.
kube-proxy는 운영 체제에 가용한 패킷 필터링 계층이 있는 경우, 이를 사용한다. 그렇지 않으면, kube-proxy는 트래픽 자체를 포워드(forward)한다.
Container runtime
컨테이너 실행을 담당하는 소프트웨어
도커(Docker), containerd, CRI-O 그리고 Kubernetes CRI (컨테이너 런타임 인터페이스)를 구현한 모든 소프트웨어 지원.
...
DNS
K8s에 의해 구동되는 컨테이너는 DNS 검색에서 이 DNS 서버를 자동으로 포함한다
웹 UI (대시보드)
컨테이너 resource 모니터링
컨테이너 resource 모니터링은 중앙 데이터베이스 내의 컨테이너들에 대한 포괄적인 시계열 매트릭스를 기록하고 그 데이터를 열람하기 위한 UI를 제공해 준다.
cluster-레벨 로깅
cluster-레벨 로깅 메커니즘은 검색/열람 인터페이스와 함께 중앙 로그 저장소에 컨테이너 로그를 저장하는 책임을 진다.
Understanding Terms(중요)
| Info |
|---|
여기서는 아래 블로그를 포함하여 각종 관련 사이트 및 K8s 공식 사이트 문서를 참고하여, 보다 간략히 k8s에 대한 이해에 반드시 필요한 개념 위주로 추려서 기술한다. 내용 中 일부 출처: https://bcho.tistory.com/1256?category=731548 [조대협의 블로그] |
...
그래서 이렇게 DB등과 같이 상태를 가지고 있는 Pod를 지원하기 위해서 StatefulSet Stateful Set 이라는 것이 새로 소개되었는데, 이를 이해하기 위해서는 K8s의 디스크 볼륨에 대한 이해가 필요하다.
...
Replication controller or Replica Set
Replica Set의 목적은 Replica Pod집합의 실행을 항상 안정적으로 유지하는 것이다. 이처럼 Replica Set은 보통 명시된 동일 Pod 개수에 대한 가용성을 보증하는데 사용한다.
Replica Set은 Replication Controller 의 새 버전으로 생각하면 된다.
큰 차이는 없고 Replication Controller 는 Equality 기반 Selector를 이용하는데 반해, Replica Set은 Set 기반의 Selector를 이용한다.
크게 3가지 파트로 구성되는데, Replica의 수, Pod Selector, Pod Template 3가지로 구성된다.
Selector : 먼저 Pod selector는 라벨을 기반으로 하여, RC가 관리한 Pod를 가지고 오는데 사용한다.
Replica 수 : RC에 의해서 관리되는 Pod의 수인데, 그 숫자만큼 Pod 의 수를 유지하도록 한다.예를 들어 replica 수가 3이면, 3개의 Pod만 띄우도록 하고, 이보다 Pod가 모자르면 새로운 Pod를 띄우고, 이보다 숫자가 많으면 남는 Pod를 삭제한다.
Pod를 추가로 기동할 때 그러면 어떻게 Pod를 만들지 Pod에 대한 정보 (도커 이미지, 포트,라벨등)에 대한 정보가 필요한데, 이는 Pod template이라는 부분에 정의 한다.
...
Deployment
실제 환경에서는 replica 수만 유지하는 것만 필요한 것이 아니라, 배포 방식 및 업데이트 방식과 함께 정책을 정하고 이를 반영해야 한다. 이를 위해 Deployment라는 선언적/추상적 상위 개념이 존재한다.
따라서, 사용자 지정 오케스트레이션이 필요하거나 업데이트가 전혀 필요하지 않은 경우라면 Replica Set을 직접적으로 사용하기 보다는 Deployment를 사용하는 것을 권장한다.
Blue/Green 배포 방식
가장 단순한 업데이트 배포 방식으로, 블루(예전)버전으로 서비스 하고 있던 시스템을 그린(새로운)버전을 배포한 후, 트래픽을 블루에서 그린으로 한번에 돌리는 방식이다.
...
위 그림에서 보는 바와 같이 이 방식을 사용하기 위해서는 일시적으로 나마 시스템 리소스가 (대략) 2배가 필요하다.
즉, 항상 업데이트 할 수 있는 정도의 여유 Stage가 필요하다.
Rolling update
가장 많이 사용되는 배포 방식 중의 하나 이며, 단순화된 과정은 다음 그림과 같다.
(아래 예에서는 RC를 사용하였으나, RS(Replica Set)으로 대체해도 무관하다, 최근에는 RS가 대세로 사용된다.)
먼저 RC를 하나 만들어서 기존 RC에서 replica 수를 하나 줄이고, 새로운 RC에는 replica 수를 하나만 준다.
...
기존 RC에서 replica 수를 또 하나 줄이고, 새로운 RC에는 replica 수를 하나 더 추가해준다.
...
마찬가지 작업을 반복하게 되면, 아래 그림과 같이 예전 버전의 Pod가 모두 빠지고 새 버전의 Pod만 서비스 되게 된다.
...
만약에 배포가 잘못되었을 경우에는 기존 RC의 replica 수를 원래대로 올리고, 새 버전의 replica 수를 0으로 만들어서 예전 버전의 Pods로 Rollback이 가능하다.
Deployment controller
여러가지 배포 방식을 RC나 RS를 이용해서 구현할 수 있지만, 운영이 복잡해지는 단점이 있다. 그래서 쿠k8s에서는 일반적으로 RC나 RS를 이용해서 배포하지 않고 Deployment라는 개념을 사용한다.
앞에서 보았듯이 rolling update 등을 할 때, RC를 두 개를 만들어야 하고, 하나씩 Pod의 수를 수동으로 조정해야 하기 때문에, 이를 자동화해서 추상화한 개념이 Deployment 이다.
위 rolling update에서의 과정을 아래 그림과 같이 Deployment controller가 대신하여 자동으로 관리해 준다.
...
| Info |
|---|
위에서 각 RC[S]와 Pod들, 서비스들, deployment들 간의 연결 구조 즉, 포함 관계는 label 및 seletor라는 개념으로 서로 간에 매핑한다. 이들 label은 각 yaml spec에 정의하도록 되어 있다. |
Volume
Service
Secret
Service Account
...