interplanetary detour

Docker Summary

리눅스 컨테이너 기반의 오픈 소스 가상화 플랫폼.

도커 컨테이너 이미지는 운영체제에 구애받지 않고, 새롭게 패키지를 설치할 필요도 없으며, 각종 라이브러리에 대한 의존성의 문제 또한 걱정할 필요가 없다. 만든 컨테이너를 다른 서버로 그대로 옮겨다 놓으면 환경, 모듈 등이 그대로 적용되기 때문에 별도의 환경설정도 필요하지 않다.

도커 컨테이너들은 HostOS로부터 GuestOS로 물리적 리소스를 1/n로 나누어 할당받는 것이 아닌 HostOS의 리소스를 다이렉트로 접근해 모든 컨테이너가 공유하며 사용하기 때문에 다른 가상화 방법에 비해 속도가 매우 빠르고 효율적이다.

도커는 Layered File System 기반이다. 마치 포토샵처럼 레이어 단위로 컨테이너 이미지를 생성하며, 이 컨테이너들은 서버 위에서 각각 하나의 프로세스처럼 작동하지만 컨테이너 자신은 스스로가 운영체제인 것처럼 생각한다.

각 도커 컨테이너는 서로 간에 절대적으로 격리(Isolated)되어 있어 한 컨테이너에 어떤 변화가 발생하더라도 다른 컨테이너에 영향을 주지 않는다.

Registry, Images, Containers, Commands and Daemon in Docker

• Public과 Private Registry 중 Public Repository를 Docker Hub라고 부르며, Docker Hub에서 이미지를 올리는 것을 Push, 이미지를 받아 오는 것을 Pull이라고 한다. Pull한 이미지는 /var/lib/docker/overlay2에 저장된다.
• Build는 직접 이미지를 생성하는 것인데 여러가지 베이스 환경을 설정해서 이미지 파일을 만든 후에 Run을 하여 프로세스에 올려 컨테이너로 만들거나 Docker Hub로 Push 할 수 있다.
• Run은 이미지를 실행하는 명령어인데 이미지가 없을 경우 Pull로 레지스트리에서 이미지를 받아온 후 Run, Start까지 한다. Run을 하게 되면 최대 3가지 처리가 동시에 이루어지고 이미지가 비로소 컨테이너가 되고 프로세스에 올라가게 된다.
• 실행되고 있는 컨테이너를 Commit해서 현 상태를 이미지로 만들어 Docker Hub로 Push 할 수 있다.
• 메모리에 올라간 컨테이너를 Kill하면 컨테이너의 프로세스가 종료된다.
• 메모리에 올라가면 컨테이너(read/write), 올라가지 않은 상태면 이미지(read only)이다.
• 이 모든 것을 백그라운드에서 실행하고 관리하는 서비스를 dockerd(Docker Daemon)이라고 한다.
• Docker Daemon을 돌리는 머신은 Docker Host라고 한다(Linux Server).

아래는 Docker Hub의 링크인데 Official Image 인증 마크가 있는 이미지는 안전하지만 그 이외의 이미지는 안전을 보장할 수 없다.

https://hub.docker.com 

레이어화 된 컨테이너 이미지

도커의 컨테이너 이미지는 3단의 레이어로 구성되며, 각 레이어는 고유의 UUID(Process ID)를 갖고 있다.

• Base Image Layer
  
  • 주로 가상적으로 OS를 구성하는 레이어.
  • 컨테이너의 가장 밑단, 배경이 되는 환경이 구축된다. 컨테이너의 냉동 설비라고 볼 수 있다.
• Source Code Layer
  
  • 실행할 소스 코드가 위치하는 레이어.
  • 컨테이너에 싣는 도구라고 볼 수 있다.
• Execution Layer
  • 실제로 소스 코드를 실행하는 레이어.
  • 컨테이너의 도구를 사용하게 되는 레이어이다.

가상환경 플랫폼 실행 단위

가상머신: Instance

도커: Container

쿠버네티스: Pod

Containers in Pod

