도커부터 시작하여 쿠버네티스까지 각 서비스의 기능 및 구성요소에 대해 자세히 소개해 드립니다 | Learn more about the features and components of each service, starting with a Docker and ending with Kubernetes.

1. 네이버 비즈니스 플랫폼 윤성훈
클라우드 시장의 대세, Kubernetes란 무엇인가?

2. Contents.
 Docker Networking
 Kubernetes
 Kubernetes 구성
 Why Container orchestration tool?
 Kubernetes 기능

3. VM .vs. Container
• Virtualization은 단일 시스템에서 여러 OS가 동시에 실행
• Container는 동일한 OS 커널을 공유하며 시스템의 나머지 부분으로 프로세스를 격리
• 기존 가상화 기반으로 많이 사용되는 OS 전체 가상화 방식이 아닌, 하나의 OS 커널 위에 각각의 개별 프로세스
와 그에 따른 환경을 격리화 시키는 방식이다. OS 가상화 보다 오버헤드가 적고, 성능 손실이 적음.

4. Docker Networking
• Docker0
• Linux Bridge (L2)
• IP pool 내에서 Prv IP 자동 할당
• 동일 호스트에 생성되는 모든 Container들은 같은 Docker0에 바인딩
• 각 Container는 외부 또는 다른 Container와 통신을 위해
Linux Bridge로 통신
• Container와 Linux Bridge 간 veth pair 생성
• Container 각각은 Linux namespace를 이용해 독립된 network 영역을 할당
• 각 Container는 의도한 Port만 노출(Expose)해서 통신

5. • Docker Networking mode : default : bridge
• Container IP Pool
• CIDR : 172.17.0.0/16 (default)
• Container Private IP
Docker Networking

6.  Docker0
• 동일 호스트, 동일 network Container의 gateway 역할
• Kubernetes Cluster 구성 시에는 CNI0가 docker0 역할
 Container eth0
• docker0 veth와 연결
• docker0 IP range 중 임의 할당
 Container Routing table
• Container의 default GW 가 docker0로 설정
Docker Networking

7. Docker Networking : East – West Communication
동일 호스트 Container 간 통신
172.17.0.2
호스트
172.17.0.3
Docker0

8. • 한계
• 동일 호스트, 동일 bridge 내 Container 간 사용 가능
• 여러 호스트에 분산된 Container의 통신을 위해서는 overlay network add-on 도입 필요
• Container 라이프사이클 특성 상 IP를 이용한 통신에 한계
• Container 호스트 파일을 이용한 도메인을 이용한 통신
EX) Container 간 link 연결
Docker Networking : East – West Communication : Linking
172.17.0.2 172.17.0.3
호스트
Docker0
link
docker run –d --name mysql mysql
docker run –d --name apache --link mysql httpd

9.  Custom Network 당 Linux Bridge 생성
 동일 Network 바인드 Container 간 사설 통신 가능
 동일 호스트, 다른 Network 바인드 Container 간 통신은 불가
• 서로 다른 VLAN 간 통신 위해 OVS 혹은 외부 Router 필요한 것과 동일
 한계
• 동일 호스트, 동일 bridge 내 Container 간 사용 가능
• 여러 호스트에 분산된 Container의 통신을 위해서는 추가 overlay network add-on 도입 필요
Docker Networking : East – West Communication: Custom Network

10. Docker Networking : East – West Communication
다른 호스트 Container 간 통신?
 앞에서 설명한 link, Custom Network 생성은 scope : local
 Overlay Network add-on 도입 필요 (OVS, flannel, Calico, weave 등)
Con #3
호스트 #2
Docker0
호스트 #1
eth0 eth0
Docker0
Con #2 Con #4 Con #5 Con #6Con #1
Overlay Network : weave / flannel
Network 1
Network 2
Network 3

11. • Overlay Network flannel를 활용한 멀티 호스트 Container 간 통신 env 구성
• Network Overlay add-on 별 특징 존재, 상황에 맞는 적합한 add-on 선택 필요
• 하기 예는 Flannel를 이용한 예시
• cni0 bridge 생성
• default GW
• 멀티 호스트 Container들은 10.244.0.0/16 대역 중 하나 임의 할당
Docker Networking : East – West Communication : Kubernetes

12. 외부와의 통신이 필요해요~
• Container expose : -p / -P
```
docker run –d –p 8080:80 --name test nginx
```
• Kubernetes의 경우는 Service 오브젝트를 통해서 외부에 Container 오픈 : LoadBalancer, NodePort 등
Docker Networking : South – North Communication

