[산대특] Docker Swarm type=volume/bind, Docker Compose, Kubernetes 이론

1107

 

Swarm 모드 사용할 때 외부 호스트의 특정 디렉터리 사용(저장 공간)

docker run -it -name host_dir -v /root:/root ubuntu:14.04

=> 맵핑해서 컨테이너에 저장공간 제공

 

Swarm 모드에서 하는 법

  - volume 타입 사용하기

docker service create --name ubuntu --mount type=volume,source=test,target=/etc/vim/(,volume-nocopy) ubuntu:14.04 ping docker.com

=> swarm 모드로 service create 하는 순간

Manager 나 Worker 노드들 중 랜덤으로 생성되어서 volume 도 랜덤으로 생성된다. 

=> 그래서 확인하려면 생성된 노드로 가서 docker volume ls 해야한다.

 

  - bind 타입 사용하기

docker service create --name ubuntu1 --mount type=bind,source=/root/host,target=/root/container ubuntu:14.04 ping docker.com

=> Task 내부에 /root/container 가 없으면 자동으로 디렉터리 만들어 mount 함.

 

==> Swarm 모드에서는 Volume 비추천

 

 

Docker Compose

APM을 컨테이너를 하나하나 만들지 않고 yaml 파일로 몇 개의 컨테이너를 어떻게 연동하여 사용할 건지 설정해서

docker-compose 기술을 사용하면 한번에 여러 컨테이너를 연계도 해서 생성할 수 있다.

 

# curl -L https://github.com/docker/compose/releases/download/1.11.0/docker-compose-$(uname -s)-$(uname -m) > /usr/local/bin/docker-compose  # chmod +x /usr/local/bin/docker-compose

하여 docker-compose 설치 후 권한 변경

 

# nano docker-compose.yml

version: "3.0" services:   web:     image: alicek106/composetest:web     ports:     - "8088:80"     links:     - mysql:db     command: apachectl -DFOREGROUND   mysql:     image: alicek106/composetest:mysql     command: mysqld

만들려는 내용을 써 놓기

 

구문검사
# docker-compose config
후
# docker-compose up -d
하면 만들어진다. 

 

따로 생성도 가능

# docker-compose up -d web

 

상태 확인

# docker-compose ps

 

컨테이너 들어가기

# docker-compose run web /bin/bash

 

# docker stack deploy --compose-file docker-compose.yml compose_cont

배포된 서비스 확인
# docker stack services compose_cont

# docker stack ps compose_cont

 

 

Kubernetes

Google 에서 개발한 Open Source Container Orchestration(지휘/통제) Tool

수 많은 컨테이너를 관리해주는 도구.

=> Hadoop 의 NameNode 와 유사

 

All-in-One 형태로 Add-on 서비스를 제공

 

Kube EcoSystem

fluentd, elastic, kibana(로깅), console(명령어), Jenkins, clair(CI/CD파이프 라인(workflow)), Grafana, Prometheus(모니터링), Helm, kubeapps(서비스 카탈로그)... 등등이 있다. 

 

장점

∎ H/W 비용대비 클라우드 리소스 비용 최대화

-> 초기 비용 절약 가능

∎ Add-on 서비스 개발/구축비용 절감

-> 개발 및 운영에 필요한 것을 제공하여 별도 비용 발생 X

∎ 운영업무 축소에 따른 비용절감

-> 인건비 X, 라이센스 비용 절감

 

Kubernetes 사이트에 나온 Features

Automated rollouts and rollbacks	자동 변경 취소/되돌림
Storage orchestration	저장소 관리
Automatic bin packing	자동 실행파일 패키징
Service discovery and load balancing	서비스 발견과 로드밸런싱
Secret and configuration management	비밀번호와 구성 관리
Batch execution	배치 실행
IPv4/IPv6 dual-stack	IPv4와 IPv6의 동시 사용
Self-healing	오류 자동 수정
Horizontal scaling	수평적 확장
Designed for extensibility	확장성을 고려한 설계

등의 기법들이 보임.

 

K8s 는 (== Kubernetes)

K8s Cli + K8s Volumes + K8s Network 

를 가지고 있다. 

 

K8s 용어 정리

Cluster	여러 노드를 논리적으로 묶은 하나의 단위. 가장 큰 단위 클러스터가 확장 -> 클라우드
Node	여러 Pods 가 실행될 수 있는 곳.
Pod	최소 단위. 컨테이너의 추상화된 객체 1 컨테이너 = 1 Pod OK / 여러 컨테이너 묶어 = 1 Pod 도 OK Docker 의 Container 처럼 언제든 지우고 새로 만들기 OK -> IP 바뀜
Service	Pod의 유동적 IP를 대표하는 고정_IP 주소 역할 Pod 에 연계되어 있고, 새롭게 생긴 Pod 를 볼 수 있다.
ReplicaSet	Pod 를 관리, Pod 의 수를 일정하게 유지시키는 역할=>’Pod 공장’ Template 을 보고 Pod가 꺼지면 살리는 역할
Deployment	배포할 파드 개수 설정, 파드들의 집합 버전 업그레이드 시 ‘무중단 배포’를 지원 ReplicatSet 을 Template 으로 가지고 있는다.  (개수 파악)
Ingress	Cluster 로 들어오는 요청을 URL 별로 분산 시켜주는 L7 Load Balancer 각각의 Service로 분산시켜주는 역할 Ingress > Service > Pod
Volumes	Pods 의 외부 저장소 클라우드는 프로세스니까 껐다 켜지면 메모리가 휘발성으로 날라가서, DB 같은 서비스는 외부 저장소가 필요
ConfigMap	Pod 실행을 유지하며 간단한 환경설정 변경을 수행할 때 사용
Secret	ConfigMap 에 중요한 정보를 base64 로 인코드하여 저장
Stateful	환경 변수 값, 암호 등과 같이 데이터 값이 일정하게 유지 배포 해야할 때 사용
Kubectl	K8s 의 명령어 도구. Master 에서 사용. 모든 것은 Kubectl 을 통한다.
kubeadm	공식적으로 제공하는 Cluster 생성/관리 도구
kubespray	Cluster 배포 오픈소스 프로젝트 On-Premise에서 Service 운영할 때 다양한 형식의 K8s 클러스터를 관리
Minikube	단일 노드 Cloud 에서 Kubernetes 작업 쉘 스크립트. => like Single Mode Hadoop
Vagrant	멀티 노드 Cloud 에서 Kubernetes 작업 쉘 스크립트 => like Multi Mode Hadoop
ClusterDNS	Node 들 간의 네트워크가 구성되지 않으면 시작되지 않는다.

자세한 설명은 개인 필기 보기!

 

Kubernetes에서 노드 간 네트워크를 제대로 구성하지 않으면, Cluster DNS(CoreDNS)와 같은 중요한 기능들이 제대로 작동하지 않습니다. Kubernetes는 여러 개의 노드(서버)로 이루어진 클러스터 환경에서, 각 노드에 있는 컨테이너(주로 Pod)가 서로 통신할 수 있도록 네트워크 연결을 해야 합니다. 이를 위해 Kubernetes는 CNI(Container Network Interface)라는 네트워크 플러그인을 사용하여 각 노드의 네트워크를 연결합니다.

◆ Kubernetes에서의 CNI(Container Network Interface) 역할

1. CNI 설치와 배포
   Kubernetes 클러스터에서는 CNI를 설치하고 배포해야 노드 간의 네트워크 연결이 가능해집니다. CNI는 (VxLAN으로서 컨테이너 간 통신을 지원하기 때문에) Pod Network라고도 불리며, 각 노드에서 실행되는 컨테이너(파드)들이 서로 통신할 수 있도록 지원합니다.
2. 기본 제공되는 kubenet
   Kubernetes에는 기본적으로 kubenet이라는 네트워크 플러그인이 제공되지만, 기능이 제한적이기 때문에 보통 Flannel, Calico, Weave와 같은 서드파티 네트워크 플러그인들이 사용됩니다. 이 플러그인들은 CNI를 기반으로 더 강력한 라우팅 기능과 보안을 제공합니다.
   

◆ Overlay 네트워크와 CNI

Overlay 네트워크는 각 노드 간에 가상 네트워크를 만들어 네트워크 간 통신을 가능하게 합니다. 이 방식은 기존 네트워크 환경에 영향을 미치지 않으면서 여러 노드들 간의 통신을 가능하게 하는 유용한 방법입니다. Kubernetes 클러스터 내에서, Overlay 네트워크는 패킷 캡슐화라는 방식을 사용해 데이터를 전송합니다. 패킷 캡슐화는 데이터를 다른 네트워크로 전달할 수 있게 패킷을 포장하는 작업을 말합니다.

하지만 Overlay 네트워크는 몇 가지 단점도 있습니다:

• 자원 소모: 패킷을 캡슐화하는 데 CPU 등의 자원이 소모되며, 패킷이 커지기 때문에 전송 효율이 떨어질 수 있습니다.
• 비효율성: 캡슐화로 인해 패킷의 크기가 커지고, 데이터가 패킷을 통해 송수신될 때 전송할 수 있는 데이터의 양이 줄어들어 상대적으로 비효율적일 수 있습니다.

◆ 대표적인 CNI 플러그인들

Kubernetes에서 네트워크를 연결하는 주요 CNI 플러그인으로는 Flannel, Calico, Weave가 있습니다. 각각의 특징을 아래와 같이 정리할 수 있습니다:

1. Flannel
   개발자: CoreOS
   특징: 간단한 Overlay 네트워크로 설치와 구성이 쉬운 플러그인입니다. Kubernetes 설치 시 기본적으로 제공되기 때문에 설정이 간편합니다.
   
   장점으론
   설치와 구성의 용이성: 기본 설치 플러그인으로 매우 간단히 사용 가능.
   
   단점으론
   보안 기능 부족: 보안 기능을 구현하는 데 어려움이 있을 수 있습니다.
   성능 한계: 패킷 캡슐화 방식으로 인해 성능이 상대적으로 떨어질 수 있다.
   
   
2. Calico
   개발자: Tigera
   특징: 성능과 유연성이 뛰어나며, 네트워크 보안과 네트워크 연결 관리가 용이한 플러그인입니다.
   
   장점으론
   성능 우수: BGP(보더 게이트웨이 프로토콜)를 사용해 네트워크 확장성이나 성능이 뛰어납니다.
   보안 설정 용이: 네트워크 보안 정책을 통해 컨테이너 간의 네트워크 접근을 제어할 수 있습니다.
   널리 사용됨: Kubernetes와 같은 환경에서 가장 많이 사용되는 CNI 플러그인 중 하나입니다.
   
   단점으론
   설정이 복잡할 수 있음: Flannel에 비해 설정이 다소 복잡할 수 있습니다.
   
   
3. Weave
   개발자: Weaveworks
   특징: 네트워크 정책, 암호화, 멀티캐스트를 지원하는 고급 기능을 제공하며, Kubernetes뿐만 아니라 다른 오케스트레이션 시스템(예: Docker Swarm, Mesos)도 지원합니다.
   
   장점으론
   네트워크 보안: 암호화 및 네트워크 정책을 지원하여 더 높은 보안을 제공합니다.
   멀티캐스트 지원: 멀티캐스트 통신을 지원하여 더 복잡한 네트워크 환경에서도 활용 가능합니다.
   다양한 오케스트레이터 지원: Kubernetes 외에도 Swarm, Mesos 등 여러 오케스트레이터에서 사용 가능합니다.
   
   단점으론
   설치와 설정이 복잡: Weave는 설치가 다소 복잡하고, 프로프리에터리(상용화된 기능)가 있어 일부 기능은 무료로 사용하기 어려울 수 있습니다.
   
   
4. 결론
   Overlay 네트워크는 여러 노드 간의 네트워크를 연결하는 방식으로, CNI를 통해 구현됩니다. 이를 통해 Pod들이 서로 다른 노드에서도 통신할 수 있습니다.
   CNI는 Flannel, Calico, Weave와 같은 다양한 플러그인을 통해 확장할 수 있습니다. 각 플러그인은 특징과 장단점이 다르므로 클러스터 환경에 맞는 플러그인을 선택해야 합니다.
   Flannel은 설정이 간편하지만 보안 기능이 부족하고 성능이 제한적일 수 있습니다.
   Calico는 성능과 보안이 뛰어나며 유연성이 좋지만, 설정이 다소 복잡할 수 있습니다.
   Weave는 고급 기능을 제공하지만, 설치와 설정이 복잡하고 일부 기능이 상용화된 특징이 있습니다.
   
   

Cgroup(Control Group)은  리눅스에서 프로세스들을 그룹화하여 시스템 리소스를 효율적으로 관리하고 제한할 수 있는 기능 Kubernetes 환경에서 Cgroup은  컨테이너의 리소스를 제어하고 격리하는 역할 ◆ Cgroup의 기본 개념 Cgroup은 프로세스 그룹을 의미 리눅스 커널에서는 시스템의 리소스(CPU, 메모리, 네트워크 대역폭 등)를 프로세스 단위로 관리 Cgroup을 사용하면 특정 프로세스들이 사용하는 리소스를 제한하거나 격리할 수 있습니다. ◆ 컨테이너와 Cgroup 컨테이너는 Cgroup을 사용하여 CPU, 메모리, 네트워크, 블록 I/O와 같은 시스템 자원을 제어하고 제한합니다. 컨테이너가 생성되면 Cgroup이 생성됩니다. 이 Cgroup은 해당 컨테이너의 리소스를 제어하는 역할을 합니다. 여기서 생성되는 프로세스들은 해당 Container Cgroup에 소속된다.  컨테이너 내에서 (Fork System Call을 통해)자식 프로세스가 생성되더라도, 그 자식 프로세스들은 자동으로 부모인 컨테이너의 Cgroup에 포함됩니다. 따라서 컨테이너의 리소스를 제어하려면 이 Cgroup만 조작하면 됩니다. ◆ Kubernetes에서 Cgroup과 Cgroup Driver Kubernetes에서는 Cgroup을 관리하는 드라이버를 사용하여 노드에서 실행되는 컨테이너들을 제어합니다. Cgroup Driver는 Kubernetes에서 컨테이너의 리소스를 어떻게 관리할지 결정하는 요소입니다. 이 드라이버는 kubelet에서 사용됩니다. kubelet은 각 노드에서 컨테이너를 관리하는 컴포넌트입니다. kubelet은 각 노드에 실행 중인 컨테이너들이 필요한 리소스를 적절히 할당하도록 Cgroup을 제어합니다. Cgroup Driver는 control-plane인 master node에서 사용됩니다. Kubernetes에서는 보통 Docker와 같은 컨테이너 런타임을 사용할 때, Docker가 Cgroup을 자동으로 감지하고 사용합니다. ◆ Cgroup Driver가 중요할 때 Cgroup Driver가 제대로 설정되지 않으면, Kubernetes 노드가 정상적으로 동작하지 않을 수 있습니다. 예를 들어, 노드의 상태가 "Pending" 또는 "NotReady"로 보일 수 있습니다. 이는 Kubernetes가 Cgroup을 통해 리소스를 관리할 수 없기 때문입니다. 그래서 Cgroup Driver가 제대로 설정되어야 클러스터가 정상적으로 동작하게 됩니다. ◆ Docker에서의 Cgroup Driver Docker는 컨테이너를 실행할 때 Cgroup을 사용하여 자원 제한을 설정합니다. Docker의 Cgroup Driver는 Kubernetes에서 kubelet이 사용할 Cgroup Driver를 자동으로 감지합니다. Kubernetes와 Docker 간에 Cgroup Driver 설정이 일치해야 클러스터가 원활하게 동작합니다. ◆ 요약: Cgroup은 리눅스 시스템에서 컨테이너와 프로세스의 리소스를 제어하고 격리하는 기능입니다. Kubernetes에서 Cgroup Driver는 컨테이너가 리소스를 적절히 사용하도록 관리하는 역할을 합니다. Cgroup Driver가 제대로 설정되지 않으면, 노드 상태가 "Pending"이나 "NotReady"가 될 수 있어, kubelet이 리소스를 관리하는 데 문제가 생길 수 있습니다. 쉽게 말하면, Cgroup은 리소스를 관리하는 '보호자'이고, Cgroup Driver는 그 보호자가 어떻게 작동해야 할지를 정의하는 설정 파일입니다.

 

 Kubernetes 구성요소의 역할

Master Node

etcd	key-value 형태로 데이터를 저장
kube-apiserver	쿠버네티스의 API를 사용하도록 요청을 받고 유효함을 검사
kube-scheduler	파드를 실행할 노드를 선택
kube-controller-manager	파드를 관찰하며 Replica로 지정한 개수 실행을 보장

Worker node

kubelet	모든 노드에서 실행되는 쿠버네티스 에이전트로써 데몬으로 작동
kube-proxy	쿠버네티스의 네트워크 동작을 관리하고 iptables rule을 구성
container-runtime	컨테이너를 실행하는 엔진으로 Docker, Containerd, runc 등 실행

 

Kubernetes 에서 원격 노드를 일괄 관리하기

Parallel SSH (pssh) 도구들	Parallel SSH (pssh)는 여러 서버에 동시에 명령을 실행하는 도구입니다. 여러 서버에서 동일한 작업을 한 번에 처리해야 할 때 매우 유용. pssh와 함께 제공되는 pscp, prsync, pslurp 등 도구를 사용하면 파일 복사, 동기화, 수집 등의 작업도 병렬로 처리할 수 있다. pdsh는 대규모 서버 환경에서 효율적으로 명령을 실행할 수 있게 도와주는 도구. 이 모든 도구는 SSH 연결을 기반으로 하여 보안성이 뛰어나며, 대규모 환경에서 효율적이고 빠른 작업 처리가 가능. 따라서, 수십 대 혹은 수백 대의 서버에서 동일한 작업을 동시에 실행해야 할 때 pssh나 pdsh 같은 병렬 SSH 도구를 사용하면 매우 효율적이고 시간 절약이 가능.
중앙관리도구	Puppet Puppet은 여러 대의 서버를 중앙에서 자동으로 관리하는 도구. Puppet Master 서버에서 설정 파일을 작성하고, 각 서버에 자동으로 적용할 수 있다. Puppet Agent는 주기적으로 Puppet Master 서버에 접속하여 최신 설정을 받아 적용. 이를 통해 수많은 서버의 설정을 손쉽게 관리하고 일관성을 유지할 수 있다.
	Ansible Ansible은 자동화된 IT 관리 도구로, 설정 관리, 배포, 자동화가 필요한 대규모 시스템에서 매우 유용. Puppet보다 설정이 간단하고, SSH 연결만으로도 원격 시스템을 관리할 수 있어 효율적. 또한, Playbook과 Inventory 파일을 통해 작업을 정의하고, 여러 서버에 동시에 작업을 적용할 수 있어 대규모 시스템 관리에 적합.
	Puppet과 Ansible의 주요 차이점 Puppet은 대규모 환경에서 자동화 및 상태 관리에 강점을 보이는 반면, Ansible은 간단하고 빠른 설정을 필요로 하는 소규모 환경이나 DevOps 파이프라인에 적합. Puppet은 복잡한 설정을 자동화하고 클라이언트 상태를 지속적으로 관리할 때 유리하며, Ansible은 에이전트 설치가 필요 없고 즉시 실행할 수 있어 효율적이고 직관적인 설정을 제공. DevOps 파이프라인은  소프트웨어 개발(Development)과 IT 운영(Operations)을 연결하고 자동화하여, 지속적 통합(CI)과 지속적 배포(CD)를 실현하는 일련의 프로세스를 의미
쿠버네티스 활용	쿠버네티스를 잘 활용하기 위해서는 YAML 파일을 잘 작성하는 것이 중요. YAML 파일을 사용하여 Pod, ReplicaSet, Service, Deployment와 같은 오브젝트들을 정의하고, 이를 통해 효율적으로 애플리케이션을 배포하고 관리할 수 있다. 각 오브젝트가 어떻게 상호작용하는지 이해하고, 이를 통해 컨테이너화된 애플리케이션의 배포, 관리, 확장을 자동화하는 것이 쿠버네티스를 효과적으로 사용하는 핵심.
ClusterIP	고정 IP, 외부에서 진입할 수 있도록 단일 진입점 제공 Deployment에서 정의하거나 Service에서 정의 => usually at Service