※ 위 책을 읽고 개념 위주로 정리한 내용임을 알립니다.
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 알아보기
- 프로메테우스와 그라파나를 활용한 모니터링 환경은 소규모 환경에서는 과분함
- 그러므로 kube-dashboard를 통해 간단한 웹 UI를 구성할 수 있음
- kubectl apply -f https://raw.githubusercontent.com/kubernetes/dashboard/v2.2.0/aio/deploy/recommended.yaml
kubespray 알아보기
- 쿠버네티스 클러스터를 구성하는 4가지 대표적인 도구들
- kubeadm, kops, KRIB, kubespray
- 이 책의 실습에서는 kubeadm을 사용했지만 kubespray가 더욱 편리함
- kubespray는 사용자가 원하는 형태의 클러스터를 구성할 수 있도록 4가시 선택 사항을 줌
- 마스터 노드의 설치 위치
- etcd의 설치 위치
- 워커 노드의 설치 위치
- 네트워크 플러그인의 선택 및 사용
- kubespray는 여러 개의 마스터와 etcd를 구성할 수 있으므로 이에 대한 수량을 지정할 수 있음
Container 깊게 들여다보기
Kubernetes가 Container를 다루는 과정
- 사용자는 kube-apiserver의 URL로 요청을 전달하거나 kubectl을 통해 명령어를 입력하여
kube-apiserver에 파드 생성 명령을 내림 - 파드 생성 명령은 네트워크를 통해 kubelet으로 전달하는데,
kube-apiserver는 노드에 있는 kubelet과 안전하게 통신하기 위해서
인증서와 키로 통신 내용을 암호화한 상태로 전달함
이 때, 키는 마스터 노드의 /etc/kubernetes/pki/ 디렉토리에 보관하고,
인증서 파일 api-server-kubelet-client.crt와 키 파일 apiserver-kubelet-client.key 사용 - kubelet으로 생성 요청이 전달되면 kubelet은 요청이 적절한 사용자로부터 전달된 것인지 검증하는데,
검증을 위해서 /var/lib/kubelet/config.yaml 파일의 clientCAFile 속성에 설정된 파일 사용 - kubelet의 검증을 마치면 containerd에 컨테이너 생성 명령을 내리는데,
명령 형식은 CRI(Container Runtime Interface) 규약을 따름
이 CRI는 컨테이너와 관련된 명령을 내리는 RuntimeService와,
이미지 관련 명령을 내리는 ImageService로 이루어져 있음
RuntimeService : 파드 CRUD, 컨테이너 CRUD와 관련된 다양한 명령 수행
kubelet이 내린 명령은 컨테이너디에 통합된 CRI plugin이라는 구성 요소에 전달
CRI plugin은 containerd에 통합되어 있으므로 containerd가 컨테이너 생성 명령을 직접 호출함 - containerd는 containerd-shim이라는 자식 프로세스를 생성하여 컨테이너를 관리함
- 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가 우리의 소중한 친구로 자리잡게 된 것
'Infrastructure' 카테고리의 다른 글
Prometheus & Grafana (0) | 2022.04.28 |
---|---|
Jenkins (0) | 2022.04.27 |
Docker (0) | 2022.04.26 |
Kubernetes (0) | 2022.04.25 |
컨테이너 인프라 환경 (0) | 2022.04.25 |