13. • Docker 호스트의 iptables를 이용한 DNAT / SNAT
Docker Networking : South – North Communication

15. Kubernetes?

16. Kubelet Kube-proxy
Worker Node
ContainerContainer ContainerContainer
PodPod
Kubernetes 구성 요소
API Server
Scheduler
Controller-Manager
Replication
Controller
Endpoint
Controller
Node
Controller
Service
Controller
etcd
Kubernetes Master (Control Plane)
Kubelet Kube-proxy
Worker Node
ContainerContainer ContainerContainer
PodPod
Kubectl
Docker
Registry
Monitoring
External
Connection
CLI / UI
Admin
Plugin Network (Flannel , Calico ..)

17. Kubernetes 구성 요소 – Master Node
API Server Scheduler
Controller-Manager
Replication
Controller
Endpoint
Controller
Node
Controller
Service Account
TokenController
etcd
Kubernetes Master (Control Plane)
Kubernetes Cluster 에서 컨테이너의 관리 및 배포를 관
리하는 액세스 제어 플레인
클러스터 복제 패턴에 따라 마스터 수는 1개 이상임
Kubernetes Master
Kubernetes API 를 노출하는 컴포넌트로, Kubernetes
오브젝트 관리/제어를 위한 프론트 엔드
API Server
Node 가 배정되지 않은 새로 생성된 Pods 를 감지하고 그
것이 구동될 Node 를 선택함
Scheduler
4개의 컨트롤러는 논리적으로는 개별 프로세스이지만
복잡성을 낮추기 위해 단일 바이너리로 컴파일
Controller-Manager
• Node Controller : 노드가 다운되었을 때 통지와 대응
• Replication Controller : 모든 replication controller
object 에 대해 알맞는 수의 pods 를 유지
• Endpoint Controller : 서비스와 Pods 를 연결
• Service Controller : 새로운 네임스페이스에 대한 기본
계정과 API 접근 토큰 생성
모든 클러스터 데이터를 담는 key-value 저장소
Replicaset, controller, scheduler, kubelet 등은 etcd 에
바로 접근하지 않고 API Server 를 통해 etcd 데이터에 접근
할 수 있음
Etcd

18. Kubernetes 구성 요소 – Worker Node
동작중인 Pods 를 유지시키고 Kubernetes 런타임 환경
을 제공함
Kubernetes Worker Node
각 Node 에 구동되는 Agent 로 Kubernetes Master 와
통신하며 Pod Spec 에 기술된 컨테이너들이 정상적으로
작동하도록 함
Kubelet
호스트 상에서 네트워크 규칙을 유지하고 연결에 대한 포
워딩을 수행함으로서 쿠버네티스 서비스 추상화가 가능하
도록 함
Kube-proxy
컨테이너가 실행될 수 있는 환경
(Docker, containerd, cri-o, rktle 등)
Container Runtime
Kubelet Kube-proxy
Worker Node
ContainerContainer
ContainerContainer
PodPod
WEB UI Monitoring
Plugin Network DNS
Kubernetes 기본 네트워크인 kubenet 은 기능 제약이
있어 사용자 요구사항에 따라 별도의 CNI 를 사용함
Plugin Network
Kubernetes 서비스를 위해 DNS 레코드를 제공해주는
DNS 서버, 기본 kube-dns 를 제공하나 성능 개선을 위
해 별도의 플러그인 DNS 를 사용하기도 함
DNS
Kubernetes 클러스터를 위한 범용의 웹 기반 UI 로 클러
스터와 클러스터 내 동작하는 어플리케이션에 대한 관리와
실패 처리가 가능함
WEB UI
중앙 데이터베이스 내에 컨테이너들에 대한 포괄적인 시계
열 메트릭스를 기록하고 데이터 조회를 위한 UI 제공함
Resource Monitoring

19. Why Container orchestration tool?
멀티 호스트 Container 간 통신?
 앞에서 설명한 docker0, link, Custom Network 생성은 scope : local
 Overlay Network add-on 도입 필요 (OVS, flannel, Calico, weave 등)
Con #3
호스트 #2
Docker0
호스트 #1
eth0 eth0
Docker0
Con #2 Con #4 Con #5 Con #6Con #1
Network 1
Network 2
Network 3

20. Why Container orchestration tool?
멀티 호스트 Container 간 통신?
 앞에서 설명한 docker0, link, Custom Network 생성은 scope : local
 Overlay Network add-on 도입 필요 (OVS, flannel, Calico, weave 등)
Con #3
호스트 #2
Docker0
호스트 #1
eth0 eth0
Docker0
Con #2 Con #4 Con #5 Con #6Con #1
Overlay Network : flannel / Calico / weave
Network 1
Network 2
Network 3
Kubernetes