기본적으로 하나의 Pod 당 1개의 컨테이너를 갖게 하는 걸 권장한다. 사이드카로 보조 컨테이너를 넣어 2개의 컨테이너를 돌아가게 하는 경우도 있지만, 3개부터는 권장하지 않는다.

쿠버네티스에서는 NAT 통신 없이도 Pod 고유의 IP + 컨테이너 별 Port 주소를 통해 각 컨테이너에 접근할 수 있다. 같은 Pod 내의 컨테이너들은 사실 상 모두 같은 IP 주소를 가진 상태이기에 서로 localhost와 개별 포트넘버를 통해 네트워크 접근을 한다.

같은 Pod 내의 컨테이너들은 반드시 동일 노드에 할당되며 동일한 생명 주기를 가진다. Pod 삭제 시, 그 Pod 내의 모든 컨테이너가 전부 같이 삭제된다. 또한 모두 같은 볼륨에 연결되어 있어 파일 시스템을 기반으로 서로 파일을 주고 받을 수 있다.

[labels] in [metadata]

# 원래 상태

kubectl get pod mynginx -o yaml

# 라벨 추가

kubectl label pod mynginx hello=world

# 변경점 확인

kubectl get pod mynginx -o yaml

# 라벨 확인

kubectl get pod mynginx --show-labels

# run label이 다른 또 하나의 Pod 생성

kubectl run yournginx --image nginx

# key가 run인 Pod 출력

kubectl get pod mynginx -l run

-l = label

# key가 run, value가 mynginx인 Pod 출력

kubectl get pod mynginx -l run=mynginx

# 워커 노드1에 라벨 부여

kubectl label node k8s-w1 disktype=ssd

# 워커 노드2에 라벨 부여

kubectl label node k8s-w2 disktype=hdd

# 워커 노드3에 라벨 부여

kubectl label node k8s-w3 disktype=hdd

# disktype에 대해 노드들의 라벨 확인

kubectl get node --show-labels | grep disktype

# 새로 만들 Pod(node-selector)의 yaml 파일 생성

nano node-selector.yaml

# node-selector.yaml
apiVersion: v1
kind: Pod
metadata:
  name: node-selector
spec:
  containers: 
  - name: nginx
    image: nginx
  # 특정 노드 라벨 선택
  nodeSelector:
    disktype: ssd

# nodeSelector 프로퍼티로 인해 이 Pod는 disktype이 ssd인 노드에서 실행될 것이다.

# node-selector Pod 생성

kubectl apply -f node-selector.yaml

# Pod가 어느 노드에서 실행되고 있는지 확인 : disktype을 ssd로 지정해뒀던 k8s-w1에서 실행되고 있을 것이다.

kubectl get pod node-selector -o wide

# node-selector.yaml 수정

nano node-selector.yaml

# node-selector.yaml
apiVersion: v1
kind: Pod
metadata:
  name: node-selector
spec:
  containers: 
  - name: nginx
    image: nginx
  # 특정 노드 라벨 선택
  nodeSelector:
    disktype: hdd

# disktype이 hdd인 노드는 2개이기 때문에 쿠버네티스 마스터가 알아서 판단해서 할당한다.

# yaml 파일 재적용

kubectl apply -f node-selector.yaml

# Pod가 어느 노드에서 실행되고 있는지 확인 : k8s-w2, k8s-w3 중 하나일 것이다.

kubectl get pod node-selector -o wide

[command], [args] in [spec]

# vi editor 사용해보기 - i로 편집 모드 진입 → 수정 후 esc키 → :wq 입력으로 저장 & 나가기

vi cmd.yaml

# cmd.yaml
apiVersion: v1
kind: Pod
metadata:
  name: cmd
spec:
  restartPolicy: OnFailure
  containers: 
  - name: nginx
    image: nginx
    # 실행명령
    command: ["/bin/echo"]
    # 파라미터
    args: ["hello"]

# 여기서 눈여겨 봐야 하는 부분은 restartPolicy인데, Always, Never, OnFailure 3가지 값을 줄 수 있다.

