Tagged: Kubernetes

Kubernetes API 서버 인증서에 도메인 추가하기

Kubernetes API 서버는 http 를 통해서 쿠버네티스에 대한 연산을 제공해 준다. kubectl 명령어로 실행되는 것들은 모두 API 서버를 거쳐서 이루어진다. 하지만 API 서버는 인증서를 기반으로 통신이 이루어지는데, 이 인증서에 기재된 도메인이나 IP가 아니면 통신이 이루어지지 않는다.

kubectl 명령어 오류
ZSH
1
kubectl unable to connect to server: x509: certificate signed by unknown authority

API 서버의 인증서는 SAN 인증서여야 한다. 도메인 리스트를 가지고 있는 SAN 인증서. 현재 API 서버의 인증서 상태는 다음과 같다.

kubectl 명령어 오류
ZSH
1
2
3
4
5
6
7
8
9
10
11
12
13
14
$ openssl x509 -text -in /etc/kubernetes/pki/apiserver.crt -noout
        X509v3 extensions:
            X509v3 Key Usage: critical
                Digital Signature, Key Encipherment
            X509v3 Extended Key Usage:
                TLS Web Server Authentication
            X509v3 Basic Constraints: critical
                CA:FALSE
            X509v3 Authority Key Identifier:
                keyid:98:B6:19:7B:C4:FF:03:49:74:7D:F3:F1:7E:31:67:91:D9:2E:B5:EA
 
            X509v3 Subject Alternative Name:
                DNS:haproxy2.systemv.local, DNS:kmaster, DNS:kubernetes, DNS:kubernetes.default, DNS:kubernetes.default.svc, DNS:kubernetes.default.svc.cluster.local, DNS:ol85.systemv.local, DNS:rhel8.systemv.local, IP Address:10.96.0.1, IP Address:192.168.96.23, IP Address:192.168.96.30, IP Address:192.168.96.7
    Signature Algorithm: sha256WithRSAEncryption

위 apiserver.crt 파일 상태를 보면 SAN 에 이미 도메인과 IP 들이 들어가 있다. 내용을 보면 haproxy2.systemv.local 도메인, 192.168.96.7 IP 가 들어가 있는데 이 서버에서 API 서버와 통신이 가능하다.

만일 추가적으로 도메인, IP 를 추가하고 싶다면 어떻게 해야할까? 이에 대해서 알아본다.

kubeadm-config 업데이트

kubeadm-config 라고 불리는 ConfigMap 을 업데이트 해줘야 한다. 이를 위해서 먼저 기존이 설정을 뽑아내야 하는데 다음과 같이 하면 된다.

kubeadm-config 설정 뽑아내기
ZSH
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
$ kubectl -n kube-system get configmap kubeadm-config -o jsonpath='{.data.ClusterConfiguration}' > kubeadm.yaml
$ cat kubeadm.yaml
apiServer:
  extraArgs:
    authorization-mode: Node,RBAC
  timeoutForControlPlane: 4m0s
apiVersion: kubeadm.k8s.io/v1beta1
certificatesDir: /etc/kubernetes/pki
clusterName: kubernetes
controlPlaneEndpoint: ""
controllerManager: {}
dns:
  type: CoreDNS
etcd:
  local:
    dataDir: /var/lib/etcd
imageRepository: k8s.gcr.io
kind: ClusterConfiguration
kubernetesVersion: v1.14.4
networking:
  dnsDomain: cluster.local
  podSubnet: ""
  serviceSubnet: 10.96.0.0/12
scheduler: {}

파일 내용을 보면 SAN 리스트가 없다. 도메인이나 IP 를 SAN 으로 추가하기 위해서 apiServer 아래에 certSANs 를 추가해 준다. 이미 다른 도메인이 있다면 제거하나 추가할 수도 있다.

kubeadm.yaml 파일 수정
ZSH
1
2
3
4
5
6
7
8
9
10
11
12
13
apiServer:
  certSANs:
  - 192.168.96.23
  - rhel8.systemv.local
  - 192.168.96.30
  - ol85.systemv.local
  - 192.168.96.7
  - haproxy2.systemv.local
  extraArgs:
    authorization-mode: Node,RBAC
  timeoutForControlPlane: 4m0s
apiVersion: kubeadm.k8s.io/v1beta3
certificatesDir: /etc/kubernetes/pki

위와같이 SAN 에 추가할 도메인, IP를 적어준다.

apiserver.crt 파일 업데이트

기존의 존재하는 apiserver.crt 파일을 백업한다.

apiserver.crt 파일 백업
ZSH
1
$ sudo mv /etc/kubernetes/pki/apiserver.{crt,key} ~

kubeadm 을 이용해 새로운 인증서를 생성해 준다.

인증서 업데이트
ZSH
1
$ sudo kubeadm init phase certs apiserver --config kubeadm.yaml

새로운 인증서가 생성되면서 certSANs 에 설정된 도메인, IP 주소들이 모두 인증서에 업데이트 된다. 이제 새로운 인증서를 가지고 구동되도록 api 서버를 재시작 시켜줘야 한다.

Docker 기반의 경우에는 다음과 같이 하면 된다.

  • docker ps | grep kube-apiserver 명령어로 kube-apiserver 의 컨테이너 ID 를 파악한다.
  • docker kill <containerID> 로 컨테이너를 킬(kill) 한다. 이렇게 하면 api 서버가 재시작 된다.

만약 containerd 를 이용하는 경우에는 다음과 같이 하면 된다.

  • crictl pods | grep kube-apiserver 로 kube-apiserver 의 Pod ID 를 파악한다.
  • crictl stopp <pod-id> 로 pod 를 정지
  • crictl rmp <pod-id> 로 pod 를 제거 합니다. 이렇게하면 다시 Pod 가 재시작 된다.

위와같이 Api 서버가 재시작되면서 새롭게 만들어진 API 서버 인증서를 인식하게 된다.

클러스터 설정 업데이트

마지막으로 클러스터 설정을 업데이트 해줘야 한다.

인증서 업데이트
ZSH
1
$ sudo kubeadm init phase upload-config kubeadm --config kubeadm.yaml

이렇게 하면 최종적으로 Api 서버에 인증서가 업데이트 된다.

Kubernetes 의 Role Based Access Control(RBAC)

쿠버네티스는 RBAC 기반으로 허가권(Permission) 을 조정하도록 설계 되었다. 그런데, 쿠버네티스는 다음과 같이 네가지의 Role 관련 리소스를 가지고 있다. 그 차이는 다음과 같다.

  1. ClusterRole – 전체 클러스터에 적용하기 위한 역할(Role) 에 할당된 허가권(Permission)
  2. ClusterRoleBinding – 특정 계정(Account) 에 ClusterRole 을 바인딩
  3. Role – 특정 네임스페이스에 적용하기 위한 역할(Role) 에 할당된 허가권(Permission)
  4. RoleBinding – 특정 계정(Account) 에 Role 을 바인딩

RBAC 을 적용하기 위해서는 계정이 필요하다. 이 계정은 쿠버네티스의 사용자를 말하는것이 아닌 쿠버네티스에서 운영되는 자원에 대한 계정을 말한다.

예를들어 ingress-nginx 라는 계정을 생성했다면 이제 이 계정에 ClusterRole 과 Role 을 Binding 을 통해서 ingress-nginx 계정과 연결하는 형식이다.

참고: Role Based Access Control (RBAC)

Istio, Pod CrashLoopBackOff 해결하기

Istio 를 설치하고 Pod 를 생성했는데, 다음과 같이 오류가 발생했다.

Istio Init 오류
ZSH
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
]$ kubectl describe pod/employee-producer-866cfb8cf8-s2qk4
Init Containers:
  istio-init:
    Container ID:  containerd://eb85c7971088c72e64b432a38f419a392182a44735281993c0c2b44460acd8fc
    Image:         docker.io/istio/proxyv2:1.13.1
    Image ID:      docker.io/istio/proxyv2@sha256:099ee79c150829471270a14520506b83117bb7448cc80ba215617785237c1eb0
    Port:          <none>
    Host Port:     <none>
    Args:
      istio-iptables
....
    State:          Waiting
      Reason:       CrashLoopBackOff
    Last State:     Terminated
      Reason:       Error
      Exit Code:    255
      Started:      Mon, 28 Feb 2022 13:07:52 +0900
      Finished:     Mon, 28 Feb 2022 13:07:52 +0900
...

istio-init 컨테이너가 오류가 발생한 것을 알 수 있다. Pod 안에 컨테이너가 여러개일 경우에 컨테이너 로그를 봐야하는데 다음과 같이 Pod 에 속한 컨테이너 로그를 볼수 있다.

Istio Init 오류 로그 보기
ZSH
1
2
3
4
5
6
7
8
]$ kubectl logs employee-producer-866cfb8cf8-spnqs -c istio-init
COMMIT
2022-02-28T04:16:59.895565Z     info    Running command: iptables-restore --noflush /tmp/iptables-rules-1646021819895421411.txt3256082129
2022-02-28T04:16:59.896995Z     error   Command error output: xtables parameter problem: iptables-restore: unable to initialize table 'nat'
 
