안승규의 블로그 (Stay hungry, stay foolish)

Cloud Native Community Day Korea 2024 Recap

seungkyua@gmail.com — Wed, 9 Apr 2025 09:51:42 +0900

2024년 행사 Recap

Kubernetes Korea Group Discord Channel

seungkyua@gmail.com — Thu, 26 Sep 2024 08:02:24 +0900

쿠버네티스 코리아 디스코드 채널 주소 입니다.

https://discord.gg/AmqYyGDQ3U

kubernetes-korea Discord 서버에 가입하세요!

Discord에서 kubernetes-korea 커뮤니티를 확인하세요. 395명과 어울리며 무료 음성 및 텍스트 채팅을 즐기세요.

discord.com

Linux single node 에서 kubeadm 으로 kubernetes 설치 하기

seungkyua@gmail.com — Thu, 8 Aug 2024 16:59:40 +0900

1. sudo 사용자 추가, 보안 s/w 내리기, swap off

$ sudo adduser ask

$ cat <<EOF | sudo tee /etc/sudoers.d/sudoers-ask
ask     ALL=(ALL:ALL)   NOPASSWD:ALL
EOF

$ sudo systemctl stop ufw
$ sudo systemctl disable ufw
$ sudo systemctl stop apparmor.service
$ sudo systemctl disable apparmor.service
$ sudo swapoff -a

2. module load

$ cat <<EOF | sudo tee /etc/modules-load.d/k8s.conf
overlay
br_netfilter
EOF

$ sudo modprobe overlay
$ sudo modprobe br_netfilter

3. network forwarding 설정

$ cat <<EOF | sudo tee /etc/sysctl.d/99-kubernetes.conf
net.bridge.bridge-nf-call-iptables  = 1
net.bridge.bridge-nf-call-ip6tables = 1
net.ipv4.ip_forward                 = 1
EOF


$ sudo sysctl --system
$ sudo iptables -P FORWARD ACCEPT

4. containerd 설치

$ sudo apt-get update
$ sudo apt-get install -y apt-transport-https ca-certificates curl gpg
$ sudo install -m 0755 -d /etc/apt/keyrings
$ sudo curl -fsSL https://download.docker.com/linux/ubuntu/gpg -o /etc/apt/keyrings/docker.asc
$ sudo chmod a+r /etc/apt/keyrings/docker.asc

$ echo \
  "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.asc] https://download.docker.com/linux/ubuntu \
  $(. /etc/os-release && echo "$VERSION_CODENAME") stable" | \
  sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

$ sudo apt-get update
$ sudo apt-get install -y containerd.io

$ sudo mkdir -p /etc/containerd
$ sudo containerd config default | sudo tee /etc/containerd/config.toml

$ sudo sed -i 's/SystemdCgroup \= false/SystemdCgroup \= true/g' /etc/containerd/config.toml

$ sudo systemctl restart containerd
$ sudo systemctl enable containerd
$ sudo systemctl status containerd

5. crictl 설치

#----------------------------------------------------------
# 서버가 arm64 or amd64 인지 확인하여 설치
#----------------------------------------------------------
$ VERSION="v1.30.0"
$ curl -L https://github.com/kubernetes-sigs/cri-tools/releases/download/$VERSION/crictl-${VERSION}-linux-arm64.tar.gz --output crictl-${VERSION}-linux-arm64.tar.gz

$ sudo tar zxvf crictl-$VERSION-linux-arm64.tar.gz -C /usr/local/bin
$ rm -f crictl-$VERSION-linux-arm64.tar.gz

#----------------------------------------------------------
# crictl 이 어느 container 를 접속할 것인지 세팅
#----------------------------------------------------------
$ cat <<EOF | sudo tee /etc/crictl.yaml
runtime-endpoint: unix:///run/containerd/containerd.sock
image-endpoint: unix:///run/containerd/containerd.sock
timeout: 2
debug: false
pull-image-on-create: false
EOF

$ sudo bash -c "crictl completion > /etc/bash_completion.d/crictl"
$ source ~/.bashrc


#----------------------------------------------------------
# containerd 설정 확인
#----------------------------------------------------------
$ sudo crictl info

6. kubectl 설치

#----------------------------------------------------------
# 서버가 arm64 or amd64 인지 확인하여 설치
#----------------------------------------------------------
$ curl -LO "https://dl.k8s.io/release/v1.30.0/bin/linux/arm64/kubectl"
$ chmod +x ./kubectl
$ sudo mv ./kubectl /usr/local/bin/kubectl

7. Kubernetes 설치

$ mkdir -p ~/kubeadm && cd ~/kubeadm

#-----------------------------------------------
# kubernetes 다운로드 key 와 url 등록
#-----------------------------------------------
$ curl -fsSL https://pkgs.k8s.io/core:/stable:/v1.30/deb/Release.key | sudo gpg --dearmor -o /etc/apt/keyrings/kubernetes-apt-keyring.gpg

$ echo 'deb [signed-by=/etc/apt/keyrings/kubernetes-apt-keyring.gpg] https://pkgs.k8s.io/core:/stable:/v1.30/deb/ /' | sudo tee /etc/apt/sources.list.d/kubernetes.list
$ sudo apt-get update


#========================================================================
# kubelet 설치 (아직 kubelet 이 뜨지는 않음)
#========================================================================
$ sudo apt-get install -y kubelet="1.30.3-*" kubeadm="1.30.3-*"
$ sudo systemctl enable --now kubelet
$ sudo systemctl start kubelet

#========================================================================
# 1. kubeadm 설치
#========================================================================
$ sudo kubeadm config images pull

#------------------------------------------------------------
# 자기 노드의 ip: --apiserver-advertise-address
# multi control-plane 일 경우 L4 ip: --control-plane-endpoint
# cgroup driver 세팅 (https://kubernetes.io/docs/tasks/administer-cluster/kubeadm/configure-cgroup-driver/)
#------------------------------------------------------------
$ vi kubeadm-config.yaml

apiVersion: kubeadm.k8s.io/v1beta3
kind: InitConfiguration
nodeRegistration:
  criSocket: "/var/run/containerd/containerd.sock"

---
apiVersion: kubeadm.k8s.io/v1beta3
kind: ClusterConfiguration
apiServer:
  certSANs:
  - 127.0.0.1
  - localhost
  - <Node private IP>
  - <Node public IP>
networking:
  serviceSubnet: 10.233.0.0/18
  podSubnet: 10.233.64.0/18
  dnsDomain: "cluster.local"


#----------------------------------------------------------------
# kubeadm init 을 하고 나면 /var/lib/kubelet/config.yaml 이 생성되어
# kubelet 이 정상적으로 실행됨
#----------------------------------------------------------------
$ sudo kubeadm init --config kubeadm-config.yaml --v=5


#------------------------------------------------------------
# kubeconfig
#------------------------------------------------------------
$ mkdir -p ~/.kube
$ sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
$ sudo chown $(id -u):$(id -g) $HOME/.kube/config

8. Calico 설치

$ mkdir -p ~/calico && cd ~/calico

$ curl -LO https://raw.githubusercontent.com/projectcalico/calico/v3.28.0/manifests/tigera-operator.yaml

$ kubectl create -f tigera-operator.yaml

$ curl -LO https://raw.githubusercontent.com/projectcalico/calico/v3.28.0/manifests/custom-resources.yaml

#------------------------------------------------------------
# yaml 을 열어서 pod 네트워크를 확인하고 변경
#------------------------------------------------------------
$ vi custom-resources.yaml
...
    cidr: 10.233.64.0/18
...

$ kubectl create -f custom-resources.yaml

#------------------------------------------------------------
# calico 설치 확인
#------------------------------------------------------------
$ kubectl get pods -n calico-system

9. kubectl bash completion

$ source <(kubectl completion bash)
$ kubectl completion bash > ~/.kube/completion.bash.inc

$ printf "
# kubectl shell completion
source '$HOME/.kube/completion.bash.inc'
" >> $HOME/.bash_aliases

$ source $HOME/.bash_aliases

10. taint 제거

$ kubectl taint nodes --all node-role.kubernetes.io/control-plane-

11. 설치 테스트

$ mkdir -p ~/sample-yaml && cd ~/sample-yaml

$ cat <<EOF | tee ./nginx-service.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: nginx-deployment
  name: nginx-deployment
spec:
  replicas: 1
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.21.0
        ports:
        - containerPort: 80

---
apiVersion: v1
kind: Service
metadata:
  name: nginx-service-nodeport
spec:
  selector:
    app: nginx
  ports:
  - protocol: TCP
    port: 8080
    targetPort: 80
    nodePort: 30180
  type: NodePort
  externalTrafficPolicy: Local
EOF


$ kubectl apply -f nginx-service.yaml

$ kubectl get pods

$ curl <Node ip>:30180

minkube, kind 설치하기

seungkyua@gmail.com — Thu, 9 May 2024 09:07:13 +0900

Minikube 설치하기

minkube 설치는 아래 사이트를 참고한다.

https://minikube.sigs.k8s.io/docs/start/

$ curl -LO <https://storage.googleapis.com/minikube/releases/latest/minikube-darwin-arm64>
$ install minikube-darwin-arm64 /Users/ask/bin/minikube

start cluster

https://minikube.sigs.k8s.io/docs/drivers/docker/

driver 를 docker 로 사용하기 때문에 docker 를 미리 설치해 놓아야 한다.

$ docker context use default

이후에 minikube 로 cluster 를 생성한다.

$ minikube start --driver=docker --memory=4096
--- output ---
   Darwin 13.5.2 (arm64) 의 minikube v1.33.0
✨  유저 환경 설정 정보에 기반하여 docker 드라이버를 사용하는 중
   Using Docker Desktop driver with root privileges
   Starting "minikube" primary control-plane node in "minikube" cluster
   Pulling base image v0.0.43 ...
   Creating docker container (CPUs=2, Memory=4096MB) ...
❗  This container is having trouble accessing <https://registry.k8s.io>
   To pull new external images, you may need to configure a proxy: <https://minikube.sigs.k8s.io/docs/reference/networking/proxy/>
   쿠버네티스 v1.30.0 을 Docker 26.0.1 런타임으로 설치하는 중
    ▪ 인증서 및 키를 생성하는 중 ...
    ▪ 컨트롤 플레인을 부팅하는 중 ...
    ▪ RBAC 규칙을 구성하는 중 ...
   bridge CNI (Container Networking Interface) 를 구성하는 중 ...
   Kubernetes 구성 요소를 확인...
    ▪ Using image gcr.io/k8s-minikube/storage-provisioner:v5
   애드온 활성화 : storage-provisioner, default-storageclass

❗  /Users/ask/bin/kubectl is version 1.28.2, which may have incompatibilities with Kubernetes 1.30.0.
    ▪ Want kubectl v1.30.0? Try 'minikube kubectl -- get pods -A'
   끝났습니다! kubectl이 "minikube" 클러스터와 "default" 네임스페이스를 기본적으로 사용하도록 구성되었습니다.

디폴트 메모리를 config 에 세팅할 수 도 있다.

config 세팅은 기존에 만든 minikube node 에는 적용이 안되고 새롭게 만드는 노드에만 적용된다.

$ minikube config set memory 4096

node 추가

minikube 에 worker node 를 추가할 수 있다.

$ minikube node add

node 가 추가된 것을 볼 수 있다.

$ kubectl get nodes
NAME           STATUS   ROLES           AGE     VERSION
minikube       Ready    control-plane   8m22s   v1.30.0
minikube-m02   Ready    <none>          86s     v1.30.0

node 에 Role 을 추가하고 싶으면 다음과 같이 지정한다.

$ kubectl label node minikube-m02 node-role.kubernetes.io/node=enabled --overwrite

$ kubectl get nodes
NAME           STATUS   ROLES           AGE     VERSION
minikube       Ready    control-plane   15m     v1.30.0
minikube-m02   Ready    node            8m12s   v1.30.0

minikube 명령어

현재 설치된 minkube node 를 조회한다.

$ minkube status
--- output ---
minikube
type: Control Plane
host: Running
kubelet: Running
apiserver: Running
kubeconfig: Configured

minikube-m02
type: Worker
host: Running
kubelet: Running

minikube 로 만든 kubernetes cluster 의 모든 namespace 를 잠시 멈춘다.

$ minkube pause -A
--- output --
⏸️  Pausing node minikube ...
⏸️  Pausing node m02 ...
⏯️  Paused 16 containers

minkube 로 pause 한 cluster 를 다시 실행한다.

$ minikube unpause -A
--- output ---
⏸️  Unpausing node minikube ...
⏸️  Unpausing node m02 ...
⏸️  Unpaused 16 containers

minikube 모든 노드를 중지한다.

$ minikube stop --all=true
--- output ---
✋  "minikube-m02" 노드를 중지하는 중 ...
   "minikube-m02"를 SSH로 전원을 끕니다 ...
✋  "minikube" 노드를 중지하는 중 ...
   "minikube"를 SSH로 전원을 끕니다 ...
   2개의 노드가 중지되었습니다.

aged 란 이름의 다른 쿠버네티스 버전을 추가로 설치한다.

$ minikube start -p aged --kubernetes-version=v1.28.2

모든 minikube 로 만든 kubernetes cluster 를 삭제한다.

minikube delete --all

minikube addons 목록을 살펴본다.

$ minikube addons list
|-----------------------------|----------|--------------|--------------------------------|
|         ADDON NAME          | PROFILE  |    STATUS    |           MAINTAINER           |
|-----------------------------|----------|--------------|--------------------------------|
| ambassador                  | minikube | disabled     | 3rd party (Ambassador)         |
| auto-pause                  | minikube | disabled     | minikube                       |
| cloud-spanner               | minikube | disabled     | Google                         |
| csi-hostpath-driver         | minikube | disabled     | Kubernetes                     |
| dashboard                   | minikube | disabled     | Kubernetes                     |
| default-storageclass        | minikube | enabled ✅   | Kubernetes                     |
| efk                         | minikube | disabled     | 3rd party (Elastic)            |
| freshpod                    | minikube | disabled     | Google                         |
| gcp-auth                    | minikube | disabled     | Google                         |
| gvisor                      | minikube | disabled     | minikube                       |
| headlamp                    | minikube | disabled     | 3rd party (kinvolk.io)         |
| helm-tiller                 | minikube | disabled     | 3rd party (Helm)               |
| inaccel                     | minikube | disabled     | 3rd party (InAccel             |
|                             |          |              | [info@inaccel.com])            |
| ingress                     | minikube | disabled     | Kubernetes                     |
| ingress-dns                 | minikube | disabled     | minikube                       |
| inspektor-gadget            | minikube | disabled     | 3rd party                      |
|                             |          |              | (inspektor-gadget.io)          |
| istio                       | minikube | disabled     | 3rd party (Istio)              |
| istio-provisioner           | minikube | disabled     | 3rd party (Istio)              |
| kong                        | minikube | disabled     | 3rd party (Kong HQ)            |
| kubeflow                    | minikube | disabled     | 3rd party                      |
| kubevirt                    | minikube | disabled     | 3rd party (KubeVirt)           |
| logviewer                   | minikube | disabled     | 3rd party (unknown)            |
| metallb                     | minikube | disabled     | 3rd party (MetalLB)            |
| metrics-server              | minikube | disabled     | Kubernetes                     |
| nvidia-device-plugin        | minikube | disabled     | 3rd party (NVIDIA)             |
| nvidia-driver-installer     | minikube | disabled     | 3rd party (Nvidia)             |
| nvidia-gpu-device-plugin    | minikube | disabled     | 3rd party (Nvidia)             |
| olm                         | minikube | disabled     | 3rd party (Operator Framework) |
| pod-security-policy         | minikube | disabled     | 3rd party (unknown)            |
| portainer                   | minikube | disabled     | 3rd party (Portainer.io)       |
| registry                    | minikube | disabled     | minikube                       |
| registry-aliases            | minikube | disabled     | 3rd party (unknown)            |
| registry-creds              | minikube | disabled     | 3rd party (UPMC Enterprises)   |
| storage-provisioner         | minikube | enabled ✅   | minikube                       |
| storage-provisioner-gluster | minikube | disabled     | 3rd party (Gluster)            |
| storage-provisioner-rancher | minikube | disabled     | 3rd party (Rancher)            |
| volumesnapshots             | minikube | disabled     | Kubernetes                     |
| yakd                        | minikube | disabled     | 3rd party (marcnuri.com)       |
|-----------------------------|----------|--------------|--------------------------------|

dashboard 를 설치한다.

$ minikube addons enable dashboard
--- output ---
   dashboard is an addon maintained by Kubernetes. For any concerns contact minikube on GitHub.
You can view the list of minikube maintainers at: <https://github.com/kubernetes/minikube/blob/master/OWNERS>
    ▪ Using image docker.io/kubernetesui/dashboard:v2.7.0
    ▪ Using image docker.io/kubernetesui/metrics-scraper:v1.0.8
   Some dashboard features require the metrics-server addon. To enable all features please run:

	minikube addons enable metrics-server

   'dashboard' 애드온이 활성화되었습니다

metrics-server 를 설치한다.

$ minikube addons enable metrics-server
--- output ---
   metrics-server is an addon maintained by Kubernetes. For any concerns contact minikube on GitHub.
You can view the list of minikube maintainers at: <https://github.com/kubernetes/minikube/blob/master/OWNERS>
    ▪ Using image registry.k8s.io/metrics-server/metrics-server:v0.7.1
   'metrics-server' 애드온이 활성화되었습니다

dashboard 에 접속한다.

$ minikube dashboard --url

minikube trouble shooting

minikube 를 설치하고 pod 가 생성안되는 가장 큰 이유는 proxy 때문이다. 회사에서 proxy 를 사용한다면 proxy 세팅을 추가로 해줘야 한다.

아래 내용은 proxy 이외의 문제일 때 해결 방법이다.

docker hub 으로 부터 이미지를 다운 받지 못하는 문제

Error response from daemon: Get "<https://registry-1.docker.io/v2/>": tls: failed to verify certificate: x509: certificate signed by unknown authority

minikube 의 docker-env 를 확인한 후 세팅한다.

$ minikube -p minikube docker-env
--- output ---
export DOCKER_TLS_VERIFY="1"
export DOCKER_HOST="tcp://127.0.0.1:53131"
export DOCKER_CERT_PATH="/Users/ask/.minikube/certs"
export MINIKUBE_ACTIVE_DOCKERD="minikube"

$ docker context create minikube --description "Minikube" --docker "host=tcp://localhost:53131,ca=/Users/ask/.minikube/certs/ca.pem,cert=/Users/ask/.minikube/certs/cert.pem,key=/Users/ask/.minikube/certs/key.pem"
$ docker context use minikube

위의 경우에는 minikube 를 띄울 때 --insecure-registry 를 추가한다.

$ minikube start --insecure-registry="registry-1.docker.io"

아니면 minikube 로 노드에 접속해서 docker 에 인증서를 추가한다.

$ minikube ssh
$ sudo su -

$ update-ca-certificates --fresh
$ openssl s_client -showcerts -verify 5 -connect k8s.gcr.io:443 < /dev/null 2>/dev/null | openssl x509 -outform PEM | tee ~/k8s.gcr.io.crt
$ openssl s_client -showcerts -verify 5 -connect registry-1.docker.io:443 < /dev/null 2>/dev/null | openssl x509 -outform PEM | tee ~/registry-1.docker.io.crt
$ openssl s_client -showcerts -verify 5 -connect auth.docker.io:443 < /dev/null 2>/dev/null | openssl x509 -outform PEM | tee ~/auth.docker.io.crt
$ cp ~/k8s.gcr.io.crt /usr/local/share/ca-certificates/
$ cp ~/registry-1.docker.io.crt /usr/local/share/ca-certificates/
$ cp ~/auth.docker.io.crt /usr/local/share/ca-certificates/
$ update-ca-certificates

$ systemctl restart docker

Kind 설치

kind 는 아래 설치 사이트를 참조한다.

https://kind.sigs.k8s.io/docs/user/quick-start/

$ [ $(uname -m) = arm64 ] && curl -Lo ./kind <https://kind.sigs.k8s.io/dl/v0.22.0/kind-darwin-arm64>
$ chmod +x kind
$ mv kind ~/bin/kind

kind config 세팅

image 는 아래 사이트에서 확인 가능하다.

https://github.com/kubernetes-sigs/kind/releases

kind config 는 여기를 참조한다.

https://kind.sigs.k8s.io/docs/user/quick-start/#configuring-your-kind-cluster

ingress 를 사용하기 위해서는 아래 내용 처럼 port mapping 을 해야 한다.

https://kind.sigs.k8s.io/docs/user/ingress

$ vi kind-config.yaml
kind: Cluster
apiVersion: kind.x-k8s.io/v1alpha4
# patch the generated kubeadm config with some extra settings
kubeadmConfigPatches:
- |
  apiVersion: kubelet.config.k8s.io/v1beta1
  kind: KubeletConfiguration
  evictionHard:
    nodefs.available: "0%"
# patch it further using a JSON 6902 patch
kubeadmConfigPatchesJSON6902:
- group: kubeadm.k8s.io
  version: v1beta3
  kind: ClusterConfiguration
  patch: |
    - op: add
      path: /apiServer/certSANs/-
      value: my-hostname
nodes:
- role: control-plane
  image: kindest/node:v1.29.2@sha256:51a1434a5397193442f0be2a297b488b6c919ce8a3931be0ce822606ea5ca245
#  extraPortMappings:
#  - containerPort: 80
#    hostPort: 10080
#    listenAddress: "0.0.0.0" # Optional, defaults to "0.0.0.0"
#    protocol: tcp # Optional, defaults to tcp
- role: worker
  image: kindest/node:v1.29.2@sha256:51a1434a5397193442f0be2a297b488b6c919ce8a3931be0ce822606ea5ca245
#featureGates:
#  FeatureGateName: true

kind create cluster

$ KIND_EXPERIMENTAL_PROVIDER=docker && kind create cluster --name kind --config kind-config.yaml
--- output ---
Creating cluster "kind" ...
 ✓ Ensuring node image (kindest/node:v1.29.2)  
 ✓ Preparing nodes    
 ✓ Writing configuration  
 ✓ Starting control-plane  ️
 ✓ Installing CNI  
 ✓ Installing StorageClass  
 ✓ Joining worker nodes  
Set kubectl context to "kind-kind"
You can now use your cluster with:

kubectl cluster-info --context kind-kind

Thanks for using kind!

kind cluster 보기

$ kind get clusters

context 로 cluster 조회하기

$ kubectl cluster-info --context kind-kind

cluster 삭제하기

$ kind delete cluster --name kind

(OpenLab 스터디) 어플리케이션 배포 전략에 따른 실제 배포 실습

seungkyua@gmail.com — Thu, 9 May 2024 08:50:54 +0900

스터디에서 준비해야 할 내용 리스트

배포 전략에 대한 개념 설명

Rolling Update
Blue/Green
Canary
Recreate

Argo CD 설치, Argo Rollout 설치

Argo CD 로 github 을 연동하여 gitops 구현해 보기
Argo Rollout 을 활용하여 Blue/Green 구현해 보기
Kubernetes 에서 Deployment 로 배포된 서비스가 Rolling Update 되는 로직을 설명
(선택) Nginx Ingress Controller 를 활용하여 Canary 배포를 구현해 보기

쿨린이가 Kubernetes(쿠버네티스)를 처음 공부하려면 무엇부터 공부해야 할까?

seungkyua@gmail.com — Tue, 30 Apr 2024 10:04:41 +0900

Kubernetes 를 세미나를 하거나 모임에서 만나면 쿠버네티스를 알고 싶어 하시는 분들이 제일 문제 물어보는 것이 있다.

"쿠버네티스를 잘 모르는데 이제부터 공부하고 싶어요. 어떤거 부터 하면 좋을까요?"

그 동안은 이는 리눅스를 무엇부터 공부해야 할까요? 와 거의 비슷한 이야기인거 같다. 그래서 키워드로 스스로 공부할 수 있도록 키워드로 리스트를 만들었다.

컨테이너

Docker 노트북에 설치
리눅스 네임스페이스 & cgroup
dockerfile 작성 및 docker image 만들기
docker image 실행/종료/삭제 하기
docker hub 에 가입하여 개인 계정에 image 올리기

Kubernetes

Kubernetes 는 누가 만들었을까? 어떻게 해서 나오게 된 것일까? (Google Borg 로 검색)
CNCF (Cloud Native Computing Foundation) - 이 재단이 어떤 재단인지 알아보기
Kubernetes 는 기능이 어떤 것들이 있을까?
- 기본적으로 Kubernetes 는 컨테이너 이미지를 실행시키는 등 관리하는 역할 수행
Kubernetes 노트북에 설치 (아래 3개 중에 하나)
- kind
- k3s
- minikube
Kubernetes client 설치
- kubectl 설치
Kubernetes Architecture 확인
- Control plane
  - etcd (key-value store)
  - kube-apiserver
  - kube-controller
  - kube-scheduler
- Node
  - kube-proxy
  - kubelet
- Network plugin
Kubernetes 에서 Pod 란 무엇인가?
Kubernetes 에 Nginx 이미지를 pod 로 띄우기
- pod yaml 만들기
- kubectl 로 pod yaml 을 Kubernetes 에 배포하기
Pod 는 어떻게 뜨는 것일까?
- 사용자가 pod yaml 을 작성
- 사용자가 kubectl 로 pod yaml 을 kubernetes 로 보냄
- kubernetes api-server 가 이를 받아서 etcd 에 저장
- kube-scheduler 가 pod 를 원하는 node 로 스케줄링
- 스케줄링된 node 에 실행중인 kubelet 이 pod 를 실행
Kubernetes Resource 알아보기
- Pod
- ReplicaSet
- Deployment
- Label & Selector
- Service
  - ClusterIP
  - NodePort
  - LoadBalancer
- Ingress & Ingress Controller
- StatefulSet
- DaemonSet
- StorageClass
- Persistent Volume
- Persistent Volume Claim
- ConfigMap
- Secret
- ServiceAccount
- ClusterRole
- ClusterRoleBinding
Custom Controller (Operator 란 무엇인가?)
CNCF Projects 알아보기
- Graduated Projects
- Incubating Projects
- Sandbox Projects

OPA(Open Policy Agent) hello rego 프로그램 실행하기

seungkyua@gmail.com — Fri, 22 Mar 2024 19:54:14 +0900

OPA 실행 파일 설치

$ curl -L -o opa <https://github.com/open-policy-agent/opa/releases/download/v0.62.1/opa_darwin_arm64_static>
$ chmod +x opa
$ mv opa ~/bin/

참고로 홈 디렉토리 아래의 bin 디렉토리에 실행 패스가 잡혀있기 때문에 해당 디렉토리로 이동시킨 것이다.

Intellij 와 Open Policy Agent Plugin 설치

JetBrain 의 IntelliJ 가 있다면 Open Policy Agent 플러그인을 설치하여 rego 프로그램을 작성할 수 있다.

hello 프로그램을 작성하여 실행하여 보자.

먼저 번들용 chap1 디렉토리를 만든다.

$ mkdir -p chap1

chap1 번들 아래에 hello.rego 파일을 만든다.

package hello

default allow_hello = false
default allow_world = false

allow_hello {
    "hello" != ""
}

allow_world {
    "world" != "world"
}

패키지 hello 는 디렉토리와 상관없으며 chap1 디렉토리를 만들었기 때문에 bundle 은 chap1 이다.

allow_hello 와 allow_world 는 rule 을 나타낸다. OPA 1.0 미만은 if 문이 없기 때문에 비교문 만으로 표현한다. OPA 1.0 부터는 if 문을 사용한다.

opa 실행은 input json 에 대한 output json 이 결과로 나오는데 input 소스를 보면 input 이 필요없기 때문에 빈 input.json 파일을 만든다.

$ touch input.json

현재까지의 디렉토리 구조를 보면 다음과 같다.

rego-example.iml 은 IntelliJ 의 OPA 플러그인에서 사용하는 파일이므로 신경쓸 필요가 없다.

$ tree .
.
├── chap1
│   ├── hello.rego
│   └── input.json
└── rego-example.iml

이를 cli 로 실행하면 다음과 같다.

$ opa eval -f pretty -b chap1 data.hello    

--- output ---
{
  "allow_hello": true,
  "allow_world": false
}

opa eval 명령어로 rule 을 평가할 수 있다.

-f pretty 결과를 보기 쉽게 출력하라는 의미이다.

-b cha1 은 Bundle 을 입력해야 하는데 chap1 디렉토리 의 아래 rego 파일을 실행하다.

data.hello 는 Query 를 의미하며, 여기에는 package 나 rule 을 넣으면 된다. data 는 명시적으로 붙혀서 data.패키지 로 입력하면 된다.

allow_hello rule 을 실행하기 위해서는 query 부분에 rule 까지 넣어주면 된다.

$ opa eval -f pretty -b chap1 data.hello.allow_hello

--- output ---
true

결과 값으로 json 형태가 디퐅트로 출력되는데 -f pretty 를 제거하면 json 으로 결과가 출력된다.

$ opa eval -b chap1 data.hello

--- output ---
{
  "result": [
    {
      "expressions": [
        {
          "value": {
            "allow_hello": true,
            "allow_world": false
          },
          "text": "data.hello",
          "location": {
            "row": 1,
            "col": 1
          }
        }
      ]
    }
  ]
}

input 을 위해서 빈 input.json 파일을 만들었는데 이를 활용하는 명령을 추가할 수 있다.

input 값을 실제로 사용하지는 않기 때문에 결과 값은 동일하다.

$ opa eval -b chap1 -i chap1/input.json data.hello

--- output ---
{
  "result": [
    {
      "expressions": [
        {
          "value": {
            "allow_hello": true,
            "allow_world": false
          },
          "text": "data.hello",
          "location": {
            "row": 1,
            "col": 1
          }
        }
      ]
    }
  ]
}

실행을 cli 로 하지 말고 IntelliJ 에서 실행하는 방법은 아래와 같이 입력하면 된다.

메뉴에서 Run >> Edit Configurations... 을 실행한다.

앞에서 설명한 cli 에서 입력한 내용을 그대로 넣으면 된다.

Run 버튼을 클릭하면 다음과 같이 결과가 나온다.

소스는 아래 사이트에서 다운받을 수 있다. (계속 업데이트 될 예정)

https://github.com/seungkyua/rego-example.git

(golang) Embedding Interface 활용

seungkyua@gmail.com — Mon, 18 Mar 2024 11:47:01 +0900

인터페이스가 다른 인터페이서를 가지는 임베딩 방식을 사용하여 인터페이스를 선언할 수 있다. 예를 들어 io.ReadCloser 인터페이스는 io.Reader 와 io.Closer 인터페이스를 가지고 있다.

type Reader interface {
        Read(p []byte) (n int, err error)
}

type Closer interface {
        Close() error
}

type ReadCloser interface {
        Reader
        Closer
}

이 경우 ReadCloser 인터페이스는 아래와 동일 효과를 갖는다.

type ReadCloser interface {
        Read(p []byte) (n int, err error)
        Close() error
}

그런데 인터페이스를 struct 타입 안에 임베딩할 수 도 있다.

이렇게 struct 타입 안에 인터페이스를 넣는 이유는 보통 Stub 으로 유닛 테스트 코드를 만들기 쉽기 때문이다.

아래와 같이 Calculator 라는 스트럭트가 있다고 하자.

type Calculator struct {
    Resolver MathResolver
}

여기에는 MathResolver 인터페이스 타입의 필드를 가지고 있다.

type MathResolver interface {
    Resolve(expression string) (float64, error)
}

이렇게 인터페이스를 만들어 놓으면 MathResolver 를 Stub 으로 구현하여 테스트 코드를 만들 수 있다.

Calculator 는 계산 표현식을 가지고 실제 계산하여 결과 값을 리턴하는 Process 라는 메소스도 가진다.

func (c Calculator) Process(r io.Reader) (float64, error) {
    expression, err := readOneLine(r)
    if err != nil {
        return 0, err
    }
    if len(expression) == 0 {
        return 0, errors.New("no expression to read")
    }
    answer, err := c.Resolver.Resolve(expression)
    return answer, err
}

readOneLine 함수는 계산 표현식을 한 줄만 읽어들이는 함수이며, 이렇게 읽어들인 함수를 MathResolver 타입의 Resolve 함수에 아규먼트로 넘겨서 결과를 받아오는 구조이다.

이제 Proecess 메소드에 대한 테스트 코드를 만들어 보자.

첫번째로 테스트 코드로 MathResolverStub 스트럭트와 Resolve 메소드를 간단히 구현한다.

type MathResolverStub struct{}

func (mr MathResolverStub) Resolve(expr string) (float64, error) {
    switch expr {
    case "2 + 4 * 10":
        return 42, nil
    case "( 2 + 4 ) * 10":
        return 60, nil
    case "( 2 + 4 * 10":
        return 0, fmt.Errorf("invalid expression: %s", expr)
    }
    return 0, nil
}

다음으로 이 스텁을 사용한 테스트 코드를 작성한다.

func TestCalculatorProcess(t *testing.T) {
    c := embed.Calculator{Resolver: MathResolverStub{}}
    in := strings.NewReader(`2 + 4 * 10
( 2 + 4 ) * 10
( 2 + 4 * 10`)

    data := []float64{42, 60, 0}
    expectedErr := errors.New("invalid expression: ( 2 + 4 * 10")
    for _, d := range data {
        result, err := c.Process(in)
        if err != nil {
            if err.Error() != expectedErr.Error() {
                t.Errorf("want (%v) got (%v)", expectedErr, err)
            }
        }
        if result != d {
            t.Errorf("Expected result %f, got %f", d, result)
        }
    }
}

MathResolverStub 를 가지는 Calculator 를 생성하여 Calculator 의 Process 메소드를 테스트할 수 있는 코드를 쉽게 작성할 수 있다.

테스트 코드의 전체 작성은 다음과 같다.

$ mkdir -p interface/embed
$ vi interface/embed/calculate.go

package embed

import (
    "errors"
    "io"
)

type Calculator struct {
    Resolver MathResolver
}

type MathResolver interface {
    Resolve(expression string) (float64, error)
}

func (c Calculator) Process(r io.Reader) (float64, error) {
    expression, err := readOneLine(r)
    if err != nil {
        return 0, err
    }
    if len(expression) == 0 {
        return 0, errors.New("no expression to read")
    }
    answer, err := c.Resolver.Resolve(expression)
    return answer, err
}

func readOneLine(r io.Reader) (string, error) {
    var out []byte
    b := make([]byte, 1)
    for {
        _, err := r.Read(b)
        if err != nil {
            if err == io.EOF {
                return string(out), nil
            }
        }
        if b[0] == '\n' {
            break
        }
        out = append(out, b[0])
    }
    return string(out), nil
}

$ vi interface/embed/calculate_test.go

package embed_test

import (
    "errors"
    "fmt"
    "strings"
    "testing"

    "github.com/seungkyua/go-test/interface/embed"
)

type MathResolverStub struct{}

func (mr MathResolverStub) Resolve(expr string) (float64, error) {
    switch expr {
    case "2 + 4 * 10":
        return 42, nil
    case "( 2 + 4 ) * 10":
        return 60, nil
    case "( 2 + 4 * 10":
        return 0, fmt.Errorf("invalid expression: %s", expr)
    }
    return 0, nil
}

func TestCalculatorProcess(t *testing.T) {
    c := embed.Calculator{Resolver: MathResolverStub{}}
    in := strings.NewReader(`2 + 4 * 10
( 2 + 4 ) * 10
( 2 + 4 * 10`)

    data := []float64{42, 60, 0}
    expectedErr := errors.New("invalid expression: ( 2 + 4 * 10")
    for _, d := range data {
        result, err := c.Process(in)
        if err != nil {
            if err.Error() != expectedErr.Error() {
                t.Errorf("want (%v) got (%v)", expectedErr, err)
            }
        }
        if result != d {
            t.Errorf("Expected result %f, got %f", d, result)
        }
    }
}

실행을 위한 세팅 명령어는 다음과 같다.

$ go mod init github.com/seungkyua/go-test
$ go mod tidy
$ go mod vendor

$ go work init
$ go work use .

go work 는 비지니스 모듈 패키지를 아직 github 에 커밋하지 않은 상태에서 로컬의 최신 패키지 참조를 위해서 필요하다.

전체 소스 트리는 다음과 같다.

$ tree .                   
.
├── README.md
├── go.mod
├── go.work
└── interface
    └── embed
        ├── calculate.go
        └── calculate_test.go

다음은 테스트 실행 결과이다.

$ go test interface/embed/calculate_test.go
ok      command-line-arguments  0.390s

소스는 아래의 링크에서 다운 받을 수 있다.

https://github.com/seungkyua/go-test.git

git commit 을 원복하는 방법

seungkyua@gmail.com — Thu, 14 Mar 2024 14:33:54 +0900

Git 을 사용하다 보면 저장소에 작업한 commit 을 원복해야 하는 경우가 종종 발생한다. 로컬에서 혼자서 작업한다면 reset 을 사용해서 이전 commit 으로 쉽게 돌릴 수 있지만 이미 원격 저장소에 push 한 상태라면 revert 를 사용하여 이전 commit 을 취소하는 새로운 commit 을 만들어야 한다.

명료하게 아래 2가지 경우만 생각하면 된다.

아직 원격 저장소에 push 하지 않은 경우 : reset 사용
원격 저장소에 push 한 경우 : revert 사용

예외적으로 원격 저장소에 push 한 경우라도 reset 을 사용해서 commit 을 돌릴 수 있다. 하지만 이 때는 원격의 commit 도 같이 삭제하는 작업이 필요하므로 git push 를 할 때 -f 으로 강제 push 를 해야하는 문제가 있어 여러명이 함께 작업하는 경우라면 다른 사람들에게 문제가 발생할 수 있다. (웬만하면 하지 말아야 한다)

git reset : 로컬 환경을 특정 commit 위치로 되돌리기

아래와 같은 commit log 가 있다고 보자.

$ git log --oneline -n 5

4e61ca5 (HEAD -> main, origin/main, origin/HEAD) add c.txt
3bd328a add b.txt
be0d36b add a.txt
205a70c Initial commit

$ ls -l
total 8
-rw-r--r--@ 1 ask  staff  17  3 14 10:12 README.md
-rw-r--r--@ 1 ask  staff   0  3 14 10:15 a.txt
-rw-r--r--@ 1 ask  staff   0  3 14 10:16 b.txt
-rw-r--r--@ 1 ask  staff   0  3 14 10:17 c.txt

Initial 커밋에는 README.md 파일이 추가되어 있고, 이후 각 커밋은 a.txt, b.txt, c.txt 가 추가되어 있는 상태이다. 여기서 a.txt 만 남기고 b.txt, c.txt 를 지운 상태의 돌아가고 싶다고 하면 a.txt 를 추가한 be0d36b add a.txt 커밋 상태로 돌아가면 된다.

$ git reset --hard be0d36b
HEAD is now at be0d36b add a.txt

로그와 파일을 조회해 보면 정상적으로 commit 이 이전 상태로 돌아온 것을 알 수 있다.

$ git log --oneline -n 5

be0d36b (HEAD -> main) add a.txt
205a70c Initial commit

$ ls -l
total 8
-rw-r--r--@ 1 ask  staff  17  3 14 10:12 README.md
-rw-r--r--@ 1 ask  staff   0  3 14 10:15 a.txt

reset 명령을 수행하면 커밋이 이전 상태로 돌아간 것이기 때문에 다시 원상태로 돌릴려면 원격 저장소에서 다시 pull 로 가져오면 된다.

$ git pull 

Updating be0d36b..4e61ca5
Fast-forward
 b.txt | 0
 c.txt | 0
 2 files changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 b.txt
 create mode 100644 c.txt

$ git log --oneline -n 5

4e61ca5 (HEAD -> main, origin/main, origin/HEAD) add c.txt
3bd328a add b.txt
be0d36b add a.txt
205a70c Initial commit

파일도 원상태로 생성된 것을 알 수 있다.

$ ls -l
total 8
-rw-r--r--@ 1 ask  staff  17  3 14 10:12 README.md
-rw-r--r--@ 1 ask  staff   0  3 14 10:15 a.txt
-rw-r--r--@ 1 ask  staff   0  3 14 10:16 b.txt
-rw-r--r--@ 1 ask  staff   0  3 14 10:17 c.txt

git revert : 이전 commit 제거하는 신규 commit 을 추가

현재 커밋 로그는 다음과 같습니다.

$ git log --oneline -n 5

4e61ca5 (HEAD -> main, origin/main, origin/HEAD) add c.txt
3bd328a add b.txt
be0d36b add a.txt
205a70c Initial commit

여기서 3bd328a add b.txt 을 삭제하고 싶을 때 revert 를 할 수 있다.

$ git revert 3bd328a --no-edit

[main 5a9e9f1] Revert "add b.txt"
 Date: Thu Mar 14 10:51:58 2024 +0900
 1 file changed, 0 insertions(+), 0 deletions(-)
 delete mode 100644 b.txt

git log 를 보면 다음과 같다.

$ git log --oneline -n 5

5a9e9f1 (HEAD -> main) Revert "add b.txt"
4e61ca5 (origin/main, origin/HEAD) add c.txt
3bd328a add b.txt
be0d36b add a.txt
205a70c Initial commit

5a9e9f1 (HEAD -> main) Revert "add b.txt" 커밋 로그를 보면 revert 하면서 새로운 commit 이 생긴 것을 알 수 있다. reset 과는 다르게 commit 의 순서와 내용은 그대로 살아있으면서 revert 가 추가된 것이기 협업할 때 아무런 문제가 없다.

리스트를 보면 b.txt 가 삭제되어 다음과 같다.

$ ls -l
total 8
-rw-r--r--@ 1 ask  staff  17  3 14 10:12 README.md
-rw-r--r--@ 1 ask  staff   0  3 14 10:15 a.txt
-rw-r--r--@ 1 ask  staff   0  3 14 10:38 c.txt

revert 와 reset 은 둘 다 파라미터로 commit hash 값을 넣는 것은 동일하나 동작되는 의미는 다르다. reset 은 해당 commit 으로 돌아가기 때문에 그 이후의 commit 은 없어지는 반면에 revert 는 해당 commit 만 제거하는 의미가 있다.

revert 를 다시 revert 할 수 있다

revert 하여 b.txt 를 삭제한 commit 은 5a9e9f1 (HEAD -> main) Revert "add b.txt" 이다. 이 commit 을 revert 하면 다시 b.txt 파일이 살아날 수 있다. revert 할 때 commit hash 값과 이를 가리키는 HEAD 도 같은 의미이기 때문에 HEAD 를 이용하여 revert 해보자.

$ git revert HEAD --no-edit

[main d2b2258] Revert "Revert "add b.txt""
 Date: Thu Mar 14 11:00:28 2024 +0900
 1 file changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 b.txt

$ git log --oneline -n 10

d2b2258 (HEAD -> main) Revert "Revert "add b.txt""
5a9e9f1 Revert "add b.txt"
4e61ca5 (origin/main, origin/HEAD) add c.txt
3bd328a add b.txt
be0d36b add a.txt
205a70c Initial commit

$ ls -l
total 8
-rw-r--r--@ 1 ask  staff  17  3 14 10:12 README.md
-rw-r--r--@ 1 ask  staff   0  3 14 10:15 a.txt
-rw-r--r--@ 1 ask  staff   0  3 14 11:00 b.txt
-rw-r--r--@ 1 ask  staff   0  3 14 10:38 c.txt

여러 commit 을 revert 하기

commit hash 값을 나열하면 여러 commit 을 revert 할 수 있다.

3bd328a add b.txt 커밋과 4e61ca5 (origin/main, origin/HEAD) add c.txt 커밋을 동시에 revert 해보자.

$ git revert --no-edit be0d36b 4e61ca5

[main 3b6ada1] Revert "add a.txt"
 Date: Thu Mar 14 11:11:07 2024 +0900
 1 file changed, 0 insertions(+), 0 deletions(-)
 delete mode 100644 a.txt
[main bd91431] Revert "add c.txt"
 Date: Thu Mar 14 11:11:07 2024 +0900
 1 file changed, 0 insertions(+), 0 deletions(-)
 delete mode 100644 c.txt

$ git log --oneline -n 20

bd91431 (HEAD -> main) Revert "add c.txt"
3b6ada1 Revert "add a.txt"
d2b2258 Revert "Revert "add b.txt""
5a9e9f1 Revert "add b.txt"
4e61ca5 (origin/main, origin/HEAD) add c.txt
3bd328a add b.txt
be0d36b add a.txt
205a70c Initial commit

revert 가 잘 되었지만 각각의 revert 에 대한 커밋이 2개 추가되었다. 3b6ada1 Revert "add a.txt" , bd91431 (HEAD -> main) Revert "add c.txt"

여러 revert 를 하나의 commit 으로 만들기

앞에서 작업한 2개의 revert commit 을 원상태로 되돌려 보자. 원격으로 push 하지 않았으므로 reset 을 사용해도 문제가 없다.

여기서는 d2b2258 Revert "Revert "add b.txt"" 커밋으로 돌아가면 된다.

$ git reset --hard d2b2258
HEAD is now at d2b2258 Revert "Revert "add b.txt""

$ git log --oneline -n 20
d2b2258 (HEAD -> main) Revert "Revert "add b.txt""
5a9e9f1 Revert "add b.txt"
4e61ca5 (origin/main, origin/HEAD) add c.txt
3bd328a add b.txt
be0d36b add a.txt
205a70c Initial commit

$ ls -l
total 8
-rw-r--r--@ 1 ask  staff  17  3 14 10:12 README.md
-rw-r--r--@ 1 ask  staff   0  3 14 11:19 a.txt
-rw-r--r--@ 1 ask  staff   0  3 14 11:00 b.txt
-rw-r--r--@ 1 ask  staff   0  3 14 11:19 c.txt

revert -n 옵션을 사용하면 revert 할 때 index 는 사용하지만 commit 을 하지 않은 상태가 된다. 그러므로 git revert --continue 로 commit 을 진행하면 된다.

 $ git revert -n be0d36b 4e61ca5

현재 상태를 보면 index 에 저장된 상태임을 알 수 있다.

$ git status

On branch main
Your branch is ahead of 'origin/main' by 2 commits.
  (use "git push" to publish your local commits)

You are currently reverting commit 4e61ca5.
  (all conflicts fixed: run "git revert --continue")
  (use "git revert --skip" to skip this patch)
  (use "git revert --abort" to cancel the revert operation)

Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
    deleted:    a.txt
    deleted:    c.txt

이제 commit 을 하면서 커밋 메세지를 추가할 수 있다.

$ git revert --continue

메세지는 다음과 같이 입력했다.

Revert "add c.txt"
Revert "add a.txt"

git log 를 보면 커밋은 a4b6156 (HEAD -> main) Revert "add c.txt" Revert "add a.txt" 하나만 생성되었음을 알 수 있다.

$ git log --oneline -n 20

a4b6156 (HEAD -> main) Revert "add c.txt" Revert "add a.txt"
d2b2258 Revert "Revert "add b.txt""
5a9e9f1 Revert "add b.txt"
4e61ca5 (origin/main, origin/HEAD) add c.txt
3bd328a add b.txt
be0d36b add a.txt
205a70c Initial commit

$ ls -l
total 8
-rw-r--r--@ 1 ask  staff  17  3 14 10:12 README.md
-rw-r--r--@ 1 ask  staff   0  3 14 11:00 b.txt

다음 설명을 위해서 다시 reset 을 하자. commit 하나만 뒤로가면 되므로 HEAD^1 을 사용해도 된다.

$ git reset --hard HEAD^1

git revert: merge commit 에 대한 revert 하기

현재 커밋 로그는 다음과 같다.

$ git log --oneline -n 20

d2b2258 (HEAD -> main) Revert "Revert "add b.txt""
5a9e9f1 Revert "add b.txt"
4e61ca5 (origin/main, origin/HEAD) add c.txt
3bd328a add b.txt
be0d36b add a.txt
205a70c Initial commit

$ ls -l
total 8
-rw-r--r--@ 1 ask  staff  17  3 14 10:12 README.md
-rw-r--r--@ 1 ask  staff   0  3 14 11:34 a.txt
-rw-r--r--@ 1 ask  staff   0  3 14 11:00 b.txt
-rw-r--r--@ 1 ask  staff   0  3 14 11:34 c.txt

git push 를 해서 원격 저장소에 저장한 다음 merge commit 을 만드는 작업을 한다.

$ git push

$ git switch -c merge_branch
$ touch d.txt
$ git add -A
$ git commit -m "add d.txt"

$ git push --set-upstream origin merge_branch

github 에서 pr 을 올리고 main branch 로 merge 한다.

이후에 main branch 에서 pull 한 다음에 커밋 로그를 보면 다음과 같다.

$ git switch main

$ git pull

$ ls -l
total 8
-rw-r--r--@ 1 ask  staff  17  3 14 10:12 README.md
-rw-r--r--@ 1 ask  staff   0  3 14 11:34 a.txt
-rw-r--r--@ 1 ask  staff   0  3 14 11:00 b.txt
-rw-r--r--@ 1 ask  staff   0  3 14 11:34 c.txt
-rw-r--r--@ 1 ask  staff   0  3 14 11:44 d.txt

$ git log
commit 409bf49c1b05a39609207da03f28f782c3b8a0b9 (HEAD -> main, origin/main, origin/HEAD)
Merge: d2b2258 9fdd01f
Author: Seungkyu Ahn <seungkyua@gmail.com>
Date:   Thu Mar 14 11:42:42 2024 +0900

    Merge pull request #1 from seungkyua/merge_branch

    add d.txt

commit 9fdd01fb9b0eff870093f15e246c998ae1fac452 (origin/merge_branch, merge_branch)
Author: Seungkyu Ahn <seungkyua@gmail.com>
Date:   Thu Mar 14 11:40:46 2024 +0900

    add d.txt

commit d2b22584cb8108cd7bc1eaaaa5775e1f19f330fa
Author: Seungkyu Ahn <seungkyua@gmail.com>
Date:   Thu Mar 14 11:00:28 2024 +0900

    Revert "Revert "add b.txt""

    This reverts commit 5a9e9f14b9b7403ad5aef1df83d14f1a1d4938dd.

첫번째 커밋 로그를 보면 Merge: d2b2258 9fdd01f 와 같이 Merge 임을 알 수 있다. merge 의 경우 revert 는 -m 옵션으로 첫번재 hash 값을 적용할지 두번째 hash 값을 적용할지를 결정해 주어야 한다.

merge 바로 이전 커밋인 d2b2258 으로 revert 할 것이기 때문에 첫번재를 선택해 준다.

$ git revert 409bf49c -m 1

[main d53c40d] Revert "Merge pull request #1 from seungkyua/merge_branch"
 1 file changed, 0 insertions(+), 0 deletions(-)
 delete mode 100644 d.txt

로그를 보면 revert 되었음을 알 수 있다.

$ git log --oneline -n 20

d53c40d (HEAD -> main) Revert "Merge pull request #1 from seungkyua/merge_branch"
409bf49 (origin/main, origin/HEAD) Merge pull request #1 from seungkyua/merge_branch
9fdd01f (origin/merge_branch, merge_branch) add d.txt
d2b2258 Revert "Revert "add b.txt""
5a9e9f1 Revert "add b.txt"
4e61ca5 add c.txt
3bd328a add b.txt
be0d36b add a.txt
205a70c Initial commit

$ ls -l
total 8
-rw-r--r--@ 1 ask  staff  17  3 14 10:12 README.md
-rw-r--r--@ 1 ask  staff   0  3 14 11:34 a.txt
-rw-r--r--@ 1 ask  staff   0  3 14 11:00 b.txt
-rw-r--r--@ 1 ask  staff   0  3 14 11:34 c.txt

patch 로 commit 삭제하기

commit 에 대한 패치 파일을 만들고 -R 옵션을 사용하여 패치 파일을 apply 하면 해당 패치 파일에 대한 commit 을 삭제할 수 있다.

현재 커밋 로그는 다음과 같다.

$ git log --oneline -n 20

d53c40d (HEAD -> main, origin/main, origin/HEAD) Revert "Merge pull request #1 from seungkyua/merge_branch"
409bf49 Merge pull request #1 from seungkyua/merge_branch
9fdd01f (origin/merge_branch, merge_branch) add d.txt
d2b2258 Revert "Revert "add b.txt""
5a9e9f1 Revert "add b.txt"
4e61ca5 add c.txt
3bd328a add b.txt
be0d36b add a.txt
205a70c Initial commit

$ ls -l
total 8
-rw-r--r--@ 1 ask  staff  17  3 14 10:12 README.md
-rw-r--r--@ 1 ask  staff   0  3 14 11:34 a.txt
-rw-r--r--@ 1 ask  staff   0  3 14 11:00 b.txt
-rw-r--r--@ 1 ask  staff   0  3 14 11:34 c.txt

여기서 3bd328a add b.txt 에 대한 패치 파일을 만들어 보자.

$ git format-patch -1 3bd328a

아래와 같이 하나의 0001-add-b.txt.patch 패치 파일이 생성되었다.

$ ls -l
total 16
-rw-r--r--@ 1 ask  staff  368  3 14 13:46 0001-add-b.txt.patch
-rw-r--r--@ 1 ask  staff   17  3 14 10:12 README.md
-rw-r--r--@ 1 ask  staff    0  3 14 11:34 a.txt
-rw-r--r--@ 1 ask  staff    0  3 14 11:00 b.txt
-rw-r--r--@ 1 ask  staff    0  3 14 11:34 c.txt

이제 -R 옵션을 적용하여 patch 파일을 적용하자. -R 옵션은 reverse 로 패치 파일을 삭제하는 역할을 한다.

$ git apply -R 0001-add-b.txt.patch

상태를 보면 다음과 같다.

$ git status
On branch main
Your branch is up to date with 'origin/main'.

Changes not staged for commit:
  (use "git add/rm <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
    deleted:    b.txt

Untracked files:
  (use "git add <file>..." to include in what will be committed)
    0001-add-b.txt.patch

no changes added to commit (use "git add" and/or "git commit -a")

파일 리스트를 보면 b.txt 가 삭제되어 있다.

$ ls -l
total 16
-rw-r--r--@ 1 ask  staff  368  3 14 13:46 0001-add-b.txt.patch
-rw-r--r--@ 1 ask  staff   17  3 14 10:12 README.md
-rw-r--r--@ 1 ask  staff    0  3 14 11:34 a.txt
-rw-r--r--@ 1 ask  staff    0  3 14 11:34 c.txt

이제 삭제된 파일을 stage 에 add 한 후 commit 한다.

$ git add b.txt
$ git commit -m "-R patch to b.txt"

커밋 로그를 보면 b.txt 가 삭제된 것을 알 수 있다.

$ git log --oneline -n 20

44e55ce (HEAD -> main) -R patch to b.txt
d53c40d (origin/main, origin/HEAD) Revert "Merge pull request #1 from seungkyua/merge_branch"
409bf49 Merge pull request #1 from seungkyua/merge_branch
9fdd01f (origin/merge_branch, merge_branch) add d.txt
d2b2258 Revert "Revert "add b.txt""
5a9e9f1 Revert "add b.txt"
4e61ca5 add c.txt
3bd328a add b.txt
be0d36b add a.txt
205a70c Initial commit

패치 파일이 있으니 apply 로 해당 commit 을 다시 살려보자. 실제로는 commit 을 살리는 것이 아니라 해당 commit 의 변경된 파일을 되살리는 것이다.

$ git apply 0001-add-b.txt.patch
$ git add b.txt
$ git commit -m "restore b.txt using patch"

아래 디렉토리에 b.txt 가 살아난 것을 알 수 있다.

$ ls -l
total 16
-rw-r--r--@ 1 ask  staff  368  3 14 13:46 0001-add-b.txt.patch
-rw-r--r--@ 1 ask  staff   17  3 14 10:12 README.md
-rw-r--r--@ 1 ask  staff    0  3 14 11:34 a.txt
-rw-r--r--@ 1 ask  staff    0  3 14 14:03 b.txt
-rw-r--r--@ 1 ask  staff    0  3 14 11:34 c.txt

필요없는 패치 파일은 삭제한다.

$ rm 0001-add-b.txt.patch

여러 커밋을 하나의 패치 파일로 만들기

현재 커밋 로그는 아래와 같다.

$ git log --oneline -n 20

9aced43 (HEAD -> main, origin/main, origin/HEAD) restore b.txt using patch
44e55ce -R patch to b.txt
d53c40d Revert "Merge pull request #1 from seungkyua/merge_branch"
409bf49 Merge pull request #1 from seungkyua/merge_branch
9fdd01f (origin/merge_branch, merge_branch) add d.txt
d2b2258 Revert "Revert "add b.txt""
5a9e9f1 Revert "add b.txt"
4e61ca5 add c.txt
3bd328a add b.txt
be0d36b add a.txt
205a70c Initial commit

여기서 be0d36b add a.txt , 3bd328a add b.txt, 4e61ca5 add c.txt 을 하나의 패치 파일로 만들고 싶으면 다음과 같이 하면 된다.

시작 hash값 ^.. 종료 hash값

만약 .. 만 사용하면 시간 hash값은 포함되지 않는다(여기서는 be0d36b add a.txt 커밋이 포함되지 않는다). 그러므로 시작 hash값을 포함하고 싶으면 ^.. 을 사용해야 한다.

$ git format-patch be0d36b^..4e61ca5 --stdout > commits.patch

한가지 더 설명하자면 format-patch 는 커밋 히스토리까지 파일에 포함 시킨다. diff 를 사용하면 커밋 히스토리를 제외할 수 있다.

$ git diff be0d36b^..4e61ca5 > diff.patch

이것만 공부하세요 - helm chart 만드는 법

seungkyua@gmail.com — Mon, 20 Nov 2023 12:35:58 +0900

helm chart 를 만들기 위해서는 여러 기능들을 알아야 하지만 그 중에서 가장 많이 쓰고 헷갈리는 기능에 대해서 살펴 본다.

기본적으로 실습할 수 있는 환경을 먼저 만들고 하나씩 공부해 본다.

$ helm create flow-control
$ cd flow-control

yaml 형태의 출력을 확인해 본다.

$ helm template .
---
# Source: flow-control/templates/serviceaccount.yaml
apiVersion: v1
kind: ServiceAccount
metadata:
  name: release-name-flow-control
  labels:
    helm.sh/chart: flow-control-0.1.0
    app.kubernetes.io/name: flow-control
    app.kubernetes.io/instance: release-name
    app.kubernetes.io/version: "1.16.0"
    app.kubernetes.io/managed-by: Helm
automountServiceAccountToken: true
---
# Source: flow-control/templates/service.yaml
apiVersion: v1
kind: Service
metadata:
  name: release-name-flow-control
  labels:
    helm.sh/chart: flow-control-0.1.0
    app.kubernetes.io/name: flow-control
    app.kubernetes.io/instance: release-name
    app.kubernetes.io/version: "1.16.0"
    app.kubernetes.io/managed-by: Helm
spec:
  type: ClusterIP
  ports:
    - port: 80
      targetPort: http
      protocol: TCP
      name: http
  selector:
    app.kubernetes.io/name: flow-control
    app.kubernetes.io/instance: release-name
---
# Source: flow-control/templates/deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: release-name-flow-control
  labels:
    helm.sh/chart: flow-control-0.1.0
    app.kubernetes.io/name: flow-control
    app.kubernetes.io/instance: release-name
    app.kubernetes.io/version: "1.16.0"
    app.kubernetes.io/managed-by: Helm
spec:
  replicas: 1
  selector:
    matchLabels:
      app.kubernetes.io/name: flow-control
      app.kubernetes.io/instance: release-name
  template:
    metadata:
      labels:
        helm.sh/chart: flow-control-0.1.0
        app.kubernetes.io/name: flow-control
        app.kubernetes.io/instance: release-name
        app.kubernetes.io/version: "1.16.0"
        app.kubernetes.io/managed-by: Helm
    spec:
      serviceAccountName: release-name-flow-control
      securityContext:
        {}
      containers:
        - name: flow-control
          securityContext:
            {}
          image: "nginx:1.16.0"
          imagePullPolicy: IfNotPresent
          ports:
            - name: http
              containerPort: 80
              protocol: TCP
          livenessProbe:
            httpGet:
              path: /
              port: http
          readinessProbe:
            httpGet:
              path: /
              port: http
          resources:
            {}
---
# Source: flow-control/templates/tests/test-connection.yaml
apiVersion: v1
kind: Pod
metadata:
  name: "release-name-flow-control-test-connection"
  labels:
    helm.sh/chart: flow-control-0.1.0
    app.kubernetes.io/name: flow-control
    app.kubernetes.io/instance: release-name
    app.kubernetes.io/version: "1.16.0"
    app.kubernetes.io/managed-by: Helm
  annotations:
    "helm.sh/hook": test
spec:
  containers:
    - name: wget
      image: busybox
      command: ['wget']
      args: ['release-name-flow-control:80']
  restartPolicy: Never

제대로 출력된다면 필요없는 파일은 삭제하고 초기화 하자.

$ rm -rf template/*
$ cat /dev/null > values.yaml

0. yaml 은 들여 쓰기가 중요하다.

가장 간단한 configmap 을 만들어서 value 값을 출력한다.

$ values.yaml
---
favorite:
  drink: coffee
  food: pizza

$ vi template/configmap.yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: {{ .Release.Name }}-configmap
data:
  myvalue: "Hello World"
  drink: {{ .Values.favorite.drink | default "tea" | quote }}
  food: {{ .Values.favorite.food | upper | quote }}
  {{ if eq .Values.favorite.drink "coffee" }}
    mug: "true"
  {{ end }}

$ helm template .
--- output ---
Error: YAML parse error on flow-control/templates/configmap.yaml: error converting YAML to JSON: yaml: line 8: did not find expected key

Use --debug flag to render out invalid YAML

template 을 제너레이션하면 에러가 발생한다. 왜 그럴까?

configmap.yaml 에 mug: "true" 가 2칸 들여써 있어서 발생하는 에러이다. 이런 에러를 조심하면서 아래 실습을 해보자.

1. 조건문과 빈라인 없애기

configmap.yaml 을 수정해서 제대로 yaml 을 생성해 보자.

$ vi template/configmap.yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: {{ .Release.Name }}-configmap
data:
  myvalue: "Hello World"
  drink: {{ .Values.favorite.drink | default "tea" | quote }}
  food: {{ .Values.favorite.food | upper | quote }}
  {{ if eq .Values.favorite.drink "coffee" }}
  mug: "true"
  {{ end }}

$ helm template .
---
# Source: flow-control/templates/configmap.yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: release-name-configmap
data:
  myvalue: "Hello World"
  drink: "coffee"
  food: "PIZZA"
                    --------------> 빈라인 발생한다.
  mug: "true"
                    --------------> 빈라인 발생한다.

.Release.Name 은 helm 으로 설치할 때 파라미터로 넘기는 값인데 여기서는 설치가 아니므로 기본 값인 release-name 으로 치환 되었고, .Values.favorite.drink 는 values.yaml 에 지정한 키값으로 그에 해당하는 밸류 값이 제너레이트 될 때 출력된다.

함수의 연속적 사용은 | 라인으로 호출 가능하며 default 는 키에 대한 값이 없을 때, quote 는 값을 " 으로 묶을 때 upper 는 값을 대문자로 변환할 때 사용하는 내장 함수이다.

비교 구문은 if eq 값1 값2 와 같이 사용할 수 있다.

출력하지 않는 곳에서는 빈라인이 발생하는데 이 부분을 다음과 같이 없애 줄 수 있다.

{{ if eq .Values.favorite.drink "coffee" }}mug: "true"{{ end }}

하지만 가독성이 떨어지므로 {{- 와 같이 표현하면 빈라인이 없어지면서 윗라인에 나란히 붙는 것과 같은 효과를 낼 수 있다.

  {{- if eq .Values.favorite.drink "coffee" }}
  mug: "true"
  {{- end }}

다시 yaml 을 생성해 보면 아래와 같이 빈라인이 없어졌음을 알 수 있다.

$ helm template .
---
# Source: flow-control/templates/configmap.yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: release-name-configmap
data:
  myvalue: "Hello World"
  drink: "coffee"
  food: "PIZZA"
  mug: "true"

조건문 대신 다음과 같이 with 를 사용하여 조건문과 키밸류 스쿱을 지정할 수 있다.

### configmap.yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: {{ .Release.Name }}-configmap
data:
  myvalue: "Hello World"
  {{- with .Values.hobby }}
  sports: {{ .sports }}
  {{- end }}

### values.yaml
hobby:
  sports: golf

with 와 함께 사용한 키는 해당 키에 대한 값이 있을 때만 with ~ end 로 감싼 구문이 출력된다. 또한 감싼 구문 안에서는 스쿱이 재정의되어 hobby 아래의 키인 sports 를 .sports 로 바로 사용할 수 있다.

yaml 을 생성하면 다음과 같은 결과가 나온다.

$ helm template .

# Source: flow-control/templates/configmap.yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: release-name-configmap
data:
  myvalue: "Hello World"
  sports: golf

만약 values 에 sports 를 없애면 아래와 같이 출력되지 않는다.

### values.yaml
hobby: {}

# Source: flow-control/templates/configmap.yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: release-name-configmap
data:
  myvalue: "Hello World"

hobby 아래의 키는 키밸류인 디셔너리 타입을 넣기 때문에 아래의 값을 모두 없애기 위해서{} 빈 딕셔너리 값으로 지정했다. 만약 아래의 값이 리스트라면 [] 와 같이 빈 리스트 값을 지정할 수 있다.

with ~ end 로 감싼 구문에서 root 영역의 value 를 활용하고 싶을 수 있다. 이 때는 $ 를 붙혀서 영역을 최상위 root 로 접근할 수 있다. 아래 예제에서 $.Release.Name 을 참고한다.

### configmap.yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: {{ .Release.Name }}-configmap
data:
  myvalue: "Hello World"
  {{- with .Values.hobby }}
  sports: {{ .sports }}
  release: {{ $.Release.Name }}
  {{- end }}

YAML 은 JSON 의 수퍼셋이기 때문에 JSON 으로 표현하여 가독성을 높혀줄 수 도 있다. pod 를 만들 때 yaml 에 args 를 추가할 수 있는데. 이 때 JSON 을 쓰면 읽기에 편하다.

args:
  - "--dirname"
  - "/foo"

위의 내용은 JSON 으로 아래와 같이 바꿀 수 있다.

args: ["--dirname", "/foo"]

2. range 함수를 이용한 반복문

range 를 이용하여 반복문을 사용할 수 있다.

### values.yaml
pizzaToppings:
  - mushrooms
  - cheese
  - peppers
  - onions

### configmap.yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: {{ .Release.Name }}-configmap
data:
  toppings: |-
    {{- range .Values.pizzaToppings }}
    - {{ . | title | quote }}
    {{- end }}

pizzaToppings 의 값은 리스트이다(- 기호가 값으로 붙었기 때문에 리스트임을 알 수 있다). 리스트로 값을 가져와서 출력하기 때문에 아래와 같은 결과가 나온다.

# Source: flow-control/templates/configmap.yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: release-name-configmap
data:
  toppings: |-
    - "Mushrooms"
    - "Cheese"
    - "Peppers"
    - "Onions"

한가지 yaml 에서 toppings: 의 뒤에 따라온 |- 기호의 의미는 멀티 라인 스트링을 받겠다는 의미이다.

tuple 을 사용하여 튜플로 만들어 쓸 수 도 있다.

### configmap.yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: {{ .Release.Name }}-configmap
data:
  sizes: |-
    {{- range tuple "small" "medium" "large" }}
    - {{ . }}
    {{- end }}

### 출력 결과
# Source: flow-control/templates/configmap.yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: release-name-configmap
data:
  sizes: |-
    - small
    - medium
    - large

$ 와 := 를 이용하여 변수를 지정할 수 있다. 아래는 리스트에서 받은 값을 index 변수와 value 변수로 받아서 활용하는 부분이다.

### values.yaml
pizzaToppings:
  - mushrooms
  - cheese
  - peppers
  - onions

### configmap.yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: {{ .Release.Name }}-configmap
data:
  toppings: |-
    {{- range $index, $value := .Values.pizzaToppings }}
    - {{ $index }}: {{ $value }}
    {{- end }}

# Source: flow-control/templates/configmap.yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: release-name-configmap
data:
  toppings: |-
    - 0: mushrooms
    - 1: cheese
    - 2: peppers
    - 3: onions

map 값을 변수로 받아 처리할 수 도 있다.

### values.yaml
favorite:
  drink: coffee
  food: pizza

### configmap.yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: {{ .Release.Name }}-configmap
data:
  favorite: |-
    {{- range $key, $value := .Values.favorite }}
    {{ $key }}: {{ $value }}
    {{- end }}

# Source: flow-control/templates/configmap.yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: release-name-configmap
data:
  favorite: |-
    drink: coffee
    food: pizza

3. template 선언 및 활용

부분적으로 사용자 정의 template 을 만들어서 활용 할 수 있다.

define - tempate 사용

template 은 define 으로 선언하고 tempate 으로 활용할 수 있다.

### configmap.yaml
{{- define "mychart.labels" }}
  labels:
    generator: helm
    date: {{ now | htmlDate }}
{{- end }}
apiVersion: v1
kind: ConfigMap
metadata:
  name: {{ .Release.Name }}-configmap
  {{- template "mychart.labels" }}
data:
  myvalue: "Hello World"

# Source: flow-control/templates/configmap.yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: release-name-configmap
  labels:
    generator: helm
    date: 2023-10-31
data:
  myvalue: "Hello World"

위의 예제는 labels 에 date: 날짜 를 추가로 넣는 부분을 named template 을 만들어서 사용한 예제이다.

chat 를 만들 때 configmap.yaml 과 같이 쿠버네티스 리소스들은 template 디렉토리 아래에 위치 시킨다고 했다. 이 디렉토리에 위치한 yaml 파일들은 자동으로 렌더링에 포함되는데 _ 로 시작하는 파일은 렌더링에서 제외한다. 그래서 보통 define 으로 정의한 함수들은 _helper.tpl 파일을 만들어서 이곳에 위치 시킨다.

define 으로 정의된 named template (함수) 은 template 으로 호출되기 전까지는 렌더링 되지 않는다. 이제 이 함수를 _helper.tpl 파일로 옮겨서 렌더링 결과를 살펴보자.

# _helper.tpl
{{- define "mychart.labels" }}
  labels:
    generator: helm
    date: {{ now | htmlDate }}
{{- end }}

# configmap.yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: {{ .Release.Name }}-configmap
  {{- template "mychart.labels" }}
data:
  myvalue: "Hello World"

# Source: flow-control/templates/configmap.yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: release-name-configmap
  labels:
    generator: helm
    date: 2023-10-31
data:
  myvalue: "Hello World"

위의 예제에서 define 함수 내에서 .Values 와 같이 value 를 가져오는 것은 하지 않았다. 아래와 같이 {{ .Chart.Name }} 을 사용한다면 위의 방식으로는 값을 표현할 수 없다.

# _helper.tpl
{{- define "mychart.labels" }}
  labels:
    generator: helm
    date: {{ now | htmlDate }}
    chart: {{ .Chart.Name }}
    version: {{ .Chart.Version }}
{{- end }} 

# Source: flow-control/templates/configmap.yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: release-name-configmap
  labels:
    generator: helm
    date: 2023-10-31
    chart:
    version:
data:
  myvalue: "Hello World"

이는 template 으로 호출할 때 뒤에 value 를 보내지 않아서 발생한 부분이다. 즉 {{- template "mychart.labels" . }} 과 같이 마지막에 현재의 scope value 인 . 을 넘겨 주어야 제대로 된 값이 출력된다.

# configmap.yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: {{ .Release.Name }}-configmap
  {{- template "mychart.labels" . }}
data:
  myvalue: "Hello World"

# Source: flow-control/templates/configmap.yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: release-name-configmap
  labels:
    generator: helm
    date: 2023-10-31
    chart: flow-control
    version: 0.1.0

define - include 사용

template 은 있는 그대로 output 을 보여주기 때문에 들여쓰기의 문제가 있을 수 있다.

# _helper.tlp
{{- define "mychart.app" -}}
app_name: {{ .Chart.Name }}
app_version: "{{ .Chart.Version }}"
{{- end -}}

# configmap.yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: {{ .Release.Name }}-configmap
  labels:
    {{ template "mychart.app" . }}
data:
  myvalue: "Hello World"
{{ template "mychart.app" . }}

# Source: flow-control/templates/configmap.yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: release-name-configmap
  labels:
    app_name: flow-control
app_version: "0.1.0"
data:
  myvalue: "Hello World"
app_name: flow-control
app_version: "0.1.0"

app_name 과 app_version 이 출력된 것을 보면 define 에 정의된 들여쓰기 대로 그대로 출력되어 원하는 대로 출력되지 않는다.

include 와 nindent 를 사용하면 원하는 들여쓰기가 가능하다.

# configmap.yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: {{ .Release.Name }}-configmap
  labels:
    {{ template "mychart.app" . }}
data:
  myvalue: "Hello World"
{{ template "mychart.app" . }}

# Source: flow-control/templates/configmap.yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: release-name-configmap
  labels:
    app_name: flow-control
    app_version: "0.1.0"
data:
  myvalue: "Hello World"
  app_name: flow-control
  app_version: "0.1.0"

끝으로 helm install 할 때 들여쓰기가 잘못되면 렌더링 오류가 나서 최종 결과를 볼 수 가 없다. 이를 해결할 수 있는 옵션이 -disable-openapi-validation 이다.

$ helm install --dry-run --disable-openapi-validation mychart ./

springboot 컨테이너 이미지 사이즈 경량화 방법

seungkyua@gmail.com — Wed, 25 Oct 2023 11:18:10 +0900

스프링 부트 기반으로 개발한 어플리케이션을 컨테이너 이미지로 만들 때 이미지 사이즈를 줄이는 방법에 대해서 알아보자.

먼저, sample source 를 다운 받는다.

$ git clone https://github.com/seungkyua/springboot-docker.git
$ cd springboot-docker

다운 받은 소스에서 mvn 으로 package 를 빌드한다.

$ mvn package

빌드 후에 소스의 디렉토리 구조는 다음과 같다.

$ tree . -L 2
.
├── LICENSE
├── README.md
├── docker
│   ├── Dockerfile
│   ├── Dockerfile2
│   └── Dockerfile3
├── logs
│   └── access_log.log
├── pom.xml
├── scripts
│   └── run.sh
├── src
│   └── main
├── target
│   ├── classes
│   ├── example-0.0.1-SNAPSHOT.jar
│   ├── example-0.0.1-SNAPSHOT.jar.original
│   ├── generated-sources
│   ├── maven-archiver
│   └── maven-status
└── work
    └── Tomcat

오늘은 자바 소스는 상관없이 도커 이미지 빌드에 대해서만 설명하므로 Dockerfile 만 살펴보자.

컨테이너 이미지 만들기 - 기본편

docker/Dockerfile2 을 보면 아래와 같다.

FROM openjdk:17.0.2-jdk-slim
MAINTAINER Ahn Seungkyu

ARG JAR_FILE=example-0.0.1-SNAPSHOT.jar

RUN mkdir -p /app
WORKDIR /app

COPY target/${JAR_FILE} /app/app.jar
COPY scripts/run.sh .
ENTRYPOINT ["./run.sh"]

base 이미지로 openjdk:17.0.2-jdk-slim 이미지를 사용하였고 target 아래의 빌드된 jar 파일을 복사하여 실행하는 방법이다.

실행 명령어는 scripts/run.sh 파일을 보면 알 수 있다.

#!/bin/sh

java ${JAVA_OPTS} -jar app.jar ${@}

JAVA_OPTS 는 환경 변수 이므로 컨테이너를 실행할 때 해당 값을 전달하는 것이 가능하다.

이제 컨테이너 이미지를 빌드하면 그 사이즈는 다음과 같다.

$ docker build -t seungkyua/springboot-docker -f docker/Dockerfile2 .

------- output -----------
[+] Building 2.6s (11/11) FINISHED                                                                                                                                                                                                               docker:desktop-linux
 => [internal] load build definition from Dockerfile2                                                                                                                                                                                                            0.0s
 => => transferring dockerfile: 442B                                                                                                                                                                                                                             0.0s
 => [internal] load .dockerignore                                                                                                                                                                                                                                0.0s
 => => transferring context: 2B                                                                                                                                                                                                                                  0.0s
 => [internal] load metadata for docker.io/library/openjdk:17.0.2-jdk-slim                                                                                                                                                                                       2.2s
 => [auth] library/openjdk:pull token for registry-1.docker.io                                                                                                                                                                                                   0.0s
 => CACHED [1/5] FROM docker.io/library/openjdk:17.0.2-jdk-slim@sha256:aaa3b3cb27e3e520b8f116863d0580c438ed55ecfa0bc126b41f68c3f62f9774                                                                                                                          0.0s
 => [internal] load build context                                                                                                                                                                                                                                0.0s
 => => transferring context: 291B                                                                                                                                                                                                                                0.0s
 => [2/5] RUN mkdir -p /app                                                                                                                                                                                                                                      0.1s
 => [3/5] WORKDIR /app                                                                                                                                                                                                                                           0.0s
 => [4/5] COPY target/example-0.0.1-SNAPSHOT.jar /app/app.jar                                                                                                                                                                                                    0.1s
 => [5/5] COPY scripts/run.sh .                                                                                                                                                                                                                                  0.0s
 => exporting to image                                                                                                                                                                                                                                           0.1s
 => => exporting layers                                                                                                                                                                                                                                          0.1s
 => => writing image sha256:6d6ba6764805971eef0532e21ec28feb6308ddb04bb650a7d087ab689d0d65be                                                                                                                                                                     0.0s
 => => naming to docker.io/seungkyua/springboot-docker

$ docker image ls 
REPOSITORY                    TAG       IMAGE ID       CREATED          SIZE
seungkyua/springboot-docker   latest    6d6ba6764805   54 seconds ago   473MB

이미지 크기가 473M 로 만들어졌다. 어플리케이션 jar 파일의 크기가 68M 이므로 JVM 을 포함하는 이미지가 405M 의 크기가 된다는 의미이다.

보통 이미지를 작게하기 위해서 base 이미지 태그로 alpine 이나 slim 을 많이 사용한다. 여기서 slim 을 사용했는데도 이 정도 크기라면 사이즈가 작다고 할 수 없다.

더 작은 사이즈를 만들기 위해서 alpine 이미지를 찾아서 적용해 보자.

base 이미지를 amazoncorretto 로 변경하고 다시 사이즈를 비교해 보자.

FROM amazoncorretto:17-alpine
MAINTAINER Ahn Seungkyu

ARG JAR_FILE=example-0.0.1-SNAPSHOT.jar

RUN mkdir -p /app
WORKDIR /app

COPY target/${JAR_FILE} /app/app.jar
COPY scripts/run.sh .
ENTRYPOINT ["./run.sh"]

$ docker build -t seungkyua/springboot-docker -f docker/Dockerfile2 .

$ docker image ls
REPOSITORY                    TAG       IMAGE ID       CREATED          SIZE
seungkyua/springboot-docker   latest    ed08524545ba   31 seconds ago   358MB
<none>                        <none>    6d6ba6764805   7 minutes ago    473MB

조회되는 이미지를 보면 base 이미지만을 바꿨을 뿐인데 358M 로 줄어들었다.

컨테이너 이미지 만들기 - 멀티 스테이지

컨테이너 이미지 사이즈를 줄이기 위해서 멀티 스테이지를 써야 한다는 말을 들어봤을 것이다. 여기서도 사이즈를 줄이기 위해 멀티 스테이지를 사용해 보자.

docker/Dockerfile3 를 보면 멀티 스테이지를 어떻게 구성하는지 알 수 있다.

# syntax=docker/dockerfile:1
FROM maven:3.8.5-openjdk-17 as build
MAINTAINER Ahn Seungkyu

WORKDIR /app
COPY . /app
RUN --mount=type=cache,target=/root/.m2 mvn -Dmaven.wagon.http.ssl.insecure=true -Dmaven.wagon.http.ssl.allowall=true package

FROM amazoncorretto:17-alpine
MAINTAINER Ahn Seungkyu

ARG JAR_FILE=example-0.0.1-SNAPSHOT.jar

WORKDIR /app
COPY --from=build /app/target/${JAR_FILE} /app/app.jar
COPY scripts/run.sh /app/
ENTRYPOINT ["./run.sh"]

빌드하는 이미지와 런타임에서 실행되는 이미지가 나눠져 있다.

# syntax=docker/dockerfile:1 는 이미지 안에서 소스 빌드를 할 때 디펜던시가 있는 파일을 매번 가져오지 말고 한 번만 가져와서 캐싱하여 효율적으로 사용하고자 할 때 사용한다.

--mount=type=cache,target=/root/.m2 는 로컬에 저장해서 재활용하자는 의미이고 -Dmaven.wagon.http.ssl.insecure=true -Dmaven.wagon.http.ssl.allowall=true 메이븐으로 패키지할 때 jvm 이 ssl 인증서 없이 사용하기 위해서 추가되었다.

첫번째는 어플리케이션을 빌드하기 위해 필요한 이미지 정의이고 두번째는 빌드된 어플리케이션을 복사하는 이미지 정의로 두번째는 앞서 기본편에서 설명한 것과 동일하다.

jar 파일만 빌드해서 복사하는 구조라 실제로 이미지 차이는 없을 것이다. 다만, 빌드를 이미지를 만들 때 로컬 환경 구성 없이도 만들 수 있다는 장점이 있다.

$ docker build -t seungkyua/springboot-docker -f docker/Dockerfile3 .

$ docker image ls
REPOSITORY                    TAG       IMAGE ID       CREATED          SIZE
seungkyua/springboot-docker   latest    33ed3cbf0300   31 seconds ago   358MB
<none>                        <none>    ed08524545ba   4 minutes ago    358MB
<none>                        <none>    6d6ba6764805   7 minutes ago    473MB

컨테이너 이미지 만들기 - alpine 에 추가

여전히 사이즈가 358M 로 작지 않은 사이즈이다.

이제 기본 alpine 이미지에 JRE 와 어플리케이션을 설치하는 방법으로 이미지 사이즈를 줄여보자.

docker/Dockerfile 을 살펴보자.

FROM amazoncorretto:17-alpine3.18 as builder-jre

RUN apk add --no-cache --repository=http://dl-cdn.alpinelinux.org/alpine/edge/main/ binutils=2.41-r0

RUN $JAVA_HOME/bin/jlink \
         --module-path "$JAVA_HOME/jmods" \
         --verbose \
         --add-modules ALL-MODULE-PATH \
         --strip-debug \
         --no-man-pages \
         --no-header-files \
         --compress=2 \
         --output /jre

#=========================================================================

# syntax=docker/dockerfile:1
FROM maven:3.8.5-openjdk-17 as build
MAINTAINER Ahn Seungkyu

WORKDIR /app
COPY . /app
RUN --mount=type=cache,target=/root/.m2 mvn -Dmaven.wagon.http.ssl.insecure=true -Dmaven.wagon.http.ssl.allowall=true package

#=========================================================================

FROM alpine:3.18.4
MAINTAINER Ahn Seungkyu

ENV JAVA_HOME=/jre
ENV PATH="$JAVA_HOME/bin:$PATH"
ARG JAR_FILE=example-0.0.1-SNAPSHOT.jar

COPY --from=builder-jre /jre $JAVA_HOME

ARG APPLICATION_USER=appuser
RUN adduser --no-create-home -u 1000 -D $APPLICATION_USER

RUN mkdir /app && chown -R $APPLICATION_USER /app

USER 1000

COPY --chown=1000:1000 --from=build /app/target/${JAR_FILE} /app/app.jar
COPY scripts/run.sh /app/

WORKDIR /app
EXPOSE 8080

ENTRYPOINT ["./run.sh"]

이미지가 3개로 구성되어 있다.

첫번째는 작은 사이즈의 jre 를 만드는 이미지, 두번째는 어플리케이션을 빌드하는 이미지, 마지막으로 세번째는 작은 alpine 베이스 이미지에 jre 와 빌드된 어플리케이션 jar 파일을 복사하는 이미지이다.

첫번째 이미지 만드는 부분에서 binutils 을 설치하는데 다운 받을 리파지토리를 지정하여 에러가 없게 한다. binutils 는 jre 을 만들 때 strip-debug 옵션을 사용하기 위해서 설치한다.

세번째 이미지 만드는 부분에서 사용자를 추가하는 로직이 있는데 이는 보안상 이미지내 실행 프로세스를 root 가 아닌 지정된 사용자로 하기 위해서 일반적으로 추가한다.

이미지 사이즈는 다음과 같다.

$ docker build -t seungkyua/springboot-docker -f docker/Dockerfile .

$ docker image ls                                                   
REPOSITORY                    TAG       IMAGE ID       CREATED          SIZE
seungkyua/springboot-docker   latest    f5dc2f994864   28 seconds ago   168MB
<none>                        <none>    ed08524545ba   24 minutes ago   358MB
<none>                        <none>    6d6ba6764805   31 minutes ago   473MB

이미지가 최종적으로 168M 로 줄어들었다.

이제 실제 이미지가 정상적으로 실행되는지 확인해 보자.

mysql 을 띄우고 어플리케이션을 띄운 후에 curl 로 데이터를 입력해 본다.

1. mysql 실행

$ mkdir -p ~/.docker-data/mysql

$ docker run --cap-add=sys_nice -d --restart=always -p 3306:3306 -e MYSQL_ROOT_PASSWORD=password \
-v ~/.docker-data/mysql:/var/lib/mysql \
--name mysql-ask mysql:8.0.34 \
--character-set-server=utf8mb4 \
--collation-server=utf8mb4_unicode_ci

2. database 생성

$ docker exec -it mysql-ask bash
# mysql -uroot -ppassword
mysql> create database if not exists order_service;

3. 어플리케이션 실행

$ docker run -d --name springboot --rm -p 19090:19090 --link mysql-ask:localhost seungkyua/springboot-docker

4. 데이터 조회

$ curl -X POST http://127.0.0.1:19090/orders \
   -H "Content-Type: application/json" \
   -d '{"customerId": 1, "orderTotal": 12.23}'

--- output ---
{"orderId":1}

정상적으로 어플리케이션이 실행되어 동작하는 것을 확인할 수 있다.

Cluster API 다이어그램

seungkyua@gmail.com — Wed, 23 Aug 2023 19:00:21 +0900

AWS Cluster API.pptx

0.05MB

RBAC 과 Service Accounts 를 사용하여 사용자 권한 제어하기 (Kubernetes v1.24 이상)

seungkyua@gmail.com — Thu, 17 Aug 2023 15:59:45 +0900

Kubernetes 에서 ServiceAccount 를 생성하면 1.22 버전까지는 자동으로 token 을 생성하였다. 그러나 1.23 부터는 토큰을 자동으로 생성해 주지 않기 때문에 수동으로 생성해야 한다.

이 바뀐 기능은 ServiceAcount 와 RBAC 을 연동하여 권한을 제어하고자 할 때 문제가 되므로 수동으로 만드는 방법을 살펴본다.

1. 네임스페이스 - SA 생성

먼저 테스트할 네임스페이스를 만든다.

$ kubectl create ns ask

ask 네임스페이스에 서비스 어카운트를 생성한다.

$ kubectl create sa ask-sa -n ask

1.24 버전부터는 sa 를 생성해도 token 이 자동으로 생성되지 않는다.

참고: https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.24.md#no-really-you-must-read-this-before-you-upgrade

token 은 Secret 타입이므로 Secret 을 조회해 보면 token이 자동 생성되지 않았음을 알 수 있다.

참고: https://kubernetes.io/docs/concepts/configuration/secret/#service-account-token-secrets

2. Token 생성

ask-sa 에 해당하는 token 을 수동으로 생성한다.

$ cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: Secret
metadata:
  name: ask-sa
  namespace: ask
  annotations:
    kubernetes.io/service-account.name: ask-sa
type: kubernetes.io/service-account-token
EOF

token 을 생성할 때 어노테이션으로 연결될 서비스 어카운트를 지정한다.

$ kubectl get secret -n ask
NAME     TYPE                                  DATA   AGE
ask-sa   kubernetes.io/service-account-token   3      7s

조회를 하면 service-account-toke 타입으로 secret 이 생성되었음을 알 수 있다.

혹은 token 을 수동으로 생성하는 방법도 있다.

$ kubectl create token ask-sa --bound-object-kind Secret --bound-object-name ask-sa --duration=999999h  -n ask

------- output -----------
xxxxxxxxxxxxxxxxxxxxxxx

base64 로 변환하여 secret 에 data.token 값으로 저장한다.

$ kubectl create token ask-sa --bound-object-kind Secret --bound-object-name ask-sa --duration=999999h  -n ask | base64 -w 0

------- output -----------
xxxxxxxxxxxxxxxxxxxxxxx

$ kubectl edit secret ask-sa -n ask
...
data:
  token: xxxxxxxxxxxxxxxxxxxx
...

3. Role 과 RoleBinding 생성

Role 과 RoleBinding 은 네임스페이스 별로 연결된다. 그러므로 생성한 권한은 해당 네임스페이스에만 권한이 주어진다.

먼저 Role 을 생성한다.

 $ cat <<EOF | kubectl apply -f -
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: ask-role
  namespace: ask
rules:
- apiGroups: ["", "*"]
  resources: ["*"]
  verbs: ["*"]
EOF

apiGroup 에서 "" 은 core API group 으로 다음의 출력으로 확인할 수 있다.

APIVERSION 이 v1 인 리소스들이 core API group 이 되면 이들에 대해서 권한을 사용하겠다는 뜻이다.

$ kubectl api-resources -o wide
NAME                              SHORTNAMES       APIVERSION      NAMESPACED   KIND                             VERBS
bindings                                           v1              true         Binding                          [create]
componentstatuses                 cs               v1              false        ComponentStatus                  [get list]
configmaps                        cm               v1              true         ConfigMap                        [create delete deletecollection get list patch update watch]
endpoints                         ep               v1              true         Endpoints                        [create delete deletecollection get list patch update watch]
events                            ev               v1              true         Event                            [create delete deletecollection get list patch update watch]
limitranges                       limits           v1              true         LimitRange                       [create delete deletecollection get list patch update watch]
namespaces                        ns               v1              false        Namespace                        [create delete get list patch update watch]
nodes                             no               v1              false        Node                             [create delete deletecollection get list patch update watch]
persistentvolumeclaims            pvc              v1              true         PersistentVolumeClaim            [create delete deletecollection get list patch update watch]
persistentvolumes                 pv               v1              false        PersistentVolume                 [create delete deletecollection get list patch update watch]
pods                              po               v1              true         Pod                              [create delete deletecollection get list patch update watch]
podtemplates                                       v1              true         PodTemplate                      [create delete deletecollection get list patch update watch]
replicationcontrollers            rc               v1              true         ReplicationController            [create delete deletecollection get list patch update watch]
resourcequotas                    quota            v1              true         ResourceQuota                    [create delete deletecollection get list patch update watch]
secrets                                            v1              true         Secret                           [create delete deletecollection get list patch update watch]
serviceaccounts                   sa               v1              true         ServiceAccount                   [create delete deletecollection get list patch update watch]
services                          svc              v1              true         Service                          [create delete deletecollection get list patch update watch]

다음은 Rolebinding을 생성한다.

$ cat <<EOF | kubectl apply -f - 
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: ask-role-binding
  namespace: ask
subjects:
- kind: ServiceAccount
  name: ask-sa
  namespace: ask
roleRef:
  kind: Role
  name: ask-role
  apiGroup: rbac.authorization.k8s.io
EOF

ServiceAcount 인 ask-sa 와 ask-role Role 을 서로 연결 시킨 다는 의미이다.

이렇게 되면 이제 ask-sa sa 는 ask-role role 에 대한 권한만을 사용할 수 있다.

4. kubeconfig 생성

sa 를 만들었으니 이를 연동할 kubeconfig 를 만들어 본다.

token 을 조회해 보자.

$ kubectl get secret -n ask ask-sa -ojsonpath={.data.token} | base64 -d

----- output -----
xxxxxxxxxxxxxxxxxxxxxxxxx

token 값으로 kubeconfig 의 user 접속 token 에 넣는다.


apiVersion: v1
clusters:
- cluster:
    certificate-authority-data: xxxxxxxxxxxxxxxxxxxxxxxx
server: https://xxxxxxxxxx.ap-northeast-2.eks.amazonaws.com
  name: mycluster
contexts:
- context:
    cluster: mycluster
    user: ask-sa
    namespace: ask
  name: mycluster
current-context: mycluster
kind: Config
users:
- name: ask-sa
  user:
    token: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

위의 kubeconfig 로 접속하면 ask 네임스페이스에 대해서 kubectl 명령어를 실행할 수 있다.

$ kubectl --kubeconfig ask.kubeconfig get pods
Error from server (Forbidden): pods is forbidden: User "system:serviceaccount:ask:ask-sa" cannot list resource "pods" in API group "" in the namespace "default"

default 네임스페이스에는 권한이 없으므로 권한 없음 에러가 리턴된다.

$ kubectl --kubeconfig ask.kubeconfig get pods -n ask
No resources found in ask namespace.

ask 네임스페이스의 파드는 정상적으로 조회된다.

프라이빗 컨테이너 이미지 저장소 HA(High Available) 로 구성하기 (feat. Harbor)

seungkyua@gmail.com — Thu, 10 Aug 2023 13:51:14 +0900

컨테이너 이미지 저장소를 독립적으로 구성하는 방법을 살펴본다.

일반적으로 컨테이너 이미지는 CNCF 의 프로젝트 중에 하나인 Harbor 를 사용하여 구성한다. Helm chart 가 잘 되어 있어 쿠버네티스 위에서 설치하는 것은 매우 쉬운데 운영 환경에 걸맞는 HA 구성은 여러가지 고려해야 할 사항들이 있다.

그래서 이번에는 Harbor 를 HA 로 구성하는 방법을 알아본다.

Harbor HA Architecture

Harbor 를 HA 로 구성하려면 아래의 전제 조건이 필요하다.

Kubernetes cluster 1.10 이상
Helm 2.8.0 이상
High Available 하게 설치된 Ingress Controller
High Available 하게 설치된 PostgreSQL 데이터베이스
High Available 하게 설치된 Redis
Shared storage 로 된 PVC

이 중에서 1, 2, 3 번은 구성되어 있다고 가정하고 이후를 살펴본다.

또한 Public Cloud 는 AWS 를 사용했고 쿠버네티스 클러스터는 EKS 를 사용했다.

아키텍처는 아래 그림과 같다.

[출처: https://goharbor.io/docs/1.10/img/ha.png]

PostgreSQL 데이터 베이스 구성

AWS 의 RDS 를 사용했으며 Harbor 에서 사용할 필요한 user 생성과 권한을 부여한다.

# psql -U postgres
postgres=# CREATE DATABASE registry;
postgres=# CREATE USER harbor WITH ENCRYPTED PASSWORD 'xxxxxxx';
postgres=# GRANT ALL PRIVILEGES ON DATABASE registry TO harbor;

어드민 권한으로 데이터베이스에 접속하여 Harbor 에서 사용할 registry database 를 생성한다. user 는 harbor 이고 필요한 password 를 생성한 다음 registry 데이터베이스의 모든 권한을 harbor 유저에 부여한다.

테이블과 스퀀스를 다루기 위해서는 아래 추가적으로 권한을 부여해야 한다. (아래 권한이 추가되지 않으면 harbor 유저로 테이블과 시퀀스에 대한 생성/조회/삭제/수정을 하지 못한다.

postgres=# \c registry
registry=# GRANT ALL ON ALL TABLES IN SCHEMA public TO harbor;
registry=# GRANT ALL ON ALL SEQUENCES IN SCHEMA public TO harbor;

Redis 구성

Harbor 는 캐시로 레디스를 사용하며 이 때 레디스 구성은 독립 혹은 레디스 + 센티널(sentinel) 구성만을 지원한다. 한마디로 클러스터 모드의 레디스는 지원하지 않는다.

AWS Elasticache Redis 서비스는 센티널을 지원하지 않아 굳이 Elasticache 서비스를 사용할 이유가 없다.

Elasticache 서비스의 레디스 구성으로 1개의 컨트롤노드 - 멀티 워커노드 로 하여 데이터 복제는 가능하나 1개의 컨트롤 노드가 무너지면 역시 장애가 발생하므로 서비스를 사용하여 구성하지 않았다.

이 후 살펴볼 Harbor Helm chart 에서 쿠버네티스 위에 레디스를 1개로 띄우는 internal 생성 방식을 사용한다.

레디스 구성을 HA 로 하고 싶다면, 레디스를 멀티 노드 센티널 구성으로 쿠버네티스 위에 띄우는 방법도 있으니 이는 레디스 설치 문서를 참고하면 된다. (센티널 구성일 때 Harbor chart 의 value 값은 코멘트로 적혀있으니 쉽게 이해할 수 있다)

Shared Storage 구성

AWS 에서 지원하는 공유 스토리지는 EFS 가 있다. EFS 는 NFSv4 프로토콜을 지원하니 공유 스토리지로 사용 가능하다.

먼저 AWS EFS 서비스에서 파일스토리지를 생성한다.

생성된 EFS 는 실제로 파일시스템의 스토리지가 생성된 것은 아니다. 일종의 정보를 생성한 것이며 필요에 따라 실제 스토리지를 생성하고 할당 받는 방식이다.

쿠버네티스에서는 Provisioner, StroageClass PVC, PV 라는 스토리지 표준 관리 방법이 있다.

[출처: https://d2908q01vomqb2.cloudfront.net/e1822db470e60d090affd0956d743cb0e7cdf113/2022/10/28/4.Dynamic-Provisioning.png]

흔히 Provisioner 라고 말하는 CSI Driver 를 설치한다.

EKS 에서는 추가 기능으로 Amazon EFS CSI Driver 를 추가할 수 있다.

이 때 권한에서 중요한 한가지가 있는데 EKS node 에서 사용하는 role 에 (role 명은 eks 의 태그 정보를 확인해 보면 된다) AmazonEFSCSIDriverPolicy 정책이 반드시 추가되어 있어야 한다.

이제 스토리지 클래스를 설치하자.

$ curl -Lo efs-sc.yaml https://raw.githubusercontent.com/kubernetes-sigs/aws-efs-csi-driver/master/examples/kubernetes/dynamic_provisioning/specs/storageclass.yaml

$ vi efs-sc.yaml
--- 
kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
  name: taco-efs-storage
provisioner: efs.csi.aws.com
parameters:
  provisioningMode: efs-ap
  fileSystemId: fs-xxxxxxx  # EFS 에서 생성한 fs id
  directoryPerms: "700"

$ kubectl apply -f efs-sc.yaml

변경해야 할 것은 fileSystemId 로 앞서 EFS 에서 생성한 파일스토리지의 fs id 값으로 변경해 준다.

스토리지클래스가 잘 작동하는지 확인하기 위해서 아래와 같이 테스트 파드를 생성해 본다.

$ kubectl create ns harbor-ask

$ vi efs-test-pod.yaml
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: efs-claim
  namespace: harbor-ask
spec:
  accessModes:
    - ReadWriteMany
  storageClassName: taco-efs-storage
  resources:
    requests:
      storage: 5Gi
---
apiVersion: v1
kind: Pod
metadata:
  name: efs-app
  namespace: harbor-ask
spec:
  containers:
    - name: app
      image: centos
      command: ["/bin/sh"]
      args: ["-c", "while true; do echo $(date -u) >> /data/out; sleep 5; done"]
      volumeMounts:
        - name: persistent-storage
          mountPath: /data
  volumes:
    - name: persistent-storage
      persistentVolumeClaim:
        claimName: efs-claim

$ kubectl apply -f efs-test-pod.yaml

Pod 가 생성되고 Pod 로 접속하면 /data/out 파일에 시간이 출력되고 있으면 정상적으로 작동하는 것이다.

PVC 를 생성할 때 accessModes 가 ReadWriteMany 인 것도 확인하자.

Harbor chart 로 HA 설치

이제 필요한 사전 구성은 마쳤으니 chart 로 설치를 진행한다.

먼저 chart 를 등록하고 다운 받는다.

$ helm repo add harbor https://helm.goharbor.io
$ helm repo update

$ helm fetch harbor/harbor --untar

차트를 다운 받을 필요는 없으니 관련 values.yaml 을 확인하기 위해서 참고용으로 다운 받았다.

필요한 value 를 설정한다.

$ vi ask-values.yaml
---
harborAdminPassword: "xxxxx"

expose:
  type: ingress
  tls:
    enabled: true
    certSource: secret
    secret:
      secretName: "taco-cat-tls"
  ingress:
    hosts:
      core: harbor.xxx
    className: "nginx"

externalURL: https://harbor.xxx

harborAdminPassword 는 Harbor 웹 화면에서 admin 계정으로 접속할 때 필요한 패스워드 이다.

expose 는 ingress 에 노출되는 값이며 도메인이 harbor.xxx 으로 DNS 에 연결되어 있으며 (DNS 가 없으면 로컬 컴퓨터에 /etc/hosts 파일에 등록해서 사용한다), 도메인 인증서는 앞에서 생성한 harbor-ask 네임스페이스에 taco-cat-tls 라는 secret 이름으로 저장되어 있다.

persistence:
  enabled: true
  resourcePolicy: "keep"
  persistentVolumeClaim:
    registry:
      storageClass: "taco-efs-storage"
      accessMode: ReadWriteMany
      size: 1024Gi
    jobservice:
      jobLog:
        storageClass: "taco-efs-storage"
        accessMode: ReadWriteMany
        size: 128Gi
    redis:
      storageClass: "taco-efs-storage"
      accessMode: ReadWriteMany
      size: 256Gi
    trivy:
      storageClass: "taco-efs-storage"
      accessMode: ReadWriteMany
      size: 128Gi
  imageChartStorage:
    disableredirect: false
    type: filesystem
    filesystem:
      rootdirectory: /storage

persistence 는 Harbor 컴포넌트에서 사용하는 스토리지 정보이다. Harbor 차트에서 설치하는 컴포넌트는 registry , jobservice , redis , trivy , core, portal 등이 있으며 스토리지가 필요한 컴포넌트만 기술하면 된다.

registry:
  replicas: 2
portal:
  replicas: 2
core:
  replicas: 2
jobservice:
  replicas: 2
trivy:
  enabled: true
  replicas: 2
notary:
  enabled: false
cache:
  enabled: true
  expireHours: 24

각 컴포넌트의 Pod 갯수를 넣는다. HA 구성 이므로 최소 2 이상을 넣는다.

notary 는 이미지 서명 관련 컴포넌트로 이번 구성에서는 설치하지 않았다.

database:
  type: external
  external:
    host: xxxxxx.ap-northeast-2.rds.amazonaws.com
    port: "5432"
    username: "harbor"
    password: "xxxxxxx"
    coreDatabase: "registry"

RDS 에 만들어진 외부 데이터베이스 정보를 넣는다.

redis:
  type: internal

레디스는 내부에서 단일 Pod 로 생성한다.

전체 values 는 다음과 같다.

$ vi ask-ha-values.yaml
---
harborAdminPassword: "xxxxxx"

expose:
  type: ingress
  tls:
    enabled: true
    certSource: secret
    secret:
      secretName: "taco-cat-tls"
  ingress:
    hosts:
      core: harbor.xxx
    className: "nginx"

externalURL: https://harbor.xxx

persistence:
  enabled: true
  resourcePolicy: "keep"
  persistentVolumeClaim:
    registry:
      storageClass: "taco-efs-storage"
      accessMode: ReadWriteMany
      size: 1024Gi
    jobservice:
      jobLog:
        storageClass: "taco-efs-storage"
        accessMode: ReadWriteMany
        size: 128Gi
    redis:
      storageClass: "taco-efs-storage"
      accessMode: ReadWriteMany
      size: 256Gi
    trivy:
      storageClass: "taco-efs-storage"
      accessMode: ReadWriteMany
      size: 128Gi
  imageChartStorage:
    disableredirect: false
    type: filesystem
    filesystem:
      rootdirectory: /storage

registry:
  replicas: 2
portal:
  replicas: 2
core:
  replicas: 2
jobservice:
  replicas: 2
trivy:
  enabled: true
  replicas: 2
notary:
  enabled: false
cache:
  enabled: true
  expireHours: 24

database:
  type: external
  external:
    host: xxxxxx.ap-northeast-2.rds.amazonaws.com
    port: "5432"
    username: "harbor"
    password: "xxxxxxx"
    coreDatabase: "registry"

redis:
  type: internal

쿠버네티스에 배포한다.

$ helm upgrade -i harbor-ask harbor/harbor --version 1.12.3 -n harbor-ask -f ask-ha-values.yaml

설치 확인

Harbor 웹에 접속하여 사용자(tks)와 프로젝트(tks)를 만든다.

해당 프로젝트의 Members 탭에는 사용자가 등록되어 있어야 한다. (그래야 컨테이너 이미지를 올릴 수 있는 권한이 있다)

$ docker login harbor.xxx -u tks
Password:

$ docker pull hello-world
$ docker tag hello-world harbor.xxx/tks/hello-world
$ docker push harbor.xxx/tks/hello-world

SpringBoot 으로 MSA 구현하기(1) - Java 에서 자주 쓰는 코드

seungkyua@gmail.com — Thu, 27 Jul 2023 08:24:29 +0900

MSA 패턴(CQRS, SAGA 등)을 코드로 구현하기 위해서 SpringBoot 으로 REST API 어플리케이션을 만드는 것을 정리하고 있는데 자료 구조외에 자주쓰게 되는 코드들이 있어서 이를 정리해 봤다.

어플리케이션 개발에 Java 를 사용하는 이유는 아직 우리나라에서는 Java 가 많이 쓰이기 때문이다. SpringBoot 으로 어느 정도 정리되면 이후에는 Gin (Go 언어 기반 웹 프레임워크)으로 정리할 예정이다.

1. null check

Primitive Type 보다는 Object 를 많이 사용하기 때문에 null check 를 항상 해야 된다.

String nullString = null;
String emptyString = "";

if (Objects.isNull(nullString))
    System.out.println("nullString is null");

if (Objects.nonNull(emptyString))
    System.out.println("emptyString is not null");

--------- output -----------
nullString is null
emptyString is not null

Objects 클래스를 사용하여 가독성있게 null 체크를 할 수 있다.

2. null check & default value 세팅

null check 와 기본 값 세팅을 메소드 체이닝으로 바로 할 수 있다.

BigDecimal bd = null;

BigDecimal defaultValue = Optional.ofNullable(bd).orElse(BigDecimal.ZERO);
System.out.println(defaultValue);

--------- output -----------
0

Optional.ofNullable 은 static 메소드로 null 혹은 객체 를 담고있는 Optional 을 리턴한다.

Optional.orElse 는 메소드로 객체의 값이 null 일 경우 넘겨주는 아큐먼트로 그 값을 채운다.

여기서는 BigDecimal.ZERO 로 채워진 것을 알 수 있다.

3. null check & throw Exception

null check 와 null 일 때 예외를 던질 수 있다.

BigDecimal bd = null;

Optional.ofNullable(bd).orElseThrow(() -> new IllegalArgumentException("db is null"));
System.out.println(defaultValue);

--------- output -----------
Exception in thread "main" java.lang.IllegalArgumentException: db is null
    at com.ask.example.Main.lambda$setDefaultValue$0(Main.java:45)
    at java.base/java.util.Optional.orElseThrow(Optional.java:403)
    at com.ask.example.Main.setDefaultValue(Main.java:45)
    at com.ask.example.Main.main(Main.java:24)

orElseThrow 메소드는 function 을 파라미터로 받으며 여기서는 람다함수를 사용하여 간단히 IllegalArgumentException 을 생성하여 던진다.

4. Array 와 List 를 Stream 으로 만들기

Stream은 Java 8부터 추가된 기능으로, Collection(Array, List, Map 등)과 같은 데이터 요소들을 처리하는데 도움을 주는 기능이다. Stream을 이용하면 다양한 작업을 수행할 수 있다.

필터링(Filtering): filter() 메서드를 사용하여 특정 조건을 만족하는 요소들만 걸러낼 수 있다.
변환(Mapping): map() 메서드를 사용하여 요소들을 다른 형태로 변환할 수 있다.
소팅(Sorting): sorted() 메서드를 사용하여 요소들을 정렬할 수 있다.
그룹화(Grouping): collect() 메서드를 사용하여 요소들을 그룹화할 수 있다.
집계(Reduction): reduce() 메서드를 사용하여 요소들을 축소하여 하나의 값으로 만들 수 있다.
제한(Limiting): limit() 메서드를 사용하여 스트림의 크기를 제한할 수 있다.
건너뛰기(Skipping): skip() 메서드를 사용하여 스트림의 앞부분 요소들을 건너뛸 수 있다.
병렬 처리(Parallel Processing): parallelStream() 메서드를 사용하여 스트림 요소들을 병렬로 처리할 수 있다.
중복 제거(Distinct): distinct() 메서드를 사용하여 스트림의 중복 요소들을 제거할 수 있다.
조인(Joining): joining() 메서드를 사용하여 문자열 요소들을 합쳐서 하나의 문자열로 만들 수 있다.

먼저 Stream 을 만들어 보자.

배열을 Stream 으로 만들기

String[] fruits = { "apple", "banana", "orange", "grape", "banana" };
Stream stream = Arrays.stream(fruits);
System.out.println(stream);

--------- output -----------
java.util.stream.ReferencePipeline$Head@36baf30c

List 를 Stream 으로 만들기

List<String> fruits = new ArrayList<String>(
        Arrays.asList("apple", "banana", "orange", "grape", "banana"));
Stream stream = fruits.stream();
System.out.println(stream);

--------- output -----------
java.util.stream.ReferencePipeline$Head@36baf30c

5. Stream 을 다른 Collection 으로 바꾸기

Stream 은 Collectors 클래스를 사용하여 다른 Collection 으로 쉽게 변경이 가능하다.

Stream → Set 으로 변경 (중복 제거)

참고로 distinct 로도 중복 제거가 가능하다.

List<String> fruits = new ArrayList<String>(
        Arrays.asList("apple", "banana", "orange", "grape", "banana"));
Set<String> newSet = fruits.stream()
        .collect(Collectors.toSet());
newSet.forEach(item -> System.out.println(item));

--------- output -----------
banana
orange
apple
grape

중복된 banana 는 하나만 출력된다.

Stream → LinkedList 로 변경

List<String> fruits = new ArrayList<String>(
        Arrays.asList("apple", "banana", "orange", "grape", "banana"));
List<String> newList = fruits.stream()
        .collect(Collectors.toCollection(
                LinkedList::new
        ));
newList.forEach(item -> System.out.println(item));

--------- output -----------
apple
banana
orange
grape
banana

Stream → Map 으로 변경

List<String> fruits = new ArrayList<String>(
        Arrays.asList("apple", "banana", "orange", "grape", "banana"));
Map<String, Integer> newMap = fruits.stream()
        .collect(Collectors.toSet()).stream()
        .collect(Collectors.toMap(
                Function.identity(),
                String::length
        ));
newMap.forEach((key, value) -> System.out.println(key + " " + value));

--------- output -----------
banana 6
orange 6
apple 5
grape 5

Map 은 중복 키를 가질 수 없기 때문에 Set 으로 변환한 다음에 Map 으로 변환하였다.

여기서 Function.identity() 는 item 그 자체의 값으로 apple 과 같은 리스트의 요소를 가리키며, Map의 키로 사용되었다. String::Length 는 스트링 객체의 길이를 구하는 메소드를 호출한 리턴 값으로 Map 의 값으로 사용되었다.

6. Stream 과 데이터 변경 메소드들

Stream.map()

map() 은 Item 각각에 대해서 다른 형태로 변경할 수 있다.

List<String> fruits = new ArrayList<String>(
        Arrays.asList("apple", "banana", "orange", "grape", "banana"));
List<String> newList = fruits.stream()
        .map(item -> item.toUpperCase())
        .collect(Collectors.toList());
newList.forEach(item -> System.out.println(item));

--------- output -----------
APPLE
BANANA
ORANGE
GRAPE
BANANA

map() 은 아규먼트로 function 을 받으며 결과로 Stream 을 반환한다. 아규먼트로 들어가는 함수는 각 요소를 변경하여 반환하는 함수이어야 한다.

Stream.flatMap()

flatMap() 은 중첩된 Collection 을 한꺼풀 벗긴다고 생각하면 된다.

List<List<String>> listInList = Arrays.asList(
        Arrays.asList("apple", "banana"),
        Arrays.asList("orange", "grape", "banana"));

List<String> newList = listInList.stream()
        .flatMap(Collection::stream)
        .distinct()
        .collect(Collectors.toList());
newList.forEach(item -> System.out.println(item));

--------- output -----------
apple
banana
orange
grape

flatMap() 도 function 를 아규먼트로 받고 결과를 Stream 으로 변환한다. 단 아규먼트로 들어가는 함수는 각 요소에 영향을 주면서 Stream 을 반환하는 함수이어야 한다.

6. enum 활용

enum 은 enum 타입이 반환된다.

enum Gender {
    MALE("male"),
    FEMALE("female");

    private final String param;

    Gender(String param) {
        this.param = param;
    }

    String getParam() {
        return this.param;
    }
}

System.out.println(Gender.MALE.getParam());

--------- output -----------
male

Gender.MALE 값은 enum Gender 타입이다.

하지만 아래와 같이 문자열을 enum 값으로 변환할 수 있다. 이 방법은 Json 을 marshal , unmarshal 할 때 많이 사용된다.

enum Gender {
    MALE("male"),
    FEMALE("female");

    private final String param;

    private static final Map<String, Gender> paramMap =
            Arrays.stream(Gender.values())
                    .collect(Collectors.toMap(
                            Gender::getParam,
                            Function.identity()
                    ));

    Gender(String param) {
        this.param = param;
    }

    static Gender fromParam(String param) {
        return Optional.ofNullable(param)
                .map(paramMap::get)
                .orElseThrow(() -> new IllegalArgumentException("param is not valid"));
    }

    String getParam() {
        return this.param;
    }
}

System.out.println(Gender.fromParam("male"));

--------- output -----------
MALE

static 으로 Map<String, Gender> 변수를 선언하여 거기에 값을 채워넣고, static fromParam 메소드를 사용하여 String 값으로 Gender 값을 가져온다.

7. Map 의 종류

Map 에는 다음과 같은 종류가 있다.

HashMap : key - value 로 저장되며 key 의 중복을 허용하지 않는다
TreeMap : HashMap 의 기능에 key 가 정렬되어 있다.
LinkedHashMap: HashMap 의 기능에 key 입력 순서대로 출력된다.
MultiValueMap: HashMap 가 다른 점이 key 의 중복을 허용한다.

다만, MultiValueMap 을 사용하기 위해서는 spring-core 패키지를 import 해야 한다. (apache commons 의 commons-collections4 에도 MultiValueMap 은 있지만 spring-core 가 더 사용하기 편하다)

pom.xml 에 아래와 같은 dependcy 를 추가한다.

<dependencies>
    <dependency>
        <groupId>org.springframework</groupId>
        <artifactId>spring-core</artifactId>
        <version>6.0.9</version>
    </dependency>
</dependencies>

MultiValueMap<String, String> map = new LinkedMultiValueMap<>();
map.add("Accept-Encoding", "compress;q=0.5");
map.add("Accept-Encoding", "gzip;q=1.0");

map.forEach((key, value) -> System.out.println(key + " " + value));

--------- output -----------
Accept-Encoding [compress;q=0.5, gzip;q=1.0]

REST API 를 만들 때 Header 에 값을 넣기 위해서 위와 같이 MultiValueMap 을 사용한다.

Custom Controller 3 - CronJob 구현하기

seungkyua@gmail.com — Wed, 12 Jul 2023 09:51:55 +0900

Kubernetes 에는 이미 CronJob 이라는 리소스 타입이 있지만, Kubebuilder 을 이용하여 Custom Controller 로 재작성 해보는 연습을 해보도록 하자.

Project 구조 만들기

먼저, Project 구조를 만들기 위해 아래와 같이 kubebuilder init 명령어를 실행한다.

$ mkdir -p cronjob-kubebuilder
$ cd cronjob-kubebuilder

$ kubebuilder init --domain tutorial.kubebuilder.io --repo tutorial.kubebuilder.io/project

도메인을 tutorial.kubebuilder.io 로 했으므로 모든 API Group 은 <group>.tutorial.kubebuilder.io 방식으로 정해지게 된다. 또한 특별히 프로젝트 이름은 지정하지 않았는데, --project-name=<dns1123-label-string> 과 같이 옵션을 추가하지 않으면 폴더의 이름이 기본적으로 프로젝트 이름이 된다. (여기서 프로젝트명은 DNS-1123 label 규칙을 따라야 한다)

한가지 주의해야 할 점은 cronjob-kubebuilder 디렉토리는 $GOPATH 경로 아래에 있어서는 안된다. 이는 Go modules 의 규칙 때문인데 좀 더 자세히 알고 싶으면 https://go.dev/blog/using-go-modules 블로그 포스트를 읽어보자.

만들어진 프로젝트의 구조는 다음과 같다.

$ tree -L 2
.
├── Dockerfile
├── Makefile
├── PROJECT
├── README.md
├── cmd
│   └── main.go
├── config
│   ├── default
│   ├── manager
│   ├── prometheus
│   └── rbac
├── go.mod
├── go.sum
└── hack
    └── boilerplate.go.txt

7 directories, 8 files

go.mod 파일은 모듈 디펜던시를 표시하고, Makefile 은 custom controller 를 빌드하고 디플로이 할 수 있다.

config 디렉토리 아래에는 Kustomize 로 작성되어 CustomResourceDefinition, RBAC, WebhookConfiguration 등의 yaml 파일들이 정의되어 있다.

특히, config/manager 디렉토리에는 Cluster 에 Custom Controller 를 파드 형태로 배포할 수 있는 Kustomize yaml 이 있고, config/rbac 디렉토리에는 서비스 어카운트로 Custom Controller 의 권한이 정의되어 있다.

Custom Controller 의 Entrypoint 는 cmd/main.go 파일이다.

처음 필요한 모듈을 임포트 한 것을 보면 아래 2개가 보인다.

core controller-runtime 라이브러리
기본 controller-runtime 로깅인 Zap

package main

import (
    "flag"
    "fmt"
    "os"

    _ "k8s.io/client-go/plugin/pkg/client/auth"

    "k8s.io/apimachinery/pkg/runtime"
    utilruntime "k8s.io/apimachinery/pkg/util/runtime"
    clientgoscheme "k8s.io/client-go/kubernetes/scheme"
    _ "k8s.io/client-go/plugin/pkg/client/auth/gcp"
    ctrl "sigs.k8s.io/controller-runtime"
    "sigs.k8s.io/controller-runtime/pkg/cache"
    "sigs.k8s.io/controller-runtime/pkg/healthz"
    "sigs.k8s.io/controller-runtime/pkg/log/zap"
    // +kubebuilder:scaffold:imports
)

모든 컨트롤러에는 Scheme 이 필요하다. 스킴은 Kind 와 Go types 간의 매핑을 제공해 준다.

var (
    scheme   = runtime.NewScheme()
    setupLog = ctrl.Log.WithName("setup")
)

func init() {
    utilruntime.Must(clientgoscheme.AddToScheme(scheme))

    //+kubebuilder:scaffold:scheme
}

main function 에는 아래의 내용들이 들어가 있다.

기본 플래그 셋업
manager 를 생성하여 모든 Custom Controller 의 실행을 추적하고, shared cache 세팅하고, scheme 을 아규먼트로 넘기주어 클라이언트를 API 서버에 설정한다.
manager 를 실행하면 manager 가 모든 컨트롤러와 웹혹을 실행한다.

func main() {
    var metricsAddr string
    var enableLeaderElection bool
    var probeAddr string
    flag.StringVar(&metricsAddr, "metrics-bind-address", ":8080", "The address the metric endpoint binds to.")
    flag.StringVar(&probeAddr, "health-probe-bind-address", ":8081", "The address the probe endpoint binds to.")
    flag.BoolVar(&enableLeaderElection, "leader-elect", false,
        "Enable leader election for controller manager. "+
            "Enabling this will ensure there is only one active controller manager.")
    opts := zap.Options{
        Development: true,
    }
    opts.BindFlags(flag.CommandLine)
    flag.Parse()

    ctrl.SetLogger(zap.New(zap.UseFlagOptions(&opts)))

    mgr, err := ctrl.NewManager(ctrl.GetConfigOrDie(), ctrl.Options{
        Scheme:                 scheme,
        MetricsBindAddress:     metricsAddr,
        Port:                   9443,
        HealthProbeBindAddress: probeAddr,
        LeaderElection:         enableLeaderElection,
        LeaderElectionID:       "80807133.tutorial.kubebuilder.io",
    })
    if err != nil {
        setupLog.Error(err, "unable to start manager")
        os.Exit(1)
    }

manager 생성 시에 컨트롤러가 특정 네임스페이스의 리소스만을 감시할 수 있도록 할 수 있다.

    mgr, err := ctrl.NewManager(ctrl.GetConfigOrDie(), ctrl.Options{
        Scheme:                 scheme,
        Namespace:              namespace,
        MetricsBindAddress:     metricsAddr,
        Port:                   9443,
        HealthProbeBindAddress: probeAddr,
        LeaderElection:         enableLeaderElection,
        LeaderElectionID:       "80807133.tutorial.kubebuilder.io",
    })

이렇게 특정 네임스페이스를 지정한 경우에는 권한을 ClusterRole 과 ClusterRoleBinding 에서 Role 과 RoleBinding 으로 변경하는 것을 권장한다.

그리고 MutiNamespacedCacheBuilder 를 사용하면 특정 네임스페이스의 묶음의 리소스만을 감시하게 제한할 수 있다.

    var namespaces []string // List of Namespaces
    cache.Options.Namespaces = namespaces

    mgr, err := ctrl.NewManager(ctrl.GetConfigOrDie(), ctrl.Options{
        Scheme:                 scheme,
        NewCache:               cache.MultiNamespacedCacheBuilder(namespaces),
        MetricsBindAddress:     fmt.Sprintf("%s:%d", metricsHost, metricsPort),
        Port:                   9443,
        HealthProbeBindAddress: probeAddr,
        LeaderElection:         enableLeaderElection,
        LeaderElectionID:       "80807133.tutorial.kubebuilder.io",
    })

MultiNamespacedCacheBuilder 는 deprecated api 이므로 cache.Options.Namespaces 를 사용한다. (https://pkg.go.dev/sigs.k8s.io/controller-runtime/pkg/cache#Options)

Groups, Versions, Kinds and Resources

쿠버네티스에서 API 에 대해서 이야기할 때는 groups, versions, kinds and resources 4개의 용어를 사용한다.

쿠버네티스의 API Group 은 단순히 관련 기능의 모음이다. 각 Group 에는 하나 이상의 Version 이 있으며, 이름에서 알 수 있듯이 시간이 지남에 따라 API의 작동 방식을 변경할 수 있다.

각 API group-version 에는 하나 이상의 API type 이 포함되며, 이를 Kind 라고 부른다. Kind 는 Version 간에 양식을 변경할 수 있지만, 각 양식은 어떻게든 다른 양식의 모든 데이터를 저장할 수 있어야 한다(데이터를 필드 또는 주석에 저장할 수 있음). 즉, 이전 API 버전을 사용해도 최신 데이터가 손실되거나 손상되지 않는다.

Resource 란 간단히 말해서 API 안에서 Kind 를 사용하는 것이다. 종종, Kind 와 Resource 는 일대일로 매핑된다. 예를 들어, Pod Resource 는 Pod Kind 에 해당한다. 그러나 때로는 여러 Resource 에서 동일한 Kind를 반환할 수도 있다. 예를 들어, Scale Kind 는 deployments/scale 또는 replicasets/scale 과 같은 모든 scale 하위 리소스에 의해 반환된다. 이것이 바로 Kubernetes HorizontalPodAutoscaler 가 서로 다른 resource 와 상호 작용할 수 있는 이유다. 그러나 CRD를 사용하면 각 Kind 는 단일 resource 에 해당한다.

resource 는 항상 소문자이며, 관례에 따라 소문자 형태의 Kind를 사용한다.

특정 group-version 에서 어떤 kind 를 지칭할 때는 줄여서 GroupVersionKind 혹은 줄여서 GVK 라고 부른다. 같은 방식으로 resource 도 GroupVersionResource 혹은 GVR 이라고 부른다.

GVK 는 패키지에서 Go type 에 해당한다.

API 는 왜 만들어야 할까?

Kind 에 대해서 Custom Resource (CR) 과 Custom Resource Definition (CRD) 을 만들어야 한다. 그 이유는 CustomResourceDefinitions 으로 Kubernetes API 를 확장할 수 있기 때문이다.

새롭게 만드는 API 는 쿠버네티스에게 custom object 를 가리치는 방법이다.

기본으로 CRD 는 customized Objects 의 정의이며, CR 은 그것에 대한 인스턴스이다.

API 추가

아래 명령으로 새로운 Kind 를 추가하자.

$ kubebuilder create api --group batch --version v1 --kind CronJob

Create Resource 와 Create Controller 를 하겠냐고 물으면 y 로 대답한다.

$ tree -L 2
.
├── Dockerfile
├── Makefile
├── PROJECT
├── README.md
├── api
│   └── v1
├── bin
│   └── controller-gen
├── cmd
│   └── main.go
├── config
│   ├── crd
│   ├── default
│   ├── manager
│   ├── prometheus
│   ├── rbac
│   └── samples
├── go.mod
├── go.sum
├── hack
│   └── boilerplate.go.txt
└── internal
    └── controller

이 경우 batch.tutorial.kubebuilder.io/v1 에 해당하는 api/v1 디렉토리가 생성된다.

api/v1/cronjob_types.go 파일을 보면, 모든 쿠버네티스 Kind 에 공통으로 포함된 metadata 를 가리키는 meta/v1 API group 을 임포트 하고 있다.

package v1

import (
    metav1 "k8s.io/apimachinery/pkg/apis/meta/v1"
)

다음으로 Kind 의 Spec 과 Status 에 대한 type 을 정의 한다.

쿠버네티스는 원하는 상태(Spec)를 실제 클러스터 상태(Status) 및 외부 상태와 조정한 다음 관찰한 것(Status)를 기록하는 방식으로 작동한다. 따라서 모든 기능 object 는 spec 과 status 를 포함한다. ConfigMap 과 같은 몇몇 타입은 원하는 상태를 인코딩하지 않기 때문에 이 패턴을 따르지 않지만 대부분의 타입은 이 패턴을 따른다.

// EDIT THIS FILE!  THIS IS SCAFFOLDING FOR YOU TO OWN!
// NOTE: json tags are required.  Any new fields you add must have json tags for the fields to be serialized.

// CronJobSpec defines the desired state of CronJob
type CronJobSpec struct {
    // INSERT ADDITIONAL SPEC FIELDS - desired state of cluster
    // Important: Run "make" to regenerate code after modifying this file
}

// CronJobStatus defines the observed state of CronJob
type CronJobStatus struct {
    // INSERT ADDITIONAL STATUS FIELD - define observed state of cluster
    // Important: Run "make" to regenerate code after modifying this file
}

실제 Kind 에 해당하는 타입인 CronJob 과 CronJobList 를 정의한다. CronJob 은 루트 타입이며, CronJob kind를 설명한다. 모든 쿠버네티스 오브젝트와 마찬가지로, API version 과 Kind 를 설명하는 TypeMeta를 포함하며, name, namespace, labes 과 같은 것을 보유하는 ObjectMeta 도 포함한다.

CronJobList 는 단순히 여러 CronJob 을 위한 컨테이너이다. LIST와 같은 대량 작업에 사용되는 Kind 이다.

//+kubebuilder:object:root=true
//+kubebuilder:subresource:status

// CronJob is the Schema for the cronjobs API
type CronJob struct {
    metav1.TypeMeta   `json:",inline"`
    metav1.ObjectMeta `json:"metadata,omitempty"`

    Spec   CronJobSpec   `json:"spec,omitempty"`
    Status CronJobStatus `json:"status,omitempty"`
}

//+kubebuilder:object:root=true

// CronJobList contains a list of CronJob
type CronJobList struct {
    metav1.TypeMeta `json:",inline"`
    metav1.ListMeta `json:"metadata,omitempty"`
    Items           []CronJob `json:"items"`
}

마지막으로 API group 에 Go 타입을 추가한다. 이렇게 하면 이 API group 의 타입을 모든 Scheme 에 추가할 수 있다.

func init() {
    SchemeBuilder.Register(&CronJob{}, &CronJobList{})
}

API 설계

쿠버네티스에는 API를 설계하는 방법에 대한 몇 가지 규칙이 있다. 즉, 직렬화된 모든 필드는 camelCase 여야 하며 JSON 구조체 태그를 사용하여 이를 지정한다. 또한, 필드가 비어 있을 때 직렬화에서 필드를 생략해야 한다는 것을 표시하기 위해 omitempty 구조체 태그를 사용할 수도 있다.

필드는 대부분의 기본 유형을 사용할 수 있다. 다만 숫자는 예외이다. API 호환성을 위해 정수의 경우 int32 및 int64, 소수의 경우 resource.Quantity 와 같이 3가지 형식의 숫자를 허용한다.

Quantity 는 10진수에 대한 특수 표기법으로, 머신 간에 이식성을 높이기 위해 명시적으로 고정된 표현을 가지고 있다.

예를 들어 2m 값은 십진수 표기법에서 0.002 를 의미한다. 2Ki 는 십진수로 2048 을 의미하고, 2K 는 십진수로 2000 을 의미한다. 분수를 지정하려면 정수를 사용할 수 있는 접미사로 전환하면 된다(예: 2.5 는 2500m).

지원되는 베이스는 두 가지이다: 10과 2(각각 10진수 및 2진수라고 함)이다. 10진수는 "nomal" SI 접미사(예: M 및 K)로 표시되며, 2진수는 "mebi" 표기법(예: Mi 및 Ki)으로 지정된다. 메가바이트와 메비바이트를 생각하면 된다.

우리가 사용하는 또 다른 특수 유형이 하나 더 있는데, 바로 metav1.Time 이다. 이것은 고정된 이식 가능한 직렬화 형식을 가지고 있다는 점을 제외하면 time.Time 과 동일하게 작동한다.

package v1

import (
    batchv1 "k8s.io/api/batch/v1"
    corev1 "k8s.io/api/core/v1"
    metav1 "k8s.io/apimachinery/pkg/apis/meta/v1"
)

// EDIT THIS FILE!  THIS IS SCAFFOLDING FOR YOU TO OWN!
// NOTE: json tags are required.  Any new fields you add must have json tags for the fields to b

CronJob 을 세부적으로 살펴보자.

먼저 spec 을 보면, spec 에는 원하는 상태가 저장되므로 controller 에 대한 모든 "입력" 은 여기에 저장된다.

기본적으로 크론잡에는 다음과 같은 요소가 필요하다:

스케줄 (CronJob 내의 cron)
실행할 Job 에 대한 template (CronJob 내의 job)

편하게 만들어줄 몇 가지 추가 기능도 필요하다:

job 시작에 대한 deadline (이 deadline 을 놓치면 다음 예정된 시간까지 기다리게 된다)
여러 job 이 한 번에 실행될 경우 어떻게 할 것인가(기다릴 것인가? 기존 job 을 중지할 것인가? 둘 다 실행할 것인가?)
CronJob 에 문제가 있을 경우, CronJob 실행을 일시 중지하는 방법
이전 job 기록에 대한 limit

자신의 상태를 읽지 않기 때문에 job 이 실행되었는지 여부를 추적할 수 있는 다른 방법이 필요하다. 이를 위해 적어도 하나의 이전 job 을 사용할 수 있다.

// CronJobSpec defines the desired state of CronJob
type CronJobSpec struct {
    //+kubebuilder:validation:MinLength=0

    // The schedule in Cron format, see https://en.wikipedia.org/wiki/Cron.
    Schedule string `json:"schedule"`

    //+kubebuilder:validation:Minimum=0

    // Optional deadline in seconds for starting the job if it misses scheduled
    // time for any reason.  Missed jobs executions will be counted as failed ones.
    // +optional
    StartingDeadlineSeconds *int64 `json:"startingDeadlineSeconds,omitempty"`

    // Specifies how to treat concurrent executions of a Job.
    // Valid values are:
    // - "Allow" (default): allows CronJobs to run concurrently;
    // - "Forbid": forbids concurrent runs, skipping next run if previous run hasn't finished yet;
    // - "Replace": cancels currently running job and replaces it with a new one
    // +optional
    ConcurrencyPolicy ConcurrencyPolicy `json:"concurrencyPolicy,omitempty"`

    // This flag tells the controller to suspend subsequent executions, it does
    // not apply to already started executions.  Defaults to false.
    // +optional
    Suspend *bool `json:"suspend,omitempty"`

    // Specifies the job that will be created when executing a CronJob.
    JobTemplate batchv1.JobTemplateSpec `json:"jobTemplate"`

    //+kubebuilder:validation:Minimum=0

    // The number of successful finished jobs to retain.
    // This is a pointer to distinguish between explicit zero and not specified.
    // +optional
    SuccessfulJobsHistoryLimit *int32 `json:"successfulJobsHistoryLimit,omitempty"`

    //+kubebuilder:validation:Minimum=0

    // The number of failed finished jobs to retain.
    // This is a pointer to distinguish between explicit zero and not specified.
    // +optional
    FailedJobsHistoryLimit *int32 `json:"failedJobsHistoryLimit,omitempty"`
}

ConcurrencyPolicy 는 실제로는 string 이지만, 재사용과 유효성 검사를 쉽게 할 수 있으므로 타입을 재정의 했다.

// ConcurrencyPolicy describes how the job will be handled.
// Only one of the following concurrent policies may be specified.
// If none of the following policies is specified, the default one
// is AllowConcurrent.
// +kubebuilder:validation:Enum=Allow;Forbid;Replace
type ConcurrencyPolicy string

const (
    // AllowConcurrent allows CronJobs to run concurrently.
    AllowConcurrent ConcurrencyPolicy = "Allow"

    // ForbidConcurrent forbids concurrent runs, skipping next run if previous
    // hasn't finished yet.
    ForbidConcurrent ConcurrencyPolicy = "Forbid"

    // ReplaceConcurrent cancels currently running job and replaces it with a new one.
    ReplaceConcurrent ConcurrencyPolicy = "Replace"
)

다음은 관찰된 상태를 저장하는 status 를 디자인해 보자.

현재 실행중인 job 목록과 마지막으로 job 을 성공적으로 실행한 시간을 유지한다. 그리고 직렬화를 위해서 time.Time 대신 metav1.Time 을 사용한다.

// CronJobStatus defines the observed state of CronJob
type CronJobStatus struct {
    // INSERT ADDITIONAL STATUS FIELD - define observed state of cluster
    // Important: Run "make" to regenerate code after modifying this file

    // A list of pointers to currently running jobs.
    // +optional
    Active []corev1.ObjectReference `json:"active,omitempty"`

    // Information when was the last time the job was successfully scheduled.
    // +optional
    LastScheduleTime *metav1.Time `json:"lastScheduleTime,omitempty"`
}

Controller 구현

컨트롤러는 쿠버네티스와 모든 operator 의 핵심이다.

컨트롤러의 역할은 주어진 오브젝트에 대해 실세계의 실제 상태(클러스터 상태와 잠재적으로 외부 상태(예: Kubelet의 경우 컨테이너 실행 또는 Cloud Provider 의 경우 로드밸런서)가 오브젝트의 원하는 상태와 일치하는지 확인하는 것이다. 각 컨트롤러는 하나의 루트 Kind 에 중점을 두지만 다른 Kind 와 상호 작용할 수 있다.

이 프로세스를 reconciling 이라고 부른다.

controller-runtime 에서 특정 kind 에 대한 reconciling 을 구현하는 로직을 Reconciler 라고 한다.

internal/controller/cronjob_controller.go 파일을 살펴 보자.

기본으로 임포트하는 모듈이 있는데, core controller-runtime 라이브러리와 client 패키지, API 타입 패키지가 있다.

package controllers

import (
    "context"

    "k8s.io/apimachinery/pkg/runtime"
    ctrl "sigs.k8s.io/controller-runtime"
    "sigs.k8s.io/controller-runtime/pkg/client"
    "sigs.k8s.io/controller-runtime/pkg/log"

    batchv1 "tutorial.kubebuilder.io/project/api/v1"
)

컨트롤러의 기본 로직은 다음과 같다.

명명된 CronJob을 로드한다.
모든 active job 을 나열하고, status 를 업데이트 한다.
히스토리 수 제한에 따라 오래된 job 을 정리한다.
Suspend 값이 세팅되었는지 확인 (값이 세팅된 경우 다른 작업을 수행하지 않음)
다음 예약된 실행 가져오기
새로운 job 이 스케줄에 맞고, deadline 이 지나지 않았으며, 동시성 정책에 의해 차단되지 않은 경우 실행
실행 중인 job 이 보이거나 (자동으로 수행됨) 다음 예약된 실행 시간이 되면 Requeue 한다.

임포트 모듈을 추가한다.

package controller

import (
    "context"
    "fmt"
    "sort"
    "time"

    "github.com/robfig/cron"
    kbatch "k8s.io/api/batch/v1"
    corev1 "k8s.io/api/core/v1"
    metav1 "k8s.io/apimachinery/pkg/apis/meta/v1"
    "k8s.io/apimachinery/pkg/runtime"
    ref "k8s.io/client-go/tools/reference"
    ctrl "sigs.k8s.io/controller-runtime"
    "sigs.k8s.io/controller-runtime/pkg/client"
    "sigs.k8s.io/controller-runtime/pkg/log"

    batchv1 "tutorial.kubebuilder.io/project/api/v1"
)

테스트를 위해서 Clock 을 추가한다.

// CronJobReconciler reconciles a CronJob object
type CronJobReconciler struct {
    client.Client
    Scheme *runtime.Scheme
    Clock
}

type realClock struct{}

func (_ realClock) Now() time.Time { return time.Now() }

// clock knows how to get the current time.
// It can be used to fake out timing for testing.
type Clock interface {
    Now() time.Time
}

RBAC 을 위해 batch group 의 job 을 핸들링 할 수 있는 권한을 추가한다.

//+kubebuilder:rbac:groups=batch.tutorial.kubebuilder.io,resources=cronjobs,verbs=get;list;watch;create;update;patch;delete
//+kubebuilder:rbac:groups=batch.tutorial.kubebuilder.io,resources=cronjobs/status,verbs=get;update;patch
//+kubebuilder:rbac:groups=batch.tutorial.kubebuilder.io,resources=cronjobs/finalizers,verbs=update
//+kubebuilder:rbac:groups=batch,resources=jobs,verbs=get;list;watch;create;update;patch;delete
//+kubebuilder:rbac:groups=batch,resources=jobs/status,verbs=get

annotation 을 위한 변수를 추가한다.

var (
    scheduledTimeAnnotation = "batch.tutorial.kubebuilder.io/scheduled-at"
)

// Reconcile is part of the main kubernetes reconciliation loop which aims to
// move the current state of the cluster closer to the desired state.
// TODO(user): Modify the Reconcile function to compare the state specified by
// the CronJob object against the actual cluster state, and then
// perform operations to make the cluster state reflect the state specified by
// the user.
//
// For more details, check Reconcile and its Result here:
// - https://pkg.go.dev/sigs.k8s.io/controller-runtime@v0.15.0/pkg/reconcile
func (r *CronJobReconciler) Reconcile(ctx context.Context, req ctrl.Request) (ctrl.Result, error) {
    log := log.FromContext(ctx)

1. 이름으로 CronJob 을 로드한다

client 를 사용하여 CronJob 을 가져온다. 모든 client 의 메소드에는 취소가 가능하게 context 를 아규먼트로 받는다.

    var cronJob batchv1.CronJob
    if err := r.Get(ctx, req.NamespacedName, &cronJob); err != nil {
        log.Error(err, "unable to fetch CronJob")
        // we'll ignore not-found errors, since they can't be fixed by an immediate
        // requeue (we'll need to wait for a new notification), and we can get them
        // on deleted requests.
        return ctrl.Result{}, client.IgnoreNotFound(err)
    }

2. 모든 active job 을 나열하고 status 를 업데이트 한다.

    var childJobs kbatch.JobList
    if err := r.List(ctx, &childJobs, client.InNamespace(req.Namespace), client.MatchingFields{jobOwnerKey: req.Name}); err != nil {
        log.Error(err, "unable to list child Jobs")
        return ctrl.Result{}, err
    }

active job 을 조회했으면 이를 active, successful, failded job 으로 분류한다.

    // find the active list of jobs
    var activeJobs []*kbatch.Job
    var successfulJobs []*kbatch.Job
    var failedJobs []*kbatch.Job
    var mostRecentTime *time.Time // find the last run so we can update the status

    isJobFinished := func(job *kbatch.Job) (bool, kbatch.JobConditionType) {
        for _, c := range job.Status.Conditions {
            if (c.Type == kbatch.JobComplete || c.Type == kbatch.JobFailed) && c.Status == corev1.ConditionTrue {
                return true, c.Type
            }
        }

        return false, ""
    }

    getScheduledTimeForJob := func(job *kbatch.Job) (*time.Time, error) {
        timeRaw := job.Annotations[scheduledTimeAnnotation]
        if len(timeRaw) == 0 {
            return nil, nil
        }

        timeParsed, err := time.Parse(time.RFC3339, timeRaw)
        if err != nil {
            return nil, err
        }
        return &timeParsed, nil
    }
    for i, job := range childJobs.Items {
        _, finishedType := isJobFinished(&job)
        switch finishedType {
        case "": // ongoing
            activeJobs = append(activeJobs, &childJobs.Items[i])
        case kbatch.JobFailed:
            failedJobs = append(failedJobs, &childJobs.Items[i])
        case kbatch.JobComplete:
            successfulJobs = append(successfulJobs, &childJobs.Items[i])
        }

        // We'll store the launch time in an annotation, so we'll reconstitute that from
        // the active jobs themselves.
        scheduledTimeForJob, err := getScheduledTimeForJob(&job)
        if err != nil {
            log.Error(err, "unable to parse schedule time for child job", "job", &job)
            continue
        }
        if scheduledTimeForJob != nil {
            if mostRecentTime == nil {
                mostRecentTime = scheduledTimeForJob
            } else if mostRecentTime.Before(*scheduledTimeForJob) {
                mostRecentTime = scheduledTimeForJob
            }
        }
    }

    if mostRecentTime != nil {
        cronJob.Status.LastScheduleTime = &metav1.Time{Time: *mostRecentTime}
    } else {
        cronJob.Status.LastScheduleTime = nil
    }
    cronJob.Status.Active = nil
    for _, activeJob := range activeJobs {
        jobRef, err := ref.GetReference(r.Scheme, activeJob)
        if err != nil {
            log.Error(err, "unable to make reference to active job", "job", activeJob)
            continue
        }
        cronJob.Status.Active = append(cronJob.Status.Active, *jobRef)
    }

디버깅을 위해서 log 를 남긴다.

    log.V(1).Info("job count", "active jobs", len(activeJobs), "successful jobs", len(successfulJobs), "failed jobs", len(failedJobs))

status 를 업데이트 한다.

    if err := r.Status().Update(ctx, &cronJob); err != nil {
        log.Error(err, "unable to update CronJob status")
        return ctrl.Result{}, err
    }

3. 히스토리 수 제한에 따른 오래된 job 삭제하기

    // NB: deleting these are "best effort" -- if we fail on a particular one,
    // we won't requeue just to finish the deleting.
    if cronJob.Spec.FailedJobsHistoryLimit != nil {
        sort.Slice(failedJobs, func(i, j int) bool {
            if failedJobs[i].Status.StartTime == nil {
                return failedJobs[j].Status.StartTime != nil
            }
            return failedJobs[i].Status.StartTime.Before(failedJobs[j].Status.StartTime)
        })
        for i, job := range failedJobs {
            if int32(i) >= int32(len(failedJobs))-*cronJob.Spec.FailedJobsHistoryLimit {
                break
            }
            if err := r.Delete(ctx, job, client.PropagationPolicy(metav1.DeletePropagationBackground)); client.IgnoreNotFound(err) != nil {
                log.Error(err, "unable to delete old failed job", "job", job)
            } else {
                log.V(0).Info("deleted old failed job", "job", job)
            }
        }
    }

    if cronJob.Spec.SuccessfulJobsHistoryLimit != nil {
        sort.Slice(successfulJobs, func(i, j int) bool {
            if successfulJobs[i].Status.StartTime == nil {
                return successfulJobs[j].Status.StartTime != nil
            }
            return successfulJobs[i].Status.StartTime.Before(successfulJobs[j].Status.StartTime)
        })
        for i, job := range successfulJobs {
            if int32(i) >= int32(len(successfulJobs))-*cronJob.Spec.SuccessfulJobsHistoryLimit {
                break
            }
            if err := r.Delete(ctx, job, client.PropagationPolicy(metav1.DeletePropagationBackground)); (err) != nil {
                log.Error(err, "unable to delete old successful job", "job", job)
            } else {
                log.V(0).Info("deleted old successful job", "job", job)
            }
        }
    }

4. Suspend 값이 세팅되었는지 확인

CronJob 객체에 suspend 값이 세팅되어 있다면 CronJob 을 일시 중단한다. CronJob 을 삭제하지 않고 잠시 멈추고 싶을 때 사용할 수 있다.

    if cronJob.Spec.Suspend != nil && *cronJob.Spec.Suspend {
        log.V(1).Info("cronjob suspended, skipping")
        return ctrl.Result{}, nil
    }

5. 다음 예약된 실행 가져오기

잠시 멈춤 상태가 아니라면 다음 스케줄을 가져온다.

    getNextSchedule := func(cronJob *batchv1.CronJob, now time.Time) (lastMissed time.Time, next time.Time, err error) {
        sched, err := cron.ParseStandard(cronJob.Spec.Schedule)
        if err != nil {
            return time.Time{}, time.Time{}, fmt.Errorf("Unparseable schedule %q: %v", cronJob.Spec.Schedule, err)
        }

        // for optimization purposes, cheat a bit and start from our last observed run time
        // we could reconstitute this here, but there's not much point, since we've
        // just updated it.
        var earliestTime time.Time
        if cronJob.Status.LastScheduleTime != nil {
            earliestTime = cronJob.Status.LastScheduleTime.Time
        } else {
            earliestTime = cronJob.ObjectMeta.CreationTimestamp.Time
        }
        if cronJob.Spec.StartingDeadlineSeconds != nil {
            // controller is not going to schedule anything below this point
            schedulingDeadline := now.Add(-time.Second * time.Duration(*cronJob.Spec.StartingDeadlineSeconds))

            if schedulingDeadline.After(earliestTime) {
                earliestTime = schedulingDeadline
            }
        }
        if earliestTime.After(now) {
            return time.Time{}, sched.Next(now), nil
        }

        starts := 0
        for t := sched.Next(earliestTime); !t.After(now); t = sched.Next(t) {
            lastMissed = t
            // An object might miss several starts. For example, if
            // controller gets wedged on Friday at 5:01pm when everyone has
            // gone home, and someone comes in on Tuesday AM and discovers
            // the problem and restarts the controller, then all the hourly
            // jobs, more than 80 of them for one hourly scheduledJob, should
            // all start running with no further intervention (if the scheduledJob
            // allows concurrency and late starts).
            //
            // However, if there is a bug somewhere, or incorrect clock
            // on controller's server or apiservers (for setting creationTimestamp)
            // then there could be so many missed start times (it could be off
            // by decades or more), that it would eat up all the CPU and memory
            // of this controller. In that case, we want to not try to list
            // all the missed start times.
            starts++
            if starts > 100 {
                // We can't get the most recent times so just return an empty slice
                return time.Time{}, time.Time{}, fmt.Errorf("Too many missed start times (> 100). Set or decrease .spec.startingDeadlineSeconds or check clock skew.")
            }
        }
        return lastMissed, sched.Next(now), nil
    }

    // figure out the next times that we need to create
    // jobs at (or anything we missed).
    missedRun, nextRun, err := getNextSchedule(&cronJob, r.Now())
    if err != nil {
        log.Error(err, "unable to figure out CronJob schedule")
        // we don't really care about requeuing until we get an update that
        // fixes the schedule, so don't return an error
        return ctrl.Result{}, nil
    }

requeue 할 값을 준비만 해 놓는다.

    scheduledResult := ctrl.Result{RequeueAfter: nextRun.Sub(r.Now())} // save this so we can re-use it elsewhere
    log = log.WithValues("now", r.Now(), "next run", nextRun)

6. 새로운 job 이 스케줄에 맞고, deadline 이 지나지 않았으며, 동시성 정책에 의해 차단되지 않은 경우 실행

    if missedRun.IsZero() {
        log.V(1).Info("no upcoming scheduled times, sleeping until next")
        return scheduledResult, nil
    }

    // make sure we're not too late to start the run
    log = log.WithValues("current run", missedRun)
    tooLate := false
    if cronJob.Spec.StartingDeadlineSeconds != nil {
        tooLate = missedRun.Add(time.Duration(*cronJob.Spec.StartingDeadlineSeconds) * time.Second).Before(r.Now())
    }
    if tooLate {
        log.V(1).Info("missed starting deadline for last run, sleeping till next")
        // TODO(directxman12): events
        return scheduledResult, nil
    }

    // figure out how to run this job -- concurrency policy might forbid us from running
    // multiple at the same time...
    if cronJob.Spec.ConcurrencyPolicy == batchv1.ForbidConcurrent && len(activeJobs) > 0 {
        log.V(1).Info("concurrency policy blocks concurrent runs, skipping", "num active", len(activeJobs))
        return scheduledResult, nil
    }

    // ...or instruct us to replace existing ones...
    if cronJob.Spec.ConcurrencyPolicy == batchv1.ReplaceConcurrent {
        for _, activeJob := range activeJobs {
            // we don't care if the job was already deleted
            if err := r.Delete(ctx, activeJob, client.PropagationPolicy(metav1.DeletePropagationBackground)); client.IgnoreNotFound(err) != nil {
                log.Error(err, "unable to delete active job", "job", activeJob)
                return ctrl.Result{}, err
            }
        }
    }

    constructJobForCronJob := func(cronJob *batchv1.CronJob, scheduledTime time.Time) (*kbatch.Job, error) {
        // We want job names for a given nominal start time to have a deterministic name to avoid the same job being created twice
        name := fmt.Sprintf("%s-%d", cronJob.Name, scheduledTime.Unix())

        job := &kbatch.Job{
            ObjectMeta: metav1.ObjectMeta{
                Labels:      make(map[string]string),
                Annotations: make(map[string]string),
                Name:        name,
                Namespace:   cronJob.Namespace,
            },
            Spec: *cronJob.Spec.JobTemplate.Spec.DeepCopy(),
        }
        for k, v := range cronJob.Spec.JobTemplate.Annotations {
            job.Annotations[k] = v
        }
        job.Annotations[scheduledTimeAnnotation] = scheduledTime.Format(time.RFC3339)
        for k, v := range cronJob.Spec.JobTemplate.Labels {
            job.Labels[k] = v
        }
        if err := ctrl.SetControllerReference(cronJob, job, r.Scheme); err != nil {
            return nil, err
        }

        return job, nil
    }

    // actually make the job...
    job, err := constructJobForCronJob(&cronJob, missedRun)
    if err != nil {
        log.Error(err, "unable to construct job from template")
        // don't bother requeuing until we get a change to the spec
        return scheduledResult, nil
    }

    // ...and create it on the cluster
    if err := r.Create(ctx, job); err != nil {
        log.Error(err, "unable to create Job for CronJob", "job", job)
        return ctrl.Result{}, err
    }

    log.V(1).Info("created Job for CronJob run", "job", job)

7. 실행 중인 job 이 보이거나 (자동으로 수행됨) 다음 예약된 실행 시간이 되면 Requeue 한다.

    // we'll requeue once we see the running job, and update our status
    return scheduledResult, nil
}

Setup

var (
    jobOwnerKey = ".metadata.controller"
    apiGVStr    = batchv1.GroupVersion.String()
)

// SetupWithManager sets up the controller with the Manager.
func (r *CronJobReconciler) SetupWithManager(mgr ctrl.Manager) error {
    // set up a real clock, since we're not in a test
    if r.Clock == nil {
        r.Clock = realClock{}
    }

    if err := mgr.GetFieldIndexer().IndexField(context.Background(), &kbatch.Job{}, jobOwnerKey, func(rawObj client.Object) []string {
        // grab the job object, extract the owner...
        job := rawObj.(*kbatch.Job)
        owner := metav1.GetControllerOf(job)
        if owner == nil {
            return nil
        }
        // ...make sure it's a CronJob...
        if owner.APIVersion != apiGVStr || owner.Kind != "CronJob" {
            return nil
        }

        // ...and if so, return it
        return []string{owner.Name}
    }); err != nil {
        return err
    }

    return ctrl.NewControllerManagedBy(mgr).
        For(&batchv1.CronJob{}).
        Owns(&kbatch.Job{}).
        Complete(r)
}

Webhook 생성

$ kubebuilder create webhook --group batch --version v1 --kind CronJob --defaulting --programmatic-validation

api/v1/cronjob_webhook.go 파일이 생성된다. 해당 파일에 체크 로직을 추가한다.

// Default implements webhook.Defaulter so a webhook will be registered for the type
func (r *CronJob) Default() {
    cronjoblog.Info("default", "name", r.Name)

    if r.Spec.ConcurrencyPolicy == "" {
        r.Spec.ConcurrencyPolicy = AllowConcurrent
    }
    if r.Spec.Suspend == nil {
        r.Spec.Suspend = new(bool)
    }
    if r.Spec.SuccessfulJobsHistoryLimit == nil {
        r.Spec.SuccessfulJobsHistoryLimit = new(int32)
        *r.Spec.SuccessfulJobsHistoryLimit = 3
    }
    if r.Spec.FailedJobsHistoryLimit == nil {
        r.Spec.FailedJobsHistoryLimit = new(int32)
        *r.Spec.FailedJobsHistoryLimit = 1
    }
}

var _ webhook.Validator = &CronJob{}

// ValidateCreate implements webhook.Validator so a webhook will be registered for the type
func (r *CronJob) ValidateCreate() error {
    cronjoblog.Info("validate create", "name", r.Name)

    return r.validateCronJob()
}

// ValidateUpdate implements webhook.Validator so a webhook will be registered for the type
func (r *CronJob) ValidateUpdate(old runtime.Object) error {
    cronjoblog.Info("validate update", "name", r.Name)

    return r.validateCronJob()
}

// ValidateDelete implements webhook.Validator so a webhook will be registered for the type
func (r *CronJob) ValidateDelete() error {
    cronjoblog.Info("validate delete", "name", r.Name)

    // TODO(user): fill in your validation logic upon object deletion.
    return nil
}

func (r *CronJob) validateCronJob() error {
    var allErrs field.ErrorList
    if err := r.validateCronJobName(); err != nil {
        allErrs = append(allErrs, err)
    }
    if err := r.validateCronJobSpec(); err != nil {
        allErrs = append(allErrs, err)
    }
    if len(allErrs) == 0 {
        return nil
    }

    return apierrors.NewInvalid(
        schema.GroupKind{Group: "batch.tutorial.kubebuilder.io", Kind: "CronJob"},
        r.Name, allErrs)
}

func (r *CronJob) validateCronJobSpec() *field.Error {
    // The field helpers from the kubernetes API machinery help us return nicely
    // structured validation errors.
    return validateScheduleFormat(
        r.Spec.Schedule,
        field.NewPath("spec").Child("schedule"))
}

func validateScheduleFormat(schedule string, fldPath *field.Path) *field.Error {
    if _, err := cron.ParseStandard(schedule); err != nil {
        return field.Invalid(fldPath, schedule, err.Error())
    }
    return nil
}

func (r *CronJob) validateCronJobName() *field.Error {
    if len(r.ObjectMeta.Name) > validationutils.DNS1035LabelMaxLength-11 {
        // The job name length is 63 character like all Kubernetes objects
        // (which must fit in a DNS subdomain). The cronjob controller appends
        // a 11-character suffix to the cronjob (`-$TIMESTAMP`) when creating
        // a job. The job name length limit is 63 characters. Therefore cronjob
        // names must have length <= 63-11=52. If we don't validate this here,
        // then job creation will fail later.
        return field.Invalid(field.NewPath("metadata").Child("name"), r.Name, "must be no more than 52 characters")
    }
    return nil
}

Controller 배포 및 실행

CR 과 CRD yaml 을 만드는 명령어를 수행한다.

$ make manifests

CRD 를 배포한다.


$ make install

WebHook 를 로컬에서 다른 터미널로 실행한다.

$ export ENABLE_WEBHOOKS=false
$ make run

config/samples/batch_v1_cronjob.yaml 파일에 값을 추가한다.

apiVersion: batch.tutorial.kubebuilder.io/v1
kind: CronJob
metadata:
  labels:
    app.kubernetes.io/name: cronjob
    app.kubernetes.io/instance: cronjob-sample
    app.kubernetes.io/part-of: cronjob-kubebuilder
    app.kubernetes.io/managed-by: kustomize
    app.kubernetes.io/created-by: cronjob-kubebuilder
  name: cronjob-sample
spec:
  schedule: "*/1 * * * *"
  startingDeadlineSeconds: 60
  concurrencyPolicy: Allow # explicitly specify, but Allow is also default.
  jobTemplate:
    spec:
      template:
        spec:
          containers:
            - name: hello
              image: busybox
              args:
                - /bin/sh
                - -c
                - date; echo Hello from the Kubernetes cluster
          restartPolicy: OnFailure

Reference site

https://book.kubebuilder.io/cronjob-tutorial/
cronJob webhook source:
https://github.com/kubernetes-sigs/kubebuilder/blob/master/docs/book/src/cronjob-tutorial/testdata/project/api/v1/cronjob_webhook.go
Writing a Kubernetes Operator from Scratch Using Kubebuilder:
https://www.youtube.com/watch?v=LLVoyXjYlYM&list=PL8pIiPkgexmmHAppEre9eHAiYqLxGFbOY&index=7
PVC Operator Sample Source:
https://github.com/civo/operator-demo/blob/main/controllers/demovolume_controller.go
elastic cloud-on-k8s source:
https://github.com/elastic/cloud-on-k8s/blob/main/pkg/apis/elasticsearch/v1/elasticsearch_types.go
https://github.com/elastic/cloud-on-k8s/blob/main/pkg/controller/elasticsearch/elasticsearch_controller.go
Develop on Kubernetes Series — Operator Dev — Understanding and Dissecting Kubebuilder:
https://yash-kukreja-98.medium.com/develop-on-kubernetes-series-operator-dev-understanding-and-dissecting-kubebuilder-4321d3ecd7d6
Learning Concurrent Reconciling:
https://openkruise.io/blog/learning-concurrent-reconciling/
Operator Pattern: https://kubernetes.io/docs/concepts/extend-kubernetes/operator/
Best practices for building Kubernetes Operators and stateful apps:
https://cloud.google.com/blog/products/containers-kubernetes/best-practices-for-building-kubernetes-operators-and-stateful-apps
Kubernetes Controllers at Scale: Clients, Caches, Conflicts, Patches Explained:
https://medium.com/@timebertt/kubernetes-controllers-at-scale-clients-caches-conflicts-patches-explained-aa0f7a8b4332
Kubernetes API guidelines: https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api-conventions.md
Golang controller-runtime: https://pkg.go.dev/sigs.k8s.io/controller-runtime
Extend the Kubernetes API with CustomResourceDefinitions: https://kubernetes.io/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/

Custom Controller 2 - Kubebuilder Architecture

seungkyua@gmail.com — Mon, 12 Jun 2023 16:38:49 +0900

Kubebuilder 의 아키텍처에 대해서 살펴보고 Kubebuilder 로 프로젝트를 생성하는 방법을 알아본다.

Kubebuilder Architeture

[출처: https://book.kubebuilder.io/architecture.html]

위의 다이어그램에서 Kubebuilder 는 controller-runtime 모듈을 사용하는 것을 알 수 있다. 또한 사용자의 비즈니스 로직은 Reconciler 에 위치 시킨다는 것을 알 수 있다.

Kubebuilder 로 프로젝트 생성

Kubebuilder 를 사용하기 위해서 사전 준비 작업이 필요하다.

사전 준비 작업

go version v1.19.0+
docker version 17.03+.
kubectl version v1.11.3+.
Access to a Kubernetes v1.11.3+ cluster.

Kubebuilder 설치

kubebuilder 는 간단히 다운 받아서 설치할 수 있다. ~/bin/ 디렉토리가 path 로 잡혀있기 때문에 다운 받은 바이너리 파일을 이 곳으로 이동시켰다.

$ cd ~/Documents/tmp

$ curl -L -o kubebuilder https://go.kubebuilder.io/dl/latest/$(go env GOOS)/$(go env GOARCH)
$ chmod +x kubebuilder
$ mv ~/Documents/tmp/kubebuilder ~/bin/kubebuilder

$ kubebuilder version
--- output ---
Version: main.version{KubeBuilderVersion:"3.10.0", KubernetesVendor:"1.26.1", GitCommit:"0fa57405d4a892efceec3c5a902f634277e30732", BuildDate:"2023-04-15T08:10:35Z", GoOs:"darwin", GoArch:"amd64"}

kustomize 설치

$ cd ~/Documents/tmp

$ curl -s "https://raw.githubusercontent.com/kubernetes-sigs/kustomize/master/hack/install_kustomize.sh"  | bash
$ mv ~/Documents/tmp/kustomize ~/bin/kustomize

$ kustomize version
--- output ---
v5.0.3

kind 설치 및 cluster 생성

$ cd ~/Documents/tmp

$ [ $(uname -m) = x86_64 ]&& curl -Lo ./kind https://kind.sigs.k8s.io/dl/v0.19.0/kind-darwin-amd64
$ chmod +x kind
$ mv ~/Documents/tmp/kind ~/bin/kind

$ kind version
--- output ---
kind v0.19.0 go1.20.4 darwin/amd64

$ kind create cluster

kubectl 설치

$ cd ~/Documents/tmp

$ curl -LO "https://dl.k8s.io/release/v1.27.1/bin/darwin/amd64/kubectl"
$ chmod +x kubectl
$ mv kubectl ~/bin/kubectl

$ kubectl version
Client Version: version.Info{Major:"1", Minor:"27", GitVersion:"v1.27.1", GitCommit:"4c9411232e10168d7b050c49a1b59f6df9d7ea4b", GitTreeState:"clean", BuildDate:"2023-04-14T13:21:19Z", GoVersion:"go1.20.3", Compiler:"gc", Platform:"darwin/amd64"}
Kustomize Version: v5.0.1
Server Version: version.Info{Major:"1", Minor:"27", GitVersion:"v1.27.1", GitCommit:"4c9411232e10168d7b050c49a1b59f6df9d7ea4b", GitTreeState:"clean", BuildDate:"2023-05-12T19:03:40Z", GoVersion:"go1.20.3", Compiler:"gc", Platform:"linux/amd64"}

프로젝트 생성

kubebuilder 명령어로 간단히 프로젝트와 API 를 생성할 수 있다. 즉, 필요한 코드들이 자동으로 생성된다.

먼저 프로젝트를 생성한다.

$ mkdir -p guestbook-kubebuilder
$ cd guestbook-kubebuilder

$ kubebuilder init --domain my.domain --repo my.domain/guestbook
--- output ---
Writing kustomize manifests for you to edit...
Writing scaffold for you to edit...
Get controller runtime:
$ go get sigs.k8s.io/controller-runtime@v0.14.4
go: downloading sigs.k8s.io/controller-runtime v0.14.4
go: downloading k8s.io/apimachinery v0.26.1
go: downloading github.com/prometheus/client_golang v1.14.0
go: downloading k8s.io/client-go v0.26.1
go: downloading k8s.io/utils v0.0.0-20221128185143-99ec85e7a448
go: downloading github.com/prometheus/client_model v0.3.0
go: downloading k8s.io/api v0.26.1
go: downloading k8s.io/component-base v0.26.1
go: downloading golang.org/x/time v0.3.0
go: downloading k8s.io/apiextensions-apiserver v0.26.1
go: downloading github.com/matttproud/golang_protobuf_extensions v1.0.2
go: downloading golang.org/x/net v0.3.1-0.20221206200815-1e63c2f08a10
go: downloading github.com/imdario/mergo v0.3.6
go: downloading k8s.io/kube-openapi v0.0.0-20221012153701-172d655c2280
go: downloading golang.org/x/oauth2 v0.0.0-20220223155221-ee480838109b
Update dependencies:
$ go mod tidy
go: downloading go.uber.org/goleak v1.2.0
Next: define a resource with:
$ kubebuilder create api

다음으로 api 를 생성한다.

$ kubebuilder create api --group webapp --version v1 --kind Guestbook
--- output ---
Create Resource [y/n]
y
Create Controller [y/n]
y
Writing kustomize manifests for you to edit...
Writing scaffold for you to edit...
api/v1/guestbook_types.go
api/v1/groupversion_info.go
internal/controller/suite_test.go
internal/controller/guestbook_controller.go
Update dependencies:
$ go mod tidy
Running make:
$ make generate
mkdir -p /Users/ahnsk/Documents/github.com/seungkyua/guestbook-kubebuilder/bin
test -s /Users/ahnsk/Documents/github.com/seungkyua/guestbook-kubebuilder/bin/controller-gen && /Users/ahnsk/Documents/github.com/seungkyua/guestbook-kubebuilder/bin/controller-gen --version | grep -q v0.11.3 || \
    GOBIN=/Users/ahnsk/Documents/github.com/seungkyua/guestbook-kubebuilder/bin go install sigs.k8s.io/controller-tools/cmd/controller-gen@v0.11.3
go: downloading sigs.k8s.io/controller-tools v0.11.3
go: downloading golang.org/x/tools v0.4.0
go: downloading k8s.io/utils v0.0.0-20221107191617-1a15be271d1d
go: downloading github.com/mattn/go-colorable v0.1.9
/Users/ahnsk/Documents/github.com/seungkyua/guestbook-kubebuilder/bin/controller-gen object:headerFile="hack/boilerplate.go.txt" paths="./..."
Next: implement your new API and generate the manifests (e.g. CRDs,CRs) with:
$ make manifests

CR 이나 CRD 를 수정하면 마지막의 make manifests 를 수행하여 다신 generation 해야 한다고 친절히 알려주고 있다.

CR 과 CRD 는 아래 guestbook_types.go 파일에 struct 로 생성되어 있다. 이곳을 원하는 대로 변경하면 된다.

테스트로 아래과 같이 변경하자.

// GuestbookSpec defines the desired state of Guestbook
type GuestbookSpec struct {
    // INSERT ADDITIONAL SPEC FIELDS - desired state of cluster
    // Important: Run "make" to regenerate code after modifying this file

    // Quantity of instances
    // +kubebuilder:validation:Minimum=1
    // +kubebuilder:validation:Maximum=10
    Size int32 `json:"size"`

    // Name of the ConfigMap for GuestbookSpec's configuration
    // +kubebuilder:validation:MaxLength=15
    // +kubebuilder:validation:MinLength=1
    ConfigMapName string `json:"configMapName"`

    // +kubebuilder:validation:Enum=Phone;Address;Name
    Type string `json:"alias,omitempty"`
}

// GuestbookStatus defines the observed state of Guestbook
type GuestbookStatus struct {
    // INSERT ADDITIONAL STATUS FIELD - define observed state of cluster
    // Important: Run "make" to regenerate code after modifying this file

    // PodName of the active Guestbook node.
    Active string `json:"active"`

    // PodNames of the standby Guestbook nodes.
    Standby []string `json:"standby"`
}

//+kubebuilder:object:root=true
//+kubebuilder:subresource:status

// Guestbook is the Schema for the guestbooks API
type Guestbook struct {
    metav1.TypeMeta   `json:",inline"`
    metav1.ObjectMeta `json:"metadata,omitempty"`

    Spec   GuestbookSpec   `json:"spec,omitempty"`
    Status GuestbookStatus `json:"status,omitempty"`
}

//+kubebuilder:object:root=true

// GuestbookList contains a list of Guestbook
type GuestbookList struct {
    metav1.TypeMeta `json:",inline"`
    metav1.ListMeta `json:"metadata,omitempty"`
    Items           []Guestbook `json:"items"`
}

Guestbook struct 에 있는 metav1.TypeMeta 와 metav1.ObjectMeta 를 설명하면, 전자는 우리가 흔히 보는 yaml 파일에서 apiVersion 과 Kind 이고 후자는 metadata 의 name, namespace 등을 나타낸다. 다음에 우리가 정의한 Spec 과 Status 가 있음을 알 수 있다.

테스트 방법 1 - Cluster 밖에서 테스트 하기

CRD 를 cluster 에 설치한다.

$ make install
--- output ---
/Users/ahnsk/Documents/github.com/seungkyua/guestbook-kubebuilder/bin/controller-gen rbac:roleName=manager-role crd webhook paths="./..." output:crd:artifacts:config=config/crd/bases
test -s /Users/ahnsk/Documents/github.com/seungkyua/guestbook-kubebuilder/bin/kustomize || { curl -Ss "https://raw.githubusercontent.com/kubernetes-sigs/kustomize/master/hack/install_kustomize.sh" --output install_kustomize.sh && bash install_kustomize.sh 5.0.0 /Users/ahnsk/Documents/github.com/seungkyua/guestbook-kubebuilder/bin; rm install_kustomize.sh; }
v5.0.0
kustomize installed to /Users/ahnsk/Documents/github.com/seungkyua/guestbook-kubebuilder/bin/kustomize
/Users/ahnsk/Documents/github.com/seungkyua/guestbook-kubebuilder/bin/kustomize build config/crd | kubectl apply -f -
customresourcedefinition.apiextensions.k8s.io/guestbooks.webapp.my.domain created

controller 를 실행시킨다. (터미널에서 포그라운드로 실행한다)

$ make run
--- output ---
test -s /Users/ahnsk/Documents/github.com/seungkyua/guestbook-kubebuilder/bin/controller-gen && /Users/ahnsk/Documents/github.com/seungkyua/guestbook-kubebuilder/bin/controller-gen --version | grep -q v0.11.3 || \
        GOBIN=/Users/ahnsk/Documents/github.com/seungkyua/guestbook-kubebuilder/bin go install sigs.k8s.io/controller-tools/cmd/controller-gen@v0.11.3
/Users/ahnsk/Documents/github.com/seungkyua/guestbook-kubebuilder/bin/controller-gen rbac:roleName=manager-role crd webhook paths="./..." output:crd:artifacts:config=config/crd/bases
/Users/ahnsk/Documents/github.com/seungkyua/guestbook-kubebuilder/bin/controller-gen object:headerFile="hack/boilerplate.go.txt" paths="./..."
go fmt ./...
go vet ./...

go run ./cmd/main.go
2023-05-24T17:18:18+09:00       INFO    controller-runtime.metrics      Metrics server is starting to listen    {"addr": ":8080"}
2023-05-24T17:18:18+09:00       INFO    setup   starting manager
2023-05-24T17:18:18+09:00       INFO    Starting server {"kind": "health probe", "addr": "[::]:8081"}
2023-05-24T17:18:18+09:00       INFO    Starting server {"path": "/metrics", "kind": "metrics", "addr": "[::]:8080"}
2023-05-24T17:18:18+09:00       INFO    Starting EventSource    {"controller": "guestbook", "controllerGroup": "webapp.my.domain", "controllerKind": "Guestbook", "source": "kind source: *v1.Guestbook"}
2023-05-24T17:18:18+09:00       INFO    Starting Controller     {"controller": "guestbook", "controllerGroup": "webapp.my.domain", "controllerKind": "Guestbook"}
2023-05-24T17:18:18+09:00       INFO    Starting workers        {"controller": "guestbook", "controllerGroup": "webapp.my.domain", "controllerKind": "Guestbook", "worker count": 1}

참고로 앞서 api 를 생성할 때 Create Resource [y/n] y 로 했다면 CR 이 config/samples 디렉토리 아래에 생성되어 있다.

여기에 Spec 부분만 추가한다.

$ tree config/samples
config/samples
├── kustomization.yaml
└── webapp_v1_guestbook.yaml

$ vi config/samples/webapp_v1_guestbook.yaml
--- output ---
apiVersion: webapp.my.domain/v1
kind: Guestbook
metadata:
  labels:
    app.kubernetes.io/name: guestbook
    app.kubernetes.io/instance: guestbook-sample
    app.kubernetes.io/part-of: guestbook-kubebuilder
    app.kubernetes.io/managed-by: kustomize
    app.kubernetes.io/created-by: guestbook-kubebuilder
  name: guestbook-sample
spec:
  # TODO(user): Add fields here
  size: 1
  configMapName: "myconfig"
  alias: "Address"

터미널을 새로 열어서 이를 설치한다.

$ kubectl apply -k config/samples/
--- output ---
guestbook.webapp.my.domain/guestbook-sample created

$ kubectl get guestbook
--- output ---           
NAME               AGE
guestbook-sample   29s

테스트 방법 2 - Cluster 안에서 돌리기

controller 를 cluster 안에서 돌리기 위해서는 먼저 이미지를 만들어야 한다.

$ docker login -u seungkyua
--- output ---         
Password: 
Login Succeeded

$ make docker-build docker-push IMG=docker.io/seungkyua/guestbook-kubebuilder:1.0

다음은 image 를 가지고 deploy 한다.

$ make deploy IMG=docker.io/seungkyua/guestbook-kubebuilder:1.0
--- output ---
test -s /Users/ahnsk/Documents/github.com/seungkyua/guestbook-kubebuilder/bin/controller-gen && /Users/ahnsk/Documents/github.com/seungkyua/guestbook-kubebuilder/bin/controller-gen --version | grep -q v0.11.3 || \
        GOBIN=/Users/ahnsk/Documents/github.com/seungkyua/guestbook-kubebuilder/bin go install sigs.k8s.io/controller-tools/cmd/controller-gen@v0.11.3
/Users/ahnsk/Documents/github.com/seungkyua/guestbook-kubebuilder/bin/controller-gen rbac:roleName=manager-role crd webhook paths="./..." output:crd:artifacts:config=config/crd/bases
test -s /Users/ahnsk/Documents/github.com/seungkyua/guestbook-kubebuilder/bin/kustomize || { curl -Ss "https://raw.githubusercontent.com/kubernetes-sigs/kustomize/master/hack/install_kustomize.sh" --output install_kustomize.sh && bash install_kustomize.sh 5.0.0 /Users/ahnsk/Documents/github.com/seungkyua/guestbook-kubebuilder/bin; rm install_kustomize.sh; }
cd config/manager && /Users/ahnsk/Documents/github.com/seungkyua/guestbook-kubebuilder/bin/kustomize edit set image controller=docker.io/seungkyua/guestbook-kubebuilder:1.0
/Users/ahnsk/Documents/github.com/seungkyua/guestbook-kubebuilder/bin/kustomize build config/default | kubectl apply -f -
# Warning: 'patchesStrategicMerge' is deprecated. Please use 'patches' instead. Run 'kustomize edit fix' to update your Kustomization automatically.
namespace/guestbook-kubebuilder-system created
customresourcedefinition.apiextensions.k8s.io/guestbooks.webapp.my.domain configured
serviceaccount/guestbook-kubebuilder-controller-manager created
role.rbac.authorization.k8s.io/guestbook-kubebuilder-leader-election-role created
clusterrole.rbac.authorization.k8s.io/guestbook-kubebuilder-manager-role created
clusterrole.rbac.authorization.k8s.io/guestbook-kubebuilder-metrics-reader created
clusterrole.rbac.authorization.k8s.io/guestbook-kubebuilder-proxy-role created
rolebinding.rbac.authorization.k8s.io/guestbook-kubebuilder-leader-election-rolebinding created
clusterrolebinding.rbac.authorization.k8s.io/guestbook-kubebuilder-manager-rolebinding created
clusterrolebinding.rbac.authorization.k8s.io/guestbook-kubebuilder-proxy-rolebinding created
service/guestbook-kubebuilder-controller-manager-metrics-service created
deployment.apps/guestbook-kubebuilder-controller-manager created

확인하면 다음과 같이 pod 가 설치된 것을 알 수 있다.

$ kubectl get pods -n guestbook-kubebuilder-system 
--- output ---
NAME                                                        READY   STATUS    RESTARTS   AGE
guestbook-kubebuilder-controller-manager-5f74f9d765-r68gn   2/2     Running   0          2m55s

삭제하기

crd 삭제

$ make uninstall

Cluster 에 설치된 controller 삭제

$ make undeploy

Kubernetes 기반의 어플리케이션 배포 시스템 구축 방법

seungkyua@gmail.com — Tue, 23 May 2023 18:12:18 +0900

DevOps 는 개발자와 운영자의 역할을 함께 수행하는 것으로 개발과 운영의 책임을 공동으로 진다. 처음 이 단어를 접한 것이 2011년 OpenStack Summit 에 참석했을 때인데 클라우드, 그 중에서 IaaS(Infrastructure as a Service)가 널리 퍼지기 시작했을 때다. DevOps 는 클라우드 기반에서 빠르게 개발하고, 배포하고, 운영하기 위해서 스타트업 회사를 중심으로 빠르게 퍼지기 시작했다.

아래는 클라우드 가상머신 기반의 DevOps 영역 중 CI/CD 에 대한 프로세스이다. 개발 언어는 Java 를 기준으로 표현하였으며, 이하 모든 설명은 Java 를 기준으로 설명한다.

문제

2015년 7월 쿠버네티스 1.0 버전이 릴리즈 되면서 DevOps 는 가상머신이 아니라 컨테이너 기반으로 점차 변화하였다. 쿠버네티스 이전의 Ops는 가상머신을 빠르게 만들고 개발된 소스 코드를 자동으로 통합 빌드하여 배포하는 영역이었다. 하지만 쿠버네티스가 나오고, 컨테이너 관리가 효율적/안정적으로 변하면서 Ops 는 소스 코드 통합 빌드, 컨테이너 이미지 만들기와 쿠버네티스에 배포, 운영하는 영역으로 바뀌었다. 즉, Ops 영역을 맡은 운영자는 컨테이너도 알아야 하고, 쿠버네티스도 알아야 한다는 의미이다.

결국 쿠버네티스 기반의 DevOps 는 소스 코드 개발, 통합 빌드, 컨테이너 이미지화, 배포의 영역 모두를 의미한다. 이를 간략하게 프로세스로 표시하면 다음과 같다.

여기서 부터 문제가 발생한다. 기존의 Dev 역할은 인프라스트럭처가 가상 머신이든 쿠버네티스이든 상관이 없지만 Ops 역할은 컨테이너와 쿠버네티스라는 새로운 기술을 알아야 하는데 해당 기술을 습득하기까지는 어느 정도의 기술 허들을 넘어야 하고 일정 기간이 지나야 한다. (클라우드 기술이 널리 퍼지기까지 기간을 생각해 보면 쉽게 이해될 것이다)

또한 배포 영역을 생각해 보면 결코 쉬운 문제가 아니다. 배포 전략에는 아래와 같은 3가지 방법이 존재한다. (크게는 4가지 이지만 가장 단순한 Recreate 배포는 생략하였다)

이미지 출처: 쿠버네티스 패턴 (책만출판사)

사족이지만 카나리아 배포를 “까나리”라고 발음하지 말자. “까나리”는 액젓이다.

해결책

개발자는 개발의 영역 즉, Dev 영역에 집중하게 하자. 어려운 Ops 영역은 시스템으로 자동으로 동작하도록 제공하자.

앞서 간단히 살펴본 개발/배포 프로세스를 다시 살펴보자.

개발자가 IDE 툴을 통해 프로그램을 개발한다.
Maven 혹은 Gradle 로 소스 코드를 빌드한다. 로컬 빌드, Jenkins 혹은 기타 다른 CI 툴을 활용한 빌드 결과물로 jar 혹은 war 파일이 생성된다. 일반적으로 스프링 부트 프로젝트는 jar 파일로 만들어지며, war 파일은 일반 스프링 프로젝트이다. 해당 결과 파일은 저장소(e.q. nexus)에 저장된다.
jar 혹은 war 파일을 로컬 빌드 혹은 기타 다른 CI 툴을 활용하여 컨테이너 이미지로 빌드한다.
빌드된 컨테이너 이미지를 이미지 저장소에 저장한다.
쿠버네티스에 배포하기 위해 deployment.yaml, service.yaml 등을 포함한 helm chart 를 만들고 이를 서버에 배포한다. 배포할 때는 배포 전략에 따라서 Rolling update, Blue-Green, Canary 로 배포한다.

1번과 2번은 개발자가 이제까지 하던 방식 그대로 개발하면 된다. 우리가 시스템으로 만들어 제공해야 할 부분은 3, 4, 5 번 영역이다.

구현 방법

해당 시스템에 대한 아키텍처를 구성하면 다음과 같다.

사용 오픈소스 S/W

Nexus
- Maven 저장소로 사용되며 테스트 용도의 jar 파일을 저장하고 다운로드 할 수 있음
Keycloak
- 인증 서버로 활용
- OIDC 접속 백엔드로 활용할 수 있음
Argo Workflow
- CNCF Graduated Project
- 워크플로우 서버로 파이프라인을 설계하고 실행할 수 있음.
- 워크플로우 템플릿을 작성하면 재사용 가능함
- 워크플로우 실행은 컨테이너 단위로 실행됨
Harbor
- CNCF Graduated Project
- 이미지 저장소로 활용
Gitea
- Helm chart 저장소로 활용
Helm
- Helm chart template 관리
Argo Rollout
- 배포 전략을 다양하게 지원함
- 지원 배포 전략: Rolling update, Blue-Green, Canary

프로세스 설명

사용자는 cli (golang)로 앱 배포를 요청한다.
API 서버 (golang) 는 해당 요청을 받아서 Argo workflow 를 호출한다.
Argo Workflow 에서 Nexus 로 부터 jar 파일을 가져온다.
Argo Workflow 에서 jar 파일을 컨테이너 이미지 파일로 빌드하고 이미지 저장소인 하버에 저장한다.
Argo Workflow 에서 이미지를 가져온다.
Argo Workflow 에서 Helm chart 템플릿을 가져온다.
Argo Workflow 에서 Helm chart 와 이미지를 조합하여 Argo Rollout 으로 배포한다.
Argo Rollout 은 초기 배포를 Blue 로 배포한다. 배포된 Blue 는 로드 발랜서와 연결된다.
사용자가 Cli 로 앱 업그레이드를 Blue-Green 전략으로 요청한다.
Argo Workflow 에서는 Rollout 으로 Green 으로 배포한다.

Kubernetes Custom Controller 개발에 필요한 Go 언어 기초 문법

seungkyua@gmail.com — Tue, 23 May 2023 18:04:57 +0900

Kubernetes custom controller 개발에 가장 잘 맞는 프로그래밍 언어는 Go 이다. Kubernetes 가 Go 로 개발된 S/W 이다 보니 Custom controller 도 Go 로 만드는 것이 좋을 것 같다는 생각이다.

그래서 겸사겸사 Custom Controller 개발에 필요한 Go 문법만 정리해 보기로 했다.

변수 선언 : var, Short Variable Declaration Operator(:=)
Package 선언 및 활용
Struct (json 으로 변환)
Receiver function
Interface 선언, 활용

변수 선언

변수는 var 키워드로 쉽게 선언할 수 있다.

// var 변수명 변수타입
var message string

변수를 선언하면서 값을 대입하면 마지막의 변수 타입은 생략 가능하다.

var message = "Hi, Welcome!"

:= operator 를 사용하면 shortcut 으로 선언하여 var 도 생략할 수 있다.

message := "Hi, Welcome!"

Package 선언 및 활용

모듈로 만들어서 import 하여 사용할 수 있다.

아래와 같이 디렉토리를 만들어보자. greetings 는 모듈로 선언하고 basic 에서 greetings 모듈을 import 하여 사용할 예정이다.

$ mkdir -p go-sample
$ cd go-sample

$ mkdir -p {basic,greetings}
$ cd greetings

go-sample 이라는 프로젝트 아래에 greetings 라는 모듈을 만든다.

모듈을 만들기 위해서 go.mod 파일을 만든다.

$ go mod init github.com/seungkyua/go-sample/greetings

go.mod 파일이 생성되며 파일 내용은 아래와 같다.

module github.com/seungkyua/go-sample/greetings

go 1.19

greetings.go 파일을 만들어서 아래와 같이 입력한다.

여기도 error 핸들링과 string format 을 위해서 모듈을 import 하고 있는데 이를 이해할려고 하지 말고 그냥 Hello function 이 있다는 것만 이해하자.

package greetings

import (
	"errors"
	"fmt"
)

func Hello(name string) (string, error) {
	if name == "" {
		return "", errors.New("empty name")
	}

	message := fmt.Sprintf("Hi, %v. Welcome!", name)
	return message, nil
}

go-sample 홈디렉토리에서 보는 greetings 디렉토리 구조는 아래와 같다.

greetings
├── go.mod
└── greetings.go

golang 1.19 버전 부터는 로컬 하위 디렉토리를 인식하기 위해서 [go.work](<http://go.work>) 를 사용한다. 그리니 아래와 같이 하여 파일을 만들어 보자.

$ go work use ./basic
$ go work use ./greetins

go-sample 홈디렉토리 아래에 [go.work](<http://go.work>) 파일이 아래와 같이 만들어 진다.

go 1.19

use (
	./greetings
	./basic
)

이제 basic 디렉토리로 가서 똑같이 go.mod 파일을 만들고 main.go 파일도 만들어 본다.

$ cd basic

$ go mod init github.com/seungkyua/go-sample/basic

go.mod 파일이 아래와 같이 생성되었음을 알 수 있다.

module github.com/seungkyua/go-sample/basic

go 1.19

greetings 모듈을 로컬로 인식하게 변경한다.

$ go mod edit -replace github.com/seungkyua/go-sample/greetings=../greetings

그리고 로컬 버전을 사용하기 위해서 pseudo 버전을 사용하게 tidy 명령을 활용한다.

$ go mod tidy

그럼 최종 go.mod 는 다음과 같다.

module github.com/seungkyua/go-sample/basic

go 1.19

// go mod edit 으로 로컬 경로를 보도록 수정
replace github.com/seungkyua/go-sample/greetings => ../greetings

// 로컬이므로 pseudo 버전을 만든다 
require github.com/seungkyua/go-sample/greetings v0.0.0-00010101000000-000000000000

main.go 파일을 만들어서 greetings 모듈을 import 하여 활용해 본다.

package main

import (
	"fmt"
	"log"

	"github.com/seungkyua/go-sample/greetings"
)

func main() {
	message, err := greetings.Hello("Seungkyu")
	if err != nil {
		log.Fatal(err)
	}
	fmt.Println(message)
}

go-sample 디렉토리 구조는 아래와 같다.

basic
├── go.mod
└── main.go
greetings
├── go.mod
└── greetings.go
go.work

Struct 활용 (json 변환)

struct 를 json data 로 변환하는 것을 marshal (encoding) 이라고 하고 json data를 struct 로 변환하는 것을 unmarshal (decoding) 이라고 한다.

json 패키지의 Marshal function 은 다음과 같다.

func Marshal(v interface{}) ([]byte, error)

Struct 를 만들어서 json data (byte slice) 로 변환해 보자.

type album struct {
	ID     string  `json:"id"`
	Title  string  `json:"title"`
	Artist string  `json:"artist"`
	Price  float64 `json:"price"`
}

a := album{ID: "1", Title: "Blue Train", Artist: "John Coltrane", Price: 56.99}
b, err := json.Marshal(a)
if err != nil {
	log.Fatal(err)
}

b2 := []byte(`{"id":"1","title":"Blue Train","artist":"John Coltrane","price":56.99}`)
fmt.Println(bytes.Equal(b, b2))

Unmarshal function 은 다음과 같다.

func Unmarshal(data []byte, v interface{}) error

json data (byte slice) 를 struct 로 다시 변환한다.

var a2 album
err = json.Unmarshal(b, &a2)
if err != nil {
	log.Fatal(err)
}
fmt.Println(a2)

Receiver Function

Receiver function 은 struct 의 멤버 변수를 활용할 수 있는 function 이다.

Vertex struct 를 만들고 그에 속한 멤버 변수를 활용하는 function 을 만들면 된다.

func 와 함수명 사이에 Struct 를 변수와 함께 넣으면 Receiver function 이 된다.

type Vertex struct {
	X, Y float64
}

func (v Vertex) Abs() float64 {
	return math.Sqrt(v.X*v.X + v.Y*v.Y)
}

func (v *Vertex) Scale(f float64) {
	v.X = v.X * f
	v.Y = v.Y * f
}

아래와 같이 main 함수를 실행하면 값은 50 이 나온다.

func main() {
	v := Vertex{3, 4}
	v.Scale(10)
	fmt.Println(v.Abs())
}

그런데 만약 위의 func (v *Vertex) Scale(f float64) **에서 Vertex 를 포인터가 아닌 value 로 만들면 어떤 결과가 나올까? 위의 함수에서 * 를 지우고 다시 실행해 보자.

결과는 5 가 된다.

즉, Struct 의 멤버 변수의 값을 바꾸고 싶으면 Pointer Receiver 를 사용해야 한다.

Interface 선언, 활용

Interface 는 method 를 모아둔 것이라 할 수 있다. interface 역시 type 키워드로 선언하기 때문에 interface 타입이라고도 말한다.

아래와 같이 Abs() 메소드를 선언하고 나서 Abs 를 Receiver function 으로 구현했다면 Abs 를 구현한 타입은 Abser 타입이라고 할 수 있다.

type Abser interface {
	Abs() float64
}

아래는 MyFloat 타입도 Abser 타입이라고 할 수 있다. 하지만 Abs 의 Receiver 는 value Receiver 이다.

type MyFloat float64

func (f MyFloat) Abs() float64 {
	if f < 0 {
		return float64(-f)
	}
	return float64(f)
}

Vertex 타입도 역시 Abser 타입이며 pointer Receiver 이다.

type Vertex struct {
	X, Y float64
}

func (v *Vertex) Abs() float64 {
	return math.Sqrt(v.X*v.X + v.Y*v.Y)
}

main 함수에서 interface 를 활용해 본다.

a = v 에서 에러가 발생한다.

func main() {
	var a Abser
	f := MyFloat(-math.Sqrt2)
	v := Vertex{3, 4}

	a = f  // MyFloat 은 Abser 인터페이스를 구현했으니 가능함
	a = &v // *Vertex 는 Abser 인터페이스를 구현했으니 가능함

	a = v  // v 는 Vertext 타입임 (*Vertex 타입이 아님), value receiver 는 구현안했으니 에러 

	fmt.Println(a.Abs())
}

Interface 선언, 활용 (2)

interface 는 interface 를 포함할 수 있다.

아래와 같이 Client interface 가 Reader interface 를 가지면 Reader interface 에 선언된 함수가 그 대로 Client 에도 속하게 된다.

package interfaces

import (
	"fmt"
)

type Reader interface {
	Get(obj string) error
	List(list []string) error
}

type Client interface {
	Reader
}

var ReconcileClient Client = &client{}

type client struct {
	name string
}

func (c *client) Get(obj string) error {
	fmt.Println(obj)
	return nil
}

func (c *client) List(list []string) error {
	fmt.Println(list)
	return nil
}

그런 다음 struct 에서 interface 를 또 다시 포함할 수 있다.

아래와 같이 GuestbookReconciler struct 에 Client interface 를 포함하면 GuestbookReconciler 는 마치 Client interface 가 가지는 함수를 자신의 메소드 처럼 사용할 수 있다.

package main

import "github.com/seungkyua/go-sample/interfaces"

type GuestbookReconciler struct {
	interfaces.Client
}

func main() {
	g := GuestbookReconciler{interfaces.ReconcileClient}
	g.Get("Seungkyu")
	g.Client.Get("Seungkyu")
}

이 때 메소드 활용은 g.Get 혹은 g.Client.Get 둘 다 가능하다.

(tmux) 터미널을 효율적으로 사용하기 (2/2)

seungkyua@gmail.com — Tue, 28 Feb 2023 13:28:54 +0900

지난 설명에 이어서 이번에는 tmux 의 설정에 대해서 자세히 살펴보자.

tmux 는 conf 파일로 단축키와 기능을 설정할 수 있다.

tmux.conf 설정 파일

tmux.conf 파일을 홈디렉토리 아래에 다음과 같이 생성한다.

$ vi ~/.tmux.conf

bind r source-file ~/.tmux.conf \; display "Reloaded!"

위의 설정은 현재의 session 에서 설정 파일인 tmux.conf 을 동적으로 바로 리로딩하는 기능을 가진다.

새로운 session 을 만들고 설정 파일을 리로딩해보자.

$ tmux new -s sample

이제 prefix + r 을 해보면 설정 파일이 리로딩된 것을 볼 수 있다. (prefix 는 ctrl + b 를 나타내며 Reloaded! 문구가 나타난 후 바로 삭제돼서 화면 캡쳐가 어렵다. ㅠㅠ)

설정 파일에 적용할 수 있는 내용을 더 알아보자.

set -s escape-time 1

prefix 와 command 사이에 인식할 수 있는 간격이 1초라는 의미이다. 리로딩의 경우 prefix 를 누르고 r 을 1초 이내에 눌러야 한다.

set -g base-index 1
setw -g pane-base-index 1

윈도우와 패인의 번호가 0 번이 아닌 1 번 부터 시작한다.

bind -r H resize-pane -L 5
bind -r J resize-pane -D 5
bind -r K resize-pane -U 5
bind -r L resize-pane -R 5

패인의 사이즈를 조절할 수 있다. prefix + H 는 왼쪽으로 5 만큼 늘린다는 의미이며, 수평(좌우)으로 2개의 패인으로 나눠진 경우에서 우측 패인에서 사용할 수 있다. 패인이 수직(위아래)으로 나눠진 경우에는 prefix + H 가 아니라 prefix + J 혹은 K 를 사용할 수 있다.

아래 이미지를 보면 오른쪽 패인이 조금 더 넓은 것을 볼 수 있다.

set -g mouse on

마우스 클릭으로 패인의 포커스를 이동할 수 있다.

setw -g pane-border-style fg=green,bg=black
setw -g pane-active-border-style fg=white,bg=yellow

현재 선택된 패인을 컬러바로 보여준다. 바로 위의 그림에서 노란색바가 아래에 있는데 이는 우측 패인이 선택되었다는 의미이다.

set -g status-left-length 40
set -g status-left "#[fg=green][#S] "

맨 아래 status 라인 왼쪽 사이드에 세션의 이름을 녹색으로 보여준다. 여기서는 [sample] 로 보여진다.

bind _ split-window -v -c "#{pane_current_path}"
bind / split-window -h -c "#{pane_current_path}"

패인을 나누면서 현재 패인의 디렉토리를 그대로 적용해 준다. prefix + % 는 수평(좌우)로 나누지만 세션을 만들 때의 디렉토리를 적용해준다. 하지만 prefix + / 는 수평(좌우)로 나누면서도 좌측 패인의 디렉토리를 우측패인에 그대로 적용해 준다.

아래 seungkyua 라는 디렉토리 위치가 그대로 적용된 것을 볼 수 있

Window / Pane 추가 기능

window 옮기기

세션에 있는 윈도우를 또 다른 세션으로 옮길 수 있으며, 서로 다른 윈도우를 하나의 윈도우에 패인으로 나눠서 통합할 수 있으며, 윈도우에 있는 패인을 또 다른 윈도우로 옮길 수 있다.

추가로 panes 세션을 만들고 거기에 first 윈도우를 만든다.

$ tmux new -s panes -n first -d

panes 세션에 second 윈도우를 만든다.

$ tmux new-window -t panes -n second

panes 세션에 들어간다. 윈도우는 second 윈도우에 접속된다.

$ tmux attach -t panes

first 윈도우를 second 윈도우에 패인으로 붙힌다.

prefix + :               ---> 명령 모드로 변경됨

join-pane -s panes:1     ---> 명령 모드에서 명령어를 실행

결과로는 first 윈도우가 second 윈도우로 합쳐지면서 second 윈도우는 2개의 패인으로 남는다.

패인 layout 바꾸기

prefix + space 는 수직(위아래) 패인 레이아웃을 수평(좌우) 패인 레이아웃으로 바꿀 수 있다. 이 때 토글로 작동한다.

여러 패인에 동시에 명령어 실행하기

prefix + ctrl + s 로 여러 패인에 동시에 명령어를 실행할 수 있다. 이 명령어도 토글로 작동된다.

현재 패인을 새로운 윈도우로 옮기기

prefix + ! 는 현재 패인을 새로운 윈도우로 만들면서 옮길 수 있다. 위에 2:second 윈도우가 있고 우측 패인이 있는데, 우측 패인에서 해당 키를 수행하면 1:zsh 윈도우가 만들어지면서 해당 패인이 윈도우가 된다.

패인 최대화하기

prefix + z 는 현재 패인을 최대화해서 보여준다. 보통 패인은 창을 나눠서 쓰기 때문에 화면이 좁을 수 있는데 일시적으로 현재 패인을 전체화면 윈도우로 만들어 준다고 생각하면 쉽다.

토글 기능이라 전체화면 윈도우에서 prefix + z 를 수행하면 원래 패인 크기도 돌아온다.

최대화가 되면 화면 아래에 status 에서 패인이름 끝에 Z 표시가 붙어 있어 현재 상태를 알기 쉽게 되어 있다.

Kubernetes Cluster 에서 Blue/Green 배포하기 (Argo Rollout 버전)

seungkyua@gmail.com — Fri, 10 Feb 2023 09:04:10 +0900

이전 글에서는 Kubernetes Cluster 상에서 App 을 Scratch 방식으로 Blue/Green 배포를 하였다. 이번에는 Argo Rollout 을 사용한 Blue/Green 배포하는 방식을 살표보자.

Nginx 혹은 AWS ALB 를 직접 연결하여 사용할 수 있지만, Blue/Green 배포는 Traffic Shifting 이 필요하지 않으므로 AWS LB → Ingress Controller 를 연결한 상태를 만들어 놓고 배포하는 방식을 설명한다.

1. Argo Rollout 설치

helm chart 를 이용하여 argo rollout 을 설치한다.

argo rollout dashboard 를 포햄하여 설치하고 싶으면 dashboard.enabled=true 를 추가하면 된다.

$ helm repo add argo https://argoproj.github.io/argo-helm
$ helm repo update

$ helm search repo argo/argo-rollouts -l
NAME                    CHART VERSION   APP VERSION     DESCRIPTION
argo/argo-rollouts      2.22.2          v1.4.0          A Helm chart for Argo Rollouts
argo/argo-rollouts      2.22.1          v1.4.0          A Helm chart for Argo Rollouts

$ helm upgrade -i argo-rollout argo/argo-rollouts --version 2.22.2 -n argo --set dashboard.enabled=true --create-namespace

argo rollout dashboard 는 인증 체계가 없다. 그러므로 포트 포워딩으로 dashboard 에 접속 하는 것을 추천한다.

$ kubectl port-forward service/argo-rollouts-dashboard 31000:3100

2. Argo Rollout kubectl plugin 설치

kubectl 로 cli 호출이 가능하도록 plugin 을 설치한다.

$ curl -LO https://github.com/argoproj/argo-rollouts/releases/download/v1.4.0/kubectl-argo-rollouts-linux-amd64
$ chmod +x kubectl-argo-rollouts-linux-amd64
$ sudo mv kubectl-argo-rollouts-linux-amd64 /usr/local/bin/kubectl-argo-rollouts

$ kubectl argo rollouts version
--- output ---
kubectl-argo-rollouts: v1.4.0+e40c9fe
  BuildDate: 2023-01-09T20:20:38Z
  GitCommit: e40c9fe8a2f7fee9d8ee1c56b4c6c7b983fce135
  GitTreeState: clean
  GoVersion: go1.19.4
  Compiler: gc
  Platform: linux/amd64

argo rollout bash complete 도 설치한다.

$ kubectl argo rollouts completion bash | tee /home/ubuntu/.kube/kubectl-argo-rollouts > /dev/null

$ vi ~/.bash_profile
source '/home/ubuntu/.kube/completion.bash.inc'
source '/home/ubuntu/.kube/kubectl-argo-rollouts'

PATH=/home/ubuntu/bin:$PATH

if [ -f ~/.bashrc ]; then
    . ~/.bashrc
fi

3. 최초 App 배포 (Blue Deployment)

초기 app (blue)을 배포한다. 이전 글에서 사용된 seungkyua/nginx:blue 이미지를 배포한다. 단 replicas 를 0 으로 배포한다. 이렇게 배포하면 실제 pod 는 실행되지 않지만 pod template 은 배포된 상태가 된다. pod template 은 나중에 rollout 에서 참조하여 사용한다.

$ cat nginx-blue-deploy.yaml
---
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: nginx-blue-green
  name: nginx-blue-green
spec:
  replicas: 0
  selector:
    matchLabels:
      app: nginx-blue-green
      version: blue-green
  template:
    metadata:
      labels:
        app: nginx-blue-green
        version: blue-green
    spec:
      containers:
      - image: seungkyua/nginx:blue
        name: nginx

$ kubectl apply -f nginx-blue-deploy.yaml

$ kubectl get deploy,pod
NAME                               READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/nginx-blue-green   0/0     0            0           11s

Service 를 배포한다.

$ cat nginx-blue-green-svc.yaml
---
apiVersion: v1
kind: Service
metadata:
  labels:
    app: nginx-blue-green
  name: nginx-blue-green-svc
spec:
  ports:
  - port: 80
    protocol: TCP
    targetPort: 80
  selector:
    app: nginx-blue-green
    version: blue-green
  type: ClusterIP

$ kubectl apply -f nginx-blue-green-svc.yaml

그리고 blue deployment app 에 웹접속이 가능하게 ingress 를 배포한다. ingress 를 배포하더라도 아직 웹 접속은 불가능하다. 앞에서 deployment 의 replicas 를 0 으로 생성했기 때문에 실행되고 있는 pod 가 없기 때문이다. (나중에 접속을 위해서 /etc/hosts 에 nginx-blue-green.taco-cat.xyz 를 등록해 놓자)

$ cat nginx-blue-green-ingress.yaml

---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: nginx-blue-green-ingress
spec:
  ingressClassName: nginx
  rules:
  - host: nginx-blue-green.taco-cat.xyz
    http:
      paths:
      - pathType: ImplementationSpecific
        backend:
          service:
            name: nginx-blue-green-svc
            port:
              number: 80

$ kubectl apply -f nginx-blue-green-ingress.yaml

Rollout 커스텀 리소스 배포

이제 초기 환경으로 Rollout 을 배포한다. Rollout 을 배포하면 pod 가 생성된다. workloadRef 영역은 Deployment 에서 Pod Template 영역과 일치한다. 그래서 이미 배포된 Deployment 를 참조하게 정의했다.

마지막 라인의 autoPromotionEnabled 는 false 로 하여 수동으로 Blue/Green 을 확인하면서 배포를 할 수 있게 한다.

$ cat nginx-rollout.yaml

apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
  name: nginx-rollout
spec:
  replicas: 2
  revisionHistoryLimit: 5
  selector:
    matchLabels:
      app: nginx-blue-green
  workloadRef:
    apiVersion: apps/v1
    kind: Deployment
    name: nginx-blue-green
  strategy:
    blueGreen:
      activeService: nginx-blue-green-svc
      autoPromotionEnabled: false

$ kubectl apply -f nginx-rollout.yaml

이제 배포가 완료되면 아래와 같이 리소스가 생성되었음을 확인할 수 있다. rollout pod 와 rollout 에서 사용하는 ReplicaSet 이 생성되어 있음을 알 수 있다.

$ kubectl argo rollouts list rollout
NAME           STRATEGY   STATUS        STEP  SET-WEIGHT  READY  DESIRED  UP-TO-DATE  AVAILABLE
nginx-rollout  BlueGreen  Healthy       -     -           2/2    2        2           2

$ kubectl get pods,deploy,rs
NAME                                 READY   STATUS    RESTARTS   AGE
pod/nginx-rollout-85c4bfb654-jmts7   1/1     Running   0          2m29s
pod/nginx-rollout-85c4bfb654-s46sm   1/1     Running   0          2m29s

NAME                               READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/nginx-blue-green   0/0     0            0           4m50s

NAME                                         DESIRED   CURRENT   READY   AGE
replicaset.apps/nginx-blue-green-8b4f9cddb   0         0         0       4m50s
replicaset.apps/nginx-rollout-85c4bfb654     2         2         2       2m29s

웹으로 접속하면 아래와 같은 화면을 볼 수 있다.

혹은 curl 로도 확인할 수 있다.

$ curl nginx-blue-green.taco-cat.xyz

--- output ---
<!DOCTYPE html>
<html>
<body style="background-color:blue;">
<h1>This is a blue webserver</h1>
</body>
</html>

Rollout dashboard 에는 아래와 같이 나온다.

4. App 업그레이드 배포 (Green Deployment)

app 을 수정하여 배포해 보자. app 은 Deployment 를 수정해서 배포하면 된다.

$ cat nginx-green-deploy.yaml
---
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: nginx-blue-green
  name: nginx-blue-green
spec:
  replicas: 0
  selector:
    matchLabels:
      app: nginx-blue-green
      version: blue-green
  template:
    metadata:
      labels:
        app: nginx-blue-green
        version: blue-green
    spec:
      containers:
      - image: seungkyua/nginx:green
        name: nginx

$ kubectl apply -f nginx-green-deploy.yaml

Deployment 가 업그레이드 되어 배포했기 때문에 Rollout 이 이를 인식하고 Green 에 해당하는 추가 Pod 와 ReplicaSet 을 생성한다. 그리고 Rollout 리소스의 상태는 Paused 가 된. (앞에서 Rollout 리소스 배포 시에 autoPromotionEnabled 는 false 로 하였기 때문이다)

$ kubectl argo rollouts list rollout
NAME           STRATEGY   STATUS        STEP  SET-WEIGHT  READY  DESIRED  UP-TO-DATE  AVAILABLE
nginx-rollout  BlueGreen  Paused        -     -           2/4    2        2           2

Pod 와 ReplicaSet 을 조회해 보면 아래와 같다. Blue 해당하는 ReplicaSet 1 개, Pod 2개, Green 에 해당하는 ReplicaSet 1개 Pod 2 개가 떠 있는 것을 알 수 있다.

Rollout Dashboar 는 아래와 같은 Pause 상태이다.

5. Rollout 진행 완료 (promote)

완전히 Green 으로 변경하려면 Rollout 을 promote 하여 최종 적용을 하던지 abort 하여 중단, 혹은 undo 하여 Pause 보다 이전 단계이 최초 Blue app 배포 단계로 돌아가는 방법이 있다.

Green 으로 진행하는 promote 를 해보자.

$ kubectl argo rollouts promote nginx-rollout

--- output ---
rollout 'nginx-rollout' promoted

ReplicaSet 은 남아 있지만 Pod 는 Green 으로 배포된 것만 남아있는 것을 확인할 수 있다.

$ kubectl get pods,rs -l rollouts-pod-template-hash --show-labels
NAME                                 READY   STATUS    RESTARTS   AGE   LABELS
pod/nginx-rollout-569b8595bf-8s94v   1/1     Running   0          10m   app=nginx-blue-green,rollouts-pod-template-hash=569b8595bf,version=blue-green
pod/nginx-rollout-569b8595bf-c7fgg   1/1     Running   0          10m   app=nginx-blue-green,rollouts-pod-template-hash=569b8595bf,version=blue-green

NAME                                       DESIRED   CURRENT   READY   AGE   LABELS
replicaset.apps/nginx-rollout-569b8595bf   2         2         2       10m   app=nginx-blue-green,rollouts-pod-template-hash=569b8595bf,version=blue-green
replicaset.apps/nginx-rollout-85c4bfb654   0         0         0       19m   app=nginx-blue-green,rollouts-pod-template-hash=85c4bfb654,version=blue-green

Rollout Dashboard 에서도 완료된 것을 알 수 있다.

마지막으로 웹 화면으로 확인한다.

마치며…

Argo Rollout 은 Deployment 변경에서만 인식을 한다. ConfigMap 이나 Secret 과 같은 다른 리소스는 지원하지 않으니 Rollout 에서 이를 지원하는 방법은 추가로 고민해야 한다.

Kustomize 활용법 (feat. GitOps 로 가는 길)

seungkyua@gmail.com — Mon, 6 Feb 2023 15:26:00 +0900

TACO 에서는 Kubernetes 에 워크로드를 배포하기 위해서 Decapod 라는 자체 빌드 및 배포 체계를 갖고 있다. Decapod 는 Helm Chart 의 value override 기능과 Kustomize 의 plugin 기능을 개발하여 적용한 또 다른 value override 를 모두 사용하고 있다.

Helm Chart 와 Kustomize 모두 value oeverride 기능을 모두 제공하는데 왜 2가지를 모두 사용할까? 그 이유는 Helm Chart 는 이미 다양하게 제공되고 있는 것들이 많아 가져다 쓰면 되고, value 값들을 하나의 yaml 파일로 합쳐서 관리하기 위해서 Kustomize 의 plugin 을 개발하여 사용하고 있다.

즉, Decapod 체계는 다음과 같은 장점이 있다.

Helm Chart 기반으로 default custom value 값을 지정할 수 있다. (decapod-base-yaml)
Kustomize plugin 을 개발하여 각 사이트마다 갖는 여러 helm chart 의 고유 value 값들을 1개의 yaml 파일에 합쳐서 관리할 수 있다.

하지만 Helm Chart 를 제공하지 않는 app 들은 어떻게 지원할까? 예를 들어 Kubeflow 의 경우 Helm Chart 를 제공하지 않지만 Kustomize 를 제공하고 있으니 이를 지원하는 방법도 필요해 보인다.

Kustomize 활용을 위한 기본 디렉토리 (base repo)

kustomize 는 설치되어 있다고 가정하고 바로 활용을 위한 기본 디렉토리를 살펴보자.

$ tree
.
├── LICENSE
├── README.md
└── service-mesh
    └── nginx
        ├── aws-msa-reference
        │   ├── kustomization.yaml
        │   └── site-values.yaml
        └── base
            ├── kustomization.yaml
            ├── nginx-deployment.yaml
            ├── nginx-service.yaml
            └── site-values.yaml

소스 홈 디렉토리 아래에는 service-mesh 라는 서비스 디렉토리가 있다. 여기에는 nginx, istio, jaeger, kaili 등 다양한 application 이 동시에 설치되어야 하는데 각 app 을 나타내는 디렉토리 (여기서는 편의상 nginx 만 설명한다)가 존재한다.

nginx 설치를 위해서는 보통 nginx-deployment.yaml 과 nginx-service.yaml 이 필요하며 이를 base 디렉토리에 위치시킨다.

$ cat nginx-deployment.yaml
---
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: nginx-blue
  name: nginx-blue
spec:
  replicas: 1
  selector:
    matchLabels:
      app: nginx-blue
      version: blue
  template:
    metadata:
      labels:
        app: nginx-blue
        version: blue
    spec:
      containers:
      - image: seungkyua/nginx:blue
        name: nginx

$ cat nginx-service.yaml
---
apiVersion: v1
kind: Service
metadata:
  name: nginx-blue-svc
spec:
  ports:
  - port: 80
    protocol: TCP
    targetPort: 80
  selector:
    app: nginx-blue
    version: blue
  type: LoadBalancer

여기까지는 Helm chart 와 동일하다. 다만 chart 는 template 을 활용하여 value 값을 override 할 수 있는데 반하여 kustomize 는 kustomize.yaml 을 통해서 value 값을 override 할 수 있다.

kustomize.yaml 을 지정하고 기본적으로 업데이트할 디폴트 값을 site-values.yaml 이라는 파일에 지정한다.

resources 는 kubernetes 에 설치할 리소스들에 대한 yaml 리스트이고 patchesStrategicMerge 는 kustomize 에서 제공하는 yaml 합성 기능 중에 하나의 방법이다.

아래의 경우에는 site-values.yaml 값과 nginx-deployment.yaml, nginx-service.yaml 값을 합쳐서 만든다.

중복되는 경우에는 site-values.yaml 값을 우선시 한다.

$ cat kustomization.yaml
---
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
- nginx-deployment.yaml
- nginx-service.yaml

patchesStrategicMerge:
- site-values.yaml

site-values.yaml 에는 override 할 default value 값을 가진다.

deployment 는 replicas 값을, service 는 NodePort 타입과 nodePort 값을 가진다. (이것을 base 값이라 생각하면 이해하기 쉽다. nginx helm chart 는 기본값이 replicas 1 인데 우리는 기본 값을 replicas 2 로 의도한 것이다.)

$ cat site-values.yaml
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-blue
spec:
  replicas: 2

---
apiVersion: v1
kind: Service
metadata:
  name: nginx-blue-svc
spec:
  ports:
  - port: 80
    protocol: TCP
    targetPort: 80
    nodePort: 32080
  type: NodePort

여기서 잠깐. nginx-deployment.yaml 과 nginx-service.yaml 값을 처음부터 바꿔서 넣으면 site-values.yaml 이 필요하지 않을 텐데 왜 굳이 이걸 만들지?

그건 kustomize 혹은 helm chart 를 제공하기 때문에 가져다 쓰는 경우도 많은데 원래의 작성 값들을 바꿔서 관리하지 않으려고 하는 의도이다. 업스트림에서 만들어 진 것이 있으면 원본은 그대로 가져다 쓰는 것이 추후 유지 보수 관점에서 편리하기 때문이다.

이제 여기까지 만든 내용을 kustomize 로 build 해 보자.

$ cd service-mesh/nginx

$ kustomize build base

--- output ---
apiVersion: v1
kind: Service
metadata:
  name: nginx-blue-svc
spec:
  ports:
  - nodePort: 32080
    port: 80
    protocol: TCP
    targetPort: 80
  selector:
    app: nginx-blue
    version: blue
  type: NodePort
---
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: nginx-blue
  name: nginx-blue
spec:
  replicas: 2
  selector:
    matchLabels:
      app: nginx-blue
      version: blue
  template:
    metadata:
      labels:
        app: nginx-blue
        version: blue
    spec:
      containers:
      - image: seungkyua/nginx:blue
        name: nginx

Site 별 디렉토리 (Site repo)

이제 특정한 사이트에 다른 값으로 설치해야 한다고 가정해 보자.

aws-msa-reference 라는 신규 사이트 디렉토리를 만들고 kustomize.yaml 과 value 값을 모아둔 site-values.yaml 을 만든다.

$ tree
.
├── LICENSE
├── README.md
└── service-mesh
    └── nginx
        ├── aws-msa-reference
        │   ├── kustomization.yaml
        │   └── site-values.yaml
        └── base
            ├── kustomization.yaml
            ├── nginx-deployment.yaml
            ├── nginx-service.yaml
            └── site-values.yaml

지금은 service-mesh/nginx 디렉토리 아리에 aws-msa-reference 가 있지만 이 디렉토리는 다른 repo 에서 관리하다가 kustomize build 를 하려할 때 해당 디렉토리로 복사해 오는 방법을 쓸 수 있다. (decapod 에서는 실제로 decapod-site 라는 repo 에 따로 사이트 값들을 관리하고 build 할 때 복사하는 방식을 사용하고 있다)

kustomize.yaml 과 site-values.yaml 을 보자.

$ cat kustomization.yaml
---
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
bases:
- ../base

patchesStrategicMerge:
- site-values.yaml

$ cat site-values.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-blue
spec:
  replicas: 3

---
apiVersion: v1
kind: Service
metadata:
  name: nginx-blue-svc
spec:
  ports:
  - port: 80
    protocol: TCP
    targetPort: 80
  type: LoadBalancer

새로운 신규 사이트에는 replicas 를 3으로 Service Type 을 LoadBalancer 로 설치하고자 한다.

이를 build 하면 다음과 같다.

$ kustomize build aws-msa-reference

--- output ---
apiVersion: v1
kind: Service
metadata:
  name: nginx-blue-svc
spec:
  ports:
  - nodePort: 32080
    port: 80
    protocol: TCP
    targetPort: 80
  selector:
    app: nginx-blue
    version: blue
  type: LoadBalancer
---
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: nginx-blue
  name: nginx-blue
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx-blue
      version: blue
  template:
    metadata:
      labels:
        app: nginx-blue
        version: blue
    spec:
      containers:
      - image: seungkyua/nginx:blue
        name: nginx

결과가 site 별로 지정한 값으로 잘 변경되었다.

어디에 적용할까?

kustomize 로 빌드된 결과 yaml 들을 특정 repo 에 저장하고 Argo CD 와 같은 tool 을 적용하면 효과적인 GitOps 체계를 만들 수 있다.

Tekton pipeline 이나 Argo workflow, Jenkins pipeline 으로 CI 를 구축하고 Argo CD 로 CD 를 연결하면 GitOps CICD 를 구축할 수 있다. (이것까지 글로 써볼까? ㅎ)

Kubernetes Cluster 에서 Blue/Green 배포하기 (scratch 버전)

seungkyua@gmail.com — Wed, 1 Feb 2023 14:25:38 +0900

Kubernetes 에서 Blue/Green 배포하는 방법을 알아보자.

Blue 와 Green 버전의 Container 이미지 만들기
Blue 버전의 Deployment 와 LoadBalancer 타입의 Service 배포
Green 버전의 Deployment 와 NodePort 타입의 Service 배포
Patch 로 Service EndPoint 변경

1. Blue 와 Green 버전의 Container 이미지 만들기

Container 이미지는 nginx 를 상속받아 쉽게 만들 수 있다. nginx 가 바라보는 web root 는 /usr/share/nginx/html 이므로 여기에 blue 버전을 표시할 수 있는 html 을 넣어준다.

index-blue.html

<!DOCTYPE html>
<html>
<body style="background-color:blue;">
<h1>This is a blue webserver</h1>
</body>
</html>

index-blue.html 을 index.html 로 변경하여 복사한다.

Dockerfile-blue

FROM nginx
COPY index-blue.html /usr/share/nginx/html/index.html

seungkyua/nginx:blue 이름과 태그를 갖는 Container 이미지를 만든다.

$ docker build -t seungkyua/nginx:blue -f Dockerfile-blue .

이미지가 정확한지 test 해본다.

$ docker run --rm -d -p 8080:80 --name nginx-blue seungkyua/nginx:blue

$ curl localhost:8080
<!DOCTYPE html>
<html>
<body style="background-color:blue;">
<h1>This is a blue webserver</h1>
</body>
</html>

이미지가 잘 확인되었으니 docker hub 에 push 한다.

$ docker login -u seungkyua
password: 

$ docker push seungkyua/nginx:blue

같은 방식으로 Green 이미지를 만들어서 docker hub 에 push 한다.

index-green.html

<!DOCTYPE html>
<html>
<body style="background-color:green;">
<h1>This is a green webserver</h1>
</body>
</html>

Dockerfile-green

$ cat Dockerfile-green
FROM nginx
COPY index-green.html /usr/share/nginx/html/index.html

$ docker build -t seungkyua/nginx:green -f Dockerfile-green .
$ docker push seungkyua/nginx:green

2. Blue 버전의 Deployment 와 LoadBalancer 타입의 Service 배포

이미지가 준비되었으니 Blue 버전의 deployment 와 service yaml 을 만들어 배포한다.

nginx-blue-deploy.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: nginx-blue
  name: nginx-blue
spec:
  replicas: 2
  selector:
    matchLabels:
      app: nginx-blue
      version: blue
  template:
    metadata:
      labels:
        app: nginx-blue
        version: blue
    spec:
      containers:
      - image: seungkyua/nginx:blue
        name: nginx

$ kubectl apply -f nginx-blue-deploy.yaml

Service 를 배포할 때는 Blue pod 의 label 을 selector 로 지정해 줘야 한다.

nginx-blue-green-svc.yaml

apiVersion: v1
kind: Service
metadata:
  labels:
    app: nginx-blue-green
  name: nginx-blue-green-svc
spec:
  ports:
  - port: 80
    protocol: TCP
    targetPort: 80
  selector:
    app: nginx-blue
    version: blue
  type: LoadBalancer

$ kubectl apply -f nginx-blue-green-svc.yaml

blue version 은 웹 브라우저에서 접속하기 위해서 Service 를 LoadBalancer 타입으로 생성하였다.

$ kubectl get svc
NAME                   TYPE           CLUSTER-IP      EXTERNAL-IP                                                                  PORT(S)        AGE
kubernetes             ClusterIP      10.233.0.1      <none>                                                                       443/TCP        12d
nginx-blue-green-svc   LoadBalancer   10.233.30.78    aa1d4e1994e454eb5aea607cfdfd3dcf-23761053.ap-northeast-2.elb.amazonaws.com   80:32234/TCP   5m18s

웹브라우저에 접속하면 아래와 같이 blue 버전으로 접속이 된다.

3. Green 버전의 Deployment 와 NodePort 타입의 Service 배포

이제 새로운 버전인 Green 버전을 배포해 보자. image 와 label 을 잘 확인해야 한다.

nginx-green-deploy.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: nginx-green
  name: nginx-green
spec:
  replicas: 2
  selector:
    matchLabels:
      app: nginx-green
      version: green
  template:
    metadata:
      labels:
        app: nginx-green
        version: green
    spec:
      containers:
      - image: seungkyua/nginx:green
        name: nginx

$ kubectl apply -f nginx-green-deploy.yaml

Service 는 Green 배포가 잘 되었는지 확인하기 위해서 Service 를 NodeType 으로 적용하였다.

nginx-green-svc.yaml

apiVersion: v1
kind: Service
metadata:
  labels:
    app: nginx-green
  name: nginx-green-svc
spec:
  ports:
  - port: 80
    protocol: TCP
    targetPort: 80
    nodePort: 32080
  selector:
    app: nginx-green
    version: green
  type: NodePort

$ kubectl apply -f nginx-green-svc.yaml

green pod 가 떠 있는 노드를 확인한다.

여기서는 172.31.49.87 노드와 172.31.46.179 노드에 pod 가 생성되어 있다.

$ kubectl get pods -o wide
NAME                           READY   STATUS    RESTARTS   AGE    IP               NODE                                               NOMINATED NODE   READINESS GATES
nginx-blue-69dd468cf4-nts5h    1/1     Running   0          6m7s   10.233.114.152   ip-172-31-49-87.ap-northeast-2.compute.internal    <none>           <none>
nginx-blue-69dd468cf4-xvxqz    1/1     Running   0          6m7s   10.233.110.80    ip-172-31-46-179.ap-northeast-2.compute.internal   <none>           <none>
nginx-green-7df845c6cf-mpj6b   1/1     Running   0          8s     10.233.114.153   ip-172-31-49-87.ap-northeast-2.compute.internal    <none>           <none>
nginx-green-7df845c6cf-pvmrc   1/1     Running   0          8s     10.233.110.81    ip-172-31-46-179.ap-northeast-2.compute.internal   <none>           <none>

curl 명령어로 Green 이 정상적으로 배포되었는지 확인한다.

$ kubectl get svc
NAME                   TYPE           CLUSTER-IP      EXTERNAL-IP                                                                  PORT(S)        AGE
kubernetes             ClusterIP      10.233.0.1      <none>                                                                       443/TCP        12d
nginx-blue-green-svc   LoadBalancer   10.233.30.78    aa1d4e1994e454eb5aea607cfdfd3dcf-23761053.ap-northeast-2.elb.amazonaws.com   80:32234/TCP   5m18s
nginx-green-svc        NodePort       10.233.33.157   <none>                                                                       80:32080/TCP   12s

$ curl 172.31.49.87:32080
<!DOCTYPE html>
<html>
<body style="background-color:green;">
<h1>This is a green webserver</h1>
</body>
</html>

4. Patch 로 Service EndPoint 변경

이제 LoadBalancer 타입으로 생성된 nginx-blue-green-svc 가 Green Pod 로 연결되게 selector 를 Green pod 가 선택되게 변경한다.

$ kubectl patch svc nginx-blue-green-svc -p '{"spec": {"selector": {"app": "nginx-green", "version": "green"}}}'

웹브라우저로 접속하면 Green 으로 변경된 것을 확인할 수 있다.

Kubernetes 에서 CSI Driver 를 활용한 ebs storage 사용하기

seungkyua@gmail.com — Tue, 31 Jan 2023 19:45:16 +0900

이전에는 aws 에 Kubernetes Cluster 를 설치한 후 Load Balancer 를 연결한는 방법을 설명하였다. Kubernetes Cluster 를 사용하려면 Load Balancer 외에도 필요한 기능이 있는데 그것이 바로 Storage 이다.

Pod 에서 영구적으로 데이터를 저장하기 위해서는 ebs 와 같은 Block Storage 를 생성해서 연결해야 하는데 Kubernetes 에서는 CSI 로 이를 지원하고 있다.

aws 에서 ebs 를 사용하려면 아래의 순서대로 적용한다.

IAM Policy 생성
CSI Driver (Provisioner) 설치
Storage Class 생성
PVC, POD 로 테스트

1. IAM Policy 생성

CSI 를 위한 IAM Policy 는 생성하기 전에 이미 만들어서 제공되고 있는 Managed Policy 를 사용해도 된다. arn:aws:iam::aws:policy/service-role/AmazonEBSCSIDriverPolicy

하지만 새로 만든다고 하면 아래와 같이 만들수 있다.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "ec2:CreateSnapshot",
        "ec2:AttachVolume",
        "ec2:DetachVolume",
        "ec2:ModifyVolume",
        "ec2:DescribeAvailabilityZones",
        "ec2:DescribeInstances",
        "ec2:DescribeSnapshots",
        "ec2:DescribeTags",
        "ec2:DescribeVolumes",
        "ec2:DescribeVolumesModifications"
      ],
      "Resource": "*"
    },
    {
      "Effect": "Allow",
      "Action": [
        "ec2:CreateTags"
      ],
      "Resource": [
        "arn:aws:ec2:*:*:volume/*",
        "arn:aws:ec2:*:*:snapshot/*"
      ],
      "Condition": {
        "StringEquals": {
          "ec2:CreateAction": [
            "CreateVolume",
            "CreateSnapshot"
          ]
        }
      }
    },
    {
      "Effect": "Allow",
      "Action": [
        "ec2:DeleteTags"
      ],
      "Resource": [
        "arn:aws:ec2:*:*:volume/*",
        "arn:aws:ec2:*:*:snapshot/*"
      ]
    },
    {
      "Effect": "Allow",
      "Action": [
        "ec2:CreateVolume"
      ],
      "Resource": "*",
      "Condition": {
        "StringLike": {
          "aws:RequestTag/ebs.csi.aws.com/cluster": "true"
        }
      }
    },
    {
      "Effect": "Allow",
      "Action": [
        "ec2:CreateVolume"
      ],
      "Resource": "*",
      "Condition": {
        "StringLike": {
          "aws:RequestTag/CSIVolumeName": "*"
        }
      }
    },
    {
      "Effect": "Allow",
      "Action": [
        "ec2:DeleteVolume"
      ],
      "Resource": "*",
      "Condition": {
        "StringLike": {
          "ec2:ResourceTag/ebs.csi.aws.com/cluster": "true"
        }
      }
    },
    {
      "Effect": "Allow",
      "Action": [
        "ec2:DeleteVolume"
      ],
      "Resource": "*",
      "Condition": {
        "StringLike": {
          "ec2:ResourceTag/CSIVolumeName": "*"
        }
      }
    },
    {
      "Effect": "Allow",
      "Action": [
        "ec2:DeleteVolume"
      ],
      "Resource": "*",
      "Condition": {
        "StringLike": {
          "ec2:ResourceTag/kubernetes.io/created-for/pvc/name": "*"
        }
      }
    },
    {
      "Effect": "Allow",
      "Action": [
        "ec2:DeleteSnapshot"
      ],
      "Resource": "*",
      "Condition": {
        "StringLike": {
          "ec2:ResourceTag/CSIVolumeSnapshotName": "*"
        }
      }
    },
    {
      "Effect": "Allow",
      "Action": [
        "ec2:DeleteSnapshot"
      ],
      "Resource": "*",
      "Condition": {
        "StringLike": {
          "ec2:ResourceTag/ebs.csi.aws.com/cluster": "true"
        }
      }
    }
  ]
}

Role 에 Policy 연결

이전 글에서 설명한 control-plane.cluster-api-provider-aws.sigs.k8s.io 와 nodes.cluster-api-provider-aws.sigs.k8s.io role 에 위의 Policy 를 연결한다.

Role : control-plane.cluster-api-provider-aws.sigs.k8s.io

Role : nodes.cluster-api-provider-aws.sigs.k8s.io

2. CSI Driver (Provisioner) 설치

EBS 용 CSI Driver 를 helm chart repo 를 등록한다.

$ helm repo add aws-ebs-csi-driver https://kubernetes-sigs.github.io/aws-ebs-csi-driver
$ helm repo update

$ helm search repo aws-ebs-csi-driver -l
NAME                                    CHART VERSION   APP VERSION     DESCRIPTION
aws-ebs-csi-driver/aws-ebs-csi-driver   2.16.0          1.15.0          A Helm chart for AWS EBS CSI Driver
aws-ebs-csi-driver/aws-ebs-csi-driver   2.15.1          1.14.1          A Helm chart for AWS EBS CSI Driver
...

지금 최신 버전 차트는 2.16.0 이다. 해당 차트는 Kubernetes 1.17+ 이상만 호환되는데 현재의 웬만한 Kubernetes 버전은 지원된다고 보면 된다.

Helm chart 로 설치한다.

$ helm upgrade -i aws-ebs-csi-driver -n kube-system aws-ebs-csi-driver/aws-ebs-csi-driver --version 2.16.0

설치가 제대로 되었는지는 아래의 명령어로 확인할 수 있다.

3. Storage Class 설치

ebs volume 이 생성될 때 CSI Driver 에게 필요한 설정 값을 전달해야 하는데 이것이 바로 Storage Class 라고 보면 된다.

아래와 같이 생성한다.

$ vi standard-ebs-sc.yaml
---
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  annotations: 
    storageclass.kubernetes.io/is-default-class: "true"
  name: standard
provisioner: ebs.csi.aws.com
volumeBindingMode: WaitForFirstConsumer
reclaimPolicy: Delete

$ kubectl apply -f standard-ebs-sc.yaml

storage class 에 storage type (gp2, gp3, io1 등), iops, 데이터 암호화 여부, 토폴로지 등을 넣을 수 있는데 이를 적용하면 현재 csi driver 에서 에러가 나므로 추가 확인이 필요하다. (볼륨 생성이 안된다던지, 볼륨 attach 가 안된다든지 하는 문제가 발생했는데 자세히 소스까지 찾아보지는 않았음 ㅠㅠ)

storage class 가 잘 생성되었는지 확인한다.

$ kubectl get sc
NAME                 PROVISIONER             RECLAIMPOLICY   VOLUMEBINDINGMODE      ALLOWVOLUMEEXPANSION   AGE
local-path           rancher.io/local-path   Delete          WaitForFirstConsumer   false                  12d
standard (default)   ebs.csi.aws.com         Delete          WaitForFirstConsumer   false                  138m

4. PVC, POD 로 테스트

pvc 를 생성하고 pod 에서 이를 mount 하여 활용해본다.

pvc 생성

$ vi pvc-example.yaml
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: ebs-claim
spec:
  accessModes:
    - ReadWriteOnce
  storageClassName: standard
  resources:
    requests:
      storage: 4Gi

$ kubectl apply -f pvc-example.yaml

sc 설정에서 volumeBindingMode: WaitForFirstConsumer 이기 때문에 pod 가 생성되기 전까지는 pv 는 만들어지지 않는다.

POD 생성

$ vi pod-example.yaml
---
apiVersion: v1
kind: Pod
metadata:
  name: app
spec:
  containers:
  - name: app
    image: centos
    command: ["/bin/sh"]
    args: ["-c", "while true; do echo $(date -u) >> /data/out.txt; sleep 5; done"]
    volumeMounts:
    - name: persistent-storage
      mountPath: /data
  volumes:
  - name: persistent-storage
    persistentVolumeClaim:
      claimName: ebs-claim

$ kubectl apply -f pod-example.yaml

out.txt 에 date 값이 설정된 것을 확인할 수 있다.

$ kubectl exec -it app -- cat /data/out.txt

Kubernetes Cluster 에서 Cloud Provider 로 aws LoadBalancer 연결하기

seungkyua@gmail.com — Wed, 25 Jan 2023 16:44:24 +0900

kubernetes 에 서비스를 올릴 때 Service 의 Type 으로 LoadBalancer 를 선택하면 cloud 에서 자동으로 LB (external-ip ) 가 생성되어 서비스 pod 에 연결된다. 어떻게 Kubernetes 에서 설정한 값이 cloud 에 연결될까? 이는 Cloud Provider 가 있어 가능하다.

Cloud Provider 는 초기에 Kubernetes Controller 에 포함되어 있다. 하지만 지금은 External Kubernete Cloud Provider 로 Kubernetes 에서 제외되었으며, 이전 Kubernetes Controller 에 포함된 Cloud Provider 는 Legacy Cloud Provider 로 불리고 있다.

AWS Cloud Provider 의 경우에는 아직 1.23 (Kubernetes 와 같이 버전을 맞춰가고 있음) alpha 버전이라 아직은 Legacy Cloud Provider 를 사용하는 것이 안정적이다.

aws 에서는 아래의 순서대로 적용한다.

IAM Policy, Role 생성
VPC, Subnet, Routing Table, Internet Gateway, Nat Gateway 생성
VM 생성
aws resource 에 Tag 적용
Kubernetes Cluster 생성

1. IAM Policy, Role 생성

Control plane 과 Node 2개의 Policy 를 생성한다.

Control Plane Policy

control node 에서 사용할 policy 이다.

정책명: control-plane.cluster-api-provider-aws.sigs.k8s.io

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "autoscaling:DescribeAutoScalingGroups",
        "autoscaling:DescribeLaunchConfigurations",
        "autoscaling:DescribeTags",
        "ec2:DescribeInstances",
        "ec2:DescribeRegions",
        "ec2:DescribeRouteTables",
        "ec2:DescribeSecurityGroups",
        "ec2:DescribeSubnets",
        "ec2:DescribeVolumes",
        "ec2:DescribeAvailabilityZones",
        "ec2:CreateSecurityGroup",
        "ec2:CreateTags",
        "ec2:CreateVolume",
        "ec2:ModifyInstanceAttribute",
        "ec2:ModifyVolume",
        "ec2:AttachVolume",
        "ec2:AuthorizeSecurityGroupIngress",
        "ec2:CreateRoute",
        "ec2:DeleteRoute",
        "ec2:DeleteSecurityGroup",
        "ec2:DeleteVolume",
        "ec2:DetachVolume",
        "ec2:RevokeSecurityGroupIngress",
        "ec2:DescribeVpcs",
        "elasticloadbalancing:AddTags",
        "elasticloadbalancing:AttachLoadBalancerToSubnets",
        "elasticloadbalancing:ApplySecurityGroupsToLoadBalancer",
        "elasticloadbalancing:CreateLoadBalancer",
        "elasticloadbalancing:CreateLoadBalancerPolicy",
        "elasticloadbalancing:CreateLoadBalancerListeners",
        "elasticloadbalancing:ConfigureHealthCheck",
        "elasticloadbalancing:DeleteLoadBalancer",
        "elasticloadbalancing:DeleteLoadBalancerListeners",
        "elasticloadbalancing:DescribeLoadBalancers",
        "elasticloadbalancing:DescribeLoadBalancerAttributes",
        "elasticloadbalancing:DetachLoadBalancerFromSubnets",
        "elasticloadbalancing:DeregisterInstancesFromLoadBalancer",
        "elasticloadbalancing:ModifyLoadBalancerAttributes",
        "elasticloadbalancing:RegisterInstancesWithLoadBalancer",
        "elasticloadbalancing:SetLoadBalancerPoliciesForBackendServer",
        "elasticloadbalancing:AddTags",
        "elasticloadbalancing:CreateListener",
        "elasticloadbalancing:CreateTargetGroup",
        "elasticloadbalancing:DeleteListener",
        "elasticloadbalancing:DeleteTargetGroup",
        "elasticloadbalancing:DescribeListeners",
        "elasticloadbalancing:DescribeLoadBalancerPolicies",
        "elasticloadbalancing:DescribeTargetGroups",
        "elasticloadbalancing:DescribeTargetHealth",
        "elasticloadbalancing:ModifyListener",
        "elasticloadbalancing:ModifyTargetGroup",
        "elasticloadbalancing:RegisterTargets",
        "elasticloadbalancing:DeregisterTargets",
        "elasticloadbalancing:SetLoadBalancerPoliciesOfListener",
        "iam:CreateServiceLinkedRole",
        "kms:DescribeKey"
      ],
      "Resource": [
        "*"
      ]
    }
  ]
}

Node Policy

일반 Node 에 대한 policy 이다.

정책명: nodes.cluster-api-provider-aws.sigs.k8s.io

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "ec2:DescribeInstances",
        "ec2:DescribeRegions",
        "ecr:GetAuthorizationToken",
        "ecr:BatchCheckLayerAvailability",
        "ecr:GetDownloadUrlForLayer",
        "ecr:GetRepositoryPolicy",
        "ecr:DescribeRepositories",
        "ecr:ListImages",
        "ecr:BatchGetImage"
      ],
      "Resource": "*"
    }
  ]
}

policy 를 생성했으면 이제 Role 을 생성한다.

Control plane Role

Policy 를 활용할 수 있는 Role 을 만들어서 Policy 와 연결한다.

Role 명: control-plane.cluster-api-provider-aws.sigs.k8s.io

연결할 Policy 리스트
- control-plane.cluster-api-provider-aws.sigs.k8s.io
- nodes.cluster-api-provider-aws.sigs.k8s.io

Node Role

Role 명: nodes.cluster-api-provider-aws.sigs.k8s.io

연결할 Policy 리스트
- nodes.cluster-api-provider-aws.sigs.k8s.io

2. VPC, Subnet, Routing Table, Internet Gateway, Nat Gateway 생성

서울 리전의 경우 VPC 를 1개 만들고, public 용도의 subnet 4개, private 용도의 subnet 4개를 만든다.

Internet Gateway 1개를 만들어서 public subnet 에 연결하고, Nat Gateway 4개를 만들어서 각각 private subnet 에 연결한다.

Routing Table 은 subnet 갯수에 맞는 8개를 만들어서 각각 연결한다. private 용 4개의 Routing table 은 0.0.0.0/0 → nat gateway 를 대상으로 설정하고, public 용 4개의 Routing table 은 0.0.0.0/0 → internet gateway 대상으로 설정한다.

1. vpc : 1개
   - vpc

2. subent : 8개
   - public-subnet-a
   - public-subnet-b
   - public-subnet-c
   - public-subnet-d
   - private-subnet-a
   - private-subnet-b
   - private-subnet-c
   - private-subnet-d

3. internat gateway : 1개
   - igw

4. Nat Gateway : 4개
   - nat-private-a
   - nat-private-b
   - nat-private-c
   - nat-private-d

5. Routing Table : 4개
   - rt-public-a (0.0.0.0/0 -> igw)
   - rt-public-b (0.0.0.0/0 -> igw)
   - rt-public-c (0.0.0.0/0 -> igw)
   - rt-public-d (0.0.0.0/0 -> igw)
   - rt-priabe-a (0.0.0.0/0 -> nat-private-a)
   - rt-priabe-b (0.0.0.0/0 -> nat-private-b)
   - rt-priabe-c (0.0.0.0/0 -> nat-private-c)
   - rt-priabe-d (0.0.0.0/0 -> nat-private-d)

3. VM 생성

VM 은 Controler Plane 3대는 각 private subnet 에 1대씩 생성하고(subnet 1개는 남는다), Node 용 4대는 각 private subnet 1대씩 생성하다.

bastion 노드로 public subnet 에 1대 생성한다.

1. bastion VM 1대
   - public-subnet-a

2. Control Plane VM 3대
   - private-subnet-a
   - private-subnet-b
   - private-subnet-c

3. Node VM 4대
   - private-subnet-a
   - private-subnet-b
   - private-subnet-c
   - private-subnet-d

4. Aws Resource 에 Tag 설정

aws cloud provider 가 리소스를 파악하기 위해서는 aws 에 적절한 값을 설정해야 한다.

4-1. VM 에 IAM Role 을 할당

VM 에서 권한을 얻기 위해서는 반드시 IAM Role 을 할당해야 한다.

Control node 에는 control-plane.cluster-api-provider-aws.sigs.k8s.io role 을 할당한다.

일반 Node 에는 nodes.cluster-api-provider-aws.sigs.k8s.io role 을 할당한다.

4-2 VM 에 Tag 설정

VM 에는 Kubernetes Cluster Name 을 Tag 로 지정한다. kubernetes.io/cluster/<cluster name> 과 같이 지정하는데 Cluster Name 은 Kubernetes 를 설치할 때 지정할 수 있다. 기본 값은 cluster.local 인데 여기서는 ahnsk 로 이름을 지정하였다.

그리고 vm 의 역할을 지정해야 하는데 Controler Node 는 control-plane 으로, Node 는 node 로 지정한다.

4-3. Subnet 에 Tag 설정

Load Balancer 를 핸들링 하기 위해서 Kubernetes Cluster 가 어느 Subnet 과 Routing Table 을 사용해야 하는지 알아야 한다.

주의해야 할 점은 public subnet 의 경우 [kubernetes.io/role/elb](http://kubernetes.io/role/elb) 이지만, private subnet 의 경우에는 [kubernetes.io/role/internal-elb](http://kubernetes.io/role/internal-elb) 로 해야 한다.

4-4. Routing Table 에 Tag 설정

5. Kubernetes Cluster 생성

Kubernetes cluster 이름은 앞에서 설명했듯이 ahnsk 로 설정한다.

kubeadm 혹은 kubespray 를 사용할 수 있으며 여기서 생성 방법을 생략한다.

aws cloud provider 를 활성화 하기 위해서는 API Server, Controller, Kubelet 에 --cloud-provider=aws 옵션을 추가해야 한다.

kube-apiserver.yaml

apiVersion: v1
kind: Pod
metadata:
  annotations:
    kubeadm.kubernetes.io/kube-apiserver.advertise-address.endpoint: 172.31.22.52:6443
  creationTimestamp: null
  labels:
    component: kube-apiserver
    tier: control-plane
  name: kube-apiserver
  namespace: kube-system
spec:
  containers:
  - command:
    - kube-apiserver
    - --advertise-address=172.31.22.52
...
    **- --cloud-provider=aws**
...
    image: registry.k8s.io/kube-apiserver:v1.24.6
...

kube-controller-manager.yaml

apiVersion: v1
kind: Pod
metadata:
  creationTimestamp: null
  labels:
    component: kube-controller-manager
    tier: control-plane
  name: kube-controller-manager
  namespace: kube-system
spec:
  containers:
  - command:
    - kube-controller-manager
    - --allocate-node-cidrs=true
...
    **- --cloud-provider=aws
...**
    image: registry.k8s.io/kube-controller-manager:v1.24.6
...

kubelet.env

...
KUBELET_CLOUDPROVIDER="**--cloud-provider=aws --cloud-config=/etc/kubernetes/cloud_config**"
...

kubelet 은 aws 의 리소스를 위해 추가해야 할 값들이 있는데 cloud_config 을 만들어서 옵션을 전달하였다.

[Global]
zone=
vpc=vpc-b342d5d8
subnetId=
routeTableId=
roleArn=
kubernetesClusterTag=ahnsk
kubernetesClusterId=ahnsk
disableSecurityGroupIngress=false
disableStrictZoneCheck=false
elbSecurityGroup=

값을 다 채워 넣으면 apiserver 가 kube-apiserver-master-dummy 라는 이름으로 잘못 실행되므로 조심해야 한다. master-dummy 로 띄우는 방법은 aws account 가 다를 경우에만 사용하는 방법이다. 이는 아래 소스를 보면 알 수 있다.

https://github.com/kubernetes/legacy-cloud-providers/blob/707ecda639b086132369678680a1b34d4d2b5c7c/aws/aws.go#L1251

...
  tagged := cfg.Global.KubernetesClusterTag != "" || cfg.Global.KubernetesClusterID != ""
    if cfg.Global.VPC != "" && (cfg.Global.SubnetID != "" || cfg.Global.RoleARN != "") && tagged {
        // When the master is running on a different AWS account, cloud provider or on-premise
        // build up a dummy instance and use the VPC from the nodes account
        klog.Info("Master is configured to run on a different AWS account, different cloud provider or on-premises")
        awsCloud.selfAWSInstance = &awsInstance{
            nodeName: "master-dummy",
            vpcID:    cfg.Global.VPC,
            subnetID: cfg.Global.SubnetID,
        }
        awsCloud.vpcID = cfg.Global.VPC
    } else {
        selfAWSInstance, err := awsCloud.buildSelfAWSInstance()
        if err != nil {
            return nil, err
        }
        awsCloud.selfAWSInstance = selfAWSInstance
        awsCloud.vpcID = selfAWSInstance.vpcID
    }
...

RoleARN 의 값을 넣으면 안되는데 값이 없으면서도 어떻게 kubelet 이 해당 Role 로 인증을 받을 수 있을까? 이는 앞에서 설명한 VM 에 IAM Role 인 control-plane.cluster-api-provider-aws.sigs.k8s.io 이나 nodes.cluster-api-provider-aws.sigs.k8s.io 이 설정되어 있기 때문에 가능하다.

kubelet-config.yaml

kubernetes node 정보에 providerID 값이 들어가 있어야 한다. 만약 이 정보가 없다면 LoadBalancer 가 생성된다고 하더라도 인스턴스가 LoadBalancer 에 할당되지 않아 제대로 사용할 수 가 없다.

providerID 는 kubelet-config.yaml 에 추가한다. aws:///<zone-id>/<instance-id> 값으로 추가한다.

$ sudo vi /etc/kubernetes/kubelet-config.yaml
...
providerID: "aws:///ap-northeast-2d/i-0f59f059e2d64213f"
...

이미 노드가 생성된 경우에는 해당 값을 변경하고 kubelet 서비스를 다시 restart 한다고 값이 추가되지는 않는다. 그래서 patch 명령으로 동적으로 추가하는 것이 좋다.

$ kubectl patch node ip-172-31-46-179.ap-northeast-2.compute.internal -p '{"spec": {"providerID": "aws:///ap-northeast-2d/i-08cb6f884239f894c"}}'

5. Nginx 로 테스트

nginx 를 생성하고 service 를 LoadBalancer type 으로 생성하여 잘 접속이 되는지 확인해 보자.

$ kubectl create deploy nginx --image=nginx
deployment.apps/nginx created

$ kubectl get pods
NAME                    READY   STATUS    RESTARTS   AGE
nginx-8f458dc5b-nhkfd   1/1     Running   0          55s

$ kubectl expose deployment nginx --name nginx-svc --target-port=80 --port=80 --type=LoadBalancer

$ kubectl get svc
NAME         TYPE           CLUSTER-IP     EXTERNAL-IP                                                                   PORT(S)        AGE
kubernetes   ClusterIP      10.233.0.1     <none>                                                                        443/TCP        5h28m
nginx-svc    LoadBalancer   10.233.7.131   a76a315f5d7c14652a4db83cc3b25125-113127685.ap-northeast-2.elb.amazonaws.com   80:30796/TCP   27s

(tmux) 터미널을 효율적으로 사용하기 (1/2)

seungkyua@gmail.com — Sat, 14 Jan 2023 16:53:46 +0900

command line 명령을 사용할 때 터미널에서 여러 기능들을 사용해야 할 때가 있다. 예를 들어 여러 윈도우(창)을 띄워놓고 필요에 따라 옮긴다던가 하나의 윈도우을 상하, 혹은 좌우로 구분하여 나눠서 사용하는 경우가 있다.

보통은 명령어를 여러 디렉토리를 옮겨가며 작업하기 때문에 디렉토리 마다 윈도우를 만들어 사용한다. 혹은 포그라운드로 프로세스를 띄워 출력되는 로그를 확인하고, 다른 윈도에서 작업하는 경우도 있다.

위와 같은 기능을 제공하는 툴에는 tmux 라는 sw가 있다. 일반적으로 linux 에는 기본으로 설치되어 있고 mac 에서는 쉽게 설치할 수 있으므로 쉽게 활용할 수 가 있다.

1. 세션 관리

세션 만들기

tmux 는 세션 단위로 구분하여 관리한다. 자신만의 새로운 세션을 만들어 독립으로 사용할 수 있다.

$ tmux new -s ahnsk

ahnsk 이라는 새로운 세션(session)이 생성되면서 1:zsh 라는 윈도우(window) 1개가 기본적으로 생성되었다.

$ exit

exit 는 현재의 윈도우를 삭제한다. 지금은 세션에 1개의 윈도우 밖에 없기 때문에 윈도우가 삭제되면 해당 세션도 삭제된다.

command prefix

tmux 에서는 vi 처럼 명령모드를 사용할 수 있다. Ctrl + b (control 키와 b 키를 동시에 누름)를 입력한 이후에 명령어를 입력하면 되는데 명령 모드를 알려주는 이 키 조합을 command prefix 라고 한다. 줄여서 앞으로는 prefix 라고 한다.

prefix + t 를 누르면 화면에 시간에 표시된다.

Detaching 과 Attaching

exit 는 윈도우를 삭제(경우에 따라서는 세션까지도 삭제) 하기 때문에 이전의 세션과 윈도우를 계속 유지 시키면서 tmux 에서 빠져나오고 싶을 때도 있다. 이 때 사용해야할 기능이 detaching 기능이다.

$ top

prefix + d 를 입력하여 detaching 한다.

[detached (from session ahnsk)] 가 출력되고 원래의 터미널 창으로 빠져나온 것이 확인 된다.

-d 옵션으로 새로운 세션을 만들고 바로 detaching 할 수 도 있다.

$ tmux new -s dummy -d

세션을 조회하여 기존에 만든 세션의 리스트를 확인할 수 있다.

$ tmux ls

--- output ---
ahnsk: 1 windows (created Sat Jan 14 14:51:09 2023)
dummy: 1 windows (created Sat Jan 14 15:25:39 2023)

기존의 만든 ahnsk 세션으로 들어가고 싶으면 attach 명령을 쓰면 된다.

$ tmux attach -t ahnsk

세션 삭제

kill-session 옵션으로 세션을 삭제할 수 있다.

$ tmux kill-session -t ahnsk
$ tmux kill-session -t dummy

2. 윈도우 관리

윈도우 만들기

session 을 만들면 새로운 윈도우도 기본으로 생성된다고 했다. 이 때 -n 옵션을 사용하여 생성되는 윈도우에 이름을 넣을 수 있다.

$ tmux new -s ahnsk -n shell

prefix + c 명령으로 새로운 윈도우를 만들 수 있다. 이렇게 새로 만든 윈도우에 top 명령을 실행해 보자.

윈도우 이름 변경

첫번째 윈도우의 이름은 shell 이고 두번째 top 이 실행되고 있는 윈도우의 이름은 top 이다. (top 이 실행되고 있으므로) 두번째 윈도우 이름을 process 로 변경해 보자.

prefix + , 로 윈도우 이름을 변경할 수 있다.

이름을 넣은 뒤에 enter 를 치면 된다.

윈도우 이동

작업 윈도우를 아래 명령으로 옮겨 다닐 수 있다.

prefix + n : 현재 윈도우 다음(next) 윈도우로 이동하기

prefix + p : 현재 윈도우 이전(previous) 윈도우로 이동하기

prefix + 1 : 첫번째(1) 윈도우로 이동하기

prefix + 5 : 다섯번째(5) 윈도우로 이동하기

prefix + w : 윈도우 리스트를 보여주고 선택하여 이동하기

윈도우 닫기

prefix + & 로 명령으로 확인 입력(y)을 받으면 윈도우를 닫을 수(삭제할 수) 있다. exit 를 입력하여 확인없이 바로 윈도우가 삭제된다.

윈도우 이름으로 생성하기

prefix + : 으로 명령어 입력창을 띄울 수 있다. 여기에 new-window -n monitor 라고 입력하고 enter 를 치면 새로운 윈도우에 이름을 지정하여 생성할 수 있다.

3. 패인 관리

패인(pane) 만들기

윈도우 안의 구분되는 영역을 패인이라 한다. 윈도우를 수평으로 2개의 패인으로 나누거나 수직으로 2개의 패인으로 나눌 수 있다.

prefix + % : 윈도우를 수평(좌우)으로 2개의 패인으로 나눈다.

prefix + " (double quote) : 윈도우를 수직(위아래)으로 2개의 패인으로 나눈다.

패인 이동하기

prefix + Left 화살표 : 좌측 패인으로 이동하기

prefix + Right 화살표 : 우측 패인으로 이동하기

prefix + Up 화살표 : 위 패인으로 이동하기

prefix + Downe 화살표 : 아래 패인으로 이동하기

prefix + o : 시계 방향으로 패인 이동하기

패인 삭제하기

prefix + x 명령으로 현재 선택된 패인을 삭제할 수 있다. exit 로도 삭제가 가능하다. 가끔 화면에 키보드 입력이 안돼서 exit 를 화면에 입력할 수 없는 경우가 있다. 이 경우에는 명령모드인 prefix + x 로 삭제해야 하므로 명령모드도 알아 두는 것이 좋다.

(go-06) Go If, For, Switch, Function

seungkyua@gmail.com — Tue, 2 Aug 2022 16:16:11 +0900

언어를 배울 때 가장 기본적인 것 중에 하나가 비교문(if), 반복문(for), 함수(function) 이다.

If 문

if 는 비교 구문에서 사용되는 키워드 이다. 변수 선언과 동시에 비교를 할 수 있는데 이 때 선언된 변수는 해당 if 문 block 안에서만 유효하다. 그렇기 때문에 마지막 라인은 num 변수는 인식하지 못해 에러가 난다.

func main() {
	if num := 5; num == 0 {
		fmt.Println("False")
	} else if num < 10 {
		fmt.Println("True")
	} else {
		fmt.Println("Big number")
	}
	fmt.Println(num)
}

--- output ---
./main_05_for_function.go:17:14: undefined: num

if 문 밖에서 선언한 변수는 if 문 안과 밖 모두에서 사용할 수 있다. 하지만 if 문 안에서 같은 변수명을 재정의 하면 해당 변수 값은 오버라이드 된다.

func main() {
	num := 10
	if num > 0 {
		fmt.Println("outer num =", num)
		num := 0
		fmt.Println("inner num =", num)
	}
	fmt.Println("outer num =", num)
}

--- output ---
outer num = 10
inner num = 0
outer num = 10

For 문

for lloop 는 반복문이며 slice 나 map 타입에 대해서 range 를 사용하여 item 을 하나씩 가져온다. slice 를 range 로 가져오면 index, value 2개의 값으로 넘어온다. value 만을 사용하고 싶으면 index 부분은 _ 로 처리하여 버릴 수 있다. 또한 index 1개의 값만 가져올 수 있다.

func main() {
	nums := []int{10, 20, 30, 40, 50}
	for i, v := range nums {
		fmt.Println("index =", i, ",", "value =", v)
	}
	for _, v := range nums {
		fmt.Println("value =", v)
	}
	for i := range nums {
		fmt.Println("index =", i)
	}
}

--- output ---
index = 0 , value = 10
index = 1 , value = 20
index = 2 , value = 30
index = 3 , value = 40
index = 4 , value = 50
value = 10
value = 20
value = 30
value = 40
value = 50
index = 0
index = 1
index = 2
index = 3
index = 4

map 도 slice 와 마찬가지로 range 로 가져올 수 있다. 이 때 return 되는 값은 key, value 이다.

func main() {
  m := map[string]int{
		"a": 1,
		"b": 2,
		"c": 3,
	}
	for k, v := range m {
		fmt.Println("key =", k, ",", "value =", v)
	}
	for _, v := range m {
		fmt.Println("value =", v)
	}
	for k := range m {
		fmt.Println("key =", k)
	}
}

--- output ---
key = c , value = 3
key = a , value = 1
key = b , value = 2
value = 2
value = 3
value = 1
key = a
key = b
key = c

Switch

선택문은 switch 로 가능하다. 각 case 마다 break 문이 없어도 되며, case 에는 , 로 여러 개의 값을 지정할 수 있다.

func main() {
  alpha := []string{"a", "ab", "abc", "abcd", "abcde", "abcdef", "abedefg"}
	for _, a := range alpha {
		switch l := len(a); l {
		case 1, 2:
			fmt.Println(a, "length = 2 or 3")
		case 3:
			fmt.Println(a, "length = 3")
		case 4, 5, 6:
			fmt.Println(a, "length = 4, 5 or 6")
		default:
			fmt.Println(a, "length > 6")
		}
	}
}

--- output ---
a length = 2 or 3
ab length = 2 or 3
abc length = 3
abcd length = 4, 5 or 6
abcde length = 4, 5 or 6
abcdef length = 4, 5 or 6
abedefg length > 6

Function

함수는 func, function name, parameter, return value 로 만들 수 있다. 아래 2개의 숫자를 받아서 나누는 div 함수는 아래와 같이 정의 할 수 있다. parameter 가 같은 타입이면 앞의 타입은 생략할 수 있다.

func main() {
  result := div(4, 2)
	fmt.Println(result)
}

// func div(n int, d int) int { 는 n, d 파라미터의 타입이 같아 아래와 같이 바꿀 수 있음
func div(n, d int) int {
	if d == 0 {
		return 0
	}
	return n / d
}

--- output ---
2

, 로 구분하여 여러 개의 아규먼트를 넘길 수 있으며 이 때 받는 함수에서는 ... 를 활용하여 가변 파라미터로 받을 수 있다. 또한 slice... 와 같이 slice 를 가변인자로 보낼 수 있다.

func main() {
  fmt.Println(addTo(1))
	fmt.Println(addTo(1, 2))
	fmt.Println(addTo(1, 2, 3))
	i := []int{4, 5}
	fmt.Println(addTo(3, i...))   // slice를 가변인자로 보내기
	fmt.Println(addTo(6, []int{7, 8, 9}...))
}

// 가변인자 (variadic parameter)
func addTo(base int, vals ...int) []int {
	result := make([]int, 0, len(vals))
	for _, v := range vals {
		result = append(result, base+v)
	}
	return result
}

--- output ---
[]
[3]
[3 4]
[7 8]
[13 14 15]

Function 의 리턴 값을 여러 개로 할 수 있다. (multi return values)

func main() {
  result, remainder, err := multiReturnValues(10, 5)
	if err != nil {
		fmt.Println(err)
	}
	fmt.Println(result, remainder)
}

// multiple retrun values
func multiReturnValues(n, d int) (int, int, error) {
	if d == 0 {
		return 0, 0, errors.New("cannot divid by zero")
	}
	return (n / d), (n % d), nil
}

--- output ---
2 0

Function 은 변수에 담을 수 있다. cal 함수 내부에 보면 map 의 value 로 Function 타입을 선언하여 할당한 것을 볼 수 있다. Function 을 변수로 선언할 수 있고, 파라미터로 받을 수 있고 return value 로도 사용할 수 있다.

func main() {
  exp := []string{"3", "+", "4"}
	result, err := cal(exp)
	if err != nil {
		fmt.Println(err)
	}
	fmt.Println(result)
}

func cal(exp []string) (int, error) {
	// Function Type
	type opFuncType func(int, int) int
	var opMap = map[string]opFuncType{
		"+": add,
		"-": sub,
	}

	a, err := strconv.Atoi(exp[0])
	if err != nil {
		fmt.Println(err)
		return 0, err
	}

	b, err := strconv.Atoi(exp[2])
	if err != nil {
		fmt.Println(err)
		return 0, err
	}

	op := exp[1]
	opFunc, ok := opMap[op]
	if !ok {
		fmt.Println("unsupported operator: ", op)
		return 0, err
	}
	return opFunc(a, b), nil
}

func add(a, b int) int {
	return a + b
}

func sub(a, b int) int {
	return a - b
}

--- output ---
7

struct 와 마찬가지로 Function 도 anonymous 로 만들 수 있다.

func main() {
  for i := 0; i < 5; i++ {
		func(j int) {
			fmt.Println(j)
		}(i)
	}
}

--- output ---
0
1
2
3
4

Function 안에는 Function 을 중첩해서 선언할 수 있는데 이 것을 clousure (클로저)라 한다. 클로저는 앞에서 설명한 Function 을 파라미터와 리턴 값으로 사용할 수 있는 성질을 많이 이용한다.

클로저는 변수 값이 사라지지 않고 계속 유지되는 특성을 갖는다. 아래 multiple(2) 을 호출 할 때 생성된 파라미터 base 변수 에는 2가 할당 되고 funcA(3) 을 호출 할 때도 계속 값이 남아 있어 base * factor 의 값은 2 * 3 이 되어 6 이 출려된다.

func main() {
  funcA := multiple(2)
	fmt.Println(funcA(3))

	funcA = multiple(4)
	fmt.Println(funcA(5))
}

// high-ooder fuctnion
func multiple(base int) func(int) int {
	return func(factor int) int {
		return base * factor
	}
}

--- output ---
6
20

함수를 호출할 때 모든 것은 Call by Value 이다. 아래과 같이 기본 타입이나 Struct 타입은 함수를 통해 넘겨받은 변수의 값을 변경하더라도 원래의 값은 변경되지 않는다. 즉, 아래와 같이 person 을 modify 함수를 통해 넘긴 다음, modify 함수에서 값을 수정해도 원래의 person 의 값은 수정되지 않는다.

func main() {
  i := 1
	s := "Hello"
	p := person{}
	modify(i, s, p)
	fmt.Println(i, s, p)
}

type person struct {
	name string
	age  int
}

// Call by Value (여기서 수정해도 원래 변수 값은 수정되지 않는다)
func modify(i int, s string, p person) {
	i = i + 1
	s = "modified"
	p.name = "ask"
	p.age = 100
}

--- output ---
1 Hello { 0}

그러나 포인터로 넘기면 원래의 값도 수정할 수 있다. 포인터는 다음에 설명하기로 하고 여기서는 slice 와 map 이 포인터와 같이 작동한다고 이해하면 된다.

한가지 중요한 것이 있다. modSlice(s) 에서의 s 변수 가 가리키는 주소와 modSlice(s []int) 함수에서 s 변수 가 가리키는 주소는 동일하다. (마치 포인터 처럼 동작한다) 하지만 s 변수 의 경우 modSlice 함수 통해 넘기는데 처음 생성할 때 길이:2, 크기:2 로 생성했다. 즉, 길이와 크기가 같아 modSlice 함수에서 append 로 item 을 추가할 경우 크기를 늘린 새로운 slice 를 만들어서 리턴 된다.

s = append(s, 3) 에서 s 가 가리키는 주소는 처음 modSlice(s []int) 일 때 가리키는 주소가 아니라 크기가 늘어나 새롭게 생성된 slice 를 가리키게 된다. 그래서 그 이전에 수정된 s 의 값은 변화가 있고, 그 이후에 수정된 s 의 값은 변화가 없다.

func main() {
  m := map[string]int{
		"one": 1,
		"two": 2,
	}
	modMap(m)
	fmt.Println(m)

	s := []int{1, 2}
	modSlice(s)
	fmt.Println(s)
}

// Call by Value but slice and map like pointer
func modMap(m map[string]int) {
	m["two"] = 20
	m["three"] = 3
	delete(m, "one")
}

func modSlice(s []int) {
	s[0] = s[0] * 10
	s = append(s, 3)  // 길이 == 크기 이므로 새로운 크기의 slice 가 만들어져서 리턴된다
	s[1] = s[1] * 10
}

--- output ---
map[three:3 two:20]
[10 2]

KServe 이 보다 더 쉬운 ML Model Serving 은 없다

seungkyua@gmail.com — Mon, 18 Jul 2022 20:11:44 +0900

MLOps 라고 불리는 s/w 가 여러개 있는데 그 중에서 Kubeflow 는 Kubernetes 기반의 MLOps 를 쉽게 구축할 수 있는 오픈 소스이다. 초창기 개발은 Google 이 주축이 되어 Arrikto 가 같이 참여하여 개발하는 형식이었는데 이제는 많은 글로벌 회사에서 같이 참여하여 점차 확대되고 있는 추세이다.

Kubeflow 는 Kubernetes 위에서만 돌아가기 때문에 Kubernetes 를 알아야 한다는 단점이 있지만, 일단 Kubernets 를 알고 있다면 설치가 아주 쉽다. 물론 그 안에 들어가는 컴포넌트들이 많고, MLOps 의 특성상 자동화는 workflow 를 잘 작성해서 pipeline 을 어떻게 구성하느냐가 중요하기 때문에 어려운 사용법을 익혀야 한다.

KServe 는 Kubeflow 의 여러 기능 중에서 ML Model Serving 에 해당하는 컴포넌트이며, 얼마전 kubeflow 내의 KFServe 컴포넌트 이었다가 독립적인 Add-Ons 으로 빠져 나오면서 KServe 로 이름을 바꾸고 자체 github repository 를 만들었다.

KServe Architecture

KServe 아키텍처는 다음과 같다.

[출처: https://www.kubeflow.org/docs/external-add-ons/kserve/kserve/]

그림과 같이 런타임으로 TensorFlow, PYTORCH, SKLearn, XGBoost, ONNX 등 다양한 모델 프레임워크를 지원하며 필요하면 커스텀 런타임을 만들어서 지원할 수 도 있다.

KServe 하단에는 Knative 와 Istio (Serverless Layer) 를 갖을 수 있는데 하단에는 다음과 같이 구성할 수 있다.

KServe + Knative + Istio
KServe + Istio

Knative 는 옵션이기는 하나 Knative 를 설치하면서 로깅 (fluentbit + ElasticSearch + Kibana), 모니터링 (Prometheus, Exporter), 트레이싱(Jaeger + ElasticSearch) 을 쉽게 연결할 수 있다는 장점이 있다. 또한 Istio 가 제공하는 Network 핸들링 기능을 쉽게 사용할 수 있다.

KServe 설치는 Istio 설치 → Knative 설치 → KServe 설치 순으로 진행하며, 이에 맞는 버전은 다음과 같다.

Recommended Version Matrix

Kubernetes Version	Istio Version	Knative Version
1.20	1.9, 1.10, 1.11	0.25, 0.26, 1.0
1.21	1.10, 1.11	0.25, 0.26, 1.0
1.22	1.11, 1.12	0.25, 0.26, 1.0

여기서는 Kubernetes 1.22 에 맞춰서 설치한다.

Istio 설치

Istio 는 Service Mesh 를 쉽게 구성가능하도록 지원하는 플랫폼으로 proxy 가 sidecar 형태로 추가되어 네트워크를 조절할 수 있다. 네트워크를 조절기능의 대표적인 것은 네트워크 쉬프팅이 있다. Canary Release 나 A/B Test 에서는 서로 다른 버전의 서비스로 호출되는 네트워크의 흐름 비중을 조절가능해야 한다.

이런 이유로 요즘 Service Mesh 는 Sidecar 활용 패턴을 사용하는데 Istio 에서는 서비스 배포 시에 Sidecar 를 자동으로 Injection 해주는 기능을 지원하고 있으며, 많은 곳에서 대부분 auto injeciton 을 사용하고 있다.

하지만 Knative 에서는 auto injection 을 사용하지 않는다. auto injection 은 kubernetes namespace 에 label 을 추가하여 (istio-injeciton=enabled) 자동으로 해당 namespace 에 배포되는 pod 에는 sidecar proxy 가 자동으로 설치되는 기능이라, Service Mesh 를 사용하고 싶지 않은 서비스들에게도 영향을 줄 수 있기 때문에 auto injection 을 disable 할 것을 권장하고 있다.

Istio 설치는 helm chart 로 쉽게 설치할 수 있다.

helm repo 를 추가하고 value 값을 오버라이드할 파일을 만든다.

$ helm repo add istio https://istio-release.storage.googleapis.com/charts
$ helm repo update

$ vi istiod_1.12.8_default_values.yaml
global:
  proxy:
        autoInject: disabled   # 원래 값은 enabled 임

Istio-system 네임스페이스를 생성한 후 helm chart 를 설치한다.

base 는 crd 를 설치하며, istiod 가 실제 데몬 서비스다.

$ kubectl create namespace istio-system
$ helm upgrade -i istio-base istio/base --version 1.12.8 -n istio-system -f istiod_1.12.8_default_values.yaml
$ helm upgrade -i istiod istio/istiod --version 1.12.8 -n istio-system -f istiod_1.12.8_default_values.yaml --wait

외부에서 서비스로 접근하기 위한 North - South 통신은 Istio Ingress Gateway 를 통해서 가능하다. 그러므로 Istio Gateway 를 추가로 설치해 준다.

먼저, value 값을 오버라이드할 파일을 만든다.

$ vi gateway_1.12.8_default_values.yaml
podAnnotations:
  prometheus.io/port: "15020"
  prometheus.io/scrape: "true"
  prometheus.io/path: "/stats/prometheus"
  inject.istio.io/templates: "gateway"
  sidecar.istio.io/inject: "true"

istio-ingress 네임스페이스를 생성하고 istio ingress gateway 를 helm chart로 설치한다.

$ kubectl create ns istio-ingress
$ helm upgrade -i istio-ingress istio/gateway --version 1.12.8 -n istio-ingress -f gateway_1.12.8_default_values.yaml

아래와 같이 잘 설치되어 있음을 확인할 수 있다.

$ kubectl get pods -n istio-system
NAME                      READY   STATUS    RESTARTS   AGE
istiod-68d7bfb6d8-nt82m   1/1     Running   0          20d

$ kubectl get pods -n istio-ingress
NAME                             READY   STATUS    RESTARTS   AGE
istio-ingress-69495c6667-7njv8   1/1     Running   0          20d

Knative 설치

Knative 는 Serverless 플랫폼이라 생각하면 된다. 서비스를 Istio 를 활용하여 배포하면 Gateway, VirtualServie 를 만들어서 연결해야 하는데 Knative 를 이를 자동으로 생성해주기 때문에 편리하다. 또한 앞에서도 설명한 모니터링, 로깅, 트레이싱이 잘 연결되기 때문에 일단 설치를 한다면 사용하기 편리하다.

Knative 는 설치 모듈이 Serving 과 Eventing 2개로 나눠져 있다. 일단 API 서비스가 가능한 Serving 모듈만 설치하고 테스트를 한다. 또한 모니터링, 로깅, 트레이싱도 다음에 설명하고 지금은 Knative Serving 기능에 집중한다.

Knative 는 Yaml 과 Operator 로 설치할 수 있는데 공식 문서에서 Operator 는 개발/테스트 환경에서만 사용하라고 권고하기 때문에 yaml 로 설치한다.

먼저, crd 를 설치하고, Serving 모듈을 설치한다.

$ kubectl apply -f https://github.com/knative/serving/releases/download/knative-v1.5.0/serving-crds.yaml
--- output ---
customresourcedefinition.apiextensions.k8s.io/certificates.networking.internal.knative.dev created
customresourcedefinition.apiextensions.k8s.io/configurations.serving.knative.dev created
customresourcedefinition.apiextensions.k8s.io/clusterdomainclaims.networking.internal.knative.dev created
customresourcedefinition.apiextensions.k8s.io/domainmappings.serving.knative.dev created
customresourcedefinition.apiextensions.k8s.io/ingresses.networking.internal.knative.dev created
customresourcedefinition.apiextensions.k8s.io/metrics.autoscaling.internal.knative.dev created
customresourcedefinition.apiextensions.k8s.io/podautoscalers.autoscaling.internal.knative.dev created
customresourcedefinition.apiextensions.k8s.io/revisions.serving.knative.dev created
customresourcedefinition.apiextensions.k8s.io/routes.serving.knative.dev created
customresourcedefinition.apiextensions.k8s.io/serverlessservices.networking.internal.knative.dev created
customresourcedefinition.apiextensions.k8s.io/services.serving.knative.dev created
customresourcedefinition.apiextensions.k8s.io/images.caching.internal.knative.dev created

$ kubectl apply -f https://github.com/knative/serving/releases/download/knative-v1.5.0/serving-core.yaml
--- output ---
namespace/knative-serving created
clusterrole.rbac.authorization.k8s.io/knative-serving-aggregated-addressable-resolver created
clusterrole.rbac.authorization.k8s.io/knative-serving-addressable-resolver created
clusterrole.rbac.authorization.k8s.io/knative-serving-namespaced-admin created
clusterrole.rbac.authorization.k8s.io/knative-serving-namespaced-edit created
clusterrole.rbac.authorization.k8s.io/knative-serving-namespaced-view created
clusterrole.rbac.authorization.k8s.io/knative-serving-core created
clusterrole.rbac.authorization.k8s.io/knative-serving-podspecable-binding created
serviceaccount/controller created
clusterrole.rbac.authorization.k8s.io/knative-serving-admin created
clusterrolebinding.rbac.authorization.k8s.io/knative-serving-controller-admin created
clusterrolebinding.rbac.authorization.k8s.io/knative-serving-controller-addressable-resolver created
customresourcedefinition.apiextensions.k8s.io/images.caching.internal.knative.dev unchanged
customresourcedefinition.apiextensions.k8s.io/certificates.networking.internal.knative.dev unchanged
customresourcedefinition.apiextensions.k8s.io/configurations.serving.knative.dev unchanged
customresourcedefinition.apiextensions.k8s.io/clusterdomainclaims.networking.internal.knative.dev unchanged
customresourcedefinition.apiextensions.k8s.io/domainmappings.serving.knative.dev unchanged
customresourcedefinition.apiextensions.k8s.io/ingresses.networking.internal.knative.dev unchanged
customresourcedefinition.apiextensions.k8s.io/metrics.autoscaling.internal.knative.dev unchanged
customresourcedefinition.apiextensions.k8s.io/podautoscalers.autoscaling.internal.knative.dev unchanged
customresourcedefinition.apiextensions.k8s.io/revisions.serving.knative.dev unchanged
customresourcedefinition.apiextensions.k8s.io/routes.serving.knative.dev unchanged
customresourcedefinition.apiextensions.k8s.io/serverlessservices.networking.internal.knative.dev unchanged
customresourcedefinition.apiextensions.k8s.io/services.serving.knative.dev unchanged
image.caching.internal.knative.dev/queue-proxy created
configmap/config-autoscaler created
configmap/config-defaults created
configmap/config-deployment created
configmap/config-domain created
configmap/config-features created
configmap/config-gc created
configmap/config-leader-election created
configmap/config-logging created
configmap/config-network created
configmap/config-observability created
configmap/config-tracing created
horizontalpodautoscaler.autoscaling/activator created
poddisruptionbudget.policy/activator-pdb created
deployment.apps/activator created
service/activator-service created
deployment.apps/autoscaler created
service/autoscaler created
deployment.apps/controller created
service/controller created
deployment.apps/domain-mapping created
deployment.apps/domainmapping-webhook created
service/domainmapping-webhook created
horizontalpodautoscaler.autoscaling/webhook created
poddisruptionbudget.policy/webhook-pdb created
deployment.apps/webhook created
service/webhook created
validatingwebhookconfiguration.admissionregistration.k8s.io/config.webhook.serving.knative.dev created
mutatingwebhookconfiguration.admissionregistration.k8s.io/webhook.serving.knative.dev created
mutatingwebhookconfiguration.admissionregistration.k8s.io/webhook.domainmapping.serving.knative.dev created
secret/domainmapping-webhook-certs created
validatingwebhookconfiguration.admissionregistration.k8s.io/validation.webhook.domainmapping.serving.knative.dev created
validatingwebhookconfiguration.admissionregistration.k8s.io/validation.webhook.serving.knative.dev created
secret/webhook-certs created

다음은 Isito 와 연동하기 위한 network 들을 설치한다.

$ kubectl apply -f https://github.com/knative/net-istio/releases/download/knative-v1.5.0/net-istio.yaml

그대로 설치하면 Isito gateway 와 연동되지 않는다. 그렇기 때문에 아래와 같이 selector 를 수정해 줘야 한다.

$ kubectl edit gateway -n knative-serving knative-ingress-gateway
...
spec:
  selector:
    istio: ingressgateway
    istio: ingress          # 추가

$ kubectl edit gateway -n knative-serving knative-local-gateway
...
spec:
  selector:
    istio: ingressgateway
    istio: ingress          # 추가

Istio 의 Ingress gateway 앞단에는 LoadBalancer 가 연결되어 있다. LoadBalancer 가 External IP 로 연결되어 있으면 IP 를 dns 로 연결해 주는 magic dns (sslip.io) 를 사용할 수 있고, LoadBalancer 가 domain name 으로 연결되어 있으면 실제 DNS 에 CNAME 을 등록하여 연결하면 된다.

$ kubectl get svc -n istio-ingress
NAME            TYPE           CLUSTER-IP       EXTERNAL-IP 
istio-ingress   LoadBalancer   10.107.111.229   xxxxx.ap-northeast-2.elb.amazonaws.com

여기서는 aws 를 사용하고 있기 때문에 Route53 에 CNAME 을 등록하였다.

서비스 도메인: helloworld-go-default.taco-cat.xyz
target: xxxxx.ap-northeast-2.elb.amazonaws.com
type: CNAME

Knative ConfigMap 설정

마지막으로 Knative ConfigMap 에 기본 도메인과 full 도메인 설정을 세팅한다.

이 설정은 앞서 Route53 에 등록한 서비스 도메인과 같은 형식으로 설정되게 구성해야 한다.

## Domain: taco-cat.xyz
$ kubectl edit cm config-domain -n knative-serving
apiVersion: v1
data:
  taco-cat.xyz: ""
kind: ConfigMap
[...]

## Name: helloworld-go
## Namesapce: default
## Domain: taco-cat.xyz
$ kubectl edit cm config-network -n knative-serving
apiVersion: v1
data:
  domain-template: "{{.Name}}-{{.Namespace}}.{{.Domain}}"

Knative sample 배포 테스트

Knative 에서 제공하는 helloworld-go 샘플 프로그램을 배포해 보자.

서비스 이름이 helloworld-go, Namespace 가 default 로 앞서 Route53 및 ConfigMap 에 설정한 도메인 형식과 동일함을 할 수 있다.

$ git clone https://github.com/knative/docs knative-docs
$ cd knative-docs/code-samples/serving/hello-world/helloworld-go

$ vi service.yaml
apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: helloworld-go
  namespace: default
spec:
  template:
    spec:
      containers:
      - image: gcr.io/knative-samples/helloworld-go
        env:
        - name: TARGET
          value: "Go Sample v1"

$ kubectl apply -f service.yaml

배포가 제대로 되었는지 확인해 보자.

$ kubectl get route
NAME            URL                                         READY   REASON
helloworld-go   http://helloworld-go-default.taco-cat.xyz   True

Knative 는 zero replicas 를 사용한다

Serverless 를 어떻게 구현했을까? 사실 Knative 는 Kubernetes 의 zero replicas 를 사용했다.

배포 후에 deployment 를 조회하면 아래과 같이 Ready 와 Available 이 0 상태임을 알 수 있다.

$ kubectl get deploy
NAME                                       READY   UP-TO-DATE   AVAILABLE   AGE
helloworld-go-00001-deployment             0/0     0            0           10d

배포도 잘되고 Route53 에 dns 도 어느 정도 시간이 지났다면 브라우저 혹은 curl 로 확인할 수 있다.

$ curl http://helloworld-go-default.taco-cat.xyz
--- output ---
Hello Go Sample v1!

이렇게 요청이 들어오면 실제로 pod 가 실행되고 있음을 알 수 있다. 1분 동안 아무런 요청이 없으면 pod 는 다시 사라지고 대기 상태가 된다. (요청이 없더라도 중간에 다시 pod 가 생겨서 실제로는 일정 시간 동안 새로운 pod 로 교체된다)

$ kubectl get deploy
NAME                                       READY   UP-TO-DATE   AVAILABLE   AGE
helloworld-go-00001-deployment             1/1     1            1           10d

TLS 인증서 적용

인증서를 가지고 있다면 gateway 에 tls 를 적용하여 tls termination 을 할 수 있다.

아래는 istio-ingress 네임스페이스에 secret 으로 taco-cat-tls 인증서를 설치한 후 gateway 에서 해당 인증서를 읽을 수 있도록 tls 를 추가한 부분이다.

$ kubectl edit gateway knative-ingress-gateway -n knative-serving
...
spec:
  selector:
    istio: ingress
  servers:
  - hosts:
    - '*'
    port:
      name: http
      number: 80
      protocol: HTTP
  - hosts:
    - '*.taco-cat.xyz'
    port:
      name: https
      number: 443
      protocol: HTTPS
    ## tls 추가
    tls:
      mode: SIMPLE
      credentialName: taco-cat-tls

HPA 설치

서비스에 요청이 신규로 들어오거나, 많아지면 replicas 수를 조절하여 pod 를 실행해주는 activator 가 있다. 이 activator 를 auto scaling 하는 hpa 를 설치한다.

$ kubectl apply -f https://github.com/knative/serving/releases/download/knative-v1.5.0/serving-hpa.yaml

hpa 를 조회해서 확인할 수 있다.

$ kubectl get hpa -n knative-serving
NAME        REFERENCE              TARGETS   MINPODS   MAXPODS   REPLICAS   AGE
activator   Deployment/activator   0%/100%   1         20        1          13d
webhook     Deployment/webhook     3%/100%   1         5         1          13d

KServe 설치

KServe 는 이제 막 Helm chart 가 만들어지고 있다. 그렇기 때문에 일단은 yaml 로 설치를 진행한다.

먼저 KServe 컴포넌트를 설치하고 이어서 각종 ML Framework 를 나타내는 Runtime을 설치한다.

$ kubectl apply -f https://github.com/kserve/kserve/releases/download/v0.8.0/kserve.yaml
--- output ---
namespace/kserve created
customresourcedefinition.apiextensions.k8s.io/clusterservingruntimes.serving.kserve.io created
customresourcedefinition.apiextensions.k8s.io/inferenceservices.serving.kserve.io created
customresourcedefinition.apiextensions.k8s.io/servingruntimes.serving.kserve.io created
customresourcedefinition.apiextensions.k8s.io/trainedmodels.serving.kserve.io created
serviceaccount/kserve-controller-manager created
role.rbac.authorization.k8s.io/leader-election-role created
clusterrole.rbac.authorization.k8s.io/kserve-manager-role created
clusterrole.rbac.authorization.k8s.io/kserve-proxy-role created
rolebinding.rbac.authorization.k8s.io/leader-election-rolebinding created
clusterrolebinding.rbac.authorization.k8s.io/kserve-manager-rolebinding created
clusterrolebinding.rbac.authorization.k8s.io/kserve-proxy-rolebinding created
configmap/inferenceservice-config created
configmap/kserve-config created
secret/kserve-webhook-server-secret created
service/kserve-controller-manager-metrics-service created
service/kserve-controller-manager-service created
service/kserve-webhook-server-service created
statefulset.apps/kserve-controller-manager created
certificate.cert-manager.io/serving-cert created
issuer.cert-manager.io/selfsigned-issuer created
mutatingwebhookconfiguration.admissionregistration.k8s.io/inferenceservice.serving.kserve.io created
validatingwebhookconfiguration.admissionregistration.k8s.io/inferenceservice.serving.kserve.io created
validatingwebhookconfiguration.admissionregistration.k8s.io/trainedmodel.serving.kserve.io created

$ kubectl apply -f https://github.com/kserve/kserve/releases/download/v0.8.0/kserve-runtimes.yaml
--- output---
clusterservingruntime.serving.kserve.io/kserve-lgbserver created
clusterservingruntime.serving.kserve.io/kserve-mlserver created
clusterservingruntime.serving.kserve.io/kserve-paddleserver created
clusterservingruntime.serving.kserve.io/kserve-pmmlserver created
clusterservingruntime.serving.kserve.io/kserve-sklearnserver created
clusterservingruntime.serving.kserve.io/kserve-tensorflow-serving created
clusterservingruntime.serving.kserve.io/kserve-torchserve created
clusterservingruntime.serving.kserve.io/kserve-tritonserver created
clusterservingruntime.serving.kserve.io/kserve-xgbserver created

KServe 설치를 확인한다.

$ kubectl get pod -n kserve
NAME                          READY   STATUS    RESTARTS   AGE
kserve-controller-manager-0   2/2     Running   0          7d10h

Rumtime 도 설치되었는지 확인한다.

$ kubectl get clusterservingruntimes
NAME                        DISABLED   MODELTYPE    CONTAINERS         AGE
kserve-lgbserver                       lightgbm     kserve-container   7d10h
kserve-mlserver                        sklearn      kserve-container   7d10h
kserve-paddleserver                    paddle       kserve-container   7d10h
kserve-pmmlserver                      pmml         kserve-container   7d10h
kserve-sklearnserver                   sklearn      kserve-container   7d10h
kserve-tensorflow-serving              tensorflow   kserve-container   7d10h
kserve-torchserve                      pytorch      kserve-container   7d10h
kserve-tritonserver                    tensorrt     kserve-container   7d10h
kserve-xgbserver                       xgboost      kserve-container   7d10h

Sample model 을 KServe 를 활용하여 배포

tensorflow 로 개발된 mnist 샘플 모델을 KServe 로 배포해 보자.

KServe 는 model in load 패턴을 적용하여 인퍼런스 서비스를 수행한다. 아래에서는 모델이 gs 에 저장되어 있으면 이를 가져와서 서빙하는 구조이다.

runtime 은 앞서 설치한 clusterservingruntime 중에 하나인 kserve-tensorflow-serving 이고 버전이 2 임을 알 수 있다.

$ vi mnist_tensorflow.yaml
---
apiVersion: "serving.kserve.io/v1beta1"
kind: "InferenceService"
metadata:
  name: "mnist"
spec:
  predictor:
    model:
      modelFormat:
        name: tensorflow
        version: "2"
      storageUri: "gs://kserve/models/mnist"
      runtime: kserve-tensorflow-serving
    logger:
      mode: all

$ kubectl apply -f mnist_tensorflow.yaml

서빙 배포 확인은 다음과 같다.

KServe 에서 도메인을 만들 때 namespace 를 추가로 붙히기 때문에 도메인이 아래와

$ kubectl get isvc
NAME    URL     READY   PREV   LATEST   PREVROLLEDOUTREVISION  LATESTREADYREVISION
mnist   http://mnist-default.taco-cat.xyz   True           100 mnist-predictor-default-00001

$ kubectl get route
NAME                      URL                                                   READY   REASON
mnist-predictor-default   http://mnist-predictor-default-default.taco-cat.xyz   True

Route53 에 도메인을 추가한다.

서비스 도메인: mnist-predictor-default-default.taco-cat.xyz
target: xxxxx.ap-northeast-2.elb.amazonaws.com
type: CNAME

아래와 같이 요청하여 결과값이 제대로 나오는지 확인한다.

$ curl https://mnist-predictor-default-default.taco-cat.xyz/v1/models/mnist:predict \
   -H 'Content-Type: application/json' \
   -d @mnist.json
--- output ---
{
    "predictions": [[3.2338352e-09, 1.66207215e-09, 1.17224181e-06, 0.000114716699, 4.34008705e-13, 4.64885304e-08, 3.96761454e-13, 0.999883413, 1.21785089e-08, 6.44099089e-07]
    ]
}

( go-05) Go Struct

seungkyua@gmail.com — Sat, 9 Jul 2022 17:38:15 +0900

Slice 와 Map 은 값을 여러개 자질 수 있는 타입이다. 그러나 선언한 타입과 같은 타입만 저장해야 하는 문제가 있다. 또한 class 와 같이 다양한 멤버 변수를 가질 수 없다.

그래서 Go 에서는 다양한 값을 가질 수 있도록 Struct 타입을 지원한다.

Struct

struct 의 를 만들려면 type 키워드, struct명, struct 키워드로 만든다. 그리고 그 안에 다양한 변수를 포함할 수 있으며 {} 로 묶어주면 된다.

type 으로 struct 를 선언했으면 그 자체가 하나의 type 이 된다. 그럼 var 로 새로운 만든 type을 활용하여 변수 선언을 할 수 있다. 아래와 같이 name 과 age 를 필드로 갖는 person 이라는 새로운 타입을 선언하고 jina 와 jamie 라는 변수를 만들 수 있다.

변수 선언만 한 struct 내의 필드들은 zero 값을 갖는다.

person 타입의 변수를 초기화 할 때는 {} 로 초기화 할 수 도 있다.

package main

import "fmt"

func main() {
	type person struct {
		name string
		age  int
	}

	var jina person
	fmt.Println(jina)

	jamie := person{}
	fmt.Println(jamie)
}

--- output ---
{ 0}
{ 0}

혹은 값을 지정하여 초기화 할 수 있다.

값을 지정하여 초기화할 때는 json 타입으로 변수: 값 으로 지정하거나 값 으로 지정할 수 있다. 변수 사이는 , 로 구분하며, 마지막 변수 끝에도 , 를 넣어야 한다.

Go 에서는 타입을 선언할 때는 { 앞에 공백을 넣지만, 값을 초기화할 때는 { 앞에 공백을 넣지 않는다. 또한 타입을 선언할 때는 필드 사이에 , 가 없지만, 값을 초기화 할 때는 필드값 사이에 , 를 넣는다.

jina := person{
	name: "Jina",
	age:  21,
}
fmt.Println(jina)

jamie := person{
	"Jamie",
	18,
}
fmt.Println(jamie)

--- output ---
{Jina 21}
{Jamie 18}

초기화는 아래와 같이 할 수 도 있다.

단, jina[”age”] 와 같이 인덱싱을 통한 접근은 지원하지 않는다.

var jina person
jina.name = "Jina"
jina.age = 21
// jina["age"] = 21  // 인덱싱은 지원하지 않음

fmt.Println(jina.name)

--- output ---
Jina

Anonymous struct

type 이 없는 struct 도 가능하다.

이 때는 type 키워드를 쓰지 않는다.

아래와 같이 바로 jina 라는 변수를 struct 형태로 지정하고 . 을 통해 값을 지정할 수 있다. 혹은 {} 를 사용하여 jamie 변수를 선언하면서 초기 값을 지정할 수 있다.

var jina struct {
		name string
		age  int
}

jina.name = "Jina"
jina.age = 21
fmt.Println(jina)

jamie := struct {
	name string
	age  int
}{
	name: "Jamie",
	age:  18,
}
fmt.Println(jamie)

--- output ---
{Jina 21}
{Jamie 18}

Struct 비교

go 에서는 type 이 같으면 대입(=), 비교(==) 를 할 수 있다. 하지만 type 이 다르면 비교나 대입을 할 수 없다.

하지만 type 을 convert 하여 맞춰 준다면 대입, 비교가 가능하다.

jina 와 jina2 는 type 이 같고 필드 값도 같다. 그래서 비교를 하면 true 값이 나온다.

하지만 jamie 는 jina 와 type 이 같지만 필드 값이 달라서 비교를 하면 false 값이 나온다.

jina := person{
	name: "Jina",
	age:  21,
}

jina2 := person{
	name: "Jina",
	age:  21,
}
fmt.Println(jina == jina2)

jamie := person{
	name: "Jamie",
	age:  18,
}
fmt.Println(jina == jamie)

--- output ---
true
false

새로운 anotherPerson type 을 만들어서 살펴보자.

아래와 같이 jina 는 person type 이고 jamie 는 anotherPerson type 이므로 서로 type 이 달라서 비교나 대입을 하면 에러가 난다.

type anotherPerson struct {
	name string
	age  int
}

jina := person{
	name: "Jina",
	age:  21,
}
fmt.Println(jina)

jamie := anotherPerson{
	name: "Jamie",
	age:  18,
}

fmt.Println(jina == jamie)

--- output ---
./main.go:88:19: invalid operation: jina == jamie (mismatched types person and anotherPerson)

이번에는 jamie 를 person type 으로 바꾸는 type converson 을 하여 비교하여 보자.

타입 변환도 잘 되고 값도 정상적으로 대입되는 것을 알 수 있다.

type anotherPerson struct {
	name string
	age  int
}

jina := person{
	name: "Jina",
	age:  21,
}
fmt.Println(jina)

jamie := anotherPerson{
	name: "Jamie",
	age:  18,
}

jina = person(jamie)
fmt.Println(jina)

--- output ---
{Jina 21}
{Jamie 18}

한가지 중요한 점은 struct 사이에 타입 변환은 타입, 필드명, 필드 순서, 필드 갯수 가 모두 동일해야 가능하다.

그럼 type 으로 선언된 struct 와 anonymous struct 는 타입을 제외한 필드명, 필드 순서, 필드 갯수 가 같다면 대입이나 비교, 타입 변환이 가능할까?

정답은 가능하다이다.

jina := person{
	name: "Jina",
	age:  21,
}
fmt.Println(jina)

var jamie struct {
	name string
	age  int
}

jamie = jina
fmt.Println(jina == jamie)

--- output ---
{Jina 21}
true

jamie := struct {
	name string
	age  int
}{
	name: "Jamie",
	age:  18,
}

var jina person

jina = person(jamie)
fmt.Println(jina)
fmt.Println(jina == jamie)

--- output --
{Jamie 18}
true

사실 person(jamie) 로 타입 변환을 하지 않아도 정상적으로 동작한다.

(go-04) Go Map 타입

seungkyua@gmail.com — Thu, 30 Jun 2022 20:55:25 +0900

Map 은 key, value 로 저장할 수 있는 타입이다. HashMap 을 사용하기 때문에 key 는 유일한 값으로 key 를 사용하면 value 를 바로 찾아서 쓸 수 있다.

앞서 slice 와 동일하게 zero 값은 nil 이다. 그러므로 map 변수를 선언만 하면 nil 값으로 비교할 수 있다. slice 는 nil 값이라도 append 를 사용하면 값을 추가하면서 새로운 slice 가 생성되어 return 되었다. 하지만 map 은 nil 값에는 어떠한 key, value 도 추가할 수 있다.

Map

map 은 key, value 쌍으로 이루어진 데이터 구조이다. 파이썬에서는 dictionary 와 비슷하다고 생각하면 된다. 단지 다른 것은 하나의 map 에는 사전에 지정된 타입의 key, value 만 저장될 수 있다.

다음은 string 타입을 key 로하고 int 를 value 로 저장하는 map 을 선언한 것이다. map[key타입]value타입 으로 선언할 수 있다.

이렇게 선언만 한 map 변수의 zero 값은 nil 이다.

var m map[string]int
fmt.Println(m == nil)

--- output ---
true

이렇게 nil 값이 상태의 map 에는 key, value 를 추가할 수 없다(slice 와는 다르다).

var m map[string]int
m["one"] = 0

--- output ---
panic: assignment to entry in nil map

아래와 같이 empty map 을 생성할 수 있으며, 여기에는 key, value 를 추가할 수 있다.

var m1 = map[string]int{}
fmt.Println(m1 == nil)
m1["one"] = 0
fmt.Println(m1)

--- output ---
false
map[one:0]

초기 값을 아래와 같이 생성할 수 도 있다. 초기화 할 때 key, 와 value 는 : 로 구분하고 연속적으로 key, value 를 입력하기 위해서는 , 구분자를 사용한다.

m2 := map[string]int{
    "one":  1,
    "two": 2,
}
fmt.Println(m2)

--- output ---
map[one:1 two:2]

make 함수

slice 와 동일하게 make 내장 함수를 사용하여 empty map 을 생성할 수 있다. 이렇게 생성된 map 은 길이는 0, 사이즈는 5 가 되고, 길이가 사이즈 보다 커질 때에도 사이즈가 확장되어 key, value 를 추가할 수 있다. (사이즈 확장은 때에 따라 성능 감소의 요인이 될 수 있다)

출력 결과와 같이 map 에 추가된 key, value 는 순서가 없다.

m := make(map[string]int, 5)
fmt.Println(len(m))

m["one"] = 1
m["two"] = 2
m["three"] = 3
m["four"] = 4
m["five"] = 5
fmt.Println(m, len(m))

m["six"] = 6
fmt.Println(m, len(m))

--- output ---
0
map[five:5 four:4 one:1 three:3 two:2] 5
map[five:5 four:4 one:1 six:6 three:3 two:2] 6

comma ok idiom

map 에서 없는 key 값으로 value 를 요청하면 value 타입의 zero 값이 리턴된다. 즉 에러가 발생하지 않는다.

m := map[string]int{
    "one": 1,
    "two": 2,
}
fmt.Println(m["three"])

--- output ---
0

그렇기 때문에 해당 key 값의 value 가 제대로 넘어왔는지 알 수 있게 , 로 구분되어 value 와 boolen 값이 리턴된다.

m := map[string]int{
    "one": 1,
    "two": 2,
}

v, ok := m["one"]
fmt.Println(v, ok)

v, ok = m["three"]
fmt.Println(v, ok)

--- output ---
1 true
0 false

map 의 item 을 삭제하려면 delete 내장 함수 를 사용한다. delete 함수에 첫번째 아규먼트에는 map 을, 두번째 아규먼트에는 key 를 넣으면 된다. 해당 key 가 map 에 없다고 해서 에러를 만들지는 않는다.

m := map[string]int{
    "one": 1,
    "two": 2,
}

delete(m, "one")
fmt.Println(m)
delete(m, "three")

--- output ---
map[two:2]

map 의 key 는 중복될 수 없다. key, value 를 추가하는데 기존의 map 에 key 가 존재한다면, key 에 해당 하는 value 값이 업데이트 된다.

Go 에는 Set 타입이 없는데 참고로 key 가 중복될 수 없다는 이 특징을 잘 활용하면 Set 을 구현할 수 있다.

m := map[string]int{
    "one": 1,
    "two": 2,
}
m["two"] = 3
fmt.Println(m)

--- output ---
map[one:1 two:3]

(go-03) Go Slice 타입

seungkyua@gmail.com — Thu, 30 Jun 2022 19:32:53 +0900

기본 내장 타입에 추가하여 Array, Slice, Map 타입에 대해서 살펴본다.

Go 에서는 Array 는 거의 사용하지 않는다. 그러므로 이번에는 Slice 와 Map 타입에 대해서만 살펴 본다.

참고로 Go 에서는 nil 이라는 값이 있다. 이는 값이 없다라는 뜻인데, 기본 타입에는 이 nil 과의 비교문 (==)을 쓸 수 없다. (이전에 기본 타입은 전부 zero 값이 nil 이 아니다.)

**nil 과 비교문이 가능한 타입은 앞으로 설명할 slice, map, pointer 이며, 이 3개의 zero 값이 nil 이다.**

Slice

slice 는 값을 순차적으로 가질 수 있는 데이터 구조이다. 파이썬에서는 list 와 비슷하다고 생각하면 된다. 단지 다른 것은 하나의 slice 에는 사전에 지정된 타입만 저장될 수 있다.

다음은 int 타입을 slice 저장 한 후에 출력한 결과이다. [] 는 slice 를 만들겠다는 의미이고, 바로 이어서 type 이 오며, 초기값을 지정하기 위해서 { } 를 사용한다.

var s = []int{1, 2, 3, 4, 5}
fmt.Println(s)

--- output ---
[1 2 3 4 5]

slice 는 초기화 값을 지정하지 않으면 nil 을 나타낸다. 즉, 변수 선언만 하면 항상 nil 값을 갖게 된다. len 과 cap 을 사용하면 slice 가 가지가 있는 길이와 용량을 알 수 있다.

Slice 는 연속적인 값을 가지고 있는 메모리 주소인 포인터, 길이, 용량 으로 구성되어 있다. (이 부분은 매우 중요하다.)

길이는 실제 들어있는 값이고 용량은 해당 값을 가질 수 있는 크기라고 할 수 있다.

아래 s1 은 nil 값이기 때문에 len 과 cap 이 모두 0 이다.

var s1 []int
fmt.Println(s1 == nil)
fmt.Println(len(s1), cap(s1))

--- output ---
true
0 0

슬라이스는 배열처럼 사용하여 s1[0] 첫번째 값을 가져올 수 있다.

하지만 선언만 하여 nil 인 상태에서는 해당 index 를 사용하게 되면 런타임 에러가 난다.

var s1 []int
fmt.Println(s1[0])

--- output ---
panic: runtime error: index out of range [0] with length 0

s1 slice 가 nil 인 상태에서도 append 내장 함수를 사용하면 값을 추가할 수 있다(그렇기 때문에 특별한 경우를 제외하고는 nil 값인 변수 선언만 하여 사용하면 된다). append 함수를 쓰면 nil 이라 하더라도 slice 에 값을 추가 할 수 있다. 물론 값이 추가된 결과 return 값은 변수에 할당해야 한다. (변수가 달라도 됨)

var s1 []int
s1 = append(s1, 1)
fmt.Println(s1)

--- output ---
[1]

slice 에 slice 를 합쳐서 추가할 수 있다. python 의 extend 와 비슷하다고 보면된다. 두번째 slice 에는 여러 아규먼트가 들어간다는 것을 표현해 주기 위해서 ... 을 붙혀야 한다.

var s1 []int
s1 = append(s1, 1)

s2 := []int{2, 3, 4, 5}
s1 = append(s1, s2...)  // append(s1, 2, 3, 4, 5) 와 동일함
fmt.Println(s1)

slice 는 값이 추가되어 길이가 커져서 용량에 도달하면 용량이 자동으로 확장된다.

var s []int
fmt.Println(s, len(s), cap(s))
s = append(s, 1)
fmt.Println(s, len(s), cap(s))
s = append(s, 2)
fmt.Println(s, len(s), cap(s))
s = append(s, 3)
fmt.Println(s, len(s), cap(s))
s = append(s, 4)
fmt.Println(s, len(s), cap(s))
s3 := append(s, 5)
fmt.Println("s:", s, len(s), cap(s))
fmt.Println("s3", s3, len(s3), cap(s3))

-- output ---
[] 0 0
[1] 1 1
[1 2] 2 2
[1 2 3] 3 4
[1 2 3 4] 4 4
s: [1 2 3 4] 4 4
s3 [1 2 3 4 5] 5 8

make 내장 함수

slice 와 map 에서 make 내장 함수를 사용하면 nil 이 아닌 empty slice 를 만들 수 있다. make 함수의 첫번째 아큐먼트는 slice type, 두번째는 길이, 세번째는 용량이다. 세번째 용량은 생략이 가능하다.

아래 make 로 생성한 s 는 nil 과의 비교가 false 임을 알 수 있다.

s := make([]int, 0, 5)
fmt.Println(s == nil)
fmt.Println(s, len(s), cap(s))

--- output ---
false
[] 0 5

make 로 길이를 지정하면 그 길이 만큼은 zero 값이 채워진 slice 가 만들어 진다. 그러니 필요없이 길이를 1 이상으로 지정하면 초기 메모리만 차지할 수 있다. 아래는 make 로 만든 s1 slice 에 0번째와 1번째 index 까지 0 값이 채워진 것을 볼 수 있다.

s1 := make([]int, 2)
fmt.Println(s1)

s1 = append(s1, 1)
fmt.Println(s1)

--- output ---
[0 0]
[0 0 1]

길이가 0 인 slice 는 아래와 같이 만들 수 도 있다. nil 이 아니면서 길이가 0 인 slice 는 JSON 으로 변환할 때 사용된다.

var s = []int{}   // make([]int, 0) 와 동일하다.

Slice 자르기

Slice 를 자르는 것은 : 을 이용해서 자를 수 있다. 하지만 자른다고 해도 최종적으로 보는 Reference 는 동일하다. 아래를 보면 이를 이해할 수 있다.

첫번째 단락에서 slice 를 자르면, b 는 0 index 이상, 3 index 미만 까지의 slice 를 갖고, c 는 2 index 이상 끝까지의 slice 값을 갖는다. 중요한 것은 c 처럼 중간에서 마지막까지 자른 slice 는 용량이 그 길이만큼으로 줄어든다는 것이다. (앞의 자른 부분이 없어졌기 때문이다)

두번째 단락에서 c[0] 에 30 을 대입하면 slice 자른 것은 같은 reference 를 바라보기 때문에 a 와 b 에 모두 영향을 준다.

세번째 단락도 마찬가지 이다.

a := []int{1, 2, 3, 4, 5}
b := a[:3]
c := a[2:]
fmt.Println("cap(a):", cap(a), "cap(b):", cap(b), "cap(c):", cap(c))
fmt.Println("a:", a)
fmt.Println("b:", b)
fmt.Println("c:", c)
fmt.Println("================")

c[0] = 30
fmt.Println("a:", a)
fmt.Println("b:", b)
fmt.Println("c:", c)
fmt.Println("================")

b = append(b, 40)
fmt.Println("a:", a)
fmt.Println("b:", b)
fmt.Println("c:", c)

--- output ---
cap(a): 5 cap(b): 5 cap(c): 3
a: [1 2 3 4 5]
b: [1 2 3]
c: [3 4 5]
================
a: [1 2 30 4 5]
b: [1 2 30]
c: [30 4 5]
================
a: [1 2 30 40 5]
b: [1 2 30 40]
c: [30 40 5]

Slice 를 자른 것이 append 를 사용해서 추가할 때 같은 레퍼런스를 처다보지 않게 하려면, 용량을 길이와 동일하게 하면 된다. 그러면 append 했을 경우 용량이 초과되어 새로운 slice 가 생겨서 return 되므로 서로 영향이 가지 않는다.

아래 처럼 a 를 잘라서 b 를 만들 때 :3:3 과 같이 마지막에 용량 3을 추가하여 b slice 의 길이와 용량을 똑같이 맞췄다. 그렇게 되면 c[0] 처럼 값을 바꾸는 것은 영향을 받지만, append(b, 40) 과 같이 append 한 것은 새로운 slice 가 만들어져서 return 되므로 a 와 c 에 영향을 주지 않는다.

a := []int{1, 2, 3, 4, 5}
b := a[:3:3]
c := a[2:]
fmt.Println("cap(a):", cap(a), "cap(b):", cap(b), "cap(c):", cap(c))
fmt.Println("a:", a)
fmt.Println("b:", b)
fmt.Println("c:", c)

fmt.Println("===== (c[0] = 30) =====")
c[0] = 30
fmt.Println("cap(a):", cap(a), "cap(b):", cap(b), "cap(c):", cap(c))
fmt.Println("a:", a)
fmt.Println("b:", b)
fmt.Println("c:", c)

fmt.Println("===== append(b, 40) ======")
b = append(b, 40)
b[0] = 10
fmt.Println("cap(a):", cap(a), "cap(b):", cap(b), "cap(c):", cap(c))
fmt.Println("a:", a)
fmt.Println("b:", b)
fmt.Println("c:", c)


--- output ---
cap(a): 5 cap(b): 3 cap(c): 3
a: [1 2 3 4 5]
b: [1 2 3]
c: [3 4 5]
===== (c[0] = 30) =====
cap(a): 5 cap(b): 3 cap(c): 3
a: [1 2 30 4 5]
b: [1 2 30]
c: [30 4 5]
===== append(b, 40) ======
cap(a): 5 cap(b): 6 cap(c): 3
a: [1 2 30 4 5]
b: [10 2 30 40]
c: [30 4 5]
c: [30 4 5]
===== append(b, 40) ======
a: [1 2 30 4 5]
b: [1 2 30 40]
c: [30 4 5]

(go-02) Go 기본 타입 설명

seungkyua@gmail.com — Thu, 30 Jun 2022 09:30:55 +0900

C 와 Java 를 안다면 Go 를 공부하면 헷갈리는 부분들이 다소 있다. 일반적으로 기본 내장 타입은 비슷해서 이해하기 쉽지만 pointer 와 interface 등을 공부하다 보면 헷갈리기 마련이다.

일단 먼저 기본 타입에 대해서 설명한다.

Built-in Type

기본 내장 타입에는 boolean, integer, rune, float, byte, string 이 있다. 물론 complex type 도 있지만 이는 생략하겠다. 기본 내장 타입은 zero 값을 갖고 있다.

이 중에서 숫자 타입은 integer, rune, float 이다.

boolean

boolean 의 zero 값은 false 이다.

var isDev bool
var isTrue = true

fmt.Println(isDev)
fmt.Println(isTrue)

--- output ---
false
true

변수 선언은 var 변수명 타입 으로 선언할 수 있다. 이렇게 설명하면 zero 값으로 false 가 자동 대입된다.

다른 방법은 var 변수명 = 값 과 같이 변수를 선언하면서 값을 대입하는 것이다. 그럼 값을 보고 알아서 타입을 결정해 준다.

Integer (숫자 타입 중 하나)

Integer type 은 int8, int16, int32, int64, uint8, uint16, uint32, uint64 이다. 그리고 특별한 integer 타입으로 byte 와 rune 타입이 있다.

byte 는 uint8 의 별칭으로 unit8 보다는 byte 를 주로 쓰게 된다.

rune 은 int32 의 별칭이다.

보통 Integer Type 은 int 로 많이 사용하는데, 32bit cpu 이면 int32, 64bit cpu 이면 int64 와 동일하다.

int 의 zero 값은 0 이다.

var x int
var y int = 1
var z = 2
fmt.Println(x)
fmt.Println(y)
fmt.Println(z)

--- output ---
0
1
2

Float (숫자 타입 중 하나)

Float type 은 float32, float64 이 있다.

float type 의 zero 값은 int 와 동일하게 0 이다.

var p float64
var q = 0.0
fmt.Println(p)
fmt.Println(q)

--- output ---
0
0

숫자 타입 간에는 편하게 해당 타입으로 변환이 가능하다.

var x int = 10
var p float64 = 20.2
fmt.Println(x + int(p))
fmt.Println(float64(x) + p)

--- output ---
30
30.2

String

string 의 zero 값은 empty string 이다. Java 에서는 null string 이 있지만 Go 에서는 null 이 아니다.

string 과 자주 사용되는 타입은 rune 과 byte 이다.

앞에서 숫자 타입은 서로 타입 변환이 해당 타입으로 감싸주면 된다고 설명했는데 string, rune, byte 도 서로 타입 변환이 가능하다.

Go 최신 버전에서는 숫자 타입을 단순히 string 으로 감싸는 것은 체크 시에 에러가 발생한다.

var r rune = 'r'
var s string = string(r)
var b byte = 'b'
var s2 string = string(b)
fmt.Println(r)
fmt.Println(b)
fmt.Println(s)
fmt.Println(s2)

--- output ---
114
98
r
b

rune 과 byte 는 int 타입의 별칭이라 숫자 값이 출력된 것을 이해하자.

나중에 설명하겠지만 [] 를 사용하여 slice (배열과 비슷한) 타입을 활용하면 string 을 []byte 혹은 []rune 으로 변환할 수 있다.

var s string = "Hello,  "
var bs []byte = []byte(s)
var rs []rune = []rune(s)
fmt.Println(bs)
fmt.Println(rs)

--- output ---
[72 101 108 108 111 44 32 240 159 152 128]
[72 101 108 108 111 44 32 128512]

이모지 값은 utf-8 으로 표시해야 되기 때문에 byte 는 [240 159 152 128] 와 같이 4 바이트로 표시되고 rune 은 [128512] 로 표시된다. byte 는 int8 이고, rune 은 int32 임을 기억하자.

이렇게 보면 string 은 rune 으로 변환하는 것이 편리하다.

마지막으로 Short Variable Delcaration Operator(:=) 를 사용하여 var 와 type 키워드 없이 변수를 선언하고 바로 할당할 수 있다.

var a, b int = 1, 2
var c, d = 3, "a"

i := 10
x, s := 20.5, "Hello World"

--- output ---
1 2 3 a
10 20.5 Hello World

(go-01) Mac golang 개발환경 설정하기 (VS Code)

seungkyua@gmail.com — Sat, 25 Jun 2022 14:37:38 +0900

Kubernetes source code 를 디버깅하면서 분석하기 위해 golang 환경 설정과 사용을 계속해서 설명하고자 한다.

오늘은 첫번째로 무료 IDE 인 (thx MS) VSCode 를 설치하고 세팅하는 법을 알아보자.

golang 설치

mac 에서 golang 은 home brew 로 간단히 설치할 수 있다. 혹시 라도 이전에 낮은 버전이 설치되어 있는지 확인한다.

$ brew list | grep go
$ go@1.12

$ go version
go version go1.12.9 darwin/amd64

새로운 버전을 install 한다.

$ brew install go@1.16

현재 1.12 버전을 unlink 한다.

$ brew unlink go

새로운 버전을 link 한다.

$ brew link --force go@1.16

새로운 버전을 check 하면 업그레이드 되어 있는 것을 알 수 있다.

$ go version
go version go1.16.14 darwin/amd64

Go Workspace

go 는 install 명령어로 다른 go tool 들을 설치할 수 있다. 설치 위치는 workspace 라고 부르는 곳인데 특별히 지정하지 않으면 디폴트로 $HOME/go 디렉토리에 설치 된다.

go install 로 설치된 툴들은 소스는 $HOME/go/src 에, 바이너리 실행파일은 $HOME/go/bin 에 설치된다.

workspace 는 변경할 수 있는데 아래와 같이 .zshrc (zsh 일 경우) 이나 .bash_profile (bash 일 경우) 파일에 환경 변수를 추가하면 된다. 설정하기 전에 해당 workspace 디렉토리는 미리 만들어 줘야 한다.

## 디렉토리 만들기
$ mkdir -p $HOME/Documents/go_workspace

## .zshrc 파일에 환경변수 세팅
export GOPATH=$HOME/Documents/go_workspace
export PATH=$PATH:$GOPATH/bin

Go Tool 설치

코드를 체크해 주는 golint 툴이 있다. 이를 설치해 보자

$ go install golang.org/x/lint/golint@latest

$ which golint
/Users/ahnsk/Documents/go_workspace/bin/lint

특정 디렉토리에서 lint 체크를 하고 싶으면 아래 명령어를 쓰면 된다. 코드를 만든 프로젝트 디렉토리에서 수행하면 모든 파일을 lint 한다.

$ golint ./...

그리고 go 를 설치하면 일부 tool 들은 자동으로 설치되는데 그 중 vet 이라는 유용한 tool 있다. vet 은 error 를 잡아주는 tool 이다.

$ go vet ./...

VS Code 설치

VS Code 는 아래 url 에 접속해서 OS 별로 설치하면 된다. 설치 화면은 생략한다.

https://code.visualstudio.com/Download

VS Code 를 띄우고 나서 아무 화면에서나 Cmd+Shift+P 키를 입력하면 Command Palette 가 화면 위에 생성된다. 거기에서 shell command 로 검색하여 install ‘code’ command in PATH 를 선택한다.

이렇게 설치한 후 터미널을 새롭게 띄워서 특정 디렉토리에서 code 명령어를 이력하면 VS Code 가 실행된다.

아래와 같이 go-sample 디렉토리에서 실행하면 VS Code 가 뜨는 것을 볼 수 있다.

$ cd go-sample
$ code

VS Code Extension 설치

VS Code 는 다양한 Extension 을 설치할 수 있다. 그 중에 go 를 써야 하니 Go extension 을 설치해 보자.

VS Code 화면에 보면 맨 좌측에 세로로 아이콘들이 여러개 있다. 그 중 위에서 5번째 혹은 6번째에 있는 extension 아이콘을 선택하고 go 를 검색해서 go Team at Google 에서 만든 Go 를 설치해 준다.

아래 그림에서 맨 처음 줄의 Go 의 install 파란 버튼을 클릭해서 설치한다.

이제 기본 설치는 끝났다.

hello world 를 출력하는 간단한 소스를 만들어서 실행해 보자.

VS Code 에서 새로운 파일을 생성해서 main.go 파일을 만들어서 저장한다.

package main

import "fmt"

func main() {
	fmt.Println("Hello world!!!")
}

VS Code 상단 메뉴에 Terminal >> New Terminal 을 클릭하면 터미널을 VS Code 에서 사용할 수 있다.

$ go run main.go
Hello world!!!

VS Code 화면을 보면 다음과 같다.

이제 세팅은 모두 끝났다. 디버깅 세팅하는 방법이 있는데 go 를 설명하다가 어느 정도 지나면 디버깅 세팅도 추가로 올릴 예정이다.

python package, module import 방법

seungkyua@gmail.com — Tue, 21 Jun 2022 13:06:44 +0900

.
├── config
│   ├── __init__.py
│   ├── __pycache__
│   │   ├── __init__.cpython-39.pyc
│   │   ├── settings.cpython-39.pyc
│   │   ├── urls.cpython-39.pyc
│   │   ├── views.cpython-39.pyc
│   │   └── wsgi.cpython-39.pyc
│   ├── asgi.py
│   ├── settings.py
│   ├── urls.py
│   ├── views.py
│   └── wsgi.py
├── db.sqlite3
├── firstapp
│   ├── __init__.py
│   ├── __pycache__
│   │   ├── __init__.cpython-39.pyc
│   │   ├── urls.cpython-39.pyc
│   │   └── views.cpython-39.pyc
│   ├── admin.py
│   ├── apps.py
│   ├── migrations
│   │   └── __init__.py
│   ├── models.py
│   ├── tests.py
│   ├── urls.py
│   └── views.py
└── manage.py

위와 같이 django 디렉토리가 있을 때 package, module import 하는 방법이 헷갈려서 정리하는 차원이다.

바로 하위 디렉토리 config 와 firstapp 은 패키지 이다.

그리고 config 아래의 urls.py 와 같은 python 파일은 모듈이다.

import 방법은 다음과 같다.

import {패키지}.{모듈}

import {패키지}.{모듈}.{함수}

from {패지키} import {모듈}

from {패키지}.{모듈} import {함수}

Kubernetes Scheduler 살펴보기

seungkyua@gmail.com — Fri, 13 May 2022 08:47:36 +0900

Pod 가 새롭게 생성되면 Scheduler 를 통해서 Pod 가 실행될 노드가 결정된다. 즉 모든 Pod 는 Scheduler 에 의해서 최적의 노드가 결정되고 실행된다.

kube-scheduler 는 Control Plane 에 속하는 컴포넌트 중에 하나이며, 디폴트 scheduler 이다. 만약 특별한 스케줄링을 원한다며 커스텀 스케줄러를 만들어서 대체할 수 도 있다.

Pod 가 스케줄링 되기 위해서는 노드가 스케줄링 요구 사항에 맞아야 하는데 이 때, 요구사항에 맞는 노드를 피저블 노드(feasible node) 라고 한다.

스케줄러는 피저블 노드를 찾고 적절한 로직을 통해 노드에 점수를 부여한다. 가장 최고 점수를 갖는 노드에 Pod 가 실행된다.

스케줄링을 결정하는 데에는 하드웨어, 소프트웨어, policy contraints, affinity 와 anti-affinity spec, local data 등 여러 요구 사항들이 있다.

kube-scheduler 가 결정하는 2-step operation

Filtering
Scoring

Filtering 단계에서는 피저블 노드를 찾는 단계이다. 예를 들면, PodFitsResources 필터는 Pod 의 request 리소스를 만족하는 리소스를 갖는 후보 노드를 추려낸다. 이 단계 이후에는 적합한 노드 리스트가 도출되는데 만약 노드 리스트의 값이 비었다면 Pod 는 스케줄링 되지 않는다.

Scoring 단계에서는 필터링된 노드 리스트 중에서 Pod 가 실행될 최적의 노드를 찾는다. 스케줄러는 노드 리스트에 있는 각 노드들에 점수를 부여한다.

마지막으로 kube-scheduler 는 최고 점수의 노드에 Pod 를 배치한다.

Filtering 과 Scoring 을 설정할 수 있는 방법은 2가지가 있다.

Scheduling Policies (kubernetes 1.22 버전까지만 사용)
- Predicates : filtering 을 조절할 수 있음
- Priorities: scoring 을 조절할 수 있음
Scheduling Profiles (https://kubernetes.io/docs/reference/scheduling/config/#profiles)
- KubeSchedulerConfiguration 리소스 타입으로 조절할 수 있음
- plugins 를 통해 Filter 와 Score 를 조절 가능

nodeSelector

Node 에 label 을 설정하고 Pod 에서 nodeSelector 로 Node 지정하는 방식이다.

$ kubectl get nodes -L nginx
NAME          STATUS   ROLES                  AGE   VERSION   NGINX
k1-master01   Ready    control-plane,master   92d   v1.21.6
k1-node01     Ready    ingress                92d   v1.21.6
k1-node02     Ready    <none>                 92d   v1.21.6   enabled
k1-node03     Ready    <none>                 92d   v1.21.6   enabled
k1-node04     Ready    <none>                 92d   v1.21.6
k1-node05     Ready    <none>                 92d   v1.21.6

k1-node02 와 k1-node03 에 nginx=enabled 로 label 이 지정되어 있다.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-nodeselector
  namespace: kube-sample
spec:
  replicas: 1
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.21.0
        ports:
        - containerPort: 80
      nodeSelector:
        nginx: enabled

nodeSelector 를 활용하여 deployment 를 배포하면 아래와 같이 k1-node02 혹은 k1-node03 에 배포된다.

$ kubectl get pods -n kube-sample -o wide
NAME                                  READY   STATUS    RESTARTS   AGE   IP             NODE        NOMINATED NODE   READINESS GATES
nginx-nodeselector-68977d7759-sf48l   1/1     Running   0          9s    10.233.113.7   k1-node02   <none>           <none>

Node affinity

nodeSelector 와 동작 방식이 유사하지만 다음과 같은 차이가 있다.

requiredDuringSchedulingIgnoredDuringExecution: 스케줄링에서 만족하는 노드가 없으면 스케줄링 되지 않는다.

preferredDuringSchedulingIgnoredDuringExecution: 스케줄링에서 만족하는 노드를 찾고 노드가 없더라도 스케줄링은 된다. weight 필드의 값을 scoring 에 포함시킨다.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-node-affinity
  namespace: kube-sample
spec:
  replicas: 1
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      affinity:
        nodeAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            nodeSelectorTerms:
            - matchExpressions:
              - key: nginx
                operator: In
                values:
                - enabled
            - matchExpressions:
              - key: kubernetes.io/os
                operator: In
                values:
                - windows
          preferredDuringSchedulingIgnoredDuringExecution:
          - weight: 1
            preference:
              matchExpressions:
              - key: another-node-label-key
                operator: In
                values:
                - another-node-label-value
      containers:
      - name: nginx
        image: nginx:1.21.0
        ports:
        - containerPort: 80

위와 같이 nodeSelectorTerms 에 여러 개의 matchExpressions 가 있으면 이 중 하나만 만족해도 스케줄링은 된다. nodeSelectorTerms 에 하나의 matchExpressions 가 있고, key value 가 여러 개가 있으면 matchExpressions 내의 모든 조건을 만족해야 스케줄링이 된다.

operator 로 쓸 수 있는 값은 In, NotIn, Exists, DoesNotExist, Gt, Lt 이다.

NotIn 과 DoesNotExist 는 node anti-affinity 로 사용 가능하다.

$ kubectl get pods -n kube-sample -o wide
NAME                                   READY   STATUS        RESTARTS   AGE    IP              NODE        NOMINATED NODE   READINESS GATES
nginx-node-affinity-755cf7f85d-ss9q5   1/1     Running       0          5s     10.233.113.10   k1-node02   <none>           <none>

Pod affinity and anti-affinity

Pod 를 서로 다른 노드에 배치시키는 방법은 pod anti-affinity 를 통해서 구현할 수 있다.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-pod-anti-affinity
  namespace: kube-sample
spec:
  replicas: 2
  selector:
    matchLabels:
      app: nginx-pod-anti-affinity
  template:
    metadata:
      labels:
        app: nginx-pod-anti-affinity
    spec:
      affinity:
        podAntiAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
          - labelSelector:
              matchExpressions:
              - key: app
                operator: In
                values:
                - nginx-pod-anti-affinity
            topologyKey: kubernetes.io/hostname
      containers:
      - name: nginx
        image: nginx:1.21.0
        ports:
        - containerPort: 80

위와 같이 pod label 에 pod anti affinity 를 설정하면 replicas 값 2 에 의해서 생성되는 2개의 pod 는 서로 다른 노드에 배치된다. topologyKey 는 kubernetes.io/hostname 값으로 세팅하고 특정 node lable 로 하고 싶으면 node affinity 를 추가하면 된다.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-pod-anti-affinity
  namespace: kube-sample
spec:
  replicas: 2
  selector:
    matchLabels:
      app: nginx-pod-anti-affinity
  template:
    metadata:
      labels:
        app: nginx-pod-anti-affinity
    spec:
      affinity:
        podAntiAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
          - labelSelector:
              matchExpressions:
              - key: app
                operator: In
                values:
                - nginx-pod-anti-affinity
            topologyKey: kubernetes.io/hostname
        nodeAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            nodeSelectorTerms:
            - matchExpressions:
              - key: nginx
                operator: In
                values:
                - enabled
      containers:
      - name: nginx
        image: nginx:1.21.0
        ports:
        - containerPort: 80

$ kubectl get pods -n kube-sample -o wide
NAME                                       READY   STATUS    RESTARTS   AGE   IP              NODE        NOMINATED NODE   READINESS GATES
nginx-pod-anti-affinity-7cfcbcff8f-c2429   1/1     Running   0          14s   10.233.96.3     k1-node03   <none>           <none>
nginx-pod-anti-affinity-7cfcbcff8f-dmqqm   1/1     Running   0          14s   10.233.113.12   k1-node02   <none>           <none>

Taint 와 Toleration

노드에 taint 를 지정하면 해당 노드에 taint effect 를 줄 수 있다. 예를 들어 taint effect 에 NoSchedule 을 준다면 해당 노드에는 pod 가 스케줄링 되지 않는다.

taint effect 를 제거할 수 있는 방법은 Pod 에 toleration 을 세팅하는 것이다.

마스터에는 기본적으로 taint 를 지정해서 스케줄링 안되게 세팅해 놓는 것을 알 수 있다.

$ kubectl describe node k1-master01

Name:               k1-master01
Roles:              control-plane,master
Labels:             beta.kubernetes.io/arch=amd64
                    beta.kubernetes.io/os=linux
                    kubernetes.io/arch=amd64
                    kubernetes.io/hostname=k1-master01
                    kubernetes.io/os=linux
                    node-role.kubernetes.io/control-plane=
                    node-role.kubernetes.io/master=
                    node.kubernetes.io/exclude-from-external-load-balancers=
Annotations:        kubeadm.alpha.kubernetes.io/cri-socket: /var/run/containerd/containerd.sock
                    node.alpha.kubernetes.io/ttl: 0
                    projectcalico.org/IPv4Address: 192.168.30.13/24
                    volumes.kubernetes.io/controller-managed-attach-detach: true
CreationTimestamp:  Tue, 08 Feb 2022 21:27:12 +0900
Taints:             node-role.kubernetes.io/master:NoSchedule

마지막의 Taints 값은 kubectl 로 세팅할 수 있다.

$ kubectl taint nodes k1-master01 node-role.kubernetes.io/master=:NoSchedule

그럼 master 노드에 toleration 을 활용하여 pod 를 배치해 보자.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-toleration
  namespace: kube-sample
spec:
  replicas: 1
  selector:
    matchLabels:
      app: nginx-toleration
  template:
    metadata:
      labels:
        app: nginx-toleration
    spec:
      tolerations:
      - key: node-role.kubernetes.io/master
        operator: Exists
        effect: NoSchedule
      affinity:
        nodeAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            nodeSelectorTerms:
            - matchExpressions:
              - key: node-role.kubernetes.io/control-plane
                operator: Exists
      containers:
      - name: nginx
        image: nginx:1.21.0
        ports:
        - containerPort: 80

toleration 으로 taint 효과를 없애고 node affinity 를 활용하여 control-plane, 즉 master 노드에 pod 를 배치 시켰다. 물론 master 노드에 node-role.kubernetes.io/control-plane 이라는 label 이 존재해야 한다.

taint effect 는 NoSchedule, NoExecute, PreferNoSchedule 이 있다.

NoSchedule 은 스케줄링을 막는 것이고, NoExecute 는 실행중인 pod 를 eviction 시킨다. PreferNoSchedule 은 가능하면 스케줄링 하지 않는다는 의미이다.

operator 에는 Exists 와 Equal 이 있다. Exists 는 key 값이 존재하는 지를 판단하기 때문에 value 값이 필요 없으며, Equal 은 key 와 value 값이 지정된 값과 일치해야 한다.

$ kubectl get pods -n kube-sample -o wide
NAME                                       READY   STATUS    RESTARTS   AGE     IP              NODE          NOMINATED NODE   READINESS GATES
nginx-toleration-fb74cd98c-hkql8           1/1     Running   0          5m31s   10.233.117.4    k1-master01   <none>           <none>

10분만에 이해하는 컨테이너 네트워크

seungkyua@gmail.com — Fri, 1 Apr 2022 14:06:51 +0900

컨테이어가 사용하는 네트워크는 처음 접할 때는 어렵기 마련이다. 그러나 리눅스 네트워크 네임스페이스를 공부하고 리눅스 명령어로 이를 구현해 보면 이해가 훨씬 쉽다.

Single Network Namespace

구현하고자 하는 목표는 아래 다이어그램과 같다.

red 네트워트 네임스페이스를 만들고 인터페이스를 만들어서 ip 를 할당하고 노드에서 ping 을 통해 통신이 가능한지 확인한다.

아래의 명령어로 컨테이너 네트워크를 만들어 본다.

1. 새로운 네임스페이스 생성 (이름: red)

$ sudo ip netns add red

2. veth pair 생성

$ sudo ip link add veth1-r type veth peer veth2-r

3. veth2-r 을 red 네임스페이스로 이동

$ sudo ip link set veth2-r netns red

4. red 네임스페이스에 존재하는 veth2-r 인터페이스에 ip 주소를 세팅

$ sudo ip netns exec red ip address add 192.168.0.1 dev veth2-r

5. red 네임스페이스에 존재하는 veth2-r 인터페이스 up

$ sudo ip netns exec red ip link set dev veth2-r up

6. 노드에 존재하는 veth1-r 인터페이스 up

$ sudo ip link set dev veth1-r up

7. red 네임스페이스에 존재하는 loopback 인터페이스 up

$ sudo ip netns exec red ip link set lo up

8. 노드의 라우팅 테이블 세팅

subnet mask 가 32 이므로 바로 해당 ip 에 대해서만 veth1-r 로 향하도록 라우팅을 세팅했다. veth1-r 은 veth2-r 과 링크가 연결되어 있으므로 192.168.0.1 을 목적지로 하는 네트워크 패킷들은 red 네임스페이스 안에 존재하는 veth2-r 인터페이스로 향하게 된다.

$ sudo ip route add 192.168.0.1/32 dev veth1-r

9. red 네임스페이스의 디폴트 라우팅을 세팅

red 네임스페이스 안에서 디폴트 게이트웨이를 veth2-r 인터페이스의 ip address 로 세팅

$ sudo ip netns exec red ip route add default via 192.168.0.1 dev veth2-r

10. 네트워크 통신 확인

$ ip netns
red (id: 0)

$ sudo ip netns exec red ip address
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
74: veth2-r@if75: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 52:42:40:a9:86:8b brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet 192.168.0.1/32 scope global veth2-r
       valid_lft forever preferred_lft forever
    inet6 fe80::5042:40ff:fea9:868b/64 scope link
       valid_lft forever preferred_lft forever

$ ping 192.168.0.1
PING 192.168.0.1 (192.168.0.1) 56(84) bytes of data.
64 bytes from 192.168.0.1: icmp_seq=1 ttl=64 time=0.057 ms
64 bytes from 192.168.0.1: icmp_seq=2 ttl=64 time=0.046 ms
64 bytes from 192.168.0.1: icmp_seq=3 ttl=64 time=0.043 ms

Single Network, 2 Namespaces

이번에는 하나의 노드에 2개의 네임스페이스가 있는 경우를 살펴보자. 보통 컨테이너는 하나의 노드에 2개 이상 멀티로 띄는 경우가 많기 때문에 이 번 케이스가 대부분의 컨테이너 네트워크에 맞다고 보면 된다.

1개의 네임스페이스와 다른 점은 ip 대역을 지정하고 (일반적으로 subnet mask 24 혹은 25) 리눅스 브릿지로 이를 연결하는 것이다. 그리고 브릿지에 ip 주소를 할당한 후 네임스페이스의 네트워크에서 사용할 디폴트 게이트웨이로 지정하여, 네임스페이스 내에서는 외부로 나가는 패킷을 리죽스 브릿지로 통하게 한다.

1. 네임스페이스 생성

$ sudo ip netns add red
$ sudo ip netns add blue

2. veth pair 생성

$ sudo ip link add veth1-r type veth peer name veth2-r
$ sudo ip link add veth1-b type veth peer name veth2-b

3. veth pair 를 네임스페이스로 이동

$ sudo ip link set veth2-r netns red
$ sudo ip link set veth2-b netns blue

4. 네트워크 네임스페이스 내에 있는 인터페이스에 ip 주소 세팅

$ sudo ip netns exec red ip address add 192.168.0.2/24 dev veth2-r
$ sudo ip netns exec blue ip address add 192.168.0.3/24 dev veth2-b

5. 네트워크 네임스페이스 내에 있는 인터페이스를 up

$ sudo ip netns exec red ip link set dev veth2-r up
$ sudo ip netns exec blue ip link set dev veth2-b up

6. 리눅스 브릿지 생성

 $ sudo ip link add name br0 type bridge

7. 네트워크 네임스페이스 인터페이스를 브릿지에 연결

$ sudo ip link set dev veth1-r master br0
$ sudo ip link set dev veth1-b master br0

8. 네트워크 네임스페이스 인터페이스를 up

$ sudo ip link set dev veth1-r up
$ sudo ip link set dev veth1-b up

9. 브릿지에 ip 주소 할당

$ sudo ip address add 192.168.0.1/24 dev br0

10. 브릿지 up

$ sudo ip link set dev br0 up

red 네임스페이스에서 blue 네임스페이스로 ping 테스트

$ sudo ip netns exec red ping 192.168.0.3
PING 192.168.0.3 (192.168.0.3) 56(84) bytes of data.

ping 은 통신이 안되고 있다. 원인이 무엇일까?

위의 통신은 아래의 경로를 지난다.

red 네임스페이스 -> root 1번 프로세스의 노드 네임스페이스 -> blue 네임스페이스

즉, red 네임스페이스의 iptables, 노드 네임스페이스의 iptables, blue 네임스페이스의 iptables 를 모두 지난다. 그러므로 각 iptables 의 filter 체인을 모두 확인해야 한다.

red 네임스페이스의 iptables 은 밖으로 나가는 출발점 이고, 응답을 받아야 하므로 OUTPUT filter 체인과 INPUT 체인이 열려 있는지를 확인한다.
노드 네임스페이스의 iptables 는 네트워크를 경유하는 곳이므로 FORWARD filter 체인이 열려있는지 확인한다. (지금의 경우에만 그렇고 서버에 접속하고 여러 작업을 하므로 INPUT, OUTPUT 이 모두 열려 있어야 한다.)
blue 네임스페이스는 iptables 는 패킷을 받고 응답을 줘야 하므로 INPUT filter 체인과 OUTPUT 체인이 열려있는지 확인한다.

## red 네임스페이스
$ sudo ip netns exec red iptables -S
-P INPUT ACCEPT
-P FORWARD ACCEPT
-P OUTPUT ACCEPT

## 노드 네임스페이스
$ sudo iptables -S
-P INPUT ACCEPT
-P FORWARD DROP
-P OUTPUT ACCEPT
...

## blue 네임스페이스
$ sudo ip netns exec blue iptables -S
-P INPUT ACCEPT
-P FORWARD ACCEPT
-P OUTPUT ACCEPT

노드 네임스페스의 FOWARD filter 가 DROP 으로 되어 있다. 이를 ACCEPT 로 변경해 준다.

$ sudo iptables -P FORWARD ACCEPT

한가지가 더 있다. 다음과 같이 sysctl 로 forward 를 열어줘야 한다.

아래의 값이 0 일 경우 이를 1로 변경해 준다.

$ sudo sysctl -a | grep -i net.ipv4.ip_forward
net.ipv4.ip_forward = 0

$ sudo vi /etc/sysctl.d/99-sysctl.conf
net.ipv4.ip_forward=1

$ sudo sysctl -p

이제 red 네임스페이스에서 blue 네임스페이스로 ping 테스트를 다시 하면 성공함을 알 수 있다.

$ sudo ip netns exec red ping 192.168.0.3
PING 192.168.0.3 (192.168.0.3) 56(84) bytes of data.
64 bytes from 192.168.0.3: icmp_seq=1 ttl=64 time=0.077 ms
64 bytes from 192.168.0.3: icmp_seq=2 ttl=64 time=0.063 ms
64 bytes from 192.168.0.3: icmp_seq=3 ttl=64 time=0.062 ms

red, blue 네임스페이스에서 외부로의 ping 테스트

노드 내부 간의 ping 테스트는 성공했으나 외부 통신은 여전히 실패한다.

$ sudo ip netns exec red ping 8.8.8.8
ping: connect: Network is unreachable

이유는 간단하다. red 네임스페이스에서 밖으로 나가는 route 경로를 지정하지 않았기 때문이다. 디폴트 게이트웨이를 아래와 같이 각각 추가해 준다.

$ sudo ip netns exec red ip route add default via 192.168.0.1 dev veth2-r
$ sudo ip netns exec blue ip route add default via 192.168.0.1 dev veth2-b

그리고 중요한 내용 하나가 더 있다.

외부에서는 node 까지는 알 수 있지만 실제로 내부의 red 네임스페이스에 대해서는 알지 못한다.

그렇기 때문에 네임스페이스 안에서 노드 밖으로 패킷이 나갈 때는 source address 를 node 의 address 로 변경해줘야 한다. 이를 masquerade 라고 하며 아래와 같이 노드에서 iptables 의 nat 테이블에 등록하면 된다.

$ sudo iptables -t nat -A POSTROUTING -s 192.168.0.0/24 ! -o br0 -j MASQUERADE

이제 다시 외부 통신을 테스트 해보면 성공함을 알 수 있다.

$ sudo ip netns exec red ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=103 time=32.6 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=103 time=32.6 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=103 time=32.6 ms

$ sudo ip netns exec blue ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=103 time=32.5 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=103 time=32.6 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=103 time=32.5 ms

참고: https://www.youtube.com/watch?v=6v_BDHIgOY8&t=1561s (Container Networking From Scratch - Kristen Jacobs)

Python 개발 환경 구성하기

seungkyua@gmail.com — Fri, 11 Feb 2022 08:56:56 +0900

Python 은 다양한 버전의 패키지 라이브러를 사용하여 개발한다. 그렇기 때문에 똑같은 패키지라도 서로 다른 버전을 사용한 프로그램이 있을 수 있어 버전 충돌이 일어날 수 있다.

결국 각 프로그램마다 고유한 개발 환경이 필요한데 그것이 바로 Virtual Envrionment 이다. 여기서는 Mac 에 python 가상 환경을 구축하는 방법을 설명한다.

1. Python 설치

mac 에서는 brew 로 프로그램 관리를 쉽게 할 수 있는데 brew 로 설치한 python 은 향후 다른 프로그램과 연계할 때 문제가 발생할 수 있어 수동으로 설치하기 위해 이전 brew 설치한 python 은 삭제한 후 아래와 같이 수동으로 다운 받아 설치한다.

(다운로드 후 설치) https://www.python.org/ftp/python/3.9.7/python-3.9.7-macos11.pkg

설치한 python 경로에 path 를 확인하고 없으면 추가해 준다. zsh 외에 bash shell 을 사용하면 ~/.bash_profile 을 확인하면 된다.

$ vi ~/.zshrc
export PATH="/Library/Frameworks/Python.framework/Versions/3.9/bin:${PATH}"

$ source ~/.zshrc

python 설치가 완료되면 아래와 같이 pip 을 설치한다.

$ wget https://bootstrap.pypa.io/get-pip.py
$ python3 get-pip.py

2. Python 가상 환경 프로그램 설치

python 가상 환경은 virtualenv 와 virtualenvwrapper 프로그램을 설치해서 만들 수 있다. 아래와 같이 2개의 툴을 설치한다.

$ sudo pip install virtualenv virtualenvwrapper

설치가 완료되면 ~/.zshrc 혹은 ~/.bash_profile 파일에 경로를 추가한다.

$ vi ~/.zshrc

alias python="/usr/local/bin/python3"

export VIRTUALENVWRAPPER_PYTHON=/usr/local/bin/python3
export VIRTUALENVWRAPPER_VIRTUALENV=/Library/Frameworks/Python.framework/Versions/3.9/bin/virtualenv
export WORKON_HOME=~/.virtualenvs
. /Library/Frameworks/Python.framework/Versions/3.9/bin/virtualenvwrapper.sh
export PATH="/Library/Frameworks/Python.framework/Versions/3.9/bin:${PATH}"

$ source ~/.zshrc

3. 가상 환경 활용

가상 환경은 아래 명령어로 생성할 수 있다. 마지막 python 옵션은 생략 가능하며 pandas-py3.6 이라는 이름으로 생성하였다.

$ mkvirtualenv pandas-py3.6 --python=python3

venv:(pandas-py3.6) $

prompt 가 “venv:...” 로 변경되어 가상환경에 들어와 있음을 알 수 있다.
생성한 가상 환경은 아래 디렉토리에 생성되고 앞으로 pip 으로 생성한 python 패키지 파일들은 ~/.virtualenvs/pandas-py3.6 아래에 설치된다.

venv:(pandas-py3.6) $ ls -al ~/.virtualenvs

drwxr-xr-x  21 ahnsk  staff   672  1 27 10:01 .
drwxr-xr-x+ 96 ahnsk  staff  3072  2 10 13:13 ..
-rwxr-xr-x   1 ahnsk  staff   135 11 13  2017 get_env_details
-rw-r--r--   1 ahnsk  staff    96 11 13  2017 initialize
drwxr-xr-x   8 ahnsk  staff   256  1 27 10:08 pandas-py3.6
-rw-r--r--   1 ahnsk  staff    73 11 13  2017 postactivate
-rw-r--r--   1 ahnsk  staff    75 11 13  2017 postdeactivate
-rwxr-xr-x   1 ahnsk  staff    66 11 13  2017 postmkproject
-rw-r--r--   1 ahnsk  staff    73 11 13  2017 postmkvirtualenv
-rwxr-xr-x   1 ahnsk  staff   110 11 13  2017 postrmvirtualenv
-rwxr-xr-x   1 ahnsk  staff    99 11 13  2017 preactivate
-rw-r--r--   1 ahnsk  staff    76 11 13  2017 predeactivate
-rwxr-xr-x   1 ahnsk  staff    91 11 13  2017 premkproject
-rwxr-xr-x   1 ahnsk  staff   130 11 13  2017 premkvirtualenv
-rwxr-xr-x   1 ahnsk  staff   111 11 13  2017 prermvirtualenv

가상 환경을 벗어나려면 deactivate 명령어로 빠져 나오면 된다.

venv:(pandas-py3.6) $ deactivate
$

가상 환경 목록을 확인하려면 lsvirtualenv 명령어로 할 수 있다.

$ lsvirtualenv

pandas-py3.6
============

해당 가상 환경으로 들어가려면 workon 명령어로 할 수 있다.

$ workon pandas-py3.6

venv:(pandas-py3.6) $  python
Python 3.9.7 (v3.9.7:1016ef3790, Aug 30 2021, 16:25:35)
[Clang 12.0.5 (clang-1205.0.22.11)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>>

AWS 에서 Kubernetes Volume 때문에 Pod 가 Rescheduling 안되는 문제 해결

seungkyua@gmail.com — Wed, 9 Feb 2022 10:11:40 +0900

EKS 서비스를 이용하기 보다는 Kubernetes 를 AWS 에 직접 설치하여 활용하는 경우가 종종 있는데, 이 경우에는 세부적인 세팅들을 해줘야 할 때가 있다. 그 중에 대표적인 추가 모듈이 Pod 에서 EBS Volume 을 연결하여 사용할 수 있는 StorageClass 이다.

잘못된 Storage Class 를 사용하는 경우

Storage class 의 Provisioner 를 kubernetes.io/aws-ebs 로 사용하는 경우가 있는데, 이는 처음에는 문제가 없으나 Pod eviction (pod 가 다른 노드로 옮겨지는 경우) 에서는 문제가 발생한다.

아래와 같은 storage class 를 적용한다.

---
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: bad-storage
provisioner: kubernetes.io/aws-ebs
parameters:
  type: gp2
  fsType: ext4

처음 만든 Pod 에서 위의 StorageClass 를 사용하여 volume 을 ReadWriteOnce 로 attach 한 경우에는 문제없이 정상 작동한다. 하지만 pod 가 rescheduling 되면 새로 옮겨가는 노드에서 pod 는 생성되지 않는다. 이유는 volume 이 이전 노드의 Pod에 이미 사용되고 있다는 정보 때문에 새로운 노드의 Pod 에서 volume attach 가 안되기 때문이다.

즉, 해당 문제를 해결하기 위해서는 이전의 attach 정보를 삭제해 줘야 하는데 위의 storage class 로는 이를 해결할 수 없다. 그래서 다음과 같은 StroageClass 를 사용해야 한다.

올바른 Storage Class 사용하기

1. CSI Provisioner 설치

AWS EBS 를 위한 CSI Driver 는 다음과 같이 설치해야 한다.

$ kubectl apply -k "github.com/kubernetes-sigs/aws-ebs-csi-driver/deploy/kubernetes/overlays/stable/?ref=release-1.5"


$ kubectl get pods -n kube-system
...
ebs-csi-controller-6fd55f99c8-9j2hr                                       6/6     Running   0             13d
ebs-csi-controller-6fd55f99c8-x5dkt                                       6/6     Running   0             13d
ebs-csi-node-bw6jb                                                        3/3     Running   0             13d
ebs-csi-node-nx7gl                                                        3/3     Running   0             13d
ebs-csi-node-zh242                                                        3/3     Running   0             13d
...

kustomize 로 설치하면 ebs-csi-controller 가 HA 로 설치되고, 각 노드 마다 ebs-csi-node 가 설치된다. 이는 ceph 스토리지 용도의 CSI Driver 와도 비슷한데 volume 을 사용할 Pod 가 실행될 VM 노드에 EBS 링크를 연결하고 이를 Pod 에서 사용하기 때문에 각 노드마다 ebs-csi-node 가 설치되는 이유이다.

2. Storage class 생성

driver 를 설치했으면 이제 스토리지 클래스를 생성할 차례이다. 아래와 같이 생성한다.

$ vi standard-ebs-sc.yaml
---
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  annotations: 
    storageclass.kubernetes.io/is-default-class: "true"
  name: standard
provisioner: ebs.csi.aws.com
volumeBindingMode: WaitForFirstConsumer
parameters:
  csi.storage.k8s.io/fstype: xfs
  type: io1
  iopsPerGB: "50"
  encrypted: "false"
reclaimPolicy: Delete
allowVolumeExpansion: true
allowedTopologies:
- matchLabelExpressions:
  - key: topology.ebs.csi.aws.com/zone
    values:
    - ap-northeast-2a
    - ap-northeast-2b
    - ap-northeast-2c



$ kubectl apply -f standard-ebs-sc.yaml

annotations 의 storageclass.kubernetes.io/is-default-class":"true" 값은 스토리지 클래스를 디폴트로 지정하는 값이다. 스토리지 클래스는 여러가지를 사용할 수 있기 때문에 기본을 지정해 주는 것이고, 또한 ebs 가 생성될 AZ 리스트를 넣어줘야 한다.

3. IAM 설정

앞에서 VM 에 ebs 링크를 걸어준다고 했는데 그렇기 때문에 IAM 설정을 해야 한다. 아래와 같이 Policy 를 만들고 해당 Policy 를 control-plane.cluster-api-provider-aws.sigs.k8s.io 과 nodes.cluster-api-provider-aws.sigs.k8s.io 에 attach 해야 한다.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "ec2:CreateSnapshot",
                "ec2:AttachVolume",
                "ec2:DetachVolume",
                "ec2:ModifyVolume",
                "ec2:DescribeAvailabilityZones",
                "ec2:DescribeInstances",
                "ec2:DescribeSnapshots",
                "ec2:DescribeTags",
                "ec2:DescribeVolumes",
                "ec2:DescribeVolumesModifications"
            ],
            "Resource": "*"
        },
        {
            "Effect": "Allow",
            "Action": [
                "ec2:CreateTags"
            ],
            "Resource": [
                "arn:aws:ec2:*:*:volume/*",
                "arn:aws:ec2:*:*:snapshot/*"
            ],
            "Condition": {
                "StringEquals": {
                    "ec2:CreateAction": [
                        "CreateVolume",
                        "CreateSnapshot"
                    ]
                }
            }
        },
        {
            "Effect": "Allow",
            "Action": [
                "ec2:DeleteTags"
            ],
            "Resource": [
                "arn:aws:ec2:*:*:volume/*",
                "arn:aws:ec2:*:*:snapshot/*"
            ]
        },
        {
            "Effect": "Allow",
            "Action": [
                "ec2:CreateVolume"
            ],
            "Resource": "*"
        },
        {
            "Effect": "Allow",
            "Action": [
                "ec2:CreateVolume"
            ],
            "Resource": "*"
        },
        {
            "Effect": "Allow",
            "Action": [
                "ec2:CreateVolume"
            ],
            "Resource": "*"
        },
        {
            "Effect": "Allow",
            "Action": [
                "ec2:DeleteVolume"
            ],
            "Resource": "*"
        },
        {
            "Effect": "Allow",
            "Action": [
                "ec2:DeleteVolume"
            ],
            "Resource": "*"
        },
        {
            "Effect": "Allow",
            "Action": [
                "ec2:DeleteVolume"
            ],
            "Resource": "*"
        },
        {
            "Effect": "Allow",
            "Action": [
                "ec2:DeleteSnapshot"
            ],
            "Resource": "*"
        },
        {
            "Effect": "Allow",
            "Action": [
                "ec2:DeleteSnapshot"
            ],
            "Resource": "*"
        }
    ]
}

4. 테스트

샘플 코드를 만들어서 잘 동작하는지 테스트 해 보자.

$ vi app-ebs-example.yaml
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: app-ebs-claim
spec:
  accessModes:
    - ReadWriteOnce
  storageClassName: standard
  resources:
    requests:
      storage: 4Gi
---
apiVersion: v1
kind: Pod
metadata:
  name: app
spec:
  containers:
  - name: app
    image: centos
    command: ["/bin/sh"]
    args: ["-c", "while true; do echo $(date -u) >> /data/out.txt; sleep 5; done"]
    volumeMounts:
    - name: persistent-storage
      mountPath: /data
  volumes:
  - name: persistent-storage
    persistentVolumeCl
      claimName: app-ebs-claim



$ kubectl apply -f app-ebs-example.yaml

위의 코드를 설치하면 pvc 가 아래와 같이 잘 생성되는 것을 알 수 있다.

$ kubectl get pvc
NAME            STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS   AGE
app-ebs-claim   Bound    pvc-4ab38fe9-7e76-4d81-85d3-0db68da9c1e0   4Gi        RWO            standard       6s


$ kubectl get volumeattachments
NAME                                                                   ATTACHER          PV                                         NODE                                             ATTACHED   AGE
csi-60f252627e620b1e91d7d32a7d463b406a3850f3a7d7b0c535fe209f699ba3bd   ebs.csi.aws.com   pvc-4ab38fe9-7e76-4d81-85d3-0db68da9c1e0   ip-10-0-214-57.ap-northeast-2.compute.internal   true       2m8s

또한 volumeattachments 를 보면 VM 에 해당 volume 이 attach 되어 링크가 걸려 있는 것을 알 수 있다.

AWS ELB 와 Ingress Controller on Kubernetes 연동하기 (나름 최선의 방법입니다)

seungkyua@gmail.com — Sun, 30 Jan 2022 17:27:36 +0900

배경

외부에서 Kubernetes Cluster 위에서 돌아가는 서비스에 접근하기 위해서는 Ingress Controller 를 통해서 가능하다. aws 와 같은 클라우드에서는 ELB -> Ingress Controller -> Workload 경로로 접근가능하다.

현재 사용하고 있는 방법은 CrossPlane 으로 AWS ELB (Classic Type) 를 자동으로 생성하여 Ingress Controller 에 연결하고 있다. 그렇기 때문에 Ingress Controller 를 배포할 때 Service Type을 특정 NodePort 를 지정/오픈하여 연결점을 알아야 한다.

예를 들면 아래와 같이 value 값을 override 해야 한다.

controller:
  replicaCount: 2
  service:
    externalTrafficPolicy: Local
    type: NodePort
    nodePorts:
      http: 32080
      https: 32443
      tcp:
        10254: 32081
  hostPort:
    enabled: true
tcp:
  10254: "10254:healthz"

CrossPlane 이 AWS ELB 에 대해서 Classic Type 만 지원하기 때문에 CrossPlane 을 제거하고 Network Type 으로 변경하는 것을 고민하였다. 참고로 현재의 방법은 Ingress Controller 를 실수로 삭제해도 ELB 는 그대로 남겨져 있어야 한다는 전제로 고려한 방법이다. DNS 가 ELB 와 연동되어야 하기 때문에 ELB 의 삭제 후 재생성은 DNS 전파의 시간을 필요로 하기 때문이다.

하지만 AWS 에서 권장하는 NLB 로 넘어가는 것, NodePort 를 지정하지 않아도 된다는 것, 그리고 CrossPlane 으로 ELB를 관리하지 않아도 되기 때문에 운영 측면에서 더 낫다고 판단되어 방법을 찾아보게 되었다.

해결책

Kubernetes 프로젝트 아래 Ingress Controller 의 annotation 을 사용하면 NLB 를 자동으로 생성할 수 있다.

$ helm repo add ingress-nginx https://kubernetes.github.io/ingress-nginx
$ helm repo update

$ helm search repo ingress-nginx/ingress-nginx

$ vi ingress-nginx-values.yaml
---
controller:
  replicaCount: 2
  affinity:
    podAntiAffinity:
      preferredDuringSchedulingIgnoredDuringExecution:
      - weight: 100
        podAffinityTerm:
          labelSelector:
            matchExpressions:
            - key: app.kubernetes.io/name
              operator: In
              values:
              - ingress-nginx
          topologyKey: "kubernetes.io/hostname"
  nodeSelector:
    app.kubernetes.io/name: ingress-nginx
  service:
    annotations:
#      service.beta.kubernetes.io/aws-load-balancer-name: "ahnsk-ingress"
      service.beta.kubernetes.io/aws-load-balancer-type: "nlb"
      service.beta.kubernetes.io/aws-load-balancer-proxy-protocol: "*"
#      service.beta.kubernetes.io/aws-load-balancer-target-group-attributes: "proxy_protocol_v2.enabled=true,preserve_client_ip.enabled=true,deregistration_delay.timeout_seconds=120,deregistration_delay.connection_termination.enabled=true"
    externalTrafficPolicy: Local
    type: LoadBalancer
#    healthCheckNodePort: 32081
  config:
    enable-underscores-in-headers: "true"
    use-proxy-protocol: "true"
    proxy-body-size: "10m"

nodeSelector 와 podAntiAffinity 를 사용하여 가능하면 지정노드에 분포해서 Ingress Controller 를 설치할 수 있다.

Service 의 annotations 을 사용하면 ELB 를 NLB type 으로 생성하여 자동으로 Ingress Controller 에 연결시켜 준다. 한가지 주의할 점은 aws-load-balancer-proxy-protocol 을 사용하면 aws-load-balancer-target-group-attributes 의 proxy_protocol_v2 를 enabled 해야 한다. 그러나 이 annotations 은 동작하지 않는다. 왜냐하면 aws 에서는 Ingress Controller (https://github.com/kubernetes-sigs/aws-load-balancer-controller/tree/main/helm/aws-load-balancer-controller)를 kubernetes-sigs 아래에 따로 만들어서 관리하기 때문이다. 즉 더 이상의 Nginx Ingress Controller 에 대한 기능 추가가 없다고 공표했다.

그럼에도 불구하고 Nginx Ingress Controller 를 선호한다. 이유는 Nginx 의 기능, 즉 config 를 원하는 대로 세팅할 수 있기 때문이다.

nginx 를 사용할 때 가장 많이 경험하는 에러가 2가지 있다. 하나는 header 에 '_' 값이 포함될 때 에러가 나고 다른 하나는 body-size 로 인한 에러이다. 이 2가지 값은 기본적으로 허용해 주는 것이 좋다.

마지막으로 ELB, Ingress Controller 를 거치면서 real client ip 를 알고 싶어 하는 경우가 많다. nginx 의 use-proxy-protocol: "true" 로 client ip 를 알아 낼 수 있다.

이렇게 세팅한 값으로 Ingress Controller 를 배포한다.

$ kubectl label node ip-10-0-181-43.ap-northeast-2.compute.internal app.kubernetes.io/name=ingress-nginx
$ kubectl label node ip-10-0-214-57.ap-northeast-2.compute.internal app.kubernetes.io/name=ingress-nginx

$ helm upgrade -i ingress-nginx ingress-nginx/ingress-nginx -n ingress-nginx --version 4.0.16 --create-namespace -f ingress-nginx-values.yaml

배포가 진행될 때 다음과 같이 NLB 의 Target Group 속성 중에 proxy_protocol_v2 값을 활성화 해줘야 한다. aws console 에서도 가능하지만 aws cli 를 통해서도 가능하다.

$ aws elbv2 describe-target-groups | jq .'TargetGroups[] | select(.VpcId == "vpc id 값") | .TargetGroupArn'

--- output ---
"arn:aws:elasticloadbalancing:ap-northeast-2:..."
"arn:aws:elasticloadbalancing:ap-northeast-2:..."

$ aws elbv2 modify-target-group-attributes --target-group-arn arn:aws:elasticloadbalancing:ap-northeast-2:... --attributes 'Key=proxy_protocol_v2.enabled,Value=true'

$ aws elbv2 modify-target-group-attributes --target-group-arn arn:aws:elasticloadbalancing:ap-northeast-2:... --attributes 'Key=proxy_protocol_v2.enabled,Value=true'

테스트

sample application 을 배포하여 실제 호출이 잘 되는지 확인한다. 아래는 배포 후에 http header 를 출력해 본 결과이다.

➜ ~ curl -L http://nginx-ahnsk.taco-cat.xyz
GET / HTTP/1.1
Host: nginx-ahnsk.taco-cat.xyz
X-Request-ID: 1ca37cbd4fe84f1c20e56e7ce014bd4c
X-Real-IP: 218.237.0.56
X-Forwarded-For: 218.237.0.56
X-Forwarded-Host: nginx-ahnsk.taco-cat.xyz
X-Forwarded-Port: 443
X-Forwarded-Proto: https
X-Forwarded-Scheme: https
X-Scheme: https
user-agent: curl/7.64.1
accept: */*

X-Real-IP 와 X-Forwared-For 에 실제 client ip 값이 출력되는 것을 확인할 수 있다.

마치며

Kubernetes 위에 서비스를 올린 후 사용자 접근을 오픈하기 위해서는 LB 와 Ingress Controller 를 사용해야 한다. 직접 Kubernetes 를 설치 관리하면서 Nginx 의 기능을 사용하고 싶다면 AWS Load Balancer Controller 보다는 Nginx Ingress Controller 를 활용해야 한다. 물론 IAM Account 연동 등을 위해서 혹은 EKS Cluster 를 사용한다면 AWS Load Balancer Controller 를 사용하는 것이 건강에 좋을 것이다.

Kubeflow 란 무엇인가? (a.k.a AI Platform)

seungkyua@gmail.com — Thu, 13 Jan 2022 11:17:29 +0900

2018년에 Kubernetes 상에서 돌아가는 ML Platform 인 Kubeflow 를 처음 알게된 후로 관심을 갖고 재미삼아 하다가 2022년에는 업무와 연관되어 일을 해야하기 때문에 중점으로 살펴보고자 한다. (최근에는 ML Platform 보다는 AI Platform 이라고 말하는 사람들이 많은 듯)

Kubeflow 를 KubeCon 에서 만나다

Kubeflow 개발자들을 처음 만난 것은 2019년 KubeCon in Europe (Barcelona) 이다. 초기 Kubeflow 는 Goolge 과 Arrito 가 주축이 되어 개발하고 있었는데 마침 초기 버전이 나오면서 Kubeflow 홍보를 시작하던 때 였었다.

Kubeflow 의 주 개발자는 화면에 보이는 구글의 Senior S/W Engineer 인 Jeremy Lewi 다. 당시 저 발표는 간단한 설명후에 데모 형태로 발표가 되었는데 Kubernetes 위에 Kubeflow 를 설치한 상태에서 Jupyter Notebook 을 띄어 Model 을 개발하고, Fairing 으로 Model Training 후 Model Serving 하는 것을 시연으로 보여주었다.

영상은 아래를 클릭하면 볼 수 있다.

https://www.youtube.com/watch?v=-GYiatVNemY

저녁에 Arrito 가 주최하는 Kubeflow 개발자 / 사용자와의 저녁 만남이 있었는데 거기서 Jeremy 와 이야기를 해봤을 때는 전형적인 내성적이고 약간은 고지식한 개발자라는 느낌을 받았던 기억이(물론 이건 주관적인 생각). 시간이 좀 지나니 혼자 따로 앉아 있던데.

Kubeflow 를 왜 써야 하나?

AI Platform Developer 라면 아래의 그림은 많이 봐왔을 것이다. 정 가운데에 있는 ML Code 는 데이터 사이언티스트들이 모델을 개발하는 코드인데, 이런 개발을 도와주거나 실제 서비스로 구축하기 위해서는 코드 이외에도 많은 Tool / System 들이 필요하다는 의미를 보여준다.

https://papers.nips.cc/paper/5656-hidden-technical-debt-in-machine-learning-systems.pdf

또한 위의 동영상에서도 아래와 같이 설명하고 있다.

간단하게 살펴보는 Kubeflow Architecture

아키텍처에 대한 설명은 Kubeflow document 사이트를 참고하여 간단히 설명하고자 한다.

https://www.kubeflow.org/docs/started/architecture/

ML 개발 프로세스는 Experimental Phase (실험 단계) 와 Production Phase (운영 단계) 로 나눌 수 있으며 전체 워크플로우는 아래와 같다.

실험 단계

1. 문제를 인식하고 데이터를 수집/분석

2. ML 알고리즘을 선택하여 모델을 코딩

3. 데이터를 가지고 모델 트레이닝

4. 하이퍼 파라미터 튜닝

운영 단계

1. 데이터 변환

2. 모델 트레이닝

3. 온라인/배치 예측을 위한 모델 서빙

4. 모델 성능 측정 (결과를 가지고 다시 트레이닝하거나 튜닝)

단계에 적용되는 Kubeflow 컴포넌트는 아래와 같다.

Fairing: 위성발사를 생각해보면 로켓 맨 상단에 중요 내용물인 위성을 보호하기 위해서 Fairing 으로 감싸고 있다. 모델을 안전하게 다른 시스템으로 전달하는 기능으로 python library 를 제공한다.
Pipelines: Argo workflow 기반으로 python library 를 제공하여 pipeline 을 구축할 수 있다. 예를 들면 데이터 전처리 등 반복되는 작업을 자동으로 수행할 수 있다.
Katib: 하이퍼 파라미터 튜닝을 자동으로 해주는 기능이다. 아래 그림과 같이 하이퍼 파라미터를 바꾸면서 결과를 그래프와 표로 보여준다.
KFServing: Kubeflow 에서 제공해주는 Model Serving 기능이다.

마치며

현재 Kubeflow 의 최신 버전은 v1.4 이다. 2019년 Arrito 개발자들과 만나서 논의했을 때 (당시에 v0.3 인걸로 기억한다) v1.0 으로 올리는 것이 의미있냐고 질문을 받은 적이 있다. 고객이 오픈소스의 안정성을 의심하기 때문에 기능이 조금 미흡하더라도 v1.0 으로 올리는 것이 좋겠다는 의견을 준적이 있었는데 어느덧 버전이 v1.4 까지 나왔다.(물론 그 때 이후 한참 지나서야 v1.0 이 나왔지만)

많은 기업에서 자체 AI Platform 을 만들어서 사용하는 것으로 알고 있는데, 제 개인적인 생각으로는 지금이라도 Kubeflow 로 바꾸는 것이 좋다는 생각이다. 그 이유는 이미 모두 알고 있을 것이다.

Kustomize plugin을 Docker Image 로 만들기

seungkyua@gmail.com — Sun, 31 Oct 2021 16:14:17 +0900

일반적으로 go 실행 프로그램을 도커 이미지를 만드는 경우는 많은데 plugin 을 이미지로 만드는 경우는 드문 것 같다. 이번에는 kustomize 의 plugin 을 go 로 작성하여 plugin 이미지를 만들어 본다. (kustomize plugin 을 만드는 방법이 아니라 kustomize plugin 을 도커 이미지로 만드는 내용이다.)

kustomize plugin 소스 다운로드

TACO 에서는 Kubernetes Resource yaml 파일을 kustomize 를 사용하여 만든다. 일반 kubernetes resource type (정확히는 HelmRelease type 임)이 아니라서 이를 위한 plugin 을 만들어 제공하고 있다.

github 으로 부터 소스를 다운 받는다.

$ git clone https://github.com/openinfradev/kustomize-helm-transformer.git

2 step building Dockerfile 작성

이미지 사이즈를 줄이기 위해서 2 step 으로 빌드하는 Dockerfile 을 작성한다.

아래는 Dockerfile2 파일의 첫번째 부분이다.

FROM golang:1.14-alpine3.13 AS builder
LABEL AUTHOR Seungkyu Ahn (seungkyua@gmail.com)

RUN apk update && apk add build-base

ENV HOME /root
ENV GO111MODULE on
ENV GOROOT /usr/local/go
ENV GOPATH $HOME/golang

RUN mkdir -p $HOME/.config/kustomize/plugin/openinfradev.github.com/v1/helmvaluestransformer

WORKDIR $HOME
COPY . $HOME/kustomize-helm-transformer

RUN cat kustomize-helm-transformer/README.md | grep -m 1 "* kustomize" | sed -nre 's/^[^0-9]*(([0-9]+\.)*[0-9]+).*/\1/p' > .kustomize_version
RUN go get sigs.k8s.io/kustomize/kustomize/v3@v$(cat $HOME/.kustomize_version)
RUN mv $GOPATH/bin/kustomize /usr/local/bin/

WORKDIR $HOME/kustomize-helm-transformer/plugin/openinfradev.github.com/v1/helmvaluestransformer/
RUN GOOS=linux GOARCH=amd64 go build -buildmode plugin -o HelmValuesTransformer.so
RUN mv HelmValuesTransformer.so $HOME/

go build 를 위해서 build-base 를 설치한다.
kustomize plugin 을 위해서 $HOME/.config/kustomize/plugin 디렉토리 아래 module 명 디렉토리를 만든다.
kustomize version 을 알아내기 위해서 README.md 파일을 파싱한다.
go get 으로 해당 버전의 kustomize 를 다운받아 /usr/local/bin 에 설치한다.
go build -buildmode plugin 으로 파일을 빌드한다. -o 옵션을 사용하면 원하는 파일명으로 만들 수 있다. go build 명령어 외에 go test 를 통해 unit test 를 수행하면서 so 파일을 생성할 수 도 있다.

다음은 Dockerfile2 의 두번째 부분이다.

FROM alpine:edge
LABEL AUTHOR Seungkyu Ahn (seungkyua@gmail.com)

RUN mkdir -p $HOME/.config/kustomize/plugin/openinfradev.github.com/v1/helmvaluestransformer
COPY --chown=0:0 --from=builder /root/*.so /root/.config/kustomize/plugin/openinfradev.github.com/v1/helmvaluestransformer/
COPY --chown=0:0 --from=builder /usr/local/bin/kustomize /usr/local/bin/kustomize
WORKDIR /

CMD ["/usr/local/bin/kustomize"]

base 이미지를 scratch 로 할 수 도 있지만 scratch 는 shell 명령을 쓸 수 없기 때문에 alpine 이미지를 사용하였다.

kustomize plugin 을 위해서 $HOME/.config/kustomize/plugin 디렉토리 아래 module 명 디렉토리를 만든다.
빌드된 kustomize plugin so 파일을 복사한다.
다운받은 kustomize 파일을 복사한다.

추가 확인 사항

kustomize 를 go get 으로 다운받으면 잘 동작하나 curl 로 바이너리만 받아서 실행하면 에러가 난다. 실제로 이 둘의 binary 사이즈에도 차이가 있는데 이는 추후 원인을 파악해 봐야 겠다.
go build 에 앞서 go mod tidy 와 go mod vender 를 수행하면 이미지를 실행할 때 앞의 1번과 같은 에러가 난다. 이 부분도 추후 확인해야 할 사항이다.

Github Action 을 cli 로 manual 하게 호출하기

seungkyua@gmail.com — Fri, 29 Oct 2021 10:15:23 +0900

최근 github action 을 workflow CI/CD 로 활용하는 사례가 점점 늘어나고 있다. 이전 글인 "10분만에 만드는 Docker image 저장 자동화"도 github action 을 활용하여 docker registry 에 컨테이너 이미지를 빌드하고 push 하는 방법을 설명하였다.

이번에는 github action 을 client cli 를 활용하여 원하는 시점에 manual 로 호출하는 방법을 알아보자.

1. 새로운 github repository 만들기

먼저 github repository 를 만들어 clone 한다.

$ git clone https://github.com/seungkyua/github-action-sample.git
$ cd github-action-sample

2. workflow action 파일 만들기

github action 을 위한 .github/workflows 디렉토리를 생성하고 action 파일인 hello.yaml 파일을 만든다. 디렉토리 명이 workflow 가 아닌 workflows 이니 실수하지 않게 조심하자.

$ mkdir -p .github/workflow
$ touch .github/workflows/hello.yaml

hello.yaml 은 다음과 같다.

name: Hello

on: 
  workflow_dispatch:
    inputs:
      greeting:
        required: false
        default: 'Hello'
        type: string
      name:
        required: false
        default: 'Seungkyu'
        type: string

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      # Checks-out your repository under $GITHUB_WORKSPACE, so your job can access it
      - uses: actions/checkout@v2

      - name: Run hello.sh
        run: |
          set -xe
          chmod +x .github/workflows/hello.sh
          .github/workflows/hello.sh ${{ github.event.inputs.greeting }} ${{ github.event.inputs.name }}

workflow 에서 parameter 를 받기 위해서는 workflow_dispatch: 를 명시적으로 선언하고 parameter 는 inputs 아래에 기술한다. inputs 아래 나오는 이름이 parameter 명이 되며 필수 여부, 기본값, 타입 등을 지정할 수 있다.

여기서는 'greeting' 과 'name' 이라는 2개의 parameter 를 받는 다고 선언하였다.

다음은 workflow step 인데 첫번째 actions/checkout@v2 는 현재의 github repository 소스를 다운 받는 다는 의미이다. 두번째 name: Run hello.sh 는 run: 으로 shell 을 실행하겠다는 의미이며, 앞 단계에서 소스를 다운받았으니 hello.sh 을 실행할 수 있게 되었으며, 실제로 hello.sh 을 실행하면서 parameter 를 argument 로 호출한다.

parameter 는 ${{ github.event.inputs.파라미터명 }} 과 같이 활용할 수 있다.

다음은 간단산 hello.sh 쉡스크립트 이다.

#!/bin/bash

if [ $# -eq 1 ]; then
  greeting=$1
elif [ $# -eq 2 ]; then
  greeting=$1
  name=$2
fi

echo "[hello.sh] ${greeting} ${name}\n"

이제 해당 파일들을 github 에 push 한다.

3. workflow 호출하기

github workflow client 를 다운 받는다. mac 에서는 brew 로 간단히 설치할 수 있다.

$ brew install gh

github-action-sample 소스를 clone 한 디렉토리에서 gh auth login 으로 github 에 로그인 한다.

$  gh auth login
? What account do you want to log into?  [Use arrows to move, type to filter]
> GitHub.com
  GitHub Enterprise Server

GitHub.com 을 선택하고 엔터를 치면 아래의 내용이 나온다.

? What account do you want to log into? GitHub.com
? You're already logged into github.com. Do you want to re-authenticate? (y/N) y

이미 로그인을 했기 때문에 다시 로그인 하겠다는 의미이며 처음이면 로그인 하라는 메세지가 나온다. y 로 선택하고 로그인을 하자.

? What account do you want to log into? GitHub.com
? You're already logged into github.com. Do you want to re-authenticate? Yes
? What is your preferred protocol for Git operations?  [Use arrows to move, type to filter]
> HTTPS
  SSH

HTTPS 를 선택한다.

? What account do you want to log into? GitHub.com
? You're already logged into github.com. Do you want to re-authenticate? Yes
? What is your preferred protocol for Git operations? HTTPS
? Authenticate Git with your GitHub credentials? (Y/n) y

y 로 Github credentials 로 로그인을 한다.

? What account do you want to log into? GitHub.com
? You're already logged into github.com. Do you want to re-authenticate? Yes
? What is your preferred protocol for Git operations? HTTPS
? Authenticate Git with your GitHub credentials? Yes
? How would you like to authenticate GitHub CLI?  [Use arrows to move, type to filter]
  Login with a web browser
> Paste an authentication token

token 으로 로그인을 한다.

? What account do you want to log into? GitHub.com
? You're already logged into github.com. Do you want to re-authenticate? Yes
? What is your preferred protocol for Git operations? HTTPS
? Authenticate Git with your GitHub credentials? Yes
? How would you like to authenticate GitHub CLI? Paste an authentication token
Tip: you can generate a Personal Access Token here https://github.com/settings/tokens
The minimum required scopes are 'repo', 'read:org', 'workflow'.
? Paste your authentication token: ****************************************

정상적으로 login 이 되면 아래와 같이 표시된다.

- gh config set -h github.com git_protocol https
✓ Configured git protocol
✓ Logged in as seungkyua

로그인 후에 gh workflow list 명령어로 workflow 를 조회하면 아래와 같이 Hello 란 workflow 가 있음을 알 수 있다.

➜ github-action-sample git:(main) gh workflow list
Hello  active  14639329

이를 실행해 본다.

$ gh workflow run hello.yaml -f greeting=Welcome -f name=Seungkyu

실행 중인 workflow 를 조회할 수 있다.

$ gh run list --workflow=hello.yaml
STATUS  NAME            WORKFLOW  BRANCH  EVENT              ID          ELAPSED  AGE
*       Initial commit  Hello     main    workflow_dispatch  1390917347  7s       0m

완료된 후의 workflow 를 조회하면 STATUS 가 완료로 체크되어 있다.

$ gh run list --workflow=hello.yaml
STATUS  NAME            WORKFLOW  BRANCH  EVENT              ID          ELAPSED  AGE
✓       Initial commit  Hello     main    workflow_dispatch  1390917347  15s      2m

웹 브라우저로 repository https://github.com/seungkyua/github-action-sample 에 접속하여 Action 탭의 build 를 클릭해보면 아래의 화면 처럼 '[hello.sh] Welcome Seungkyu\n' 가 출력되어 있음을 알 수 있다.

4. 활용법

manual 하게 github action 을 호출하는 부분은 다른 workflow tool 과 같이 사용할 때가 많다. 예를 들면 argo workflow 에서 하나의 단계로 github action 을 필요한 시점에 호출하여 결과를 활용하는 등으로 사용할 수 있다.

github action 은 github 의 리소스를 활용하므로 CI 에서 많은 리소스가 필요할 때는 github action 을 같이 활용하는 것도 좋은 대안이 될 것이다.

10분만에 만드는 Docker image 저장 자동화 (feat Github Action)

seungkyua@gmail.com — Fri, 3 Sep 2021 12:19:15 +0900

애플리케이션을 개발하면서 원하는 시점에 자동으로 Docker image 를 build 하고 이를 docker hub 저장소에 push 할 수 있는 방법을 소개한다. 보통은 이를 CI 로 구축하는데 CI 시스템을 따로 구축하기에는 시간과 비용이 들고 이를 유지보수 하기에도 귀찮은 면이 있다. 만약 Github 을 사용하고 있다면 10분 만에 Github Action 으로 이를 쉽게 구현할 수 있다.

1. Dockerfile 만들기

가장 먼저 해야할 일은 도커 이미지 빌드를 위한 Dockerfile 을 만드는 것이다. golang 으로 개발하고 있다면 아래와 같이 만들 수 있을 것이다. 어느 정도 최적화를 고려했지만 완전히 최적화한 부분은 아니니 자신의 환경에 맞게 변경해야 한다. Dockerfile 의 위치는 $PROJECT_HOME 디렉토리 바로 아래이다.

FROM golang:1.16.3-stretch AS builder
LABEL AUTHOR Seungkyu Ahn (seungkyua@gmail.com)

RUN mkdir -p /build
WORKDIR /build

COPY . .
RUN go mod tidy && go mod vendor
RUN CGO_ENABLED=0 GOOS=linux GOARCH=amd64 go build -o bin/server ./cmd/server

RUN mkdir -p /dist
WORKDIR /dist
RUN cp /build/bin/server ./server


FROM golang:alpine3.13

RUN mkdir -p /app
WORKDIR /app

COPY --chown=0:0 --from=builder /dist /app/
EXPOSE 9111

ENTRYPOINT ["/app/server"]
CMD ["-port", "9110"]

2. Github Action 파일 만들기

Github Action 은 규칙에 맞게 yaml 을 파일은 정해진 위치에 넣으면 Github 에서 알아서 실행시켜 준다. Action 을 실행시키는 시점은 소스가 github 에 push 되는 순간이며, 어느 branch 에 push 되었는지, Pull Request 를 했을 때 등의 실행 조건을 정의 할 수 있다.

$PROJECT_HOME 디렉토리에서 다음과 같이 디렉토리를 만든다.

$ mkdir -p .github/workflows

github action yaml 은 아래와 같다.

$ vi .github/workflows/deploy-image.yml

name: Build and Push Docker Image
on:
  push:
    branches:
      - main
jobs:
  build-and-push-image:
    runs-on: ubuntu-latest
    steps:
    - name: Checkout
      uses: actions/checkout@v2

    - name: Set up Docker Buildx
      uses: docker/setup-buildx-action@v1

    - name: Login to DockerHub
      uses: docker/login-action@v1
      with:
        username: ${{ secrets.DOCKERHUB_USERNAME }}
        password: ${{ secrets.DOCKERHUB_TOKEN }}

    - name: Build and push
      id: docker_build
      uses: docker/build-push-action@v2
      with:
        push: true
        tags: seungkyua/tks-contract:latest

처음의 on 은 해당 action 이 수행될 조건을 의미한다. push - branches - main 은 main branch 에 push 가 일어나면 수행된다는 의미이다. 그렇기 때문에 요청된 PR 을 merge 하거나 main branch 에 직접 push 하면 해당 action 이 trigger 된다.

모든 branch 의 push 에 대해서 동작하게 하려면 '*' 로 하면 된다.

job 은 pipeline 을 구성하는 부분이다. steps 처음을 보면 "name: Checkout" 부분에 uses: actions/checkout@v2 로 되어 있는데 이는 github action 으로 정의된 모듈이다. 실체 소스는 https://github.com/actions/checkout 으로 접속하면 볼 수 있으며 해당 기능은 디폴트로 action 이 수행되는 github repository 의 소스 (현재 project 의 소스)를 내려받는 기능이다. 내려 받을 repository 를 바꿀려면 변경 가능하다. (action/checkout 에 접속하여 사용법을 확인하자)

"name: Set up Docker Buildx" 부분은 builder driver 나 platform 등을 세팅하는 부분이다. 역시 자세한 부분은 https://github.com/docker/setup-buildx-action 를 확인하자.

"name: Login to DockerHub" 는 docker hub 에 접근하기 위해서 id 와 password 를 지정하는 부분이다. 이를 위해서는 github repository 의 settings 로 들어가서 좌측 하단의 secrets >> Actions 에서 Action 용 secret 을 만들어야 한다.

docker hub 에 접속할 id 와 password 에 대한 secret 을 만들고 이를 github action 에서 ${{ secrets.DOCKERHUB_USERNAME }} 와 같이 변수로 가져다 쓰는 방식이다.

마지막으로 "name: Build and push" 부분은 docker image 를 build 하고 push 하는 부분이다. 이미지 name 과 tag 는 tags 로 지정했다. Dockerfile 의 위치 및 파일명은 file 키로 변경할 수 있다. 아무런 지정을 하지 않으면 해당 프로젝트 디렉토리에 있는 Dockerfile 을 찾는다. 자세한 내용은 https://github.com/docker/build-push-action 를 참조하자.

최종적으로 파일들은 아래와 같이 존재하게 된다.

보너스로 한가지 더.

main branch 로 merge 될 때 외에도 PR 을 할 때 docker image 를 build 하고 push 할 수 는 없을까? 이미지의 tag 는 latest 가 아니라 PR 을 요청한 source 의 branch 명으로 만들고 싶을 수 있다.

이럴 때는 새로운 파일을 만들고 github 의 내장 환경 변수를 사용하면 된다. 앞부분의 on 부분과 마지막 Build and push 부분의 tags 를 다음과 같이 수정하면 된다.

$ vi .github/workflows/deploy-image-with-branch.yml

name: Create and publish a package
on:
  pull_request:
    branches:
      - main
...
...
  - name: Build and push
      id: docker_build
      uses: docker/build-push-action@v2
      with:
        push: true
        tags: seungkyua/tks-contract:${{ github.head_ref }}

Kaggle's 30 Days of ML 동영상

seungkyua@gmail.com — Tue, 17 Aug 2021 09:51:43 +0900

Kaggle 을 통해서 Machine Learning 을 배우고 Kaggle Competition 에 참여하는 방법을 알 수 있습니다.

https://www.youtube.com/playlist?list=PL98nY_tJQXZnP-k3qCDd1hljVSciDV9_N

Kaggle's 30 Days of ML

www.youtube.com

Advanced Helm chart 만들기 - chart hook편

seungkyua@gmail.com — Wed, 4 Aug 2021 10:36:04 +0900

Helm chart 의 Life cycle 을 이해하면 조금 더 고급스러운 chart 를 만들 수 있다. 예를 들면 이전 chart 의 애플리케이션에서 postgresql DB를 사용하기 때문에 사용자, 데이터베이스, 테이블을 생성해야 하는 경우를 생각해 보자. 차트가 배포될 때 애플리케이션이 실행되기 이전에 해당 작업들을 할 수 있다면 chart 배포 한 번으로 모든 배포를 끝낼 수 있으니 멋진 일이다.

Helm 에서는 chart 가 실행되기 이전에 혹은, 실행된 이후에 작업을 정의할 수 있도록 hook 기능을 제공한다. 이러한 hook 의 종류는 아래와 같다.

Annotation 값	설 명
`pre-install`	Executes after templates are rendered, but before any resources are created in Kubernetes
`post-install`	Executes after all resources are loaded into Kubernetes
`pre-delete`	Executes on a deletion request before any resources are deleted from Kubernetes
`post-delete`	Executes on a deletion request after all of the release's resources have been deleted
`pre-upgrade`	Executes on an upgrade request after templates are rendered, but before any resources are updated
`post-upgrade`	Executes on an upgrade request after all resources have been upgraded
`pre-rollback`	Executes on a rollback request after templates are rendered, but before any resources are rolled back
`post-rollback`	Executes on a rollback request after all resources have been modified
`test`	Executes when the Helm test subcommand is invoked ( view test docs)

hook 을 정의하는 것은 Annotation 으로 하며, 앞에서 설명한 시나리오의 경우에는 pre-install hook 을 사용하는 것이 적절하기 때문에 "helm.sh/hook": pre-install 로 설정한다. 또한 이런 단발성 호출의 경우에는 Job 으로 설정하는 것이 좋다.

apiVersion: batch/v1
kind: Job
metadata:
...
  annotations:
    "helm.sh/hook": pre-install
    "helm.sh/hook-weight": "1"
    "helm.sh/hook-delete-policy": before-hook-creation

hook-weight 는 낮을 수록 우선순위가 높으며, hook-delete-policy 의 before-hook-creation 은 hook 으로 실행된 리소스를 다음 hook 이 실행될 때 까지 지우지 않고 남겨둔다는 의미이다. policy 는 아래와 같이 3가지가 있다.

Annotation Value	Description
`before-hook-creation`	Delete the previous resource before a new hook is launched (default)
`hook-succeeded`	Delete the resource after the hook is successfully executed
`hook-failed`	Delete the resource if the hook failed during execution

그럼 postgresql 을 설치하고 사용자, 데이터베이스, 테이블을 생성하는 pre-install hook 을 작성해 보자.

1. postgresql 설치

bitnami chart repo 에서 postgresql 을 다운받아 설치한다.

$ helm repo add bitnami https://charts.bitnami.com/bitnami
$ helm repo update
$ helm upgrade -i postgresql bitnami/postgresql --version 10.8.0 -n decapod-db --create-namespace \
--set postgresqlPassword=password \
--set persistence.enabled=true \
--set persistence.storageClass=rbd \
--set persistence.size=10Gi

chart 의 value 값을 필요한 부분만 override 하였다. db user 는 postgres 이며 db password는 password 로 설치했다. 테스트 환경에서는 외부 스토리지를 제공하고 있어 10Gi 로 설정하였다.

$ kubectl get pods -n decapod-db
NAME                      READY   STATUS    RESTARTS   AGE
postgresql-postgresql-0   1/1     Running   0          35h


$ kubectl get svc -n decapod-db
NAME                  TYPE        CLUSTER-IP     EXTERNAL-IP   PORT(S)    AGE
postgresql            ClusterIP   10.233.46.14   <none>        5432/TCP   35h
postgresql-headless   ClusterIP   None           <none>        5432/TCP   35h

2. pre-install hook 만들기

chart 가 설치될 때 한 번 실행되면 되므로 Job 타입으로 리소스를 작성한다. psql 명령을 사용할 수 있는 컨테이너 이미지를 활용하고 수행할 명령어들은 쉘 스크립트로 작성하였다.

{chart_source_home}/templates/pre-install-job.yaml

apiVersion: batch/v1
kind: Job
metadata:
  name: {{ include "tks-contract.fullname" . }}
  namespace: {{ .Values.namespace }}
  labels:
    {{- include "tks-contract.labels" . | nindent 4 }}
  annotations:
    "helm.sh/hook": pre-install
    "helm.sh/hook-weight": "-5"
    "helm.sh/hook-delete-policy": before-hook-creation
spec:
  template:
    metadata:
      name: {{ include "tks-contract.fullname" . }}
    spec:
      restartPolicy: Never
      containers:
      - name: pre-install-job
        image: "bitnami/postgresql:11.12.0-debian-10-r44"
        env:
        - name: DB_ADMIN_USER
          value: {{ .Values.db.adminUser }}
        - name: PGPASSWORD
          value: {{ .Values.db.adminPassword }}
        - name: DB_NAME
          value: {{ .Values.db.dbName }}
        - name: DB_USER
          value: {{ .Values.args.dbUser }}
        - name: DB_PASSWORD
          value: {{ .Values.args.dbPassword }}
        - name: DB_URL
          value: {{ .Values.args.dbUrl }}
        - name: DB_PORT
          value: "{{ .Values.args.dbPort }}"
        command:
        - /bin/bash
        - -c
        - -x
        - |
          # check if ${DB_NAME} database already exists.
          psql -h ${DB_URL} -p ${DB_PORT} -U ${DB_ADMIN_USER} -lqt | cut -d \| -f 1 | grep -qw ${DB_NAME}
          if [[ $? -ne 0 ]]; then
            psql -h ${DB_URL} -p ${DB_PORT} -U ${DB_ADMIN_USER} -c "CREATE DATABASE ${DB_NAME};"
          fi

          # check if ${DB_USER} user already exists.
          psql -h ${DB_URL} -p ${DB_PORT} -U ${DB_ADMIN_USER} -tc '\du' | cut -d \| -f 1 | grep -qw ${DB_USER}
          if [[ $? -ne 0 ]]; then
            psql -h ${DB_URL} -p ${DB_PORT} -U ${DB_ADMIN_USER} -c "create user ${DB_USER} SUPERUSER password '${DB_PASSWORD}';"
          fi

          # check if contracts table in tks database already exists.
          psql -h ${DB_URL} -p ${DB_PORT} -U ${DB_ADMIN_USER} -d ${DB_NAME} -tc '\dt' | cut -d \| -f 2 | grep -qw contracts
          if [[ $? -ne 0 ]]; then
            echo """
              \c ${DB_NAME};
              CREATE TABLE contracts
              (
                  contractor_name character varying(50) COLLATE pg_catalog."default",
                  id uuid primary key,
                  available_services character varying(50)[] COLLATE pg_catalog."default",
                  updated_at timestamp with time zone,
                  created_at timestamp with time zone
              );
              CREATE UNIQUE INDEX idx_contractor_name ON contracts(contractor_name);
              ALTER TABLE contracts CLUSTER ON idx_contractor_name;
              INSERT INTO contracts(
                contractor_name, id, available_services, updated_at, created_at)
                VALUES ('tester', 'edcaa975-dde4-4c4d-94f7-36bc38fe7064', ARRAY['lma'], '2021-05-01'::timestamp, '2021-05-01'::timestamp);

              CREATE TABLE resource_quota
              (
                  id uuid primary key,
                  cpu bigint,
                  memory bigint,
                  block bigint,
                  block_ssd bigint,
                  fs bigint,
                  fs_ssd bigint,
                  contract_id uuid,
                  updated_at timestamp with time zone,
                  created_at timestamp with time zone
              );
            """ | psql -h ${DB_URL} -p ${DB_PORT} -U ${DB_ADMIN_USER}
          fi

{chart_source_home}/values.yaml

args:
  port: 9110
  dbUrl: postgresql.decapod-db.svc
  dbPort: 5432
  dbUser: tksuser
  dbPassword: password

db:
  adminUser: postgres
  adminPassword: password
  dbName: tks

컨테이너에서 필요한 값들(db superuser admin 과 password, db url, db port 등)은 env 로 전달한다. 참고로 postgresql 은 psql 로 접속할 때 패스워드를 전달하는 아규먼트가 없다. 대신 환경 변수로 다음과 같이 설정하면 패스워드를 사용하여 접속할 수 있다. ($ export PGPASSWORD=password)

먼저 DB 에 해당 database 가 존재하는 조회하고 없으면 database 를 생성한다.
DB User 가 존재하는지 조회하고 없으면 새로운 DB User 를 생성한다.
Table 이 존재하는지 조회하고 없으면 Table 을 생성한다. Table 을 생성하기 위해 psql 로 접속 시에 해당 database 에 접속할 수 있지만 (-d database명 옵션 사용), "\c database명" 으로 database 를 선택할 수 있다는 것을 보여주기 위해 이 부분을 추가하였다.

chart 를 배포하면 다음과 같이 job 이 실행됨을 알 수 있다.

$ kubectl get pods -n tks
NAME                               READY   STATUS      RESTARTS   AGE
tks-contract-h5468                 0/1     Completed   0          31h


$ kubectl logs tks-contract-h5468 -n tks
+ psql -h postgresql.decapod-db.svc -p 5432 -U postgres -lqt
+ cut -d '|' -f 1
+ grep -qw tks
+ [[ 0 -ne 0 ]]
+ psql -h postgresql.decapod-db.svc -p 5432 -U postgres -tc '\du'
+ cut -d '|' -f 1
+ grep -qw tksuser
+ [[ 0 -ne 0 ]]
+ psql -h postgresql.decapod-db.svc -p 5432 -U postgres -d tks -tc '\dt'
+ cut -d '|' -f 2
+ grep -qw contracts
+ [[ 0 -ne 0 ]]

10분만에 만드는 쿠버네티스 Helm chart

seungkyua@gmail.com — Thu, 29 Jul 2021 15:40:04 +0900

쿠버네티스에 서비스를 배포하기 위해 사용하는 대표적인 방법중에 하나가 바로 Helm chart 이다. 한마디로 말해서 Helm chart 는 쿠버네티스 용도의 패키징된 s/w 라 할 수 있다. Helm chart 문법은 go template 을 활용하였기 때문에 go template 을 안다면 조금 더 쉽게 이해할 수 있다.

여기서 설명하는 내용은 사전에 쿠버네티스 클러스터가 있으며 kubectl 로 api 에 접근할 수 있는 환경이 있다는 것을 가정한다.

그럼 도커 이미지를 가지고 쿠버네티스에 Helm 으로 배포할 수 있는 Helm chart 를 만들어 보자.

먼저 Helm (v3)을 설치한다.

$ curl -fsSL -o get_helm.sh https://raw.githubusercontent.com/helm/helm/master/scripts/get-helm-3
$ chmod 700 get_helm.sh
$ ./get_helm.sh

$ helm version
version.BuildInfo{Version:"v3.4.0", GitCommit:"7090a89efc8a18f3d8178bf47d2462450349a004", GitTreeState:"clean", GoVersion:"go1.14.10"}

Helm 버전은 틀릴 수 있는데 v.3.0.0 이상이면 상관없다.

1. 기본 코드 생성하기

아무 디렉토리로 이동해서 아래의 명령어로 기본 코드를 생성한다. (여기서 예제는 gRpc 기반의 tks-contract 이라는 프로그램을 기반으로 했다)

$ helm create tks-contract

helm create 명령어는 tks-contract 디렉토리를 만들고 아래와 같은 구조로 디렉토리와 샘플 코드를 자동으로 만들어 준다. 그 구조는 다음과 같다.

$ tree tks-contract    
tks-contract
├── Chart.yaml
├── charts
├── templates
│   ├── NOTES.txt
│   ├── _helpers.tpl
│   ├── deployment.yaml
│   ├── hpa.yaml
│   ├── ingress.yaml
│   ├── service.yaml
│   ├── serviceaccount.yaml
│   └── tests
│       └── test-connection.yaml
└── values.yaml

3 directories, 10 files

Chart.yaml 은 chart 에 대한 기본적인 정보가 있는 파일이다. chart 명, chart 버전, chart 설명 등을 적을 수 있으며, 지금은 별로 바꿀 내용이 없다.

charts 디렉토리는 의존성을 관리한다. 예를 들면 DB를 이용하는 웹 애플리케이션 chart 를 만들 때 DB 가 설치되어야 한다면 여기에 chart 를 넣거다 chart repo 에 존재하는 chart 의 링크를 기술 할 수 있다. 이 것도 지금은 바꿀 내용이 없다.

templates 디렉토리는 가장 중요한 디렉토리다. 이 디렉토리 안에는 쿠버네티스 리소스 yaml 파일들이 (예를 들면, Deployment, Service 와 같은 리소스 정의 파일) 위치한다.

values.yaml 파일은 한마디로 변수들을 정의한 파일이다. templates 디렉토리 안에 있는 yaml 파일들의 특정 변수 값을 치환하고 싶을 때 값을 선언해 놓는 곳이다. 일반적으로 key: value 형태로 기술한다.

2. Template 작성 방법

먼저 간단한 templates 디렉토리 안의 service.yaml 을 변경해 보자.

apiVersion: v1
kind: Service
metadata:
  name: {{ include "tks-contract.fullname" . }}
  namespace: {{ .Values.namespace }}
  labels:
    {{- include "tks-contract.labels" . | nindent 4 }}
spec:
  type: {{ .Values.service.type }}
  ports:
    - port: {{ .Values.service.port }}
      targetPort: {{ .Values.args.port }}
      protocol: TCP
  selector:
    {{- include "tks-contract.selectorLabels" . | nindent 4 }}

go 템플릿을 사용하기 때문에 {{ }} 기호로 값을 치환한다는 것을 알 수 있다. 일반적으로 values.yaml 파일에 정의된 값을 치환할 수 있게 적혀있다. 가령 {{ .Values.namespace }} 는 values.yaml 파일의 namespace 를 키로 하는 값을 가져와서 치환하라는 의미이다. 실제 values.yaml 에는 아래와 같이 되어 있다.

namespace: tks
service:
  type: LoadBalancer
  port: 9110

values.yaml 파일의 service 아래의 type 을 키로 하는 값, 즉 LoadBalancer 라는 값을 가져오기 위해서는 {{ .Values.service.type }} 으로 적어주면 된다.

마지막 라인의 {{- include "tks-contract.selectorLabels" . | nindent 4 }} 와 같이 include 는 정의된 템플릿 호출을 의미한다. 즉 tks-contract.selectorLabels 라는 정의된 템플릿을 호출했다고 할 수 있다. 템플릿 정의들은 보통 templates 디렉토리 아래 _helpers.tpl 파일에 정의하며 define 으로 선언되어 있다. _helpers.tpl 파일의 일부를 살펴보자.

{{/*
Selector labels
*/}}
{{- define "tks-contract.selectorLabels" -}}
app.kubernetes.io/service: tks
app.kubernetes.io/name: {{ include "tks-contract.name" . }}
{{- end }}

{{/* */}} 은 주석처리이다. 그 아래에 {{- define "tks-contract.selectorLabels" -}} ... {{- end }} 은 템플릿 정의이다.

{{- include "tks-contract.selectorLabels" . | nindent 4 }} 에서 {{- 는 맨앞에 쓰였을 때 {{ }} 코드가 차지하는 영역의 줄바꿈과 공백을 없애라는 뜻이며 . 은 values.yaml 에 있는 모든 변수들을 아규먼트로 넘긴다는 뜻이다. 마지막으로 | 는 shell 에서의 파이프라인과 동일하고 nindent 4 는 결과를 프린트 할 때 공백 4개를 멀티라인으로 계속 들여쓰라는 의미이다.

정리해 보면 service.yaml 과 _helper.tpl 파일을 이 활용되어 아래와 같이 작동된다는 것을 알 수 있다.

## service.yaml
  selector:
    {{- include "tks-contract.selectorLabels" . | nindent 4 }}

+

## _helpers.tpl
{{- define "tks-contract.selectorLabels" -}}
app.kubernetes.io/service: tks
app.kubernetes.io/name: {{ include "tks-contract.name" . }}
{{- end }}


================ 결과 ===============
  selector:
    app.kubernetes.io/service: tks
    app.kubernetes.io/name: tks-contract

app.kubernetes.io/service: tks 와 app.kubernetes.io/name: tks-contract 가 들여쓰기 4 만큼 프린트 됐다. 물론 _helpers.tpl 내의 템플릿 정의를 찾아보면 {{ include "tks-contract.name" . }} 의 결과 값은 tks-contract 이다.

그리고 NOTES.txt 에 적힌 내용은 chart 가 배포되고 나서 터미널에 프린트된다.

3. 전체 소스 작성

코드를 원하는 값으로 수정하고 배포될 때의 최종 yaml 이 어떻게 될지 확인해보자.

먼저 Chart.yaml 이다.

$ vi tks-contract/Chart.yaml
apiVersion: v2
name: tks-contract
description: A Helm chart for tks-contract
type: application
version: 0.1.0
appVersion: 0.1.0

_helpers.tpl 은 selectorLabels 를 원하는 값을 넣기 위해서 49 라인만 수정하였다.

$ vi tks-contract/_helpers.tpl
...
{{/*
Selector labels
*/}}
{{- define "tks-contract.selectorLabels" -}}
app.kubernetes.io/service: tks
app.kubernetes.io/name: {{ include "tks-contract.name" . }}
{{- end }}
...

deployment.yaml 은 container 의 args 값을 추가했다.

$ vi tks-contract/templates/deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: {{ include "tks-contract.fullname" . }}
  namespace: {{ .Values.namespace }}
  labels:
    {{- include "tks-contract.labels" . | nindent 4 }}
spec:
  {{- if not .Values.autoscaling.enabled }}
  replicas: {{ .Values.replicaCount }}
  {{- end }}
  selector:
    matchLabels:
      {{- include "tks-contract.selectorLabels" . | nindent 6 }}
  template:
    metadata:
      {{- with .Values.podAnnotations }}
      annotations:
        {{- toYaml . | nindent 8 }}
      {{- end }}
      labels:
        {{- include "tks-contract.selectorLabels" . | nindent 8 }}
    spec:
      {{- with .Values.imagePullSecrets }}
      imagePullSecrets:
        {{- toYaml . | nindent 8 }}
      {{- end }}
      serviceAccountName: {{ include "tks-contract.serviceAccountName" . }}
      securityContext:
        {{- toYaml .Values.podSecurityContext | nindent 8 }}
      containers:
        - name: {{ .Chart.Name }}
          securityContext:
            {{- toYaml .Values.securityContext | nindent 12 }}
          image: "{{ .Values.image.repository }}:{{ .Values.image.tag | default .Chart.AppVersion }}"
          imagePullPolicy: {{ .Values.image.pullPolicy }}
          ports:
            - name: tks-contract
              containerPort: {{ .Values.args.port }}
              protocol: TCP
          command:
            - /app/server
          args: [
            "-port", "{{ .Values.args.port }}",
            "-dbhost", "{{ .Values.args.dbUrl }}",
            "-dbport", "{{ .Values.args.dbPort }}",
            "-dbuser", "{{ .Values.args.dbUser }}",
            "-dbpassword", "{{ .Values.args.dbPassword }}",
            "-info-address", "{{ .Values.args.tksInfoAddress }}",
            "-info-port", "{{ .Values.args.tksInfoPort }}"
          ]
          resources:
            {{- toYaml .Values.resources | nindent 12 }}
      {{- with .Values.nodeSelector }}
      nodeSelector:
        {{- toYaml . | nindent 8 }}
      {{- end }}
      {{- with .Values.affinity }}
      affinity:
        {{- toYaml . | nindent 8 }}
      {{- end }}
      {{- with .Values.tolerations }}
      tolerations:
        {{- toYaml . | nindent 8 }}
      {{- end }}

조건절은 {{- if }} 혹은 {{- if not }} {{ end }} 로 사용할 수 있고 {{- with 키 }} {{ end }} 는 with 절 안에서는 구조상 해당 키 아래의 값들을 사용하겠다는 의미이다. {{- toYaml 키 }} 는 키의 값을 그대로 Yaml 로 프린트 해 준다.

nodeSelector 를 예를 들어 보자.

## deployment.yaml
      {{- with .Values.nodeSelector }}
      nodeSelector:
        {{- toYaml . | nindent 8 }}
      {{- end }}

+

## values.yaml
nodeSelector:
  taco-tks: enabled


============ 결과 =================
      nodeSelector:
        taco-tks: enabled

values.yaml 에 nodeSelector 키 아래에 taco-tks: enabled 라는 값을 그대로 toYaml 로 프린트 한다.

service.yaml 전체는 다음과 같다.

$ vi tks-contract/templates/service.yaml
apiVersion: v1
kind: Service
metadata:
  name: {{ include "tks-contract.fullname" . }}
  namespace: {{ .Values.namespace }}
  labels:
    {{- include "tks-contract.labels" . | nindent 4 }}
spec:
  type: {{ .Values.service.type }}
  ports:
    - port: {{ .Values.service.port }}
      targetPort: {{ .Values.args.port }}
      protocol: TCP
  selector:
    {{- include "tks-contract.selectorLabels" . | nindent 4 }}

values.yaml 에 전체 값을 넣는다.

$ vi tks-contract/values.yaml

replicaCount: 1

namespace: tks

image:
  repository: docker.io/seungkyu/tks-contract
  pullPolicy: Always
  tag: "latests"

imagePullSecrets: []
nameOverride: "tks-contract"
fullnameOverride: "tks-contract"

serviceAccount:
  create: true
  annotations: {}
  name: "tks-info"

args:
  port: 9110
  dbUrl: postgresql.decapod-db.svc
  dbPort: 5432
  dbUser: tksuser
  dbpassword: tkspassword
  tksInfoAddress: tks-info.tks.svc
  tksInfoPort: 9110

podAnnotations: {}

podSecurityContext: {}
  # fsGroup: 2000

securityContext: {}
  # capabilities:
  #   drop:
  #   - ALL
  # readOnlyRootFilesystem: true
  # runAsNonRoot: true
  # runAsUser: 1000

service:
  type: LoadBalancer
  port: 9110

ingress:
  enabled: false
  annotations: {}
  hosts:
    - host: chart-example.local
      paths: []
  tls: []
  #  - secretName: chart-example-tls
  #    hosts:
  #      - chart-example.local

resources: {}
  # We usually recommend not to specify default resources and to leave this as a conscious
  # choice for the user. This also increases chances charts run on environments with little
  # resources, such as Minikube. If you do want to specify resources, uncomment the following
  # lines, adjust them as necessary, and remove the curly braces after 'resources:'.
  # limits:
  #   cpu: 100m
  #   memory: 128Mi
  # requests:
  #   cpu: 100m
  #   memory: 128Mi

autoscaling:
  enabled: false
  minReplicas: 1
  maxReplicas: 100
  targetCPUUtilizationPercentage: 80
  # targetMemoryUtilizationPercentage: 80

nodeSelector:
  taco-tks: enabled

tolerations: []

affinity: {}

마지막으로 배포후 프린트될 내용은 NOTES.txt 을 수정한다.

$ vi tks-contract/templates/NOTES.txt
TKS-Contract
{{- if contains "LoadBalancer" .Values.service.type }}
     NOTE: It may take a few minutes for the LoadBalancer IP to be available.
           You can watch the status of by running 'kubectl get --namespace {{ .Values.namespace }} svc -w {{ include "tks-contract.fullname" . }}'
  export SERVICE_IP=$(kubectl get svc --namespace {{ .Values.namespace }} {{ include "tks-contract.fullname" . }} --template "{{"{{ range (index .status.loadBalancer.ingress 0) }}{{.}}{{ end }}"}}")
  gRPC Call => $SERVICE_IP:{{ .Values.service.port }}
{{- end }}

4. 결과 확인

작성된 chart 는 아래 명령어로 최종 yaml 이 어떻게 변환되어 배포되는지 dry-run 으로 확인할 수 있다.

$ helm upgrade -i tks-contract ./tks-contract --dry-run --debug

---
# Source: tks-contract/templates/serviceaccount.yaml
apiVersion: v1
kind: ServiceAccount
metadata:
  name: tks-info
  labels:
    helm.sh/chart: tks-contract-0.1.0
    app.kubernetes.io/service: tks
    app.kubernetes.io/name: tks-contract
    app.kubernetes.io/version: "0.1.0"
    app.kubernetes.io/managed-by: Helm
---
# Source: tks-contract/templates/service.yaml
apiVersion: v1
kind: Service
metadata:
  name: tks-contract
  namespace: tks
  labels:
    helm.sh/chart: tks-contract-0.1.0
    app.kubernetes.io/service: tks
    app.kubernetes.io/name: tks-contract
    app.kubernetes.io/version: "0.1.0"
    app.kubernetes.io/managed-by: Helm
spec:
  type: LoadBalancer
  ports:
    - port: 9110
      targetPort: 9110
      protocol: TCP
  selector:
    app.kubernetes.io/service: tks
    app.kubernetes.io/name: tks-contract
---
# Source: tks-contract/templates/deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: tks-contract
  namespace: tks
  labels:
    helm.sh/chart: tks-contract-0.1.0
    app.kubernetes.io/service: tks
    app.kubernetes.io/name: tks-contract
    app.kubernetes.io/version: "0.1.0"
    app.kubernetes.io/managed-by: Helm
spec:
  replicas: 1
  selector:
    matchLabels:
      app.kubernetes.io/service: tks
      app.kubernetes.io/name: tks-contract
  template:
    metadata:
      labels:
        app.kubernetes.io/service: tks
        app.kubernetes.io/name: tks-contract
    spec:
      serviceAccountName: tks-info
      securityContext:
        {}
      containers:
        - name: tks-contract
          securityContext:
            {}
          image: "docker.io/seungkyu/tks-contract:latests"
          imagePullPolicy: Always
          ports:
            - name: tks-contract
              containerPort: 9110
              protocol: TCP
          command:
            - /app/server
          args: [
            "-port", "9110",
            "-dbhost", "postgresql.decapod-db.svc",
            "-dbport", "5432",
            "-dbuser", "tksuser",
            "-dbpassword", "",
            "-info-address", "tks-info.tks.svc",
            "-info-port", "9110"
          ]
          resources:
            {}
      nodeSelector:
        taco-tks: enabled

NOTES:
TKS-Contract
     NOTE: It may take a few minutes for the LoadBalancer IP to be available.
           You can watch the status of by running 'kubectl get --namespace tks svc -w tks-contract'
  export SERVICE_IP=$(kubectl get svc --namespace tks tks-contract --template "{{ range (index .status.loadBalancer.ingress 0) }}{{.}}{{ end }}")
  gRPC Call => $SERVICE_IP:9110

Cluster API 로 AWS에 Kubernetes 설치하기(2)

seungkyua@gmail.com — Fri, 16 Jul 2021 17:30:42 +0900

이전 글은 Cluster API 가 어떤 것이고 어떻게 동작하는지를 알아봤다면 이번에는 AWS 에 Cluster API를 이용하여 Kubernetes 를 쉽게 설치하는 방법을 설명한다. 사실 AWS를 어느 정도 알고있어야 (특히 VPC, Subnet, Route Table, Nat Gateway, Internet Gateway 같은 네트워크) 해당 내용들을 이해하기가 쉽기 때문에 Cluster API 로 구현되는 최종 Kubernetes Cluster 구성에 대해서 먼저 설명하겠다.

특정 리전 (여기서는 서울)에 3개의 가용존(AZ1~3)에 Kubernetes Master 와 Node 가 설치되게 된다. 하나의 AZ에는 public subnet 과 private subnet 이 만들어지며 public subnet은 인터넷과 통하는 Internet Gateway 와 연결되어 있다. 네트워크 통신을 위해서는 Route Table 을 통해서 default gateway (0.0.0.0/0)를 설정해야 하는데 public subnet 은 Internet Gateway 를 private subnet 은 EIP 가 할당되어 있는 NAT gateway 를 설정한다.

AWS 에서는 Internet Gateway 와 연결되어 있는데 subnet 을 public subnet 으로 명명하며 public IP 가 할당되는 자원들은 모두 public subnet 에 생성한다. 그 외의 subnet 은 private subnet 이라 명명하는데, 이 때 외부 outbound 연결을 하기 위해서는 public subnet 에 NAT Gateway 를 만들어 활용한다. 보라색 점선이 Internet Gateway 와 NAT Gateway 로 default gateway 를 설정한 내용을 보여준다.

요약하면 AWS 에서의 네트워크는 Subnet, Route table, Gateway (Internet 혹은 NAT) 로 구성된다.

모든 VM (Control plane과 Node) instance는 private subnet에 생성되어 외부에서 직접 VM 으로 접속하는 경로를 차단한다. 필요에 따라 외부의 Inbound 를 트래픽을 가능하게 하려면 Load Balancer 를 통해서 연결한다(물론 Internal LB도 가능하다). Load Balancer 가 private subent 의 VM 에 연결되기 위해서는 public subnet 이 LB에 등록되어야 한다. 다이어그램에서 이를 표현한 것이 초록색 점선이다. LB 와 Control plane 을 연결한 것은 API Server 가 LB 에 등록되어 로드밸랜싱된다는 의미이며, 고객 서비스의 연결은 Node VM 에 연결될 수 있다. 이 때 Service 리소스의 Type 을 LoadBalancer 로 지정하면 자동으로 연결된다.

이 기능들이 가능한 이유는 Kubernetes 에 Cloud provider controller 가 내장되어 있기 때문이다. 하지만 이 기능은 deprecated 될 예정으로 버전 1.23 부터는 소스가 분리될 예정이다.

또 한가지 일반적인 방법으로 설치하면 그림의 내용과 같이 모든 Node VM 이 AZ1 의 private subnet 에 몰려서 생성된다. 이는 가용성에 문제가 될 수 있으며 이를 해결하기 위해서는 아직은 experimental 버전인 MachinePool 기능을 사용해야 한다.

이제 본격적으로 Cluster API 로 Kubernetes Cluster 를 설치해 보자.

이전 글을 보면 Management cluster 에 Cluster API Controller 를 설치한 후 Custom Resource (CR) 를 생성하면 자동으로 Workload cluster 가 생성된다는 것을 설명하였다. 이를 잘 기억해 두고 Management cluster 는 존재한다는 가정하에 시작한다(인터넷에서 조회해보면 Kind 로 쉽게 Management cluster 를 구성하는 방법을 찾을 수 있다).

1. clusterctl 설치

clusterctl 은 Managed cluster 에 Cluster API controller 를 설치하고 Workload cluster 를 위한 CR 생성을 도와주는 도구이다.

$ curl -L https://github.com/kubernetes-sigs/cluster-api/releases/download/v0.3.20/clusterctl-linux-amd64 -o clusterctl
$ chmod +x ./clusterctl
$ mv ./clusterctl /usr/local/bin/clusterctl
$ clusterctl version
=== output ===
clusterctl version: &version.Info{Major:"0", Minor:"3", GitVersion:"v0.3.20", GitCommit:"ea9dc4bdc2a9938325aab3817ece3e654873aaab", GitTreeState:"clean", BuildDate:"2021-06-30T22:10:51Z", GoVersion:"go1.13.15", Compiler:"gc", Platform:"linux/amd64"}

2. clusterawsadm 설치

clusterawsadm 은 aws 에 필요한 Role 과 Policy 를 자동으로 생성해 주는 도구이다.

$ curl -L https://github.com/kubernetes-sigs/cluster-api-provider-aws/releases/download/v0.6.6/clusterawsadm-linux-amd64 -o clusterawsadm
$ chmod +x clusterawsadm
$ mv ./clusterawsadm /usr/local/bin/clusterawsadm
$ clusterawsadm version
=== output ===
clusterawsadm version: &version.Info{Major:"0", Minor:"6", GitVersion:"v0.6.6-4-d4593daa95fb96-dirty", GitCommit:"d4593daa95fb961be91dc6db869f26ca4359ebc0", GitTreeState:"dirty", BuildDate:"2021-06-01T20:05:33Z", GoVersion:"go1.13.15", AwsSdkVersion:"v1.36.26", Compiler:"gc", Platform:"linux/amd64"}

3. awscli 및 jq 설치

$ curl -L https://awscli.amazonaws.com/awscli-exe-linux-x86_64-2.2.13.zip -o awscliv2.zip
$ unzip awscliv2.zip
$ ./aws/install
$ aws --version
=== output ===
aws-cli/2.2.13 Python/3.8.8 Linux/4.4.0-87-generic exe/x86_64.ubuntu.16 prompt/off

$ mkdir -p ~/.aws
$ vi ~/.aws/credentials
[default]
aws_access_key_id=<< access_key_id >>
aws_secret_access_key=<< secret_access_key >>

$ vi ~/.aws/config
[default]
region = ap-northeast-2

4. 사전 작업

clusterawsadm 을 활용하여 IAM Role 과 Policy 를 생성한다.

## 설정이 안되어 있을 때 환경 변수로 설정한다.
$ export AWS_REGION=ap-northeast-2
$ export AWS_ACCESS_KEY_ID=<< access_key_id >>
$ export AWS_SECRET_ACCESS_KEY=<< secret_access_key >>

$ clusterawsadm bootstrap iam create-cloudformation-stack

Workload cluster VM 에 접속할 key pair 를 Import 한다.

$ aws ec2 import-key-pair \
  --key-name capi-seungkyu \
  --public-key-material fileb://~/.ssh/id_rsa.pub

5. Management cluster 생성

clusterctl 생성에 필요한 환경 변수를 다음과 같이 설정한다.

$ clusterawsadm bootstrap credentials encode-as-profile
=== output ===
<< crendentials >>

$ vi env.sh
export AWS_REGION=ap-northeast-2
export AWS_ACCESS_KEY_ID=<< access_key_id >>
export AWS_SECRET_ACCESS_KEY=<< secret_access_key >>
export AWS_B64ENCODED_CREDENTIALS=<< crendentials >>

$ source ./env.sh

clusterctl init 명령어를 사용하여 Management cluster 를 생성한다.

$ clusterctl init --core cluster-api:v0.3.20 --infrastructure aws:v0.6.6 --bootstrap kubeadm:v0.3.20 --control-plane kubeadm:v0.3.20 -v5
=== output ===
...
Fetching providers
Installing cert-manager
Waiting for cert-manager to be available...
...
Installing Provider="cluster-api" Version="v0.3.20" TargetNamespace="capi-system"
...
Installing Provider="bootstrap-kubeadm" Version="v0.3.20" TargetNamespace="capi-kubeadm-bootstrap-system"
...
Installing Provider="control-plane-kubeadm" Version="v0.3.20" TargetNamespace="capi-kubeadm-control-plane-system"
...
Installing Provider="infrastructure-aws" Version="v0.6.6" TargetNamespace="capa-system"

Your management cluster has been initialized successfully!

You can now create your first workload cluster by running the following:

  clusterctl config cluster [name] --kubernetes-version [version] | kubectl apply -f -

6. Workload cluster 생성

필요한 환경변수를 설정하고 clusterctl config 명령어를 이용하여 CR 파일을 생성한다.

$ vi env-workload.sh
export AWS_CONTROL_PLANE_MACHINE_TYPE=t3.large
export AWS_NODE_MACHINE_TYPE=t3.large
export AWS_SSH_KEY_NAME=capi-seungkyu

$ source ./env-workload.sh

$ clusterctl config cluster capi-quickstart \
  -n capi-quickstart \
  --kubernetes-version v1.20.5 \
  --control-plane-machine-count=3 \
  --worker-machine-count=3 \
  > capi-quickstart.yaml

capi-quickstart.yaml 을 확인하면 아래와 같다.

$ cat capi-quickstart.yaml
---
apiVersion: cluster.x-k8s.io/v1alpha3
kind: Cluster
metadata:
  name: capi-quickstart
  namespace: capi-quickstart
spec:
  clusterNetwork:
    pods:
      cidrBlocks:
      - 192.168.0.0/16
  controlPlaneRef:
    apiVersion: controlplane.cluster.x-k8s.io/v1alpha3
    kind: KubeadmControlPlane
    name: capi-quickstart-control-plane
  infrastructureRef:
    apiVersion: infrastructure.cluster.x-k8s.io/v1alpha3
    kind: AWSCluster
    name: capi-quickstart
---
apiVersion: infrastructure.cluster.x-k8s.io/v1alpha3
kind: AWSCluster
metadata:
  name: capi-quickstart
  namespace: capi-quickstart
spec:
  region: ap-northeast-2
  sshKeyName: capi-seungkyu
---
apiVersion: controlplane.cluster.x-k8s.io/v1alpha3
kind: KubeadmControlPlane
metadata:
  name: capi-quickstart-control-plane
  namespace: capi-quickstart
spec:
  infrastructureTemplate:
    apiVersion: infrastructure.cluster.x-k8s.io/v1alpha3
    kind: AWSMachineTemplate
    name: capi-quickstart-control-plane
  kubeadmConfigSpec:
    clusterConfiguration:
      apiServer:
        extraArgs:
          cloud-provider: aws
      controllerManager:
        extraArgs:
          cloud-provider: aws
    initConfiguration:
      nodeRegistration:
        kubeletExtraArgs:
          cloud-provider: aws
        name: '{{ ds.meta_data.local_hostname }}'
    joinConfiguration:
      nodeRegistration:
        kubeletExtraArgs:
          cloud-provider: aws
        name: '{{ ds.meta_data.local_hostname }}'
  replicas: 3
  version: v1.20.5
---
apiVersion: infrastructure.cluster.x-k8s.io/v1alpha3
kind: AWSMachineTemplate
metadata:
  name: capi-quickstart-control-plane
  namespace: capi-quickstart
spec:
  template:
    spec:
      iamInstanceProfile: control-plane.cluster-api-provider-aws.sigs.k8s.io
      instanceType: t3.large
      sshKeyName: capi-seungkyu
---
apiVersion: cluster.x-k8s.io/v1alpha3
kind: MachineDeployment
metadata:
  name: capi-quickstart-md-0
  namespace: capi-quickstart
spec:
  clusterName: capi-quickstart
  replicas: 3
  selector:
    matchLabels: null
  template:
    spec:
      bootstrap:
        configRef:
          apiVersion: bootstrap.cluster.x-k8s.io/v1alpha3
          kind: KubeadmConfigTemplate
          name: capi-quickstart-md-0
      clusterName: capi-quickstart
      infrastructureRef:
        apiVersion: infrastructure.cluster.x-k8s.io/v1alpha3
        kind: AWSMachineTemplate
        name: capi-quickstart-md-0
      version: v1.20.5
---
apiVersion: infrastructure.cluster.x-k8s.io/v1alpha3
kind: AWSMachineTemplate
metadata:
  name: capi-quickstart-md-0
  namespace: capi-quickstart
spec:
  template:
    spec:
      iamInstanceProfile: nodes.cluster-api-provider-aws.sigs.k8s.io
      instanceType: t3.large
      sshKeyName: capi-seungkyu
---
apiVersion: bootstrap.cluster.x-k8s.io/v1alpha3
kind: KubeadmConfigTemplate
metadata:
  name: capi-quickstart-md-0
  namespace: capi-quickstart
spec:
  template:
    spec:
      joinConfiguration:
        nodeRegistration:
          kubeletExtraArgs:
            cloud-provider: aws
          name: '{{ ds.meta_data.local_hostname }}'

해당 CR 은 아래 다이어그램 구조로 매칭된다.

Cluster API 는 공통이 Abstract Class 와 같이 기본을 정의해 놓았으며, Provider 는 실제 Cloud 에 맞는 구현을 정의하였다. AWSCluster 에는 VPC, subnet, Route table 등과 같은 인프라 생성 정보를 가지고 있고 AWSMachineTemplate 은 Kubernetes Control Plane 에 대한 정보를 AWSMachineTemplate 에는 Node 정보를 갖고 있다.

CR 을 배포하여 Workload cluster 를 생성한다.

$ kubectl create ns capi-quickstart

$ kubectl apply -f capi-quickstart.yaml
=== output ===
cluster.cluster.x-k8s.io/capi-quickstart created
awscluster.infrastructure.cluster.x-k8s.io/capi-quickstart created
kubeadmcontrolplane.controlplane.cluster.x-k8s.io/capi-quickstart-control-plane created
awsmachinetemplate.infrastructure.cluster.x-k8s.io/capi-quickstart-control-plane created
machinedeployment.cluster.x-k8s.io/capi-quickstart-md-0 created
awsmachinetemplate.infrastructure.cluster.x-k8s.io/capi-quickstart-md-0 created
kubeadmconfigtemplate.bootstrap.cluster.x-k8s.io/capi-quickstart-md-0 created

kubectl 명령어를 위해 아래와 같이 kubeconfig 를 생성한다.

$ clusterctl get kubeconfig capi-quickstart -n capi-quickstart > capi-quickstart.kubeconfig

한가지 중요한 부분은 Cluster API 는 Network 모듈이나, CSI 를 설치해 주지는 않는다. 이는 추가로 설치해야 한다.

$ kubectl --kubeconfig=./capi-quickstart.kubeconfig \
  apply -f https://docs.projectcalico.org/v3.19/manifests/calico.yaml

네트워크 모듈까지 다 설치하면 정상적으로 Kubernetes Cluster 가 설치된 것을 볼 수 있다.

$ kubectl get kubeadmcontrolplane -n capi-quickstart
=== output ===
NAME                            INITIALIZED   API SERVER AVAILABLE   VERSION   REPLICAS   READY   UPDATED   UNAVAILABLE
capi-quickstart-control-plane   true          true                   v1.20.5   3          3       3


$ kubectl --kubeconfig=mycluster.kubeconfig get nodes
=== output ===
NAME                                              STATUS   ROLES                  AGE   VERSION
ip-10-0-143-5.ap-northeast-2.compute.internal     Ready    control-plane,master   23h   v1.20.5
ip-10-0-164-198.ap-northeast-2.compute.internal   Ready    <none>                 23h   v1.20.5
ip-10-0-222-84.ap-northeast-2.compute.internal    Ready    control-plane,master   23h   v1.20.5
ip-10-0-255-19.ap-northeast-2.compute.internal    Ready    <none>                 23h   v1.20.5
ip-10-0-68-113.ap-northeast-2.compute.internal    Ready    <none>                 23h   v1.20.5
ip-10-0-80-79.ap-northeast-2.compute.internal     Ready    control-plane,master   23h   v1.20.5

Cluster API 로 AWS에 Kubernetes 설치하기(1)

seungkyua@gmail.com — Thu, 24 Jun 2021 00:11:38 +0900

AWS 에서 Kubernetes 사용하는 방법은 Managed Service 인 EKS 서비스를 신청/설치 방법과 일반 VM 에 Kubernetes 를 설치하는 방법이 있다.

VM 에 Kubernetes 를 설치하는 방법은 VM 을 생성하고 필요한 Security Group 을 지정하고 Muti Control plane 에 ELB 를 연결하여 다중 Master 로 사용가능 하도록 세팅해야할 내용이 제법 있다. Kubernetes 자체 설치도 kubeadm 이나 kubespray 같은 툴을 사용해서 설치한다. - 역시 쉽지 않은 내용임에 분명하다.

Cluster API 란 ?

지금 소개하는 방법은 Kubernetes Cluster Lifecycle SIG 에서 개발하고 있는 Cluster API 로 Operator Pattern 을 활용하여 Kubernetes 를 설치하는 방법이다. Cluster API 란 Management Kubernetes Cluster 에 Custom Controller 를 설치하고 Custom Resource 를 생성하면 자동으로 Cloud 에 VM 을 생성하고 Kubernetes 를 설치하는 방법이다. Controller 로 관리하기 때문에 VM 이 죽으면 다시 살려주는 장점이 있다. Kubernetes 가 설치된 VM 이 다운되었을 때 Self healing 으로 Recovering 해준다니 정말 멋진 아이디어인 것 같다.

Cluster API 의 시작은 2년 정도 전부터 시작되었는데 초장기에는 PoC 정도였다면 지금은 어느 정도 안정화 되어 사용하기에 문제가 없다.

개념을 보면 Management Kubernetes Cluster 를 설치(Kind, Minikube 등도 가능)하고 여기에 필요한 여러 Custom Controller 를 실행시킨다. 그리고 나서 Custom Resource 를 생성하면 지정된 Cloud 에 VM 을 생성하고 Workload Kubernetes Cluster (고객이 사용할 클러스터) 를 자동으로 생성해 주는 방법이다.

Cluster API 구성도

그림에서 보면 좌측 맨 위에 Cluster API Controller 가 있다. Cluster API Controller 는 마치 java class 로 치면 Abstraction Class 의 역활과 동일하다. Cluster Pod Network, Control Plane VM 갯수, Node VM 갯수 등을 관리한다.

이렇게 정의를 하면 Boostrap provider Controller 에서 kubeadm 으로 어떻게 Kubernetes 를 설치할 지를 관리한다.

Infrastructure provider Controller 에서는 AWS, Azure, GCP 와 같이 Public Cloud 의 자원 생성을 관리한다.

마지막으로 Control Plane provider Controller 특별하게 Control Plane 의 설치를 관리한다.

우측 위는 Custom Resource 를 보여주고 있다.

Cluster API Provider Controller 와 Infrastructure Provider Controller 의 상관 관계를 보면 다음과 같다.

Cluster API 는 Infrastructure Provider 에게 이런 식으로 구현을 해야 한다고 알려주는 가이드라고 보면 된다.

이제 세부적으로 하나씩 살펴보자.

Cluster API Controller

Cluster API Controller 는 cluster 의 기본 정보를 관리하는 Controller 이다. 이 Controller 가 관리하는 Custom Resource 는 다음과 같이 4개가 있다.

clusters
machinedeployments
machinehealthchecks
machines

이 중에서 machinehealthchecks 는 AWS Provider 에서는 사용하고 있지 않으므로 이를 제외하고 나머지 3가지만 살펴보겠다.

clusters CR(Custom Resource) 는 다음과 같은 정보를 가지고 있다.

Cluster Pod Network 정보
Kubernetes API url 정보
Control Plane 을 생성하는 CR 정보
Cloud Infrastructure 로 사용되는 CR 정보

  Cluster Network:
    Pods:
      Cidr Blocks:
        192.168.0.0/16
  Control Plane Endpoint:
    Host:  capi-quickstart-apiserver-479433786.ap-northeast-2.elb.amazonaws.com
    Port:  6443
  Control Plane Ref:
    API Version:  controlplane.cluster.x-k8s.io/v1alpha3
    Kind:         KubeadmControlPlane
    Name:         capi-quickstart-control-plane
    Namespace:    capi-quickstart
  Infrastructure Ref:
    API Version:  infrastructure.cluster.x-k8s.io/v1alpha3
    Kind:         AWSCluster
    Name:         capi-quickstart
    Namespace:    capi-quickstart

machinedeployments CR 의 정보는 Kubernetes Worker Node 에 대한 일반적인 내용이며 아래의 내용을 포함한다.

Bootstrap 으로 사용될 Kubeadm Config Template
Infrastructure Provider 에 대한 VM 정보 Template
Cluster name 및 Kubernetes Version 정보

  Cluster Name:               capi-quickstart
  Min Ready Seconds:          0
  Progress Deadline Seconds:  600
  Replicas:                   3
  Revision History Limit:     1
  Selector:
    Match Labels:
      cluster.x-k8s.io/cluster-name:     capi-quickstart
      cluster.x-k8s.io/deployment-name:  capi-quickstart-md-0
  Strategy:
    Rolling Update:
      Max Surge:        1
      Max Unavailable:  0
    Type:               RollingUpdate
  Template:
    Metadata:
      Labels:
        cluster.x-k8s.io/cluster-name:     capi-quickstart
        cluster.x-k8s.io/deployment-name:  capi-quickstart-md-0
    Spec:
      Bootstrap:
        Config Ref:
          API Version:  bootstrap.cluster.x-k8s.io/v1alpha3
          Kind:         KubeadmConfigTemplate
          Name:         capi-quickstart-md-0
      Cluster Name:     capi-quickstart
      Infrastructure Ref:
        API Version:  infrastructure.cluster.x-k8s.io/v1alpha3
        Kind:         AWSMachineTemplate
        Name:         capi-quickstart-md-0
      Version:        v1.20.5

machines CR 은 Kubernetes Control Plane VM 별 정보와 Kubernetes Worker Node VM 별 정보를 갖고 있는데 둘다 아래의 정보를 동일하게 갖고 있다.

Boostrap 으로 KubeadmConfig CR 정보
Infrastructure 로서 AWSMachine CR 정보

  Bootstrap:
    Config Ref:
      API Version:     bootstrap.cluster.x-k8s.io/v1alpha3
      Kind:            KubeadmConfig
      Name:            capi-quickstart-md-0-7f4xk
      Namespace:       capi-quickstart
      UID:             7b095ef9-3380-45cc-950e-9bce8602f954
    Data Secret Name:  capi-quickstart-md-0-7f4xk
  Cluster Name:        capi-quickstart
  Infrastructure Ref:
    API Version:  infrastructure.cluster.x-k8s.io/v1alpha3
    Kind:         AWSMachine
    Name:         capi-quickstart-md-0-dcdcx
    Namespace:    capi-quickstart
    UID:          3383bd5b-1040-4577-a690-741c556d1076
  Provider ID:    aws:///ap-northeast-2a/i-090230ea1d12065ce
  Version:        v1.20.5

Bootstrap Provider Controller

Bootstrap provider controller 는 Kubernetes 를 설치하는 kubeadm 관련 정보를 가지고 있다.

kubeadmconfigs
kubeadmconfigtemplates

kubeadmconfigs 는 kubeadm 으로 kubernetes 를 설치할 때 사용하는 정보로서 Control Plane VM 별 정보와 Work Node VM별 정보를 갖고 있다.

Cluster Configuration 으로 provider 정보를 갖고 있다.
Join Configuration 으로 Token 정보를 갖고 있다.

  Cluster Configuration:
    API Server:
      Extra Args:
        Cloud - Provider:  aws
    Controller Manager:
      Extra Args:
        Cloud - Provider:  aws
    Dns:
    Etcd:
    Networking:
    Scheduler:
  Join Configuration:
    Control Plane:
      Local API Endpoint:
        Advertise Address:
        Bind Port:          0
    Discovery:
      Bootstrap Token:
        API Server Endpoint:  capi-quickstart-apiserver-479433786.ap-northeast-2.elb.amazonaws.com:6443
        Ca Cert Hashes:
          sha256:de8ef58efd55489531f681066eb77cec21a7d7f8e2a04eb41a06ad38b18d066e
        Token:                        xxxx.xxxxxxxxxxx
        Unsafe Skip CA Verification:  false
    Node Registration:
      Kubelet Extra Args:
        Cloud - Provider:  aws
      Name:                {{ ds.meta_data.local_hostname }}

kubeadmconfigtemplates 는 Worker Node 가 join 한 template 정보로 Node 명을 가진다.

  Template:
    Spec:
      Join Configuration:
        Node Registration:
          Kubelet Extra Args:
            Cloud - Provider:  aws
          Name:                {{ ds.meta_data.local_hostname }}

Infrastructure Provider Controller

Infrastructure Provider Controller 는 각각의 Cloud 의 API 를 활용하여 리소스를 관리하는 Controller 로 aws 의 경우에는 아래의 정보를 가진다.

awsclustercontrolleridentities
awsclusterroleidentities
awsclusters
awsclusterstaticidentities
awsfargateprofiles
awsmachinepools
awsmachines
awsmachinetemplates
awsmanagedclusters
awsmanagedmachinepools

이 중에서 awsclusters, awsmachines, awsmachinetemplate 3가지만 살펴본다.

awsclusters 는 aws 에 설치된 Kubernetes workload cluster 에 대한 정보를 갖고 있다.

  Bastion:
    Allowed CIDR Blocks:
      0.0.0.0/0
    Enabled:  false
  Control Plane Endpoint:
    Host:  capi-quickstart-apiserver-479433786.ap-northeast-2.elb.amazonaws.com
    Port:  6443
  Identity Ref:
    Kind:  AWSClusterControllerIdentity
    Name:  default
  Network Spec:
    Cni:
      Cni Ingress Rules:
        Description:  bgp (calico)
        From Port:    179
        Protocol:     tcp
        To Port:      179
        Description:  IP-in-IP (calico)
        From Port:    -1
        Protocol:     4
        To Port:      65535
    Subnets:
      Availability Zone:  ap-northeast-2a
      Cidr Block:         10.0.0.0/20
      Id:                 subnet-04e972e6bfcb98336
      Is Public:          true
      Nat Gateway Id:     nat-0d456fe6c4dd2ce3d
      Route Table Id:     rtb-0dfccca96ffc00732
      Tags:
        Name:                                                          capi-quickstart-subnet-public-ap-northeast-2a
        kubernetes.io/cluster/capi-quickstart:                         shared
        kubernetes.io/role/elb:                                        1
        sigs.k8s.io/cluster-api-provider-aws/cluster/capi-quickstart:  owned
        sigs.k8s.io/cluster-api-provider-aws/role:                     public
      Availability Zone:                                               ap-northeast-2a
      Cidr Block:                                                      10.0.64.0/18
      Id:                                                              subnet-06f2be3eedb46d622
      Is Public:                                                       false
      Route Table Id:                                                  rtb-00090ad5d1de60b20
      Tags:
        Name:                                                          capi-quickstart-subnet-private-ap-northeast-2a
        kubernetes.io/cluster/capi-quickstart:                         shared
        kubernetes.io/role/internal-elb:                               1
        sigs.k8s.io/cluster-api-provider-aws/cluster/capi-quickstart:  owned
        sigs.k8s.io/cluster-api-provider-aws/role:                     private
      Availability Zone:                                               ap-northeast-2b
      Cidr Block:                                                      10.0.16.0/20
      Id:                                                              subnet-02a9eed4c602fd3a2
      Is Public:                                                       true
      Nat Gateway Id:                                                  nat-050244cb7c9cff368
      Route Table Id:                                                  rtb-020e9366a2da25625
      Tags:
        Name:                                                          capi-quickstart-subnet-public-ap-northeast-2b
        kubernetes.io/cluster/capi-quickstart:                         shared
        kubernetes.io/role/elb:                                        1
        sigs.k8s.io/cluster-api-provider-aws/cluster/capi-quickstart:  owned
        sigs.k8s.io/cluster-api-provider-aws/role:                     public
      Availability Zone:                                               ap-northeast-2b
      Cidr Block:                                                      10.0.128.0/18
      Id:                                                              subnet-03880f2f847b3c21e
      Is Public:                                                       false
      Route Table Id:                                                  rtb-06b52ab77da5c5f2c
      Tags:
        Name:                                                          capi-quickstart-subnet-private-ap-northeast-2b
        kubernetes.io/cluster/capi-quickstart:                         shared
        kubernetes.io/role/internal-elb:                               1
        sigs.k8s.io/cluster-api-provider-aws/cluster/capi-quickstart:  owned
        sigs.k8s.io/cluster-api-provider-aws/role:                     private
      Availability Zone:                                               ap-northeast-2c
      Cidr Block:                                                      10.0.32.0/20
      Id:                                                              subnet-09ccabe6dd862df6a
      Is Public:                                                       true
      Nat Gateway Id:                                                  nat-030068539013d5c64
      Route Table Id:                                                  rtb-0973a222fc772ff76
      Tags:
        Name:                                                          capi-quickstart-subnet-public-ap-northeast-2c
        kubernetes.io/cluster/capi-quickstart:                         shared
        kubernetes.io/role/elb:                                        1
        sigs.k8s.io/cluster-api-provider-aws/cluster/capi-quickstart:  owned
        sigs.k8s.io/cluster-api-provider-aws/role:                     public
      Availability Zone:                                               ap-northeast-2c
      Cidr Block:                                                      10.0.192.0/18
      Id:                                                              subnet-0be3353fd3b6f1637
      Is Public:                                                       false
      Route Table Id:                                                  rtb-0854effe818750d33
      Tags:
        Name:                                                          capi-quickstart-subnet-private-ap-northeast-2c
        kubernetes.io/cluster/capi-quickstart:                         shared
        kubernetes.io/role/internal-elb:                               1
        sigs.k8s.io/cluster-api-provider-aws/cluster/capi-quickstart:  owned
        sigs.k8s.io/cluster-api-provider-aws/role:                     private
    Vpc:
      Availability Zone Selection:    Ordered
      Availability Zone Usage Limit:  3
      Cidr Block:                     10.0.0.0/16
      Id:                             vpc-070a545cb4b967dd7
      Internet Gateway Id:            igw-03a4ee0ca0f8d0f72
      Tags:
        Name:                                                          capi-quickstart-vpc
        sigs.k8s.io/cluster-api-provider-aws/cluster/capi-quickstart:  owned
        sigs.k8s.io/cluster-api-provider-aws/role:                     common
  Region:                                                              ap-northeast-2
  Ssh Key Name:                                                        capi-seungkyu

awsmachinetemplates 은 aws vm spec 에 대한 정보를 template 으로 갖고 있다. template 은 control plane 과 worker node 각 1개씩 가진다.

control plane template

  Template:
    Spec:
      Iam Instance Profile:  control-plane.cluster-api-provider-aws.sigs.k8s.io
      Instance Type:         t3.large
      Ssh Key Name:          capi-seungkyu

worker node template

  Template:
    Spec:
      Iam Instance Profile:  nodes.cluster-api-provider-aws.sigs.k8s.io
      Instance Type:         t3.large
      Ssh Key Name:          capi-seungkyu

awsmachines 은 awsmachinetemplates 으로 연결된 control plane 과 worker node 별 aws VM 에 대한 정보를 갖는다.

contol plane vm1

  Ami:
  Cloud Init:
    Secure Secrets Backend:  secrets-manager
  Iam Instance Profile:      control-plane.cluster-api-provider-aws.sigs.k8s.io
  Instance ID:               i-0433d589b68e42cd0
  Instance Type:             t3.large
  Provider ID:               aws:///ap-northeast-2c/i-0433d589b68e42cd0
  Ssh Key Name:              capi-seungkyu

Control plane Provider Controller

Control plane provider controller 는 Kubernetes control plane 에 대한 정보를 관리하는 Controller 이다.

kubeadmcontrolplanes

kubeadmcontrolplanes 은 말그래도 control plane 의 정보를 담고 있으며 앞에서 살펴본 정보들을 활용한다.

Infrastructure Template 으로 AWSMachineTemplate 을 사용
Kubeadm Config 로 Init Configuration 과 Join Configuration 정보
Replicas 개수 정보
Kubernetes version 정보

  Infrastructure Template:
    API Version:  infrastructure.cluster.x-k8s.io/v1alpha3
    Kind:         AWSMachineTemplate
    Name:         capi-quickstart-control-plane
    Namespace:    capi-quickstart
  Kubeadm Config Spec:
    Cluster Configuration:
      API Server:
        Extra Args:
          Cloud - Provider:  aws
      Controller Manager:
        Extra Args:
          Cloud - Provider:  aws
      Dns:
      Etcd:
      Networking:
      Scheduler:
    Init Configuration:
      Local API Endpoint:
        Advertise Address:
        Bind Port:          0
      Node Registration:
        Kubelet Extra Args:
          Cloud - Provider:  aws
        Name:                {{ ds.meta_data.local_hostname }}
    Join Configuration:
      Discovery:
      Node Registration:
        Kubelet Extra Args:
          Cloud - Provider:  aws
        Name:                {{ ds.meta_data.local_hostname }}
  Replicas:                  3
  Rollout Strategy:
    Rolling Update:
      Max Surge:  1
    Type:         RollingUpdate
  Version:        v1.20.5

쿠알못을 위한 쿠버네티스 입문(2)

seungkyua@gmail.com — Sun, 20 Jun 2021 12:18:48 +0900

https://www.youtube.com/watch?v=lIzAMFUKxBE&t=4s

쿠알못을 위한 쿠버네티스 입문(1)

seungkyua@gmail.com — Sun, 20 Jun 2021 12:17:00 +0900

https://www.youtube.com/watch?v=HNGEo7Kd3_k&t=3s