# Always: Pod 종료 시 항상 재시작(default), Never: 재시작을 시도하지 않음, OnFailure: 실패 시 재시작

# 그런데 여기서 echo 명령은 웹 서버와 다르게 실행 후 종료되기 때문에 OnFailure로 주어야 하는 것.

# Pod 생성

kubectl apply -f cmd.yaml

-f = file

# 로그 확인 : 만약 restartPolicy를 Always로 했다면 무수히 많은 hello가 찍힐 것이다.

kubectl logs -f cmd

-f = flow

Volume Mounting

# volume.yaml 파일 생성

vi volume.yaml

# volume.yaml
apiVersion: v1
kind: Pod
metadata:
  name: volume
spec:
  containers: 
  - name: nginx
    image: nginx

    # 컨테이너 내부의 연결 위치 지정
    volumeMounts:
    - mountPath: /container-volume
      name: my-volume
  
  # host 서버의 연결 위치 지정
  volumes:
  - name: my-volume
    hostPath:
      path: /home

# [spec]-[containers]-[volumeMounts] 부분에 컨테이너 내부의 경로와 이름을 잡고,

# [spec]-[volumes] 부분에 노드(호스트 서버) 쪽의 경로와 이름을 잡는다.

# Pod 생성

kubectl apply -f volume.yaml

# volume Pod 안으로 접속해 연결시켜준 위치를 ls 명령어를 통해 확인한다.

kubectl exec volume -- ls /container-volume

# 호스트 서버의 디렉토리에서 목록 출력

ls /home

[resources]-[limits]-[cpu], [memory] in [spec] for Resource Management

# limits.yaml 파일 생성

vi limits.yaml

# limits.yaml
apiVersion: v1
kind: Pod
metadata:
  name: limits
spec:
  restartPolicy: OnFailure
  containers: 
  - name: mynginx
    image: python:3.7
    command: [ "python" ]
    args: [ "-c", "arr = []\nwhile True: arr.append(range(1000))" ]
    resources:
      limits:
        cpu: "500m"
        memory: "1Gi"

# 파이썬 이미지를 사용해 파이썬 코드를 작성하고 수행하는 컨테이너를 만들 수 있다.

# limits Pod 생성

kubectl apply -f limits.yaml

# watch 명령어의 지속적인 체크로 STATUS 변화 확인 : Running → OOMKilled

watch -d 'kubectl get pod limits'

[livenessProbe] in [spec] for Health Check

# yaml 파일 생성

vi liveness.yaml

# liveness.yaml
apiVersion: v1
kind: Pod
metadata:
  name: liveness
spec:
  containers: 
  - name: nginx
    image: nginx
    livenessProbe:
      httpGet:
        path: /live
        port: 80

# 상태 확인 및 자가치유 부분은 확인 과정이 복잡하기 때문에 단순히 위의 속성을 주게 되면

#정상적으로 작동하는지 실시간으로 체크하고 자가치유를 수행한다는 것만 알면 될 것 같다.

2개의 컨테이너 실행 (Sidecar)

# yaml 파일 생성

vi second.yaml

# second.yaml
apiVersion: v1
kind: Pod
metadata:
  name: second
spec:
  containers: 
  - name: nginx
    image: nginx
  - name: curl
    image: curlimages/curl
    command: ["/bin/sh"]
    args: ["-c", "while true; do sleep 5; curl -s localhost; done"]

# containers 아래에 name이 두 개가 있는 모습. 하나의 Pod 안에 두 개의 Container를 생성하는 것이다.

# 아래의 명령어는 5초마다 로컬호스트로 시그널을 보내며, 응답을 받지 못하면 에러가 뜨게 되는 코드이다.

# Pod 생성

kubectl apply -f second.yaml

# 생성 확인. 그리고 다른 Pod들과는 다르게 second는 READY 컬럼에 2개가 있는 것을 볼 수 있다.

kubectl get pod

# second 컨테이너의 (nginx 컨테이너에 대한) 로그를 출력