Error occurred at line: 1
Try `iptables-restore -h' or 'iptables-restore --help' for more information.
2022-02-28T04:16:59.897030Z     error   Failed to execute: iptables-restore --noflush /tmp/iptables-rules-1646021819895421411.txt3256082129, exit status 2

이 문제는 istio cni 컴포넌트를 함께 설치해주면 된다. 보통 Istio 를 설치할때에 Profile 만 지정하는데, demo 프로파일에 경우에 CNI 를 설치하지 않는다. 다음과 같이 재설치를 해준다.

Istio 재설치
ZSH
1
2
]$ istioctl x uninstall --purge # 삭제
]$ istioctl install --set profile=demo --set components.cni.enabled=true -y

이렇게 CNI 를 활성화해서 재설치를 하면 문제없이 작동 된다.

문제점

여기서 한가지 문제가 있다. CNI 는 보통 Flannel, Calico 등을 이용하는데, 이것과 별도로 Istio-cni 를 설치하게 되는 것이다. 이왕이면 기존에 있는 것을 활용하는 방안을 고려해야 한다.

Calico 의 경우에 이에 대해서 기술하고 있는 문서가 있으니 참고해서 한번 해볼만 하다.

Istio 설치

Istio 는 쿠버네티스의 Network 레벨의 Mesh 서비스다. 비교하자면 Netflix OSS 에 Ribbon 과 비슷하다고 볼 수 있다.

Istio 설치 방법

Istio 설치 방법은 다양하다. 처음에 Istio 를 시작할때에 가장 헷깔리는 것이 바로 설치 방법이다. 구글에서 검색을 하면 설치방법이 나오지만 읽어보면 제각각인 이유가 다양한 설치 방법 때문이다.

그래서인지 Istio 홈페이지에서 다양한 설치 방법을 적어놨는데 대략 3가지 방법이 많이 쓰인다.

  1. Install with Istioctl
  2. Install with Helm
  3. Install Istio Operator

여기서는 Istoctl 을 이용해 설치하는 법을 다룬다. 이 방법은 다음 문서에 잘 나와 있다.

Download Istioctl

다음과 같이 Istio 를 다운로드 한다.

istio 다운로드
ZSH
1
2
3
4
$ curl -L https://istio.io/downloadIstio | sh -
$ sudo cp istio-1.13.0/bin/istioctl /usr/local/bin/
[sudo] password for systemv:
$ sudo chmod +x /usr/local/bin/istioctl

istio profile

istioctl 은 말그대로 istio 관련 작업을 위한 툴이다. 설치를 할때도 이를 활용할 수 있다.

istio 설치는 미리 정의되어 있는 프로파일을 정의하면 그 프로파일에 맞는 컴포넌트들을 같이 설치해 준다. 미리정의된 프로파일은 다음과 같이 조회가 가능하다.

istio 설치 프로파일 리스트
ZSH
1
2
3
4
5
6
7
8
9
10
$ istioctl profile list
Istio configuration profiles:
    default
    demo
    empty
    external
    minimal
    openshift
    preview
    remote

프로파일의 내용은 대략 다음과 같다.

  • default: 프로덕트 환경에 적합하도록 기본세팅되어 있다.
  • demo: 쇼케이스를 위해서 세팅된 값을 쓴다.
  • minimal: 오진 컨트롤 플레인만 설치된다.
  • empty: 아무것도 디폴로이 되지 않는다. 이것은 커스텀 설정을 위한 베이스 프로파일처럼 사용할 수 있다.

각 프로파일의 내용은 다음과 같이 dump 옵션을 사용해 가능하다.

istio 프로파일 dump 사용
ZSH
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
$ istioctl profile dump default
apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
spec:
  components:
    base:
      enabled: true
    cni:
      enabled: false
    egressGateways:
    - enabled: false
      name: istio-egressgateway
    ingressGateways:
    - enabled: true
      name: istio-ingressgateway
    istiodRemote:
      enabled: false
    pilot:
      enabled: true
  hub: docker.io/istio
  meshConfig:
    defaultConfig:
      proxyMetadata: {}
    enablePrometheusMerge: true
  profile: default
  tag: 1.13.0

위 내용을 보면, cni, egressGateway 와 istiodRemote 가 비활성화 되어 있다.

전체설정의 서브셋만 보고 싶다면 –config-path 를 사용하면 가능하다.

istio 프로파일 설정의 서브셋 사용
ZSH
1
2
$ istioctl profile dump --config-path components.cni default
enabled: false

프로파일에 차이를 알고 싶다면 다음과 같이 확인할 수 있다.

istio 프로파일 내용 차이 확인
ZSH
1
2
3
$ istioctl profile diff default demo
The difference between profiles:
apiVersion: install.istio.io/v1alpha1

demo profile 설치

demo 프로파일을 이용해 설치를 진행 한다. istio 문서대로 한번 해보는 것이다.

istio demo 프로파일을 이용해 설치
ZSH
1
2
3
4
5
6
7
8
$ istioctl install --set profile=demo -y
✔ Istio core installed                                                                                                                                                                                
✔ Istiod installed                                                                                                                                                                                    
✔ Egress gateways installed                                                                                                                                                                          
✔ Ingress gateways installed                                                                                                                                                                          
✔ Installation complete                                                                                                                                                                               Making this installation the default for injection and validation.
 
Thank you for installing Istio 1.13.  Please take a few minutes to tell us about your install/upgrade experience!  https://forms.gle/pzWZpAvMVBecaQ9h9

자동으로 Envoy 사이드카 프록시를 자동으로 주입시키기 위한 네임스페이스에 라벨을 추가해준다.

Envoy 사이드카 자동 인젝션을 위한 라벨링 작업
ZSH
1
2
$ kubectl label namespace default istio-injection=enabled
namespace/default labeled

default 네임스페이스에 라벨링을 해줬다. default 네임스페이스에 드플로이를 해주면 Envoy 사이드카가 자동으로 주입된다.

istio 설치 확인

먼저 네임스페이스를 확인해 보자. 네임스페이스는 istio-system 이 생성된다.

istio-system 네임스페이스 확인
ZSH
1
2
3
4
5
6
7
8
9
10
$ kubectl get ns
NAME              STATUS   AGE
default           Active   300d
ingress-nginx     Active   16d
istio-system      Active   4m54s
kube-node-lease   Active   300d
kube-public       Active   300d
kube-system       Active   300d
metallb-system    Active   204d
monitoring        Active   201d

그리고 이제 어떤것이 설치되었는지를 살펴보자.

istio-system 네임스페이스에 자원들
ZSH
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
$ kubectl get all -n istio-system
NAME                                       READY   STATUS    RESTARTS   AGE
pod/istio-egressgateway-599c8845c9-hcp24   1/1     Running   0          8m31s
pod/istio-ingressgateway-69dc56d7f-64xl4   1/1     Running   0          8m31s
pod/istiod-8c75fcbc9-d6svq                 1/1     Running   0          8m51s
 
NAME                           TYPE           CLUSTER-IP    EXTERNAL-IP     PORT(S)                                                                      AGE
service/istio-egressgateway    ClusterIP      10.32.0.43    <none>          80/TCP,443/TCP                                                               8m29s
service/istio-ingressgateway   LoadBalancer   10.32.0.206   192.168.111.5   15021:30526/TCP,80:32234/TCP,443:30548/TCP,31400:30295/TCP,15443:30456/TCP   8m29s
service/istiod                 ClusterIP      10.32.0.196   <none>          15010/TCP,15012/TCP,443/TCP,15014/TCP                                        8m51s
 
NAME                                   READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/istio-egressgateway    1/1     1            1           8m31s
deployment.apps/istio-ingressgateway   1/1     1            1           8m31s
deployment.apps/istiod                 1/1     1            1           8m52s
 
NAME                                             DESIRED   CURRENT   READY   AGE
replicaset.apps/istio-egressgateway-599c8845c9   1         1         1       8m31s
replicaset.apps/istio-ingressgateway-69dc56d7f   1         1         1       8m31s
replicaset.apps/istiod-8c75fcbc9                 1         1         1       8m52s

CRD 도 함께 생성된다. 다음과 같이 확인 가능하다.

istio 네임스페이스
ZSH
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
$ kubectl get crd | grep istio
authorizationpolicies.security.istio.io               2022-02-12T12:35:39Z
destinationrules.networking.istio.io                  2022-02-12T12:35:40Z
envoyfilters.networking.istio.io                      2022-02-12T12:35:40Z
gateways.networking.istio.io                          2022-02-12T12:35:40Z
istiooperators.install.istio.io                       2022-02-12T12:35:40Z
peerauthentications.security.istio.io                 2022-02-12T12:35:41Z
proxyconfigs.networking.istio.io                      2022-02-12T12:35:41Z
requestauthentications.security.istio.io              2022-02-12T12:35:41Z
serviceentries.networking.istio.io                    2022-02-12T12:35:41Z
sidecars.networking.istio.io                          2022-02-12T12:35:41Z
telemetries.telemetry.istio.io                        2022-02-12T12:35:42Z
virtualservices.networking.istio.io                   2022-02-12T12:35:42Z
wasmplugins.extensions.istio.io                       2022-02-12T12:35:42Z
workloadentries.networking.istio.io                   2022-02-12T12:35:43Z
workloadgroups.networking.istio.io                    2022-02-12T12:35:43Z

문제

이벤트(Events) 를 보면 다음과 같이 오류가 난것을 확인할 수 있다.

istio 오류
ZSH
1
2
3
4
5
6
7
8
9
10
11
19m         Warning   listen tcp4 :30754: bind: address already in use   node/kworker3.systemv.local            can't open port "nodePort for istio-system/istio-ingressgateway:status-port" (:30754/tcp4), skipping it
19m         Warning   listen tcp4 :32315: bind: address already in use   node/kworker3.systemv.local            can't open port "nodePort for istio-system/istio-ingressgateway:https" (:32315/tcp4), skipping it
19m         Warning   listen tcp4 :31159: bind: address already in use   node/kworker3.systemv.local            can't open port "nodePort for istio-system/istio-ingressgateway:tcp" (:31159/tcp4), skipping it
19m         Warning   listen tcp4 :31078: bind: address already in use   node/kworker3.systemv.local            can't open port "nodePort for istio-system/istio-ingressgateway:http2" (:31078/tcp4), skipping it
19m         Warning   listen tcp4 :31384: bind: address already in use   node/kworker3.systemv.local            can't open port "nodePort for istio-system/istio-ingressgateway:tls" (:31384/tcp4), skipping it
8m58s       Warning   listen tcp4 :30051: bind: address already in use   node/kworker3.systemv.local            can't open port "nodePort for istio-system/istiod:http-monitoring" (:30051/tcp4), skipping it
8m58s       Warning   listen tcp4 :31601: bind: address already in use   node/kworker3.systemv.local            can't open port "nodePort for istio-system/istiod:https-dns" (:31601/tcp4), skipping it
8m58s       Warning   listen tcp4 :30751: bind: address already in use   node/kworker3.systemv.local            can't open port "nodePort for istio-system/istiod:https-webhook" (:30751/tcp4), skipping it
8m58s       Warning   listen tcp4 :30761: bind: address already in use   node/kworker3.systemv.local            can't open port "nodePort for istio-system/istiod:grpc-xds" (:30761/tcp4), skipping it
32m         Warning   FailedCreate                                       replicaset/productpage-v1-65b75f6885   Error creating: Internal error occurred: failed calling webhook "namespace.sidecar-injector.istio.io": failed to call webhook: Post "https://istiod.istio-system.svc:443/inject?timeout=10s": context deadline exceeded
35m         Warning   FailedCreate

쿠버네티스 curl 사용하기

쿠버네티스에서 클러스터내에서 Pod 에 데이터가 잘 나오는지를 확인하는 방법은 CURL 일 것이다. ClusterIP 로 IP 가 할당되면 클러스터내에서 접근이 가능한데 이때에 다음과 같이 사용하면 된다.

curl 파드 생성
ZSH
1
2
3
$ kubectl run curl -it --rm --image curlimages/curl -- sh
If you don't see a command prompt, try pressing enter.
/ $

curl 을 비롯한 ping, nslookup 도 가능하다.

Calico Metrics 모니터링 하기

Calico 는 쿠버네티스(Kubernetes) 의 CNI 다. 쉽게 말해서 쿠버네티스의 네트워킹을 가능하게 해준다. 설치도 쉽게 할수 있는데, 프로메테우스에서 Calico 모니터링을 하기 위해서는 추가적인 작업이 필요한데 여기에 대해서 알아본다.

calicoctl

calicoctl 을 설치해야 한다. 이 파일은 바이너리이며 wget, curl 명령어를 이용해서 설치가 가능하다. 설치를 한 후에 이것을 사용하기 위해서는 다음과 같이 환경변수를 설정해 준다.

Calico 환경변수 설정
ZSH
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
$ export DATASTORE_TYPE=kubernetes
$ export KUBECONFIG=~/.kube/config
$ calicoctl get nodes
NAME                    
kworker1.systemv.local  
kworker2.systemv.local  
kworker3.systemv.local
$ calicoctl get workloadendpoints
WORKLOAD                                 NODE                     NETWORKS          INTERFACE        
dnsutils                                 kworker2.systemv.local   10.31.168.71/32   calib3c61c3cba9  
springboot-deployment-77db875f78-9fshx   kworker3.systemv.local   10.31.4.57/32     cali11c98587cc4  
springboot-deployment-77db875f78-km8rd   kworker1.systemv.local   10.31.20.48/32    cali712f16523f2  
springboot-deployment-77db875f78-nj7t7   kworker1.systemv.local   10.31.20.57/32    calibcff04191b7
$ calicoctl get ippools
NAME                  CIDR           SELECTOR  
default-ipv4-ippool   10.31.0.0/16   all()

calicoctl 명령어는 다양한 질의를 할 수 있다.

Calico CRD

Calico 설치를 메니페스트로 설치를 하게 되면 CRD 가 생성되면서 CRD 에 정의된 오브젝트가 함께 생성된다.

Calico 커스텀 리소스 정의
ZSH
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
$ kubectl get crd | grep calico
bgpconfigurations.crd.projectcalico.org               2021-04-18T17:42:07Z
bgppeers.crd.projectcalico.org                        2021-04-18T17:42:07Z
blockaffinities.crd.projectcalico.org                 2021-04-18T17:42:08Z
caliconodestatuses.crd.projectcalico.org              2022-01-28T16:00:01Z
clusterinformations.crd.projectcalico.org             2021-04-18T17:42:08Z
felixconfigurations.crd.projectcalico.org             2021-04-18T17:42:08Z
globalnetworkpolicies.crd.projectcalico.org           2021-04-18T17:42:08Z
globalnetworksets.crd.projectcalico.org               2021-04-18T17:42:08Z
hostendpoints.crd.projectcalico.org                   2021-04-18T17:42:08Z
ipamblocks.crd.projectcalico.org                      2021-04-18T17:42:09Z
ipamconfigs.crd.projectcalico.org                     2021-04-18T17:42:09Z
ipamhandles.crd.projectcalico.org                     2021-04-18T17:42:09Z
ippools.crd.projectcalico.org                         2021-04-18T17:42:09Z
ipreservations.crd.projectcalico.org                  2022-01-28T16:00:02Z
kubecontrollersconfigurations.crd.projectcalico.org   2021-04-18T17:42:09Z
networkpolicies.crd.projectcalico.org                 2021-04-18T17:42:09Z
networksets.crd.projectcalico.org                     2021-04-18T17:42:10Z

이것을 언급하는 이유는 Calico 홈페이지에 보면 이에 대한 언급이 많이 되어 있지 않은채, API 를 언급하고 있다. 만일 API 조회를 해봤는데 없다면 CRD 를 살펴보고 찾으면 된다.

Monitor Calico component metrics

Felix configuration

이제 Calico 의 컴포넌트 메트릭을 활성화 해보자. 이를 위해서는 felixconfigurations 의 설정을 먼저 바꿔야 한다. 이를 위해서 calicoctl 명령어를 활용한다.

felixConfiguration 설정 변경
ZSH
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
$ kubectl get felixconfigurations -o yaml
apiVersion: v1
items:
- apiVersion: crd.projectcalico.org/v1
  kind: FelixConfiguration
  metadata:
    annotations:
      projectcalico.org/metadata: '{"uid":"92e205c7-7ba5-48f2-997d-e6c50b9893df","creationTimestamp":"2021-04-18T17:42:57Z"}'
    creationTimestamp: "2021-04-18T17:42:57Z"
    generation: 2
    name: default
    resourceVersion: "35474"
    uid: 92e205c7-7ba5-48f2-997d-e6c50b9893df
  spec:
    bpfLogLevel: ""
    ipipEnabled: true
    logSeverityScreen: Info
    reportingInterval: 0s
kind: List
metadata:
  resourceVersion: ""
  selfLink: ""
$ calicoctl patch felixConfiguration default  --patch '{"spec":{"prometheusMetricsEnabled": true}}'
Successfully patched 1 'FelixConfiguration' resource
$ kubectl get felixconfigurations -o yaml
apiVersion: v1
items:
- apiVersion: crd.projectcalico.org/v1
  kind: FelixConfiguration
  metadata:
    annotations:
      projectcalico.org/metadata: '{"uid":"92e205c7-7ba5-48f2-997d-e6c50b9893df","creationTimestamp":"2021-04-18T17:42:57Z"}'
    creationTimestamp: "2021-04-18T17:42:57Z"
    generation: 3
    name: default
    resourceVersion: "1015953"
    uid: 92e205c7-7ba5-48f2-997d-e6c50b9893df
  spec:
    bpfLogLevel: ""
    ipipEnabled: true
    logSeverityScreen: Info
    prometheusMetricsEnabled: true
    reportingInterval: 0s
kind: List
metadata:
  resourceVersion: ""
  selfLink: ""

Creating a service to expose Felix metrics

이제 프로메테우스에서 메트릭 수집을 위한 서비스를 다음과 같이 만든다.

Caclico 메트릭을 위한 서비스 생성
ZSH
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
$ kubectl apply -f - <<EOF
apiVersion: v1
kind: Service
metadata:
  name: calico-felix-metrics-svc
  namespace: kube-system
  labels:
    app.kubernetes.io/instance: calico
    app.kubernetes.io/name: felix
    k8s-app: felix-metrics
spec:
  selector:
    k8s-app: calico-node
  ports:
  - name: metrics
    port: 9091
    protocol: TCP
    targetPort: 9091
EOF
service/felix-metrics-svc created

Felix 는 쿠버네티스 WorkerNode 에서 실행되는 CNI 를 말한다. 셀렉터를 보면 k8s-app: calico-node 를 설정하고 있는데, Calico Node 의 Pods 를 지정한 것이다.

또, 나중에 ServiceMonitor 설정을 위해서 Labels 를 잘 설정해줘야 한다.

Typha 설정은 하지 않는다. 50개 노드 이하로 설치를 했기 때문에 Typha 가 없다.

Confirm prometheus metrics port

쿠버네티스는 컨트롤 설정을 하나로 모아 놨다. 이 설정을 보면 여러가지 오브젝트에 대한 내용도 나오는데, 이 오브젝트에 대한 프로메테우스 엔드포인트는 9094로 정의 되어 있다. 이 포트를 이용하면 모든 메트릭의 엔드포이트를 가지고 올 수 있다.

Caclico 프로메테우스 메트릭 포트
ZSH
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
$ kubectl get kubecontrollersconfiguration -o yaml
apiVersion: v1
items:
- apiVersion: crd.projectcalico.org/v1
  kind: KubeControllersConfiguration
  metadata:
    annotations:
      projectcalico.org/metadata: '{"uid":"d2a63152-c0ba-407c-9d2e-8be8d559d941","creationTimestamp":"2021-04-18T17:43:07Z"}'
    creationTimestamp: "2021-04-18T17:43:07Z"
    generation: 4
    name: default
    resourceVersion: "797517"
    uid: d2a63152-c0ba-407c-9d2e-8be8d559d941
  spec:
    controllers:
      namespace:
        reconcilerPeriod: 5m0s
      node:
        leakGracePeriod: 15m0s
        reconcilerPeriod: 5m0s
        syncLabels: Enabled
      policy:
        reconcilerPeriod: 5m0s
      serviceAccount:
        reconcilerPeriod: 5m0s
      workloadEndpoint:
        reconcilerPeriod: 5m0s
    etcdV3CompactionPeriod: 10m0s
    healthChecks: Enabled
    logSeverityScreen: Info
    prometheusMetricsPort: 9094
  status:
    environmentVars:
      DATASTORE_TYPE: kubernetes
      ENABLED_CONTROLLERS: node
    runningConfig:
      controllers:
        node:
          hostEndpoint:
            autoCreate: Disabled
          leakGracePeriod: 15m0s
          syncLabels: Disabled
      etcdV3CompactionPeriod: 10m0s
      healthChecks: Enabled
      logSeverityScreen: Info
kind: List
metadata:
  resourceVersion: ""
  selfLink: ""

Creating a service to expose kube-controllers metrics

앞에 Felix 는 Node 의 CNI 라고 한다면 이를 제어하는 것이 컨트롤러이다. 이를 위한 서비스를 다음과 같이 생성해 준다.

프로메테우스 엔드포인트 서비스 생성
ZSH
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
$ kubectl apply -f - <<EOF
apiVersion: v1
kind: Service
metadata:
  name: calico-kube-controllers-metrics-svc
  namespace: kube-system
  labels:
    app.kubernetes.io/instance: calico
    app.kubernetes.io/name: calico-kube-controllers-metrics-svc
    k8s-app: calico-kube-controllers-metrics-metrics
spec:
  selector:
    k8s-app: calico-kube-controllers
  ports:
  - name: metrics
    port: 9094
    protocol: TCP
    targetPort: 9094
EOF

Calico-kube-controllers 의 Pods 를 찾기 위해서 셀렉터 k8s-app: calico-kube-controllers 지정해 준다. 그리고 ServiceMonitor 에서 찾을 수 있도록 Labels 를 설정해 줬다.

Prometheus ServiceMonitor 생성

나는 프로메테우스를 Operator 로 설치했다. Prometheus-Operator 설치를 할 경우에 메트릭 수집은 ServiceMonitor 를 통해서 이루어진다. 이 ServiceMonitor 는 Prometheus 의 설정을 함께 적용하면서 동작한다. Prometheus 의 Scape 을 ServiceMonitor 가 대신하는 것이라고 생각하면 쉽다.

Felix 를 위한 ServiceMonitor

Felix 를 위한 ServiceMonitor 는 다음과 같다.

Felix 를 위한 ServiceMonitor
ZSH
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  labels:
    serviceapp: calico-felix-servicemonitor
    release: prometheus
  name: prometheus-kube-prometheus-calico-felix
  namespace: monitoring
spec:
  namespaceSelector:
    matchNames:
    - kube-system
  selector:
    matchLabels:
      app.kubernetes.io/instance: calico
      app.kubernetes.io/name: felix
      k8s-app: felix-metrics
  jobLabel: felix_metrics
  endpoints:
  - bearerTokenFile: /var/run/secrets/kubernetes.io/serviceaccount/token
    interval: 15s
    port: metrics
    relabelings:
    - sourceLabels: [__meta_kubernetes_service_name]
      regex: calico-felix-metrics-svc
      action: keep
      replacement: $1

셀렉터를 이용해서 Service 의 Felix 를 지정해줬고, 스크랩에서도 Felix 를 인식하도록 서비스 이름을 지정해 줬다.

Calico Kube Controller ServiceMonitor

Calico kube controller 를 위한 ServiceMonitor 는 다음과 같다.

Calico kube controller 를 위한 ServiceMonitor
ZSH
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  labels:
    serviceapp: calico-kube-controller-servicemonitor
    release: prometheus
  name: prometheus-kube-prometheus-calico-controller
  namespace: monitoring
spec:
  namespaceSelector:
    matchNames:
    - kube-system
  selector:
    matchLabels:
      app.kubernetes.io/instance: calico
      app.kubernetes.io/name: calico-kube-controllers-metrics-svc
      k8s-app: calico-kube-controllers-metrics-metrics
  jobLabel: calico_kube_controller_metrics
  endpoints:
  - bearerTokenFile: /var/run/secrets/kubernetes.io/serviceaccount/token
    interval: 15s
    port: metrics
    relabelings:
    - sourceLabels: [__meta_kubernetes_service_name]
      regex: calico-kube-controllers-metrics-svc
      action: keep
      replacement: $1

위와같이 한 후에 프로메테우스를 살펴보면 다음과 같이 나온다.

쿠버네티스 secret 파일 저장하기

쿠버네티스의 Secret 은 암호화해서 데이터를 저장하는데, 파일도 저장할 수 있다. 바이너리 파일이던 텍스트 파일이던 모두 base64 인코딩 스트링으로 저장이된다. 이것을 파일로 저장하는 방법에 대해서 간단하게 알아본다.

Prometheus 설정 Secret

Pormetheus 를 오퍼레이터(Operator) 로 설치를 했을 경우에 다음과 같은 Secret 을 볼 수 있다.

Prometheus 설정 파일
ZSH
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
$ kubectl get secret prometheus-prometheus-kube-prometheus-prometheus -n monitoring -o yaml
apiVersion: v1
data:
  prometheus.yaml.gz: H4sIAAAAAAAA/+ydz4+jNhTH7/krfNjDzFYZdraXijmttJV66G5X7bGqLMe8JN4Y27JNOqOq/3uFYxJIIBtmWCZp3g0wfjz/4H2+NmAWUs+YTCeEwJrJgnmhFRXKg10zmZIf37kJIY5bZuDgMDx6sIpJKtkMpCuNEGKszsEvoXApybUSXluhFsnu8HRVzGBa299t7hmgFowUnKXkzc2X3z7Szx8+/Xw7sYUEOhcSXDqZkgQ8rxlPylSXtFo/cuFpmS3YnL5L3t49sVxOYqG5VnOxCNf6qmdUsRxS4sCuBYdPm/Ilp5WTSbA+Z4otwCbvJoQstdK2qjwyZ9LBhJAym1XgwVGX7S5PyJRYLSEloDKjhfKb6iodcoZxiPUfj1Q701ojTAjJwVvBHTXML1OSxN0JIRaCH83rOV1YDo3mDbUQtjyzC/CbxJRQ6nNDa21XVVYwxHjZr1KyAjAhc6tlSnPwjNYrYFPPm/MoM+a0M40FB8pvM1hYwGNKbvZbxHnGV412uX3wthjSZwsSWGjXHn7XM1W+79we3EcHck5jN+nn6EHOytvSwwH8rLo6Ndr6qjttr7L03kz/hll3Xz1ikWWZBedo7MYrobLembYOOTDMMq9tSh7qHn7WGTzc3L29jQeNZBxyUD4lb/65/7flPlI6g/Mtzxed9SuO0Vmf0myDWVvN1NJONlj12m3JmjZjch+LRmdd1noWtrTEtfJMKLBdNrcnDFjqKoK3NeB079yqqxxmOOXuq/oX7STGkrllSMx1VshSNNyH3SpilOn58XptmIkd9c3NH798+P3jbcNWjD4b6NF94pE//xqA8UaU+UYFfAZzVkgfdNoSStfLpikze+mi/c3ZQjnghQXqVsLQNVgxf9r5RcjG9Vj+nZshjbMgulKSrJlNbKESB9yCd8nuxDuhk1htjHNdKJ9wdsdt6dsMmAVLvV6BepalkPNClArXudEK4m1zMk6b2SqWbvvU4OA3Vq9FBj2h38hVl1abTKNg350vI5H5yPxLY/4AQa7rcpvwcPdDd//pJzmO3vlXpze4tpApN6LaCB64J+chvzaqf6f5h9iGVzL1cMKQfjcrdaZIRMQj4q8C8V/17NdyY1TCn3L/Xx3oF5bNmWL43OB53K4nCk2Fcp4p3pON37Azwkz9oQfbWPCCUuxD+CZ2NpzAR9Ij6S+O9DiB/wLOhv2yzayWEux0/Of1zQH286b0Y9zGWftzGN93dCkc7+N4H1UAqgAc7+N4v0OHgOcZTu1fOvrLVkTYI+wR9gh7hD3CvgP2xurHJ6T9pdM+NCPiHnGPuEfcI+4R9x24d3wJWSHx0QIqjhcqjm1PQtWBqgNVB6oOVB2oOtpVhwTfIjdiREa18T9SG2O8Jhh71OCyY/WT6y+Y6pmGd/CELxJRdKDoQNFxFqKjHgtG+y7xxPt/+xp9q/Kon4DqpUW93L+Oemn//iHhLFsLF9a+QX2D+gb1Deob1Deob1DfoL55pr55f1b6xlg9A4fqBtUNqpvXVgOoblDdoLpBdXOJ6kYbCCFgvIdPjdUrXrou5k6+7K02zsF6FxUI3V2SHlshNMuFc0IrylmMj7VFN0+ow8tRMb0lywH+D994qWoB33XBlTBRsaBiec3FM/D9kva/aeAiVefDy++4GNV5EhN/bYFwR7gj3HFlrCH47jzzUM2NvNLo/ULovTffjktMfvPpQ7N3jcLU8+UP8hR5emk8HTrAjDXbf9Vcr22WEWQKj2W0fL1fUtYn5y+H9i8bq3e1wZWM0fELzvMrD/Iaed0aQvALzoFIHf4zLFR45hy2D85qBNWQlFndIMfhz7ErY3FV4WgkvKJgLMzFY0qSzY3f5OwRqndxvY3se2w/oDshzAi6ButCodbvY2kOCt7Kk1ainHhjtNTZ0V9yD+BDB9cOZ3X/CwAA///mZWEHdn0AAA==
kind: Secret
metadata:
  annotations:
    generated: "true"
  creationTimestamp: "2022-01-29T16:06:35Z"
  labels:
    managed-by: prometheus-operator
  name: prometheus-prometheus-kube-prometheus-prometheus
  namespace: monitoring
  ownerReferences:
  - apiVersion: monitoring.coreos.com/v1
    blockOwnerDeletion: true
    controller: true
    kind: Prometheus
    name: prometheus-kube-prometheus-prometheus
    uid: 6b8415cb-b99a-4ac4-8bc1-a6175265fd1c
  resourceVersion: "841303"
  uid: 18933ea2-4dd8-464c-a61b-69513f7a807c
type: Opaque

data 필드를 보면 prometheus.yaml.gz 파일이름이 보이고 내용이 base64 스트링이 보인다. 이 prometheus.yaml.gz 파일을 받기 위해서는 간단히 bas64 스트링을 디코딩하고 나오는 스트링을 그냥 파일명으로 저장하면 된다.

bas64 스트링 디코딩
ZSH
1
2
3
$ echo "H4sIAAAAAAAA/+ydz4+jNhTH7/krfNjDzFYZdraXijmttJV66G5X7bGqLMe8JN4Y27JNOqOq/3uFYxJIIBtmWCZp3g0wfjz/4H2+NmAWUs+YTCeEwJrJgnmhFRXKg10zmZIf37kJIY5bZuDgMDx6sIpJKtkMpCuNEGKszsEvoXApybUSXluhFsnu8HRVzGBa299t7hmgFowUnKXkzc2X3z7Szx8+/Xw7sYUEOhcSXDqZkgQ8rxlPylSXtFo/cuFpmS3YnL5L3t49sVxOYqG5VnOxCNf6qmdUsRxS4sCuBYdPm/Ilp5WTSbA+Z4otwCbvJoQstdK2qjwyZ9LBhJAym1XgwVGX7S5PyJRYLSEloDKjhfKb6iodcoZxiPUfj1Q701ojTAjJwVvBHTXML1OSxN0JIRaCH83rOV1YDo3mDbUQtjyzC/CbxJRQ6nNDa21XVVYwxHjZr1KyAjAhc6tlSnPwjNYrYFPPm/MoM+a0M40FB8pvM1hYwGNKbvZbxHnGV412uX3wthjSZwsSWGjXHn7XM1W+79we3EcHck5jN+nn6EHOytvSwwH8rLo6Ndr6qjttr7L03kz/hll3Xz1ikWWZBedo7MYrobLembYOOTDMMq9tSh7qHn7WGTzc3L29jQeNZBxyUD4lb/65/7flPlI6g/Mtzxed9SuO0Vmf0myDWVvN1NJONlj12m3JmjZjch+LRmdd1noWtrTEtfJMKLBdNrcnDFjqKoK3NeB079yqqxxmOOXuq/oX7STGkrllSMx1VshSNNyH3SpilOn58XptmIkd9c3NH798+P3jbcNWjD4b6NF94pE//xqA8UaU+UYFfAZzVkgfdNoSStfLpikze+mi/c3ZQjnghQXqVsLQNVgxf9r5RcjG9Vj+nZshjbMgulKSrJlNbKESB9yCd8nuxDuhk1htjHNdKJ9wdsdt6dsMmAVLvV6BepalkPNClArXudEK4m1zMk6b2SqWbvvU4OA3Vq9FBj2h38hVl1abTKNg350vI5H5yPxLY/4AQa7rcpvwcPdDd//pJzmO3vlXpze4tpApN6LaCB64J+chvzaqf6f5h9iGVzL1cMKQfjcrdaZIRMQj4q8C8V/17NdyY1TCn3L/Xx3oF5bNmWL43OB53K4nCk2Fcp4p3pON37Azwkz9oQfbWPCCUuxD+CZ2NpzAR9Ij6S+O9DiB/wLOhv2yzayWEux0/Of1zQH286b0Y9zGWftzGN93dCkc7+N4H1UAqgAc7+N4v0OHgOcZTu1fOvrLVkTYI+wR9gh7hD3CvgP2xurHJ6T9pdM+NCPiHnGPuEfcI+4R9x24d3wJWSHx0QIqjhcqjm1PQtWBqgNVB6oOVB2oOtpVhwTfIjdiREa18T9SG2O8Jhh71OCyY/WT6y+Y6pmGd/CELxJRdKDoQNFxFqKjHgtG+y7xxPt/+xp9q/Kon4DqpUW93L+Oemn//iHhLFsLF9a+QX2D+gb1Deob1Deob1DfoL55pr55f1b6xlg9A4fqBtUNqpvXVgOoblDdoLpBdXOJ6kYbCCFgvIdPjdUrXrou5k6+7K02zsF6FxUI3V2SHlshNMuFc0IrylmMj7VFN0+ow8tRMb0lywH+D994qWoB33XBlTBRsaBiec3FM/D9kva/aeAiVefDy++4GNV5EhN/bYFwR7gj3HFlrCH47jzzUM2NvNLo/ULovTffjktMfvPpQ7N3jcLU8+UP8hR5emk8HTrAjDXbf9Vcr22WEWQKj2W0fL1fUtYn5y+H9i8bq3e1wZWM0fELzvMrD/Iaed0aQvALzoFIHf4zLFR45hy2D85qBNWQlFndIMfhz7ErY3FV4WgkvKJgLMzFY0qSzY3f5OwRqndxvY3se2w/oDshzAi6ButCodbvY2kOCt7Kk1ainHhjtNTZ0V9yD+BDB9cOZ3X/CwAA///mZWEHdn0AAA==" | base64 -d > prometheus.yaml.gz
$ file prometheus.yaml.gz
prometheus.yaml.gz: gzip compressed data, original size modulo 2^32 32118

간단하게 echo “<encoded-value>” | base64 -d prometheus.yaml.gz 으로 보면 된다.

압축을 해제하고 파일을 수정한 후에 다시 압축을 한다. 그리고 이것을 base64 로 인코딩 스트링을 만들면 되는데 다음과 같이 만들 수 있다.

Base64 인코딩 스트링 만들기
ZSH
1
$ cat prometheus.yaml.gz | base64 -w 0

이렇게 하게 되면 Base64 인코딩 스트링 나오는데, Secret 에 데이터부분에 이 스트링을 넣고 편집하면 된다.

쿠버네티스에 프로메테우스(Prometheus) 오퍼레이터 설치하기

프로메테우스(Prometheus)는 모니터링 시스템을 말한다. 프로메테우스는 파일 기반의 타임시리즈(Time-Series) 데이터베이스다. 시스템의 메트릭스들을 수집하기 위해서는 익스포터(Exportor) 를 설치해야 한다. 이외에도 알람을 전달해주는 AlertManager 도 있는데, 전체적인 아키텍쳐는 다음과 같다.

프로메테우스 아키텍쳐

프로메테우스는 쿠버네티스에서도 설치가 가능한데, 이글은 쿠버네티스에 프로메테우스 설치에 대한 글이다.

환경

환경은 다음과 같다.

  • Kubernetes 버전: 1.20
  • Kubernetes Nodes: Master 3개, Worker 3개
  • Prometheus 설치 방법: Helm Operator

설치

프로메테우스(Prometheus) 설치는 매우 다양한데, 검색을 해보면 Helm 을 이용한 방법 그중에서도 오퍼레이터(Operator) 를 이용한 방법이 많이 소개 되어 있다. 여기서도 이 오퍼레이터를 이용한 방법을 사용하고자 한다.

Prometheus Operator 로 검색을 해보면 github 저장소를 찾을 수 있다.

중간에 보면 Prometheus Operator vs kube-prometheus vs community helm chart 가 보인다. 자세히 읽어보면 쿠버네티스에 설치할 수 있는 방법이 세 가지로 나뉜다는 것을 알수 있다.

이중에서 나는 Helm chart 를 이용한 방법을 이용할 생각이다.

노드 레이블 설정

노드에 레이블을 설정하게 되면 쿠버네티스에 앱을 배포할때에 레이블을 지정함으로써 특정 노드에 생성되도록 강제할 수 있다. 프로메테우스 오퍼레이터 설치를 특정 노드에 하기 위해서 레이블을 부여할 생각이다. 대상 노드는 kworker3.systemv.local 노드이며 다음과 같이 레이블을 할당해 줬다.

노드 레이블 확인 및 설정
ZSH
1
2
3
4
5
6
7
$ kubectl get node --show-labels
NAME                     STATUS   ROLES    AGE   VERSION   LABELS
kworker1.systemv.local   Ready    <none>   97d   v1.20.6   beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,kubernetes.io/arch=amd64,kubernetes.io/hostname=kworker1.systemv.local,kubernetes.io/os=linux
kworker2.systemv.local   Ready    <none>   97d   v1.20.6   beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,kubernetes.io/arch=amd64,kubernetes.io/hostname=kworker2.systemv.local,kubernetes.io/os=linux
kworker3.systemv.local   Ready    <none>   97d   v1.20.6   beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,kubernetes.io/arch=amd64,kubernetes.io/hostname=kworker3.systemv.local,kubernetes.io/os=linux
$ kubectl label nodes kworker3.systemv.local system.rule=monitoring
node/kworker3.systemv.local labeled

kworker3.systemv.local 노드에 system.rule=monitoring 레이블이 새겨졌다.

Helm Chart 가지고 오기

Helm 를 이용하면 명령어 한줄로 설치가 되지만 설정을 변경하기 위해서는 챠트(Chart) 를 수정해줘야 한다. 이를 위해서 챠트를 다운받아야만 한다. Helm 챠트는 프로메테우스 커뮤니티에서 관리하고 있다.

Helm Chart 가지고 오기
ZSH
1
2
3
4
5
6
7
$ git clone https://github.com/prometheus-community/helm-charts.git
$ cd helm-charts/charts
$ ls
alertmanager           prometheus-adapter              prometheus-couchdb-exporter        prometheus-mongodb-exporter  prometheus-pingdom-exporter   prometheus-redis-exporter        prometheus-to-sd
kube-prometheus-stack  prometheus-blackbox-exporter    prometheus-druid-exporter          prometheus-mysql-exporter    prometheus-postgres-exporter  prometheus-snmp-exporter
kube-state-metrics     prometheus-cloudwatch-exporter  prometheus-elasticsearch-exporter  prometheus-nats-exporter     prometheus-pushgateway        prometheus-stackdriver-exporter
prometheus             prometheus-consul-exporter      prometheus-kafka-exporter          prometheus-node-exporter     prometheus-rabbitmq-exporter  prometheus-statsd-exporter

많은 챠트가 존재하는데, 여기서 설치 대상은 kube-prometheus-stack 이다.

설정을 하기위해서 프로메테우스 오퍼레이터의 구성을 살펴볼 필요가 있다.

  • Prometheus – 프로메테우스 리소스 정의가 되어 있다. 프로메테우스를 위한 파드(Pod) 의 리플리카(Replica) 갯수, 퍼시스턴스 볼륨 구성등이다. 프로메테이스 오퍼레이터는 파드를 StatefulSet 으로 배포 한다. 그리고 어떤 애플리케이션, 혹은 리소스를 모니터링할 것이지를 지정하는 것인데, 이것은 ServiceMonitor 로 설정이 이루어 진다.
  • ServiceMonitor – 프로메테우스 오퍼레이터는 어노테이션 기반의 서비스 디스커버리를 지원하지 않으며 대신 PodMonitor, ServiceMonitor 를 이용한다. ServiceMonitor는 애플리케이션이나 서비스의 리소스를 모니터링할 것인지를 지정한다. 쿠버네티스의 NodeSelector 처럼 LableSelector 로 서비스의 리소스를 선택할 수 있고, 엔드포인트(EndPoint) 를 통해서 애플리케이션의 메트릭을 수집할 수 있다. ServiceMonitor 는 rule 을 기반으로 Prometheus의 모니터링 대상이 되는 ServiceMonitor를 scan하여 해당 정보를 Secret으로 배포한다. 그리고 이 Secret을 Prometheus StatefulSet에 마운트한다. 이런 방식으로 Prometheus 팟은 자신이 모니터링할 Service가 무엇인지 알 수 있다.
  • Altermanager – 알람 매니저 이다. 프로메테우스 컴포넌트중에 하나다.
  • PodMonitor – 파드에 대한 모니터다. 역시나 LabelSelector 를 통해서 모니터링하고자 하는 파드를 지정할 수 있다.

위 내용을 잘 알야하는 이유는 kube-prometheus-stack 디렉토리에 values.yaml 파일에 구조와 연관이 있다.

values.yaml 파일 편집

프로메테우스 오퍼레이터를 Helm 으로 설치할 때에는 values.yaml 파일의 설정을 참고하도록 되어 있다. values.yaml 에는 altermanager, Grafana, Prometheus 등에 대한 설정 값들이 들어가 있다. 앞에서 특정 노드에 배포하도록 하기 위해서 worker3.systemv.local 노드에 레이블링을 해줬기 때문에 이들 컴포넌트의 NodeSeletor 를 지정해 줘야 한다.

values.yaml 의 nodeSelector 설정
ZSH
1
2
3
4
5
    ## Define which Nodes the Pods are scheduled on.
    ## ref: https://kubernetes.io/docs/user-guide/node-selection/
    ##
    nodeSelector:
      system.rule: monitoring

Grafana, Altermanager, Prometheus 의 파드들은 system.rule=monitoring 레이블링 된 노드에만 설치되도록 해뒀다.

Node Exportor 는 system.rule=monitoring 레이블링을 할당하지 않는다. 이들은 노드마다 작동되어야 하기 때문이다.

Helm 설치

이제 설치를 해야 하는데, 설치하기 앞서 의존성 챠트를 업데이트 해야 한다.

프로메테우스 오퍼레이터 의존성 업데이트
ZSH
1
2
3
4
5
6
7
8
9
10
11
12
13
14
$ cd charts/kube-prometheus-stack/
$ helm dependency update
Getting updates for unmanaged Helm repositories...
...Successfully got an update from the "https://grafana.github.io/helm-charts" chart repository
Hang tight while we grab the latest from your chart repositories...
...Successfully got an update from the "ingress-nginx" chart repository
...Successfully got an update from the "prometheus-community" chart repository
...Successfully got an update from the "stable" chart repository
Update Complete. ⎈Happy Helming!⎈
Saving 3 charts
Downloading kube-state-metrics from repo https://prometheus-community.github.io/helm-charts
Downloading prometheus-node-exporter from repo https://prometheus-community.github.io/helm-charts
Downloading grafana from repo https://grafana.github.io/helm-charts
Deleting outdated charts

이제 다음과 같이 설치를 실행해 준다.

프로메테우스 오퍼레이터 설치
ZSH
1
2
3
4
5
6
7
8
9
10
11
$ helm install -f values.yaml promethus --namespace=monitoring .
NAME: promethus
LAST DEPLOYED: Sun Jul 25 09:08:15 2021
NAMESPACE: monitoring
STATUS: deployed
REVISION: 1
NOTES:
kube-prometheus-stack has been installed. Check its status by running:
  kubectl --namespace monitoring get pods -l "release=promethus"
 
Visit https://github.com/prometheus-operator/kube-prometheus for instructions on how to create & configure Alertmanager and Prometheus instances using the Operator.

확인

이제 확인을 해보자.

프로메테우스 설치 확인
ZSH
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
$ kubectl get pod -n monitoring -o wide
NAME                                                    READY   STATUS    RESTARTS   AGE     IP              NODE                     NOMINATED NODE   READINESS GATES
alertmanager-promethus-kube-prometheus-alertmanager-0   2/2     Running   0          5m52s   10.31.4.1       kworker3.systemv.local   <none>           <none>
prometheus-promethus-kube-prometheus-prometheus-0       2/2     Running   0          5m51s   10.31.4.2       kworker3.systemv.local   <none>           <none>
promethus-grafana-5d7bb49d46-w9447                      2/2     Running   0          6m19s   10.31.4.63      kworker3.systemv.local   <none>           <none>
promethus-kube-prometheus-operator-5b8849665f-b47dq     1/1     Running   0          6m19s   10.31.4.62      kworker3.systemv.local   <none>           <none>
promethus-kube-state-metrics-7f4995ccfb-5l2tb           1/1     Running   0          6m19s   10.31.20.15     kworker1.systemv.local   <none>           <none>
promethus-prometheus-node-exporter-g8hvx                1/1     Running   0          6m19s   192.168.96.49   kworker1.systemv.local   <none>           <none>
promethus-prometheus-node-exporter-mwdwd                1/1     Running   0          6m19s   192.168.96.50   kworker2.systemv.local   <none>           <none>
promethus-prometheus-node-exporter-p684h                1/1     Running   0          6m19s   192.168.96.51   kworker3.systemv.local   <none>           <none>
$ $ kubectl get svc -n monitoring -o wide
NAME                                     TYPE        CLUSTER-IP    EXTERNAL-IP   PORT(S)                      AGE     SELECTOR
alertmanager-operated                    ClusterIP   None          <none>        9093/TCP,9094/TCP,9094/UDP   9m59s   app.kubernetes.io/name=alertmanager
prometheus-operated                      ClusterIP   None          <none>        9090/TCP                     9m58s   app.kubernetes.io/name=prometheus
promethus-grafana                        ClusterIP   10.32.0.231   <none>        80/TCP                       10m     app.kubernetes.io/instance=promethus,app.kubernetes.io/name=grafana
promethus-kube-prometheus-alertmanager   ClusterIP   10.32.0.135   <none>        9093/TCP                     10m     alertmanager=promethus-kube-prometheus-alertmanager,app=alertmanager
promethus-kube-prometheus-operator       ClusterIP   10.32.0.147   <none>        443/TCP                      10m     app=kube-prometheus-stack-operator,release=promethus
promethus-kube-prometheus-prometheus     ClusterIP   10.32.0.148   <none>        9090/TCP                     10m     app.kubernetes.io/name=prometheus,prometheus=promethus-kube-prometheus-prometheus
promethus-kube-state-metrics             ClusterIP   10.32.0.71    <none>        8080/TCP                     10m     app.kubernetes.io/instance=promethus,app.kubernetes.io/name=kube-state-metrics
promethus-prometheus-node-exporter       ClusterIP   10.32.0.162   <none>        9100/TCP                     10m     app=prometheus-node-exporter,release=promethus

이렇게 설치가 된것으로 보이지만, 사실 프로메테우스의 오퍼레이터는 CRD 를 이용해 리소스를 생성하였기 때문에 이를 알아야 한다. CRD 를 포함한 monitoring 네임스페이스에 모든 리소스를 보기 위해서 다음과 같이 할 수 있다.

프로메테우스 오퍼레이터의 CRD 리소스 확인
ZSH
1
$ kubectl api-resources --verbs=list --namespaced -o name | xargs -n 1 kubectl get --show-kind --ignore-not-found -n monitoring

이를 통해 확인할 수 있는 CRD 예로 ServiceMonitor, Prometheus 등을 확인해 볼 수 있다.

필자는 Metallb 를 이용해서 LoadBalancer 를 사용할 수 있기 때문에 grafana, prometheus 서비스에 대해서 타입을 ClusterIP 를 LoadBalancer 로 변경해 외부접속이 가능하도록 할 수 있다.

grafana, prometheus 접속을 위해 LoadBalancer 타입으로 변경
ZSH
1
2
3
4
$ kubectl get svc -n monitoring
NAME                                      TYPE           CLUSTER-IP    EXTERNAL-IP     PORT(S)                      AGE
prometheus-grafana                        LoadBalancer   10.32.0.147   192.168.111.3   80:30015/TCP                 83m
prometheus-kube-prometheus-prometheus     LoadBalancer   10.32.0.142   192.168.111.4   9090:31559/TCP               83m

Metallb 에 의해서 EXTERNAL-IP 에 외부접속 IP 가 할당 되었다.

Ingress Nginx

인그레스(Ingress) 는 쿠버네티스에 설치하는 클러스터 내의 서비스에 대한 외부 접근을 관리하는 API 오브젝트이며, 일반적으로 HTTP를 관리한다. 인그레스를 위해서는 인그레스 오브젝트를 설치해야 하는데, 이를 구현한 것들이 꽤 있지만 nginx 가 대표적이다.

여기서는 Ingress-Nginx 에 대해서 간단히 알아 본다.

설치전 고려사항

첫째로 일단 쿠버네티스에 서비스(Service) 에 고려 해야 한다. 쿠버네티스의 서비스는 클러스터내에 접속지점을 생성해 준다. ClusterIP, LoadBalancer, NodePort 세 가지의 타입이 존재한다. 문제는 LoadBalancer 타입인데, 이 타입을 지정해주면 EXTERNAL-IP 가 할당되어야 하지만 일반적인 환경에서는 할당되지 않는다.

LoadBalancer 는 클라우드 서비스 제공 사업자를 위한 것으로 AWS, GCP, Azure 클라우드에서 제공하는 로드밸런서를 위한 것이다. 그래서 일반적인 베어메탈(Bare Metal) 이나 VM 환경(VMware, VirtualBox, KVM) 에서 쿠버네티스를 구성한 상태에서 LoadBalancer 를 사용하게 되면 EXTERNAL-IP 할당되지 않는다.

KVM 환경에서 쿠버네티스 서비스
ZSH
1
2
3
4
$ kubectl get svc
NAME                 TYPE        CLUSTER-IP    EXTERNAL-IP   PORT(S)   AGE
kubernetes           ClusterIP   10.32.0.1     <none>        443/TCP   96d
springboot-service   ClusterIP   10.32.0.216   <none>       80/TCP    9s

이렇게 하면 외부에서 접속이 되지 않는다. 이 접속은 클러스터내에 파드(Pod) 에서 호출할 수 있지만 외부에서는 호출이 되지 않는다.

그래서 베어메탈이나 가상환경에서 쿠버네티스에서 LoadBalancer 를 사용할 수 있도록 해주는 Metallb 을 이용했다. 이를 이용하면 서비스 타입을 LoadBalancer 로 지정했을 경우, EXTERNAL-IP 가 할당돼 외부에서 접속이 가능해 진다.

두번째로 ingress-nginx 를 Helm 으로 설치하지 말아야 한다. 현재 Helm 저장소에 올라온 ingress-nginx 는 api 버전이 과거에 버전이다. v1beta 버전으로 되어 있는데, 필자의 쿠버네티스에서는 오래된 버전으로 인식된다.

이를 해결하기 위해서는 github 저장소에 baremetal 버전에 deploy.yaml 파일을 이용해야 한다.

설치

먼저 ingress-nginx 의 github 에 접속해 baremetal 버전을 다운로드 받는다.

ingress-nginx github 에서 baremetal 의 deploy 다운로드
ZSH
1
$ wget https://raw.githubusercontent.com/kubernetes/ingress-nginx/main/deploy/static/provider/baremetal/deploy.yaml

이 deploy.yaml 은 baremetal 버전인데, 여기의 서비스 타입은 NodePort 로 되어 있다. 필자는 앞에서도 말했지만 Metallb 를 설치했기 때문에 LoadBalancer 타입으로 변경을 해줘야 한다. deploy.yaml 파일을 열어서 바꿔 준다.

NodePort 를 LoadBalancer 로 바꾼다
diff
1
2
3
4
5
6
7
8
9
10
11
12
spec:
-  type: NodePort
+  type: LoadBalancer
  ports:
    - name: http
      port: 80
      protocol: TCP
      targetPort: http
    - name: https
      port: 443
      protocol: TCP
      targetPort: https

서비스 타입을 바꿨다면 이제 설치를 해 준다.

ingress-nginx 설치
ZSH
1
$ kubectl apply -f deploy.yaml

이 방법으로 설치를 하게 되면 다음과 같은 특징을 갖게 된다.

  • ingress-nginx 네임스페이스가 생성 된다.
  • LoadBalancer 타입이며, Metallb 으로 인해 EXTERNAL-IP 가 할당 된다.
  • apiVersion 이 networking.k8s.io/v1 최신 버전을 지원 한다.
ingress-nginx 의 서비스
ZSH
1
2
3
4
5
$ kubectl get svc -A
NAMESPACE       NAME                                 TYPE           CLUSTER-IP    EXTERNAL-IP     PORT(S)                        AGE
default         kubernetes                           ClusterIP      10.32.0.1     <none>          443/TCP                        97d
ingress-nginx   ingress-nginx-controller             LoadBalancer   10.32.0.228   192.168.111.2   80:30077/TCP,443:31356/TCP     3m18s
</none>

LoadBalancer 에 EXTERNAL-IP 에 외부 접속을 하기 위한 IP가 할당되어 있다.

예제

예제는 springboot 를 이용한 서비스를 배포하고 ingress 를 통해서 접속해 본다. 이 예제는 하나의 서비스에 대한 것이다.

먼저 Deployment, Service 를 다음과 같이 작성 한다.

springboot 의 Deployment, Service 생성
ZSH
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
]$ vim springboot.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: springboot-deployment
  labels:
    app: springboot
spec:
  replicas: 3
  selector:
    matchLabels:
      app: springboot
  template:
    metadata:
      labels:
        app: springboot
    spec:
      containers:
      - name: springboot
        image: gazgeek/springboot-helloworld
        imagePullPolicy: Always
        ports:
        - containerPort: 8080
---
apiVersion: v1
kind: Service
metadata:
  name: springboot-service
spec:
  selector:
    app: springboot
  ports:
    - protocol: TCP
      port: 80
      targetPort: 8080
]$ kubectl apply -f springboot.yaml
deployment.apps/springboot-deployment created
service/springboot-service created

정상적으로 생성이 되었다. 이제 이것을 인그래스와 연결을 해줘야 한다. 인그래스에서 URI 가 /springboot 이면 지금 배포한 springboot 의 메시지가 화면 표시되도록 했다.

인그래스 작성 및 적용
ZSH
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
]$ vim ingress-springboot.yaml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: springboot-ingress
  annotations:
    kubernetes.io/ingress.class: nginx
    nginx.ingress.kubernetes.io/rewrite-target: /
spec:
  rules:
  - http:
      paths:
      - path: /springboot
        pathType: Prefix
        backend:
          service:
            name: springboot-service
            port:
              number: 80
]$ kubectl apply -f ingress-springboot.yaml
Error from server (InternalError): error when creating "ingress.yaml": Internal error occurred: failed calling webhook "validate.nginx.ingress.kubernetes.io": Post "https://ingress-nginx-controller-admission.ingress-nginx.svc:443/networking/v1/ingresses?timeout=10s": context deadline exceeded

직접해보면 위와같이 오류가 발생한다. 이는 보안 관련 쪽에 문제가 있는 것으로 보이는데, 아마도 TLS 설정에 문제가 있기 때문인 것으로 추정 된다. 이를 해결하기 위해서는 webhook 설정을 삭제해주면 된다.

webhook 설정 삭제
ZSH
1
2
]$ kubectl delete -A ValidatingWebhookConfiguration ingress-nginx-admission
validatingwebhookconfiguration.admissionregistration.k8s.io "ingress-nginx-admission" deleted

그리고 다시 한번 ingress-springboot.yaml 파일을 적용해주면 인그래스가 생성 된다.

생성한 인그래스 확인
ZSH
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
$ kubectl describe ingress springboot-ingress
Name:             springboot-ingress
Namespace:        default
Address:          192.168.96.51
Default backend:  default-http-backend:80 (<error: endpoints="" "default-http-backend"="" not="" found="">)
Rules:
  Host        Path  Backends
  ----        ----  --------
  *          
              /springboot   springboot-service:80 (10.31.4.55:8080,10.31.4.56:8080,10.31.4.57:8080)
Annotations:  kubernetes.io/ingress.class: nginx
              nginx.ingress.kubernetes.io/rewrite-target: /
Events:
  Type    Reason  Age               From                      Message
  ----    ------  ----              ----                      -------
  Normal  Sync    3s (x2 over 54s)  nginx-ingress-controller  Scheduled for sync

/springboot URI 는 springboot-service 백엔드로 연결이 되어 있다걸 확인할 수 있다. 이제 인그레스 서비스에 LoadBalancer 의 외부 접속 IP 로 접속을 시도해 보자.

인그레스 확인
ZSH
1
2
$ curl http://192.168.111.2/springboot
Hello from GazGeek!

위와같이 인그레스가 정상적으로 동작함을 알 수 있다.

정리

지금까지의 예제는 쿠버네티스 인그레스 문서의 첫번째 다이어그램과 정확하게 같은 것이다.

단일 서비스에 인그레스 적용 다이어그램

클라이언트가 인그레스 로드 밸런서로 접속이 가능해야 했기 때문에 Metallb 을 이용해서 외부접속 IP를 할당해 주도록 설정을 했다.

인그레스 서비스는 설치할때 한번 생성되어지고 이것을 통해서 뒤에 서비스들과 연결이 되어지는데, 이 백엔드 서비스들에 어떻게 연결을 할 것이지에 대한 설정은 인그레스 컨트롤러에 의해서 결정되게 된다.

쿠버네티스 수동 설치

쿠버네티스 설치는 kubeadm 명령어를 이용하면 손쉽게 자동으로 이루어 진다. HA 를 위한 설치에서는 좀 더 손이 더 가겠지만 어쨌거나 그것도 kubeadm 을 이용한다. 쿠버네티스 설치에 많은 시간을 들이는 것이 그렇게 현명해 보이지는 않을 수 있지만 쿠버네티스의 기본적인 구조를 이해하는데 수동 설치만큼 유용한 것도 없다.

인터넷을 검색해보면 쿠버네티스 수동 설치는 보통 ‘Hard way’ 로 많이 나온다. ‘힘든 방법’ 등으로 번역할 수 있는데, 하나하나 수동으로 설치를 하게 된다. 이 글이 어렵다면 ‘Kubernetes Hard way’ 로 검색하면 많은 자료를 얻을 수 있다.

Requirements

쿠버네티스 수동 설치의 최종적인 모습은 다음과 같다.

위 그림은 ‘고가용성 토폴로지 선택‘ 문서에 나온 것이다. 컨트롤 플레인 노드는 적어도 3개, 워커 노드도 적어도 3개 그리고 중간에 로드 밸런서(Load balancer) 가 필요하다. 정리를 하면 다음과 같다.

  1. 컨트롤 플레인 노드(Control plane Node): 3개
  2. 워커 노드(Worker Node): 3개
  3. 로드 밸런서(Load balancer): 1개

이를 위해서 필자는 KVM 으로 VM 호스트를 6개를 만들었고 로드 밸런서는 KVM 호스트 컴퓨터에 HAProxy 를 구성하는 것으로 결정 했다.

툴 설치

쿠버네티스는 내부에 많은 프로그램들로 구성된다. 이들 프로그램들 간의 통신은 보안 통신을 기반으로 하는데, 이를 위해서는 TLS 인증서가 필요하다. 생성하는 방법은 다양하지만 CloudFlare 에서 만든 cfssl, cfssljson 명령어를 가장 많이 이용한다.

cfssl, cfssljson 명령어는 cfssl respository 에서 공식 배포 된다.

cfssl, cfssljson 설치
ZSH
1
2
3
4
5
6
]$ wget -q --show-progress --https-only --timestamping \
  https://pkg.cfssl.org/R1.2/cfssl_linux-amd64 \
  https://pkg.cfssl.org/R1.2/cfssljson_linux-amd64
]$ chmod +x cfssl_linux-amd64 cfssljson_linux-amd64
]$ sudo mv cfssl_linux-amd64 /usr/local/bin/cfssl
]$ sudo mv cfssljson_linux-amd64 /usr/local/bin/cfssljson

kubectl 명령어도 다음과 같이 설치를 해준다. kubectl 명령어 설치는 Kubernetes 메뉴얼에 잘 나와 있다.

kubectl 설치
ZSH
1
2
3
]$ curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl"
]$ chmod +x kubectl
]$ sudo mv kubectl /usr/local/bin/

쿠버네티스 수동 설치를 위한 자원들

앞에서 쿠버네티스 컨트롤 플레인, 워커, 로드 밸런서에 대해서 언급을 했었는데 자세하게는 다음과 같다.

호스트 이름도메인아이피
kmaster1kmaster1.systemv.local192.168.96.46
kmaster2kmaster2.systemv.local192.168.96.47
kmaster3kmaster3.systemv.local192.168.96.48
haproxyhaproxy.systemv.local192.168.96.7
kworker1kworker1.systemv.local192.168.96.49
kworker2kworker2.systemv.local192.168.96.50
kworker3kworker3.systemv.local192.168.96.51

도메인은 내부 도메인네임서버를 운영하고 있어 이를 이용했다. 운영체제는 우분투(Ubuntu) 20.04 LTS 다. KVM 의 네트워크는 NAT 가 아니라 브릿지(Bridge) 네트워크로 구성해 KVM 게스트를 외부에서도 자유롭게 접속되도록 구성 했다. KVM의 게스트는 공유기 IP 대역에서 고정IP로 설정을 했다.

TLS 인증서 생성하기

CA(Certificate Authority) 작성하기

쿠버네티스에서 사용하는 인증서는 Self Sign 인증서다. 보통 인증서라고 하면 HTTPS 통신을 위한 인증서를 많이 들어봤을 것이다. 이 인증서를 발급받기 위해서는 여러 과정이 필요한데, 이 과정을 자세히 알고 있다면 이 과정이 이해하기 쉽다.

HTTPS 인증서를 발급 받기 위해서는 CSR 을 먼저 작성해야 한다. 하지만 그 전에 필요한 것이 CA 다. 보통은 CSR 을 작성해 CA 기관에 제출하는 형태로 진행이되지만 Self Sign 할때에는 CA 가 없다. 공인 CA에서 Self Sign 인증서를 발급해줄리도 만무하고… 그래서 CA 를 먼저 생성해 준다.

Root CA 의 역할은 제출받은 CSR 를 받아서 개인키를 돌려준다. 보통 HTTP 인증서를 발급받을때에 Root CA 는 기관에서 하기 때문에 돈을 주고 해달라고 요청을 하게 된다. 하지만 Self Sign 인증서를 작성할때에는 Root CA 기관의 CA 키가 있다고 가정하고 그 CA Key + CSR 를 돌려서 개인키를 발급받게 된다. 요약하자면 공인 Root CA 에서 사용하는 CA 키를 셀프로 만드는 것이다.

셀프 Root CA 는 모든 인증서의 기반이 된다.

Self Sign Root CA 인증성 생성
ZSH
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
]$ cat > ca-config.json <<EOF
{
  "signing": {
    "default": {
      "expiry": "8760h"
    },
    "profiles": {
      "kubernetes": {
        "usages": ["signing", "key encipherment", "server auth", "client auth"],
        "expiry": "8760h"
      }
    }
  }
}
EOF
]$ cat > ca-csr.json <<EOF
{
  "CN": "Kubernetes",
  "key": {
    "algo": "rsa",
    "size": 2048
  },
  "names": [
    {
      "C": "US",
      "L": "Portland",
      "O": "Kubernetes",
      "OU": "CA",
      "ST": "Oregon"
    }
  ]
}
EOF
]$ cfssl gencert -initca ca-csr.json | cfssljson -bare ca
2021/04/16 10:39:10 [INFO] generating a new CA key and certificate from CSR
2021/04/16 10:39:10 [INFO] generate received request
2021/04/16 10:39:10 [INFO] received CSR # csr 받음
2021/04/16 10:39:10 [INFO] generating key: rsa-2048
2021/04/16 10:39:10 [INFO] encoded CSR # csr 인코딩
2021/04/16 10:39:10 [INFO] signed certificate with serial number 218079751927709843791408092001643512042320999306

출력 메시지를 자세히보면 new CA key 와 CSR 를 기반으로 new certificate 를 생성중이라고 시작하고 ‘CSR 받았다’ 그리고 ‘CSR 인코드’ 라고 나온다. 생성된 파일은 다음과 같다.

생성된 파일
ZSH
1
2
3
4
5
$ ls -lh
total 20K
-rw-r--r-- 1 systemv systemv 1005 Apr 16 10:39 ca.csr
-rw------- 1 systemv systemv 1.7K Apr 16 10:39 ca-key.pem
-rw-rw-r-- 1 systemv systemv 1.4K Apr 16 10:39 ca.pem

ca.pem 은 인증서이며 ca-key.pem 은 Root CA 에서 사용할 개인키(Private Key) 다. ca.csr 은 인증 요청서. Self Root CA 조차도 Key 를 요청하기는 것이기 때문에 CSR 이 필요하게 돼, ca.csr 이 만들어진다.

이 Self Root CA 는 Self Root CA 기관을 하나 만들었다고 생각하면 된다.

apiserver 클러스터 관리자 인증을 위한 클라이언트 인증서

마치 SSH 인증서를 사용한 인증 로그인이 가능하듯이 apiserver 클러스터 관리자 인증을 위해서 별도의 인증서가 필요한 모양이다. 이를 다음과 같이 생성해 준다.

apiserver 클러스터 관리자 인증을 위한 인증서 생성
ZSH
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
$ cat > admin-csr.json <<EOF
{
  "CN": "admin",
  "key": {
    "algo": "rsa",
    "size": 2048
  },
  "names": [
    {
      "C": "US",
      "L": "Portland",
      "O": "system:masters",
      "OU": "Kubernetes The Hard Way",
      "ST": "Oregon"
    }
  ]
}
EOF
$ cfssl gencert \
  -ca=ca.pem \
  -ca-key=ca-key.pem \
  -config=ca-config.json \
  -profile=kubernetes \
  admin-csr.json | cfssljson -bare admin
2021/04/16 11:00:23 [INFO] generate received request
2021/04/16 11:00:23 [INFO] received CSR
2021/04/16 11:00:23 [INFO] generating key: rsa-2048
2021/04/16 11:00:23 [INFO] encoded CSR
2021/04/16 11:00:23 [INFO] signed certificate with serial number 115687386704811718443950929337723184713983594790
2021/04/16 11:00:23 [WARNING] This certificate lacks a "hosts" field. This makes it unsuitable for
websites. For more information see the Baseline Requirements for the Issuance and Management
of Publicly-Trusted Certificates, v.1.1.6, from the CA/Browser Forum (https://cabforum.org);
specifically, section 10.2.3 ("Information Requirements").

O, 그러니까 조직(Oganization) 이 “system:masters” 라는 사실에 주목해야 한다.

이렇게하면 admin-key.pem, admin.pem 이 생성된다.

Kubelet 클라이언트 인증서

Kubelet 은 쿠버네티스 클러스터에 각 노드에 설치되는 에이전트다. 이는 파드(Pod) 에 컨테이너가 실행되도록 해준다.

쿠버네티스는 노드 인증(Node Authorizer) 라 부르는, 특히 Kubelets 에 의한 API 요청 인증에 특별한 목적의 인증 모드를 사용한다. 노드 인증(Node Authorizer) 로 인증되기 위해, Kubelets 는 반드시 system:node:<nodename> 의 이름을 가진 system:nodes 그룹에 그들이 있는 것처럼 확인된 자격증명을 사용해야 한다.

따라서 nodename 이 반드시 있어야 한다. 만일 DNS 서버가 없다고 해도 괜찮다. 쿠버네티스 클러스터를 위한 서버들에 /etc/hosts 에 정적으로 도메인을 할당하면 되며, 호스트도 마찬가지로 정적으로 넣어줘도 된다.

앞에서 워커 노드의 경우에 worker1, worker2, worker3, 3개의 worker 노드가 있다. 이에 대해서 CSR 을 만들어 준다.

Kubelet 클라이언트 인증서를 위한 CSR 요청서
ZSH
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
$ DOMAIN="systemv.local"
$ for instance in kworker1 kworker2 kworker3; do
cat > ${instance}-csr.json <<EOF
{
  "CN": "system:node:${instance}.${DOMAIN}",
  "key": {
    "algo": "rsa",
    "size": 2048
  },
  "names": [
    {
      "C": "US",
      "L": "Portland",
      "O": "system:nodes",
      "OU": "Kubernetes The Hard Way",
      "ST": "Oregon"
    }
  ]
}
EOF
done
$ cat kworker1-csr.json
{
  "CN": "system:node:kworker1",
  "key": {
    "algo": "rsa",
    "size": 2048
  },
  "names": [
    {
      "C": "US",
      "L": "Portland",
      "O": "system:nodes",
      "OU": "Kubernetes The Hard Way",
      "ST": "Oregon"
    }
  ]
}

CSR 은 인증서를 요청하기 위한 문서라고 보면 된다. 여기에는 요청에 필요한 각종정보를 적게 되어 있는데, O 의 경우에 조직(Oganization) 을 뜻하며 CN 은 Company Name 이다. 이것을 Kubelets 에서는 system:nodes 조직, system:nodes:worker1.systemv.local 회사등으로 인식한다고 보면 된다. CN 에 node 이름을 도메인명으로 했다는 것을 잘 봐둬야 한다.

이제 인증서를 만들어야 하는데, Self Root CA 와 CSR 를 조합해서 만든다. 단, 여기서 주의해야 하는 것은 호스트네임(hostname) 을 줘야 한다. 호스트네임은 콤마(,) 를 구분자로 여러개를 줄 수 있는데 여기서는 호스트네임, 아이피를 주고 생성한다. worker 서버 3개에 대해서 각각 만들어 준다.

Kubelet 클라이언트 인증서 생성
ZSH
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
$ cfssl gencert \
  -ca=ca.pem \
  -ca-key=ca-key.pem \
  -config=ca-config.json \
  -hostname=kworker1.systemv.local,kworker1,192.168.96.49 \
  -profile=kubernetes \
  kworker1-csr.json | cfssljson -bare kworker1
2021/04/16 11:25:47 [INFO] generate received request
2021/04/16 11:25:47 [INFO] received CSR
2021/04/16 11:25:47 [INFO] generating key: rsa-2048
2021/04/16 11:25:48 [INFO] encoded CSR
2021/04/16 11:25:48 [INFO] signed certificate with serial number 538816406986381230934384726276464293616164354584
$ cfssl gencert \
  -ca=ca.pem \
  -ca-key=ca-key.pem \
  -config=ca-config.json \
  -hostname=kworker2.systemv.local,kworker2,192.168.96.50 \
  -profile=kubernetes \
  kworker2-csr.json | cfssljson -bare kworker2
2021/04/16 11:26:59 [INFO] generate received request
2021/04/16 11:26:59 [INFO] received CSR
2021/04/16 11:26:59 [INFO] generating key: rsa-2048
2021/04/16 11:27:00 [INFO] encoded CSR
2021/04/16 11:27:00 [INFO] signed certificate with serial number 597751742484889183781059204510460046544933863841
$ cfssl gencert \
  -ca=ca.pem \
  -ca-key=ca-key.pem \
  -config=ca-config.json \
  -hostname=kworker3.systemv.local,kworker3,192.168.96.51 \
  -profile=kubernetes \
  kworker3-csr.json | cfssljson -bare kworker3
2021/04/16 11:27:46 [INFO] generate received request
2021/04/16 11:27:46 [INFO] received CSR
2021/04/16 11:27:46 [INFO] generating key: rsa-2048
2021/04/16 11:27:47 [INFO] encoded CSR
2021/04/16 11:27:47 [INFO] signed certificate with serial number 9063887800656623067709796741742546672753221216

-hostname 에 콤마(,) 를 이용해 도메인, 호스트네임, IP 주소를 적고 있는데 이것은 SAN 확장을 위한 것이다. 멀티도메인 인증서에서 주로 많이 나오는 이야기인데, SAN 은 하나의 SSL 인증서에 여러개의 도메인을 사용할 수 있도록 해주는 X509 인증서의 확장이다.

이렇게 해서 생성한 인증서는 다음과 같다.

Kubelet 클라이언트 인증서
1
2
3
4
5
6
kworker1-key.pem
kworker1.pem
kworker2-key.pem
kworker2.pem
kworker3-key.pem
kworker3.pem

-hostname 으로 준 도메인,호스트네임,IP 주소가 인증서에 잘 있는지를 확인하는 방법은 다음과 같다.

kworker1.pem 인증서 확인
1
2
3
4
5
$ openssl x509 -in kworker1.pem -text -noout
...
            X509v3 Subject Alternative Name:
                DNS:kworker1.systemv.local, DNS:kworker1, IP Address:192.168.96.49
...

TLS 인증서는 CSR 과 RSA Public Key 조합으로 구성되며 이것을 Root CA 의 Private Key 를 이용해 암호화 된 상태다. 따라서 그냥 텍스트 에디터로 열어보면 암호화 스트링을 볼수 있는데, openssl 명령어를 이용하면 위와같이 텍스트로 확인이 가능하다. -hostname 으로 준 도메인,호스트네임,IP 주소는 DNS 와 IP Address 로 인식이 되었다.

kube-controller-manager 와 통신을 위한 인증서

kube-controller-manager 와 통신을 위한 인증서를 생성해 준다.

kube-controller-manager 와 통신을 위한 인증서
ZSH
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
$ cat > kube-controller-manager-csr.json <<EOF
{
  "CN": "system:kube-controller-manager",
  "key": {
    "algo": "rsa",
    "size": 2048
  },
  "names": [
    {
      "C": "US",
      "L": "Portland",
      "O": "system:kube-controller-manager",
      "OU": "Kubernetes The Hard Way",
      "ST": "Oregon"
    }
  ]
}
EOF
$ cfssl gencert \
  -ca=ca.pem \
  -ca-key=ca-key.pem \
  -config=ca-config.json \
  -profile=kubernetes \
  kube-controller-manager-csr.json | cfssljson -bare kube-controller-manager
2021/04/16 11:53:51 [INFO] generate received request
2021/04/16 11:53:51 [INFO] received CSR
2021/04/16 11:53:51 [INFO] generating key: rsa-2048
2021/04/16 11:53:51 [INFO] encoded CSR
2021/04/16 11:53:51 [INFO] signed certificate with serial number 707492023587759406906035528054497220180910976164
2021/04/16 11:53:51 [WARNING] This certificate lacks a "hosts" field. This makes it unsuitable for
websites. For more information see the Baseline Requirements for the Issuance and Management
of Publicly-Trusted Certificates, v.1.1.6, from the CA/Browser Forum (https://cabforum.org);
specifically, section 10.2.3 ("Information Requirements").

“O”: “system:kube-controller-manager” 에 주목해야 한다.

kube-proxy 와 통신을 위한 인증서

kube-proxy 와 통신을 위한 인증서를 생성해 준다.

kube-proxy 와 통신을 위한 인증서
ZSH
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
$ cat > kube-proxy-csr.json <<EOF
{
  "CN": "system:kube-proxy",
  "key": {
    "algo": "rsa",
    "size": 2048
  },
  "names": [
    {
      "C": "US",
      "L": "Portland",
      "O": "system:node-proxier",
      "OU": "Kubernetes The Hard Way",
      "ST": "Oregon"
    }
  ]
}
EOF
$ cfssl gencert \
  -ca=ca.pem \
  -ca-key=ca-key.pem \
  -config=ca-config.json \
  -profile=kubernetes \
  kube-proxy-csr.json | cfssljson -bare kube-proxy
2021/04/16 11:56:31 [INFO] generate received request
2021/04/16 11:56:31 [INFO] received CSR
2021/04/16 11:56:31 [INFO] generating key: rsa-2048
2021/04/16 11:56:31 [INFO] encoded CSR
2021/04/16 11:56:31 [INFO] signed certificate with serial number 663577426807755857235217640760583940251020445314
2021/04/16 11:56:31 [WARNING] This certificate lacks a "hosts" field. This makes it unsuitable for
websites. For more information see the Baseline Requirements for the Issuance and Management
of Publicly-Trusted Certificates, v.1.1.6, from the CA/Browser Forum (https://cabforum.org);
specifically, section 10.2.3 ("Information Requirements").

“O”: “system:node-proxier” 에 주목해야 한다.

kube-scheduler 와 통신을 위한 인증서

kube-scheduler 와 통신을 위한 인증서를 생성해 준다.

kube-scheduler 와 통신을 위한 인증서
ZSH
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
$ cat > kube-scheduler-csr.json <<EOF
{
  "CN": "system:kube-scheduler",
  "key": {
    "algo": "rsa",
    "size": 2048
  },
  "names": [
    {
      "C": "US",
      "L": "Portland",
      "O": "system:kube-scheduler",
      "OU": "Kubernetes The Hard Way",
      "ST": "Oregon"
    }
  ]
}
EOF
$ cfssl gencert \
  -ca=ca.pem \
  -ca-key=ca-key.pem \
  -config=ca-config.json \
  -profile=kubernetes \
  kube-scheduler-csr.json | cfssljson -bare kube-scheduler
2021/04/16 11:59:13 [INFO] generate received request
2021/04/16 11:59:13 [INFO] received CSR
2021/04/16 11:59:13 [INFO] generating key: rsa-2048
2021/04/16 11:59:13 [INFO] encoded CSR
2021/04/16 11:59:13 [INFO] signed certificate with serial number 619651712283739066643157460188000366903756344982
2021/04/16 11:59:13 [WARNING] This certificate lacks a "hosts" field. This makes it unsuitable for
websites. For more information see the Baseline Requirements for the Issuance and Management
of Publicly-Trusted Certificates, v.1.1.6, from the CA/Browser Forum (https://cabforum.org);
specifically, section 10.2.3 ("Information Requirements").

노드간 API Server 통신을 위한 인증서

Kubernetes API Server 인증서라고 설명되어 있지만 앞에 다이어그램을 보면, API Server 는 쿠버네티스 컨트롤 플레인 노드에 있게 된다. 그리고 로드 밸런서를 통해서 워커 노드와 통신을 하게 된다. 이뿐만 아니라 API Server 는 외부에 클라이언트와 Kubectl 을 통해서 통신도 해야 한다.

이를 위해서 인증서에는 쿠버네티스 컨트롤 플레인 서버들과 로드밸런서에 대해 각각 인증이 가능해야 한다.

kube-api server 와 통신을 위한 인증서
ZSH
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
$ DOMAIN=systemv.local
$ KUBERNETES_HOSTNAMES=kubernetes,kubernetes.default,kubernetes.default.svc,kubernetes.default.svc.cluster,kubernetes.svc.cluster.local
$ cat > kubernetes-csr.json <<EOF
{
  "CN": "kubernetes",
  "key": {
    "algo": "rsa",
    "size": 2048
  },
  "names": [
    {
      "C": "US",
      "L": "Portland",
      "O": "Kubernetes",
      "OU": "Kubernetes The Hard Way",
      "ST": "Oregon"
    }
  ]
}
EOF
$ cfssl gencert \
  -ca=ca.pem \
  -ca-key=ca-key.pem \
  -config=ca-config.json \
  -hostname=haproxy.${DOMAIN},192.168.96.7,192.168.96.46,192.168.96.47,192.168.96.48,127.0.0.1,10.32.0.1,${KUBERNETES_HOSTNAMES} \
  -profile=kubernetes \
  kubernetes-csr.json | cfssljson -bare kubernetes

-hostname 옵션에 보면 haproxy 의 도메인과 IP 주소를 연다라 입력해줬고, 그 이후에 kmaster1~3 까지 IP 주소를 입력해 줬다. 그리고 localhost 에 해당하는 127.0.0.1 을 입력해주고 10.32.0.1 을 입력해줬다. 이 주소는 후에 컨트롤 플레인을 만들때에 사용할 Cluster IP 주소 대역 10.32.0.0/16 에 첫번째 주소다.

쿠버네티스 API 서버는 내부 DNS 네임에 kubernetes 를 Cluster IP 대역의 첫번째 IP와 묶어서 저장해놓는다. 따라서 이 10.32.0.1 주소는 Cluster IP 대역과 연관이 돼 있다는 것을 알아야 한다.

Service Account Key Pair

Kubernetes Controller Manager는 managing service accounts 문서에 설명된대로 키 페어를 사용하여 서비스 계정 토큰을 생성하고 서명합니다.

service account key pair 위한 인증서
ZSH
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
$ cat > service-account-csr.json <<EOF
{
  "CN": "service-accounts",
  "key": {
    "algo": "rsa",
    "size": 2048
  },
  "names": [
    {
      "C": "US",
      "L": "Portland",
      "O": "Kubernetes",
      "OU": "Kubernetes The Hard Way",
      "ST": "Oregon"
    }
  ]
}
EOF
$ cfssl gencert \
  -ca=ca.pem \
  -ca-key=ca-key.pem \
  -config=ca-config.json \
  -profile=kubernetes \
  service-account-csr.json | cfssljson -bare service-account
2021/04/16 12:26:10 [INFO] generate received request
2021/04/16 12:26:10 [INFO] received CSR
2021/04/16 12:26:10 [INFO] generating key: rsa-2048
2021/04/16 12:26:10 [INFO] encoded CSR
2021/04/16 12:26:10 [INFO] signed certificate with serial number 657346270815993169700676646594372924490206343750
2021/04/16 12:26:10 [WARNING] This certificate lacks a "hosts" field. This makes it unsuitable for
websites. For more information see the Baseline Requirements for the Issuance and Management
of Publicly-Trusted Certificates, v.1.1.6, from the CA/Browser Forum (https://cabforum.org);
specifically, section 10.2.3 ("Information Requirements").

이제 필요한 인증서는 다 작성되었다.

인증서 배포

워커 노드에는 ca, kubelet 클라이언트 인증서, kubelet 클라이언트 키를 노드에 복사해 준다.

워커 노드에 인증서 배포
ZSH
1
2
3
$ scp ca.pem kworker1.pem kworker1-key.pem kube-proxy.pem kube-proxy-key.pem kworker1.systemv.local:./
$ scp ca.pem kworker2.pem kworker2-key.pem kube-proxy.pem kube-proxy-key.pem kworker2.systemv.local:./
$ scp ca.pem kworker3.pem kworker3-key.pem kube-proxy.pem kube-proxy-key.pem kworker3.systemv.local:./

컨트롤 플레인 노드에는 ca, ca key, apiserver 인증서, apiserver key, service account key pair 를 노드에 복사해 준다.

컨트롤 플레인 노드에 인증서 배포
ZSH
1
2
3
$ scp ca.pem ca-key.pem kubernetes-key.pem kubernetes.pem service-account-key.pem service-account.pem kmaster1.systemv.local:./
$ scp ca.pem ca-key.pem kubernetes-key.pem kubernetes.pem service-account-key.pem service-account.pem kmaster2.systemv.local:./
$ scp ca.pem ca-key.pem kubernetes-key.pem kubernetes.pem service-account-key.pem service-account.pem kmaster3.systemv.local:./

클라이언트 인증 설정

controller manager, kubelet, kube-proxy, scheduler 클라이언트 그리고 admin 사용자를 위한 kubeconfig 파일을 생성해준다.

쿠버네티스 공인 IP 주소

kubeconfig 는 쿠버네티스 API Server 에 접속이 필요하다. 고가용성을 위해서 API Server 앞에 외부 로드 밸런서에 IP 주소를 할당해서 사용했다. 이것은 아키텍쳐 다이어그램에서 로드밸런서가 쿠버네티스의 공인 IP가 되며 여기는 HAProxy 의 IP 주소다.

Kubernetes 공인 IP
ZSH
1
$ KUBERNETES_PUBLIC_ADDRESS=192.168.96.7

kubelet 쿠버네티스 설정 파일

Kubelets 를 위한 kubeconfig 파일을 생성할때, Kubelet의 노드 이름과 일치하는 클라이언트 인증서를 사용해야 한다. 이것은 쿠버네티스 Node Authorizer 로 인증할 수 있도록 해준다.

kubelet 쿠버네티스 설정 파일
ZSH
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
$ DOMAIN=systemv.local
$ for instance in kworker1 kworker2 kworker3; do
  kubectl config set-cluster kubernetes-the-hard-way \
    --certificate-authority=ca.pem \
    --embed-certs=true \
    --server=https://${KUBERNETES_PUBLIC_ADDRESS}:6443 \
    --kubeconfig=${instance}.kubeconfig
 
  kubectl config set-credentials system:node:${instance}.${DOMAIN} \
    --client-certificate=${instance}.pem \
    --client-key=${instance}-key.pem \
    --embed-certs=true \
    --kubeconfig=${instance}.kubeconfig
 
  kubectl config set-context default \
    --cluster=kubernetes-the-hard-way \
    --user=system:node:${instance}.${DOMAIN} \
    --kubeconfig=${instance}.kubeconfig
 
  kubectl config use-context default --kubeconfig=${instance}.kubeconfig
done
Cluster "kubernetes-the-hard-way" set.
User "system:node:kworker1" set.
Context "default" created.
Switched to context "default".
Cluster "kubernetes-the-hard-way" set.
User "system:node:kworker2" set.
Context "default" created.
Switched to context "default".
Cluster "kubernetes-the-hard-way" set.
User "system:node:kworker3" set.
Context "default" created.
Switched to context "default".

kube-proxy 쿠버네티스 설정 파일

kube-proxy 서비스를 위한 설정 파일을 생성해 준다.

kube-proxy 서비스를 위한 설정 파일 생성
ZSH
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
$ kubectl config set-cluster kubernetes-the-hard-way \
    --certificate-authority=ca.pem \
    --embed-certs=true \
    --server=https://${KUBERNETES_PUBLIC_ADDRESS}:6443 \
    --kubeconfig=kube-proxy.kubeconfig
Cluster "kubernetes-the-hard-way" set.
$ kubectl config set-credentials system:kube-proxy \
    --client-certificate=kube-proxy.pem \
    --client-key=kube-proxy-key.pem \
    --embed-certs=true \
    --kubeconfig=kube-proxy.kubeconfig
User "system:kube-proxy" set.
$ kubectl config set-context default \
    --cluster=kubernetes-the-hard-way \
    --user=system:kube-proxy \
    --kubeconfig=kube-proxy.kubeconfig
Context "default" created.
$ kubectl config use-context default --kubeconfig=kube-proxy.kubeconfig
Switched to context "default".

kube-proxy.kubeconfig 파일이 생성된다.

kube-controller-manager 쿠버네티스 설정 파일

kube-controller-manager 서비스를 위한 kubeconfig 파일을 생성해 준다.

kube-controller-manager 서비스를 위한 설정 파일 생성
ZSH
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
$ kubectl config set-cluster kubernetes-the-hard-way \
    --certificate-authority=ca.pem \
    --embed-certs=true \
    --server=https://127.0.0.1:6443 \
    --kubeconfig=kube-controller-manager.kubeconfig
Cluster "kubernetes-the-hard-way" set.
$ kubectl config set-credentials system:kube-controller-manager \
    --client-certificate=kube-controller-manager.pem \
    --client-key=kube-controller-manager-key.pem \
    --embed-certs=true \
    --kubeconfig=kube-controller-manager.kubeconfig
User "system:kube-controller-manager" set.
$ kubectl config set-context default \
    --cluster=kubernetes-the-hard-way \
    --user=system:kube-controller-manager \
    --kubeconfig=kube-controller-manager.kubeconfig
Context "default" created.
$ kubectl config use-context default --kubeconfig=kube-controller-manager.kubeconfig
Switched to context "default".

kube-controller-manager.kubeconfig 파일이 생성된다.

kube-scheduler 쿠버네티스 설정 파일

kube-scheduler 서비스를 위한 kubeconfig 파일을 생성해 준다.

kube-scheduler 서비스를 위한 설정 파일 생성
ZSH
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
$ kubectl config set-cluster kubernetes-the-hard-way \
    --certificate-authority=ca.pem \
    --embed-certs=true \
    --server=https://127.0.0.1:6443 \
    --kubeconfig=kube-scheduler.kubeconfig
Cluster "kubernetes-the-hard-way" set.
$ kubectl config set-credentials system:kube-scheduler \
    --client-certificate=kube-scheduler.pem \
    --client-key=kube-scheduler-key.pem \
    --embed-certs=true \
    --kubeconfig=kube-scheduler.kubeconfig
User "system:kube-scheduler" set.
$ kubectl config set-context default \
    --cluster=kubernetes-the-hard-way \
    --user=system:kube-scheduler \
    --kubeconfig=kube-scheduler.kubeconfig
Context "default" created.
$ kubectl config use-context default --kubeconfig=kube-scheduler.kubeconfig
Switched to context "default".

kube-scheduler.kubeconfig 파일이 생성된다.

admin 사용자를 위한 kubeconfig 파일

admin 사용자를 위한 kubeconfig 파일을 생성해 준다.

admin 사용자를 위한 설정 파일 생성
ZSH
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
$ kubectl config set-cluster kubernetes-the-hard-way \
    --certificate-authority=ca.pem \
    --embed-certs=true \
    --server=https://127.0.0.1:6443 \
    --kubeconfig=admin.kubeconfig
Cluster "kubernetes-the-hard-way" set.
$ kubectl config set-credentials admin \
    --client-certificate=admin.pem \
    --client-key=admin-key.pem \
    --embed-certs=true \
    --kubeconfig=admin.kubeconfig
User "admin" set.
$ kubectl config set-context default \
    --cluster=kubernetes-the-hard-way \
    --user=admin \
    --kubeconfig=admin.kubeconfig
Context "default" created.
$ kubectl config use-context default --kubeconfig=admin.kubeconfig
Switched to context "default".

admin.kubeconfig 파일이 생성된다.

생성된 파일을 배포

워커 노드에는 node.kubeconfig 와 kube-proxy.kubeconfig 파일을 복사해 준다.

워커 노드에 배포
ZSH
1
2
3
$ scp kworker1.kubeconfig kube-proxy.kubeconfig kworker1.systemv.local:./
$ scp kworker2.kubeconfig kube-proxy.kubeconfig kworker2.systemv.local:./
$ scp kworker3.kubeconfig kube-proxy.kubeconfig kworker3.systemv.local:./

컨트롤 플레인 노드에는 admin, kube-controller-manager, kube-scheduler 에 kubeconfig 파일을 배포해 준다.

워커 노드에 배포
ZSH
1
2
3
$ scp admin.kubeconfig kube-controller-manager.kubeconfig kube-scheduler.kubeconfig kmaster1.systemv.local:./
$ scp admin.kubeconfig kube-controller-manager.kubeconfig kube-scheduler.kubeconfig kmaster2.systemv.local:./
$ scp admin.kubeconfig kube-controller-manager.kubeconfig kube-scheduler.kubeconfig kmaster3.systemv.local:./

데이터 암호화 설정 및 키 생성

쿠버네티스트는 클러스터 상태, 애플리케이션 설정들, secret 등 다양한 데이터를 저장한다. 쿠버네티스는 클러스터 데이터를 암호화를 제공한다.

쿠버네티스 Secret 의 암호화를 위한 암호화 설정과 암호화 키 생성을 위한 설정을 작성해준다.

encryption-config.yaml 파일 작성
ZSH
1
2
3
4
5
6
7
8
9
10
11
12
13
14
$ ENCRYPTION_KEY=$(head -c 32 /dev/urandom | base64)
$ cat > encryption-config.yaml <<EOF
kind: EncryptionConfig
apiVersion: v1
resources:
  - resources:
      - secrets
    providers:
      - aescbc:
          keys:
            - name: key1
              secret: ${ENCRYPTION_KEY}
      - identity: {}
EOF

이것을 컨트롤 플레인에 배포 해 준다.

HAProxy 서버 설치 및 설정

HAProxy 는 컨트롤 플레인을 로드 밸런싱을 해주는 역할을 한다. 다이어그램을 보면 워커와 컨트롤 플레인을 연결해주는 것으로 나오는데, 워커가 컨트롤 플레인을 하나의 도메인으로 연결하기 위한 것이기도 하다.

컨트롤 플레인은 외부에 통신을 6443 포트를 이용하게 된다. 도메인, IP 가 다른 컨트롤 플레인을 하나의 도메인 haproxy.systemv.local:6443 로 묶게 된다.

설치는 Ubuntu 20.04 서버에 APT 명령어로 패키지 설치 했다. 설정은 다음과 같이 간단하게 해줬다.

haproxy 설정
ZSH
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
$ sudo vim /etc/haproxy/haproxy.cfg
listen stats
        bind *:9000
        stats enable
        stats realm Haproxy\ Statistics
        stats uri /haproxy_stats
        stats auth admin:password
        stats refresh 30
        mode http
 
frontend k8s
        bind *:6443
        default_backend k8s
        mode tcp
        option tcplog
 
backend k8s
        balance roundrobin
        #balance source
        mode tcp
        option tcplog
        option tcp-check
        server kmaster1.systemv.local 192.168.96.46:6443 check
        server kmaster2.systemv.local 192.168.96.47:6443 check
        server kmaster3.systemv.local 192.168.96.48:6443 check
$ sudo systemctl restart haproxy

etcd 클러스터 설치

etcd 는 key-value 로 데이터를 저장해주는 서버다. 쿠버네티스는 자체적인 데이터를 하나도 가지고 있지 않다. 전부다 외부에 데이터를 저장하는데 그것을 해주는 것이 etcd 다. 서버 한대만 가지고 데이터를 저장하는 것은 위험함으로 이것도 클러스터로 여러 서버를 하나로 묶는다.

다운로드 및 설치

etcd 서버 설치
ZSH
1
2
3
4
$ wget -q --timestamping "https://github.com/etcd-io/etcd/releases/download/v3.4.15/etcd-v3.4.15-linux-amd64.tar.gz"
$ tar xvzf etcd-v3.4.15-linux-amd64.tar.gz
$ chmod +x etcd-v3.4.15-linux-amd64/etcd*
$ sudo mv etcd-v3.4.15-linux-amd64/etcd* /usr/local/bin/

etcd 는 클러스터내에 서버들과 kmaster, kworker 서버들과 통신을 해야 한다. 하지만 쿠버네티스는 TLS 통신을 기반으로 하기 때문에 인증서를 함께 설치해 줘야 한다. 모든 서버와 통신을 위한 인증서로 Root CA 인증서와 kubernetes 인증서를 설치해 준다.

etcd 인증서 설치
ZSH
1
2
$ sudo mkdir -p /etc/etcd /var/lib/etcd
$ sudo cp -v ca.pem kubernetes-key.pem kubernetes.pem /etc/etcd/

ubuntu20.04, centos 7 서버의 경우에 systemd 가 핵심이다. etcd 를 서비스 등록을 위해서 systemd 를 이용한다. 이 서버는 kmaster1 서버에 실행해준다.

etcd systemd 등록하기
ZSH
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
$ INTERNAL_IP=$(hostname --ip-address)
$ ETCD_NAME=$(hostname -s)
$ cat <<EOF | sudo tee /etc/systemd/system/etcd.service
[Unit]
Description=etcd
Documentation=https://github.com/coreos
 
[Service]
ExecStart=/usr/local/bin/etcd \\
  --name ${ETCD_NAME} \\
  --cert-file=/etc/etcd/kubernetes.pem \\
  --key-file=/etc/etcd/kubernetes-key.pem \\
  --peer-cert-file=/etc/etcd/kubernetes.pem \\
  --peer-key-file=/etc/etcd/kubernetes-key.pem \\
  --trusted-ca-file=/etc/etcd/ca.pem \\
  --peer-trusted-ca-file=/etc/etcd/ca.pem \\
  --peer-client-cert-auth \\
  --client-cert-auth \\
  --initial-advertise-peer-urls https://${INTERNAL_IP}:2380 \\
  --listen-peer-urls https://${INTERNAL_IP}:2380 \\
  --listen-client-urls https://${INTERNAL_IP}:2379,https://127.0.0.1:2379 \\
  --advertise-client-urls https://${INTERNAL_IP}:2379 \\
  --initial-cluster-token etcd-cluster-0 \\
  --initial-cluster kmaster1=https://${IP kmaster1}:2380,kmaster2=https://${IP master2}:2380,kmaster3=https://${IP master3}:2380 \\
  --initial-cluster-state new \\
  --data-dir=/var/lib/etcd
Restart=on-failure
RestartSec=5
 
[Install]
WantedBy=multi-user.target
EOF
$ sudo systemctl daemon-reload
$ sudo systemctl enable etcd.service --now

INTERNAL IP 는 kmaster1 서버의 IP, ETCD_NAME 은 kmaster1 이며 각각의 kmaster1, kmater2, kmaster3 에 IP를 적어주면 된다. 각각 kmaster 에서 INTERNAL IP 와 ETC_NAME 을 바꿔가면서 해주면 된다.

모두 정상적으로 설치가 되었다면 다음과 같이 확인할 수 있다.

etcd 확인하기
ZSH
1
2
3
4
5
6
7
8
$ sudo ETCDCTL_API=3 /usr/local/bin/etcdctl member list \
>   --endpoints=https://127.0.0.1:2379 \
>   --cacert=/etc/etcd/ca.pem \
>   --cert=/etc/etcd/kubernetes.pem \
>   --key=/etc/etcd/kubernetes-key.pem
5b11cfa779be5990, started, kmaster3, https://192.168.96.48:2380, https://192.168.96.48:2379, false
735f2a33dbd756c4, started, kmaster1, https://192.168.96.46:2380, https://192.168.96.46:2379, false
9066c1507a7e5374, started, kmaster2, https://192.168.96.47:2380, https://192.168.96.47:2379, false

ETCD 클러스터 설치와 설정으로 이것으로 끝이다.

Controll Plane(Master) 설치

컨트롤 플레인(Controll Plane) 혹은 마스터(Master) 노드는 쿠버네티스에 두뇌에 해당한다. 모든 명령과 연산은 모두 컨트롤 플레인에서 이루어진다. 클라이언트의 명령은 컨트롤 플레인의 api server 에서 받아서 워커 노드에 kubelet 이 실행하는 형태다. 데이터는 모두 etcd 에 저장된다.

컨트롤 플레인의 주요 구성요소는 다음과 같다.

  1. kube-apiserver
  2. kube-controller-manager
  3. kube-scheduler
  4. kubectl

다운로드 및 설치

바이너리 파일을 받아야 한다. github 에는 소스코드만 올라와 있어서 어디서 받을지 잠시 헷깔렸는데, dowloadkubernetes 에서 받을 수 있었다.

쿠버네티스(kubernetes) 다운로드 및 설치
ZSH
1
2
3
4
5
6
$ curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kube-apiserver"
$ curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kube-controller-manager"
$ curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kube-scheduler"
$ curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl"
$ chmod +x kube-apiserver kube-controller-manager kuber-scheduler kubectl
$ sudo mv -vv kube-apiserver kube-controller-manager kuber-scheduler kubectl /usr/local/bin/

쿠버네티스 API Server 설정

API Server 설정을 해보도록 하자. 쿠버네티스의 내부적인 데이터 이동은 암호화 통신을 기반으로 하기 때문에 인증서를 항상 달고 산다고 보면 된다.

인증서 복사
ZSH
1
2
3
4
$ sudo mkdir -p /var/lib/kubernetes/
$ sudo mv ca.pem ca-key.pem kubernetes-key.pem kubernetes.pem \
    service-account-key.pem service-account.pem \
    encryption-config.yaml /var/lib/kubernetes/

이제 systemd 유닛 등록을 위한 파일을 다음과 같이 작성해 준다.

kube-apiserver 를 위한 systemd 유닛 파일 작성
ZSH
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
$ INTERNAL_IP=$(hostname --ip-address)
$ cat <<EOF | sudo tee /etc/systemd/system/kube-apiserver.service
[Unit]
Description=Kubernetes API Server
Documentation=https://github.com/kubernetes/kubernetes
 
[Service]
ExecStart=/usr/local/bin/kube-apiserver \\
  --advertise-address=${INTERNAL_IP} <