search

beadss / docker-study

0 stars 0 forks source link

week(3): kubernetes #8

Open brainbackdoor opened 5 years ago

brainbackdoor commented 5 years ago

1. 쿠버네티스란 무엇인가

쿠버네티스는 컨테이너 운영을 자동화하기 위한 컨테이너 오케스트레이션 도구 많은 수의 컨테이너를 협조적으로 연동시키기 위한 통합 시스템이며 이 컨테이너를 다루기 위한 API 및 명령행 도구 등이 함께 제공된다. 컨테이너를 이용한 애플리케이션 배포 외에도 다양한 운영 관리 업무를 자동화할 수 있다. 도커 호스트 관리, 서버 리소스의 여유를 고려한 컨테이너 배치, 스케일링, 여러 개의 컨테이너 그룹에 대한 로드 밸런싱, 헬스 체크 등의 기능을 갖추고 있다.

쿠버네티스의 역할

도커는 컨테이너를 관리하는 데몬인 dockerd와 명령행 도구로 구성된다. 스웜은 여러 대의 호스트를 묶어 기초적인 컨테이너 오케스트레이션 기능을 제공하는 도커 관련된 기술이다. 쿠버네티스는 스웜보다 충실한 기능을 갖춘 컨테이너 오케스트레이션 시스템이자 도커를 비롯해 여러가지 컨테이너 런타임을 다룰 수 있다. https://hackernoon.com/kubernetes-vs-docker-swarm-a-comprehensive-comparison-73058543771e

2. 로컬 PC에서 쿠버네티스 실행

http://localhost:8001/api/v1/namespaces/kube-system/services/https:kubernetes-dashboard:/proxy/

3. 쿠버네티스의 주요 개념

리소스 용도
Node 컨테이너가 배치되는 서버
NameSpace 쿠버네티스 클러스터 안의 가상 클러스터
Pod 컨테이너의 집합 중 가장 작은 단위로, 컨테이너의 실행 방법을 정의한다.
Replicaset 같은 스펙을 갖는 Pod를 여러 개 생성하고 관리하는 역할을 한다.
Deployment Replicaset의 리비전을 관리한다.
Service Pod의 집합에 접근하기 위한 경로를 정의한다.
Ingress Service를 쿠버네티스 클러스터 외부로 노출시킨다.
ConfigMap 설정 정보를 정의하고 Pod에 전달한다.
PersistentVolume Pod가 사용할 스토리지의 크기 및 종류를 정의
PersistentVolumeClaim Persistent Volume을 동적으로 확보
StorageClass Persistent Volume이 확보하는 스토리지의 종류를 정의
StatefulSet 같은 스펙으로 모두 동일한 Pod를 여러 개 생성하고 관리한다.
Job 상주 실행을 목적으로 하지 않는 Pod를 여러 개 생성하고 정상적인 종료를 보장한다.
Cronjob Cron 문법으로 스케줄링되는 Job
Secret 인증 정보같은 기밀 데이터를 정의한다.
Role NameSpace 안에서 조작 가능한 쿠버네티스 리소스의 규칙을 정의한다.
RoleBinding 쿠버네티스 리소스 사용자와 롤을 연결 짓는다.
ClusterRole 클러스터 전체적으로 조작 가능한 쿠버네티스 리소스의 규칙을 정의한다.
ClusterRoleBinding 쿠버네티스 리소스 사용자와 클러스터롤을 연결 짓는다.
ServiceAccount Pod가 쿠버네티스 리소스를 조작할 때 사용하는 계정

4. 쿠버네티스 클러스트와 노드

컴코넌트명 역할
kube-apiserver 쿠버네티스 API를 노출하는 컴포넌트 kubectl로부터 리소스를 조작하라는 지시를 받는다.
etcd 고가용성을 갖춘 분산 key-value store. 쿠버네티스 클러스터의 백킹 스토어로 쓰인다.
kube-scheduler 노드를 모니터링하고 컨테이너를 배치할 적절한 노드를 선택한다.
kube-controller-manager 리소스를 제어하는 컨트롤러를 실행한다.
1) kubernetes component는 오직 api 서버와 통신한다.