kubectl logs second -f -c nginx

-f = flow

-c = container

# Pods 확인 명령어

kubectl get pods --all-namespaces -o=jsonpath='{range .items[*]}{"\n"}{.metadata.name}{":\t"}{range .spec.containers[*]}{.image}{", "}{end}{end}' |\sort

Init Container

# yaml 파일 생성

vi init-container.yaml

# init-container.yaml
apiVersion: v1
kind: Pod
metadata:
  name: init-container
spec:
  restartPolicy: OnFailure
  containers: 
  - name: busybox
    image: k8s.gcr.io/busybox
    command: [ "ls" ]
    args: [ "/tmp/moby" ]
    volumeMounts:
    - name: workdir
      mountPath: /tmp
  initContainers:
  - name: git
    image: alpine/git
    command: ["sh"]
    args:
    - "-c"
    - "git clone https://github.com/moby/moby.git /tmp/moby"
    volumeMounts:
    - name: workdir
      mountPath: "/tmp"
  volumes:
  - name: workdir
    emptyDir: {}

# 메인 컨테이너가 실행되기 전에 초기화 컨테이너에서 미리 git pull을 받아서

# 컨테이너끼리의 공유 공간인 emptyDir volume(/tmp)를 통해 git 레파지토리를 전달한다.

# Pod 생성

kubectl apply -f init-container.yaml

# initContainer 로그 확인

kubectl logs init-container -f -c git

# 메인 컨테이너(busybox) 로그 확인

kubectl logs init-container

Delete all Pods

kubectl delete pod --all

아래 사진은 쿠버네티스의 전체적인 프로세스 구조이다.

Control Plane Components

API Server

API 서버는 쿠버네티스 API를 노출하는 쿠버네티스 컨트롤 플레인 컴포넌트이다. API 서버는 쿠버네티스 컨트롤 플레인의 프론트 엔드이다.

쿠버네티스 API 서버의 주요 구현은 kube-apiserver 이다. kube-apiserver는 수평으로 확장되도록 디자인되었다. 즉, 더 많은 인스턴스를 배포해서 확장할 수 있다. 여러 kube-apiserver 인스턴스를 실행하고, 인스턴스간의 트래픽을 균형있게 조절할 수 있다.

etcd

모든 클러스터 데이터를 담는 쿠버네티스 뒷단의 저장소로 사용되는 일관성·고가용성 키-값 저장소.

쿠버네티스 클러스터에서 etcd를 뒷단의 저장소로 사용한다면, 이 데이터를 백업하는 계획은 필수이다.

etcd에 대한 자세한 정보는, 공식 문서를 참고한다.

Scheduler

노드가 배정되지 않은 새로 생성된 파드 를 감지하고, 실행할 노드를 선택하는 컨트롤 플레인 컴포넌트.

스케줄링 결정을 위해서 고려되는 요소는 리소스에 대한 개별 및 총체적 요구 사항, 하드웨어/소프트웨어/정책적 제약, 어피니티(affinity) 및 안티-어피니티(anti-affinity) 명세, 데이터 지역성, 워크로드-간 간섭, 데드라인을 포함한다

Controller Manager

컨트롤러 프로세스를 실행하는 컨트롤 플레인 컴포넌트.

논리적으로, 각 컨트롤러는 분리된 프로세스이지만, 복잡성을 낮추기 위해 모두 단일 바이너리로 컴파일되고 단일 프로세스 내에서 실행된다.

이들 컨트롤러는 다음을 포함한다.

• 노드 컨트롤러: 노드가 다운되었을 때 통지와 대응에 관한 책임을 가진다.
• 레플리케이션 컨트롤러: 시스템의 모든 레플리케이션 컨트롤러 오브젝트에 대해 알맞은 수의 파드들을 유지시켜 주는 책임을 가진다.
• 엔드포인트 컨트롤러: 엔드포인트 오브젝트를 채운다(즉, 서비스와 파드를 연결시킨다.)
• 서비스 어카운트 & 토큰 컨트롤러: 새로운 네임스페이스에 대한 기본 계정과 API 접근 토큰을 생성한다.

Node Components

kubelet

클러스터의 각 노드에서 실행되는 에이전트. Kubelet은 파드에서 컨테이너가 확실하게 동작하도록 관리한다.

Kubelet은 다양한 메커니즘을 통해 제공된 파드 스펙(PodSpec)의 집합을 받아서 컨테이너가 해당 파드 스펙에 따라 건강하게 동작하는 것을 확실히 한다. Kubelet은 쿠버네티스를 통해 생성되지 않는 컨테이너는 관리하지 않는다.

kube-proxy

kube-proxy는 클러스터의 각 노드에서 실행되는 네트워크 프록시로, 쿠버네티스의 서비스 개념의 구현부이다.

kube-proxy는 노드의 네트워크 규칙을 유지 관리한다. 이 네트워크 규칙이 내부 네트워크 세션이나 클러스터 바깥에서 파드로 네트워크 통신을 할 수 있도록 해준다.

kube-proxy는 운영 체제에 가용한 패킷 필터링 계층이 있는 경우, 이를 사용한다. 그렇지 않으면, kube-proxy는 트래픽 자체를 포워드(forward)한다.

Cloud controller manager

클라우드별 컨트롤 로직을 포함하는 쿠버네티스 컨트롤 플레인 컴포넌트이다. 클라우드 컨트롤러 매니저를 통해 클러스터를 클라우드 공급자의 API에 연결하고, 해당 클라우드 플랫폼과 상호 작용하는 컴포넌트와 클러스터와만 상호 작용하는 컴포넌트를 구분할 수 있게 해 준다.

cloud-controller-manager는 클라우드 제공자 전용 컨트롤러만 실행한다. 자신의 사내 또는 PC 내부의 학습 환경에서 쿠버네티스를 실행 중인 경우 클러스터에는 클라우드 컨트롤러 매니저가 없다.

kube-controller-manager와 마찬가지로 cloud-controller-manager는 논리적으로 독립적인 여러 컨트롤 루프를 단일 프로세스로 실행하는 단일 바이너리로 결합한다. 수평으로 확장(두 개 이상의 복제 실행)해서 성능을 향상시키거나 장애를 견딜 수 있다.

다음 컨트롤러들은 클라우드 제공 사업자의 의존성을 가질 수 있다.

• 노드 컨트롤러: 노드가 응답을 멈춘 후 클라우드 상에서 삭제되었는지 판별하기 위해 클라우드 제공 사업자에게 확인하는 것
• 라우트 컨트롤러: 기본 클라우드 인프라에 경로를 구성하는 것
• 서비스 컨트롤러: 클라우드 제공 사업자 로드밸런서를 생성, 업데이트 그리고 삭제하는 것

자료 출처: https://kubernetes.io/ko/docs/concepts/overview/components/

Operation

자료 출처: Pod | 쿠버네티스 안내서 (subicura.com)

먼저 Ubuntu Server의 iso 이미지를 다운로드 받아서 Oracle VirtualBox에 가상 머신을 만들었다.

설치 방법 및 기본 설정은 이전 게시글에 있으니 링크를 걸어둔다. 하지만 이번 실습에선 아래 글과 같이 하나하나 설정하지 않고 대부분 기본 설정으로 빠르게 만들었다. 또한 네트워크 인터페이스 카드도 NAT 하나만 설정했다.

https://yoonhoji.tistory.com/3?category=1042734 

Configure Ubuntu Server

먼저 인터넷 연결을 확인한다.

sudo apt update

NetworkManager를 설치한다.

sudo apt install -y network-manager

sudo systemctl status network-manager

포트 포워딩 적용을 위해 위에 첨부한 글을 참고해 설정해준다.

포트포워딩 & NAT Network 설정

시스템 설정 파일인 yaml 파일을 백업해둔다.

cd /etc/netplan

sudo cp 00-installer-config.yaml 00-installer-config.yaml.bak

sudo nano 00-installer-config.yaml

두 칸씩 들여쓰기에 주의하며 yaml 파일에 고정 IP 주소를 할당한다. 수정을 완료했다면 Ctrl+O로 덮어쓰고, Ctrl+X로 nano editor를 빠져나가면 된다.

sudo netplan try

(Enter)

sudo netplan apply

sudo systemctl stop network-manager

sudo systemctl start network-manager

sudo systemctl stop network-manager

sudo systemctl start network-manager

NetworkManager를 몇 번 재부팅 해 주고 난 뒤 인터넷 연결을 확인하기 위해 업데이트를 해본다.

sudo apt update

만약 여기서 인터넷 연결이 안 되었다고 나온다면 게이트웨이로 핑을 쳐 봐야 한다.

ping 10.0.2.1

ping 10.0.2.2

ping 10.0.2.3

이 정도로 확인해보면 첫 번째는 연결이 안 될 것이고 2번이나 3번에 핑이 닿는다면 아까 정적으로 IP 주소를 할당해 주었던 단계로 돌아가서 gateway4 부분을 수정해주고 이후의 과정을 수행하고 난 뒤 다시 업데이트를 해 본다.

sudo apt update

인터넷 연결이 정상적으로 되었다면 hostname을 수정한다.

cd $HOME

sudo nano /etc/hostname

위와 같이 설정하고 저장한다.

sudo nano /etc/hosts

위와 같이 두 번째 줄의 hostname을 변경하고 저장한다.

그리고 핑을 쳐서 호스트 네임이 정상적으로 인식되고 있는지 확인한다.

Client Tool로 접속하기 위해 SSH를 설치한다.

sudo apt install -y openssh-server

HOST를 잡아준다.

export HOST=docker-ubuntu

Firewall 설정은 생략했다.

그리고 클라이언트 툴(XShell, putty, SecureCRT 등)으로 접속한다.

127.0.0.1:105

Install Docker Engine

우분투 서버 환경 구성은 완료됐고 이제부터 Docker Engine을 설치한다.

Install Docker Engine on Ubuntu | Docker Documentation

아래 정리한 명령어들은 위의 문서에서 그대로 가져온 것이다.

복사, 붙여넣기로 진행하는 것을 추천.

sudo apt-get update 

sudo apt-get install ca-certificates curl gnupg lsb-release

echo \ "deb [arch=$(dpkg --print-architecture) signed-by=/usr/share/keyrings/docker-archive-keyring.gpg] https://download.docker.com/linux/ubuntu \ $(lsb_release -cs) stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

sudo apt install docker-ce docker-ce-cli containerd.io

sudo systemctl status docker

sudo docker version

sudo docker run hello-world

Lab 1 - Ubuntu, Git in Docker Container

아래 이미지와 같이 Base Image로 Ubuntu Server를 Pull & Run하고 그 Ubuntu 위에 Git을 Install 한다.

sudo docker pull ubuntu

sudo docker image ls

Run 명령어로 Pull 까지 한 번에 한다.

sudo docker run -it --name git ubuntu:latest bash

(i : Interactive, t : Tty)

apt update

apt install -y git

git --version

exit (도커 프로세스 종료)

sudo docker ps -a

sudo docker commit git ubuntu:git

sudo docker images

sudo docker run -it --name git2 ubuntu:git bash

git --version

exit

sudo docker rm git2

sudo docker rm git

sudo docker rm 7e1 (CONTAINER ID의 앞 3자리)

Lab 2 - Nginx Web Server in Docker Container

(관리자 로그인)

su -

docker search nginx

docker pull nginx

이미지 레이어 확인하기

cd /var/lib/docker/overlay2

ls -l

Nginx는 총 6개의 레이어로 이루어져 있음을 알 수 있다 (l은 디폴트).

Nginx를 Run해서 메모리에 프로세스로 올려 Container로 만든다.

docker run -d --name webserver -p 80:80 nginx:latest

이제 실제 OS인 Windows에서 브라우저를 열고 192.168.56.100:80으로 접속하면 Nginx 웹 서버가 나온다.