Infrastructure

Kubernetes와 친해지기

Loko 2022. 4. 28. 18:04

※ 위 책을 읽고 개념 위주로 정리한 내용임을 알립니다.

 

 

Kubectl을 더 쉽게 사용하기

kubectl 명령 자동 완성하기

  • bash shell 명령 자동 완성을 해주는 bash-completion 패키지 사용
  • bash-completion은 bash의 Built-in 명령 중 하나인 complete 명령으로 자동 완성 목록 표시
  • kubectl completion bash 명령으로 complete에 맞게 목록을 생성하는 방식
  • 자동 완성 목록을 구현한 뒤에는 tab 키를 사용해서 자동 완성 활용 가능

※ bash-completion.sh

#!/usr/bin/env bash
#Usage:
#1. bash <(curl -s https://raw.githubusercontent.com/sysnet4admin/IaC/master/manifests/bash-completion.sh)

# install bash-completion for kubectl
yum install bash-completion -y

# kubectl completion on bash-completion dir
kubectl completion bash >/etc/bash_completion.d/kubectl

# alias kubectl to k
echo 'alias k=kubectl' >> ~/.bashrc
echo 'complete -F __start_kubectl k' >> ~/.bashrc

#Reload rc
su -
  • 쿠버네티스에서 제공하는 오브젝트들을 외우기 힘들 때 사용하기에 편리함
  • kubectl을 k라는 별칭으로 만들어서 사용하는 설정도 포함

 

kubectl의 약어들

이름 약어 Object 이름
nodes no Node
namespaces ns Namespace
deployments deploy Deployment
pods po Pod
services svc Service
replicasets rs ReplicaSet
ingresses ing Ingress
configmaps cm ConfigMap
horizontalpodautoscalers hpa HorizontalPodAutoscaler
daemonsets ds DaemonSet
persistentvolumeclaims pvc PersistentVolumeClaim
persistentvolumes pv PersistentVolume
statefulsets sts StatefulSet
replicationcontrollers rc ReplicationController
resourcequotas quota ResourceQuota
serviceaccounts sa ServiceAccount
cronjobs cj CronJob
events ev Event
storageclasses sc StorageClass
endpoints ep EndPoints
limitranges limits LimitRange

※ 약어 확인 명령어 : kubectl api-resources

 

 

kube-dashboard 알아보기

 

 

kubespray 알아보기

  • 쿠버네티스 클러스터를 구성하는 4가지 대표적인 도구들
    • kubeadm, kops, KRIB, kubespray
  • 이 책의 실습에서는 kubeadm을 사용했지만 kubespray가 더욱 편리함
  • kubespray는 사용자가 원하는 형태의 클러스터를 구성할 수 있도록 4가시 선택 사항을 줌
    • 마스터 노드의 설치 위치
    • etcd의 설치 위치
    • 워커 노드의 설치 위치
    • 네트워크 플러그인의 선택 및 사용
  • kubespray는 여러 개의 마스터와 etcd를 구성할 수 있으므로 이에 대한 수량을 지정할 수 있음

 

 

Container 깊게 들여다보기

Kubernetes가 Container를 다루는 과정

  1. 사용자는 kube-apiserver의 URL로 요청을 전달하거나 kubectl을 통해 명령어를 입력하여
    kube-apiserver에 파드 생성 명령을 내림
  2. 파드 생성 명령은 네트워크를 통해 kubelet으로 전달하는데,
    kube-apiserver는 노드에 있는 kubelet과 안전하게 통신하기 위해서
    인증서와 키로 통신 내용을 암호화한 상태로 전달함
    이 때, 키는 마스터 노드의 /etc/kubernetes/pki/ 디렉토리에 보관하고,
    인증서 파일 api-server-kubelet-client.crt와 키 파일 apiserver-kubelet-client.key 사용
  3. kubelet으로 생성 요청이 전달되면 kubelet은 요청이 적절한 사용자로부터 전달된 것인지 검증하는데,
    검증을 위해서 /var/lib/kubelet/config.yaml 파일의 clientCAFile 속성에 설정된 파일 사용
  4. kubelet의 검증을 마치면 containerd에 컨테이너 생성 명령을 내리는데,
    명령 형식은 CRI(Container Runtime Interface) 규약을 따름
    이 CRI는 컨테이너와 관련된 명령을 내리는 RuntimeService와,
    이미지 관련 명령을 내리는 ImageService로 이루어져 있음
    RuntimeService : 파드 CRUD, 컨테이너 CRUD와 관련된 다양한 명령 수행
    kubelet이 내린 명령은 컨테이너디에 통합된 CRI plugin이라는 구성 요소에 전달
    CRI plugin은 containerd에 통합되어 있으므로 containerd가 컨테이너 생성 명령을 직접 호출함
  5. containerd는 containerd-shim이라는 자식 프로세스를 생성하여 컨테이너를 관리함
  6. containerd가 생성한 containerd-shim 프로세스는 컨테이너를 조작
    실제로 containerd-shim이 runC 바이너리 실행 파일을 호출해서 컨테이너를 생성

 

Container에서 PID 1의 의미

  • 리눅스 운영 체제에서의 PID 1은 커널이 할당하는 첫번째 PID라는 특수한 의미
    • 일반적으로 init 또는 systemd에 할당되며, 시스템 구동에 필요한 프로세스들을 띄우는 매우 중요한 역할 수행
  • 그런데 컨테이너는 운영 체제 시스템을 구동시킬 필요도 없이 바로 동작함
  • 그렇기 때문에 시스템에 예약된 PID 1번이 처음에는 할당되지 않은 상태
  • 그러므로 컨테이너 세계에서 PID 1은 컨테이너가 처음으로 실행하는 애플리케이션에게 할당되는 것

 

만약 Docker가 아닌 runC로 Container를 생성한다면?

  • runC : OCI라는 단체에서 만든 컨테이너 생성 및 관리를 위한 표준 규격
  • containerd나 CRI-O 등의 다양한 컨테이너 런타임들이 내부적으로 runC를 활용하는 것
  • High-level container runtime : 쿠버네티스나 도커 명령을 받아들이는 containerd나 CRI-O 등
  • Low-level container runtime : 컨테이너에 명령을 내리기 위해 리눅스에 명령을 내리는 runC
  • 저수준에서 runC 컨테이너를 구동하려면 네트워크 인터페이스를 격리하고
    오픈 컨테이너 이니셔티브 규격을 준수하는 설정 파일을 직접 작성해야 함
  • 저수준의 과정을 사용자가 직접 하려면 네트워크, 파일, 시스템, 리눅스 커널 등에 대한 지식 필요
  • 그러한 연유로, Docker가 우리의 소중한 친구로 자리잡게 된 것