즉, api 서버는 etcd와 통신할 수 있는 유일한 component다.

2) etcd 는 key-value storage로, 모든 object(pod, rc, service, secret 등)을 분산 저장한다.

api server를 통해 간접적으로 읽고 쓰이는데 이때 낙관적 잠금방식을 통해 동시성 제어를 하며 우선순위는 RAFT 알고리즘을 활용한다 (이에 etcd 인스턴스는 홀수여야 한다. https://blog.containership.io/etcd/)

3) kubectl 등의 client로 api server에 post요청을 할때, 인증/권한승인/승인제어 플로그인 등을 거치게 된다. 이 후 api server는 object의 유효성을 검사하고 etcd에 저장한 다음 client에 응답을 전달한다.
4) Scheduler는 Pod가 (1) 스케줄될 수 있는 모든 노드의 목록을 얻은 후 (2)우선순위를 정한다.
(1) 노드가 포드의 하드웨어 리소스 요청을 이행할수 있는지

(2) 노드에 리소스가 부족한지(메모리나 디스크 상태)

(3) 노드가 포드 스펙의 노드 셀렉터에 맞는 라벨을 가질 수 있는지

(4) 특정 호스트 포트에 바인딩 된 경우, 해당 노드에 포트가 이미 사용되고 있는지

(5) 포드가 특정 볼륨 유형을 요청하는 경우 이 볼륨을 노드가 마운트 할 수 있는지

등의 부분을 체크한다.

  1. 네임스페이스

  2. 파드

실제 포드 컨테이너는 Worker node에서 실행된다.
1) kubectl을 사용하여 (api server에) Deployment Resource를 생성요청을 하면, 

2-1) Deployment Controller가 이를 감지하고 (api server에) ReplicaSet 요청을 한다.

2-2) 이를 ReplicaSet Controller가 감지하고 (api server에) Pod 생성 요청을 한다. 

2-3) Scheduler는 이를 감지하고 Node에 Pod를 할당하며

3) Kubelet은 node에 스케줄되는 pod 할당을 감지하고 pod의 container를 실행하고 api 서버에 보고한다.

패드 생성 및 배포하기 파드 다루기

  1. 레플리카세트

  2. 디플로이먼트 레플리카세트의 생애주기 쿠버네티스는 디플로이먼트를 단위로 애플리케이션을 배포한다. 실제 운영에서는 레플리카세트를 직접 다루기보다는 디플로이먼트 메니페스트 파일을 통해 다루는 경우가 대부분이다. 디플로이먼트가 관리하는 레플리카세트는 지정된 개수만큼 파드를 확보하거나 파드를 새로운 버전으로 교체하거나 이전 버전으로 롤백하는 등 중요한 역할을 한다.

replicas 값만 변경해서는 레플리카세트의 교체가 일어나지 않는다. 이미지를 수정하면 새로운 리비전이 생성된 것을 확인할 수 있다.

롤백 실행하기 kubectl rollout history deployment echo --revision=1 kubectl rollout undo deployment echo

  1. 서비스 서비스는 쿠버네티스 클러스터 안에서 파드의 집합(주로 레플리카세트)에 대한 경로나 서비스 디스커버리를 제공하는 리소스다. 서비스의 대상이 되는 파드는 서비스에서 정의하는 레이블 셀렉터로 정해진다. ClusterIP 서비스 NodePort 서비스 LoadBalancer 서비스 External 서비스

10 인그레스 쿠버네티스 클러스터 외부로 서비스를 공개하려면 서비스를 NodePort로 노출시킨다. 그러나 이 방법은 L4레벨까지만 다룰 수 있기 때문에 L7레벨의 제어는 불가능하다. 인그레스를 통해 접근하기