21. Why Container orchestration tool?
Container
Docker0
호스트 #1
Con #1 Con #2
eth0
Docker0
호스트 #2
Con #3 Con #4
eth0
Docker0
호스트 #3
eth0
Con #5 Con #6 Con #7 Con #8
? ? ?
추가 컨테이너는 어디에 위치?
 호스트 리소스 (CPU, MEM..)와 affinity 설정
등 여러 요소 기준으로 스케줄링 노드 선정 가능

22. Why Container orchestration tool?
Container
Docker0
호스트 #1
Con #1 Con #2
eth0
Con #4 Con #5 Con #6 Con #7
컨테이너 failure resistance?
 Replication Controller(Replicaset)
 Deployment
X
Docker0
호스트 #2
Con #3 Con #4
eth0
Docker0
호스트 #3
eth0
Con #5 Con #6 Con #7 Con #8
X

23. Why Container orchestration tool?
Container
Docker0
호스트 #1
Con #1 Con #2
eth0
컨테이너 failure resistance?
 Replication Controller(Replicaset)
 Deployment
Con #4 Con #5 Con #6 Con #7
X
Docker0
호스트 #2
Con #3 Con #4
eth0
Docker0
호스트 #3
eth0
Con #5 Con #6 Con #7 Con #8
X
Con #9

24. Why Container orchestration tool?
Container
Docker0
호스트 #1
Con #1 Con #2
eth0
Docker0
호스트 #2
Con #3 Con #4
eth0
Docker0
호스트 #3
eth0
Con #5 Con #6 Con #7 Con #8
컨테이너 failure resistance?
 Replication Controller(Replicaset)
 Deployment
X

25. Why Container orchestration tool?
Container
Docker0
호스트 #1
Con #1 Con #2
eth0
Docker0
호스트 #2
Con #3 Con #4
eth0
Docker0
호스트 #3
eth0
Con #5 Con #6 Con #7 Con #8
컨테이너 failure resistance?
 Replication Controller(Replicaset)
 Deployment
XCon #9 Con #10 Con #12Con #11

26. Why Container orchestration tool?
Load Balancer
컨테이너 교체가 필요한데?
 Rolling update
Pod #1
Replication Controller
Pod #2 Pod #4Pod #3

27. Why Container orchestration tool?
컨테이너 교체가 필요한데?
 Rolling update
Replication Controller Replication Controller v2
Load Balancer
Pod #1
X
Pod #2 Pod #4Pod #3 Pod #5

28. Why Container orchestration tool?
컨테이너 교체가 필요한데?
 Rolling update
Replication Controller Replication Controller v2
Load Balancer
Pod #1
X
Pod #2 Pod #4Pod #3 Pod #5
X
Pod #6

29. Kubernetes 기능
Automatic Binpacking Service Discovery & Load Balancing
Secret & Configuration Management Batch Execution
Storage Orchestration Self Healing
Horizontal Scailng Automatic Rollbacks & Rollouts
Worker node 의 가용성을 유지하면서 보유한 리소스를
충분히 활용할 수 있도록 스스로 스케쥴링하며
컨테이너를 배치함
컨테이너에 IP 주소를 자동으로 할당하고 클러스터 내
트래픽을 로드 밸런싱 할 수 있는 컨테이너 세트에
단일 DNS 이름을 할당함
로컬 저장소를 선택하거나 NFS, iSCSI 등과 같은
공유 네트워크 스토리지를 컨테이너에 할당/마운트 하여
사용 가능함
실패한 컨테이너를 자동으로 다시 시작하고, 사용자가 정의한
헬스체크에 응답이 없는 컨테이너를 종료함. 워커 노드 장애 시
사용 가능한 다른 워커 노드에 컨테이너를 다시 기동함
Application 연동 및 접근 제어를 위한 보안 키, 설정 내역을
컨테이너 이미지의 변경 없이 업데이트 할 수 있고 외부로
노출하지 않고 사용 가능함
CPU 사용률과 같은 metric 을 기반으로 pod 의 Deployments,
replicaset 을 스케줄링하여 수평적 확장 가능함
컨테이너 기반의 서비스 관리 뿐 아니라 배치 및 CI 작업 부하를
관리할 수 있으므로 원하는 경우 실패한 컨테이너 대체 가능함
컨테이너의 응용 프로그램이나 구성에 대한 변경 사항을 점진적으로
업데이트 하고 문제 발생 시 자동으로 롤백 할 수 있음

30. The End of Document
Thank you