Category: Kubernetes

쿠버네티스에 관한 글들의 모음.

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를 할당해 주도록 설정을 했다.

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

Metallb 설치하기

쿠버네티스(Kubernetes) 의 서비스(Service) 에 타입에는 Loadbalancer, NodePort 등을 지원한다. 문제는 Loadbalancer 는 클라우드(Cloud) 서비스 사업자를 위한 것으로 AWS, GCP, Azure 에서 제공하는 Loadbalancer 를 위한 것이다.

그런데, 많은 쿠버네티스의 사례를 살펴보면 Loadbalancer 를 사용한 사례가 아주 많다. 그래서 굳이 클라우드 서비스 사업자가 아니라고 하더라도 Loadbalancer 를 사용할 수 있도록 해보자해서 만들어진게 바로 Metallb 이다.

필자는 KVM 리눅스 가상화에 쿠버네티스를 설치했다. KVM 가상 시스템의 게스트 OS 들은 브릿지 네트워크 모드로 이기 때문에 필자의 공유기에서 자동으로 아이피를 할당 받거나, 공유기의 대역에 IP를 고정으로 사용하기도 한다. 필자의 공유기는 192.168.96.0/20 대역폭을 사용하도록 세팅을 해놨기 때문에 할당 가능한 IP는 차고도 넘친다.

Metalb 는 이렇게 외부에서 접속이 가능한 아이피 대역을 할당해 사용한다.

설치

설치를 위해서 필요한게 있는데, CNI 가 먼저 있어야 한다. Flannel, Calico 와 같은 CNI 가 설치가 먼저 되어 있어야 한다. 설치는 설치를 위한 메니페스토 파일을 이용한다.

metallb 설치
ZSH
1
2
]$ kubectl apply -f https://raw.githubusercontent.com/metallb/metallb/v0.10.2/manifests/namespace.yaml
]$ kubectl apply -f https://raw.githubusercontent.com/metallb/metallb/v0.10.2/manifests/metallb.yaml

namespace.yaml 은 그냥 네임스페이스를 만들도록 되어 있어서 명령어로도 가능하다.

이렇게 하면 설치는 되지만 아직 동작하지는 않는데, Metallb 에서 사용할 외부 아이피나 운영 모드등을 설정해줘야 하는데, 이는 ConfigMap 를 이용해 다음과 같이 설정해 줘야 한다.

metallb 를 위한 configmap
YAML
1
2
3
4
5
6
7
8
9
10
11
12
apiVersion: v1
kind: ConfigMap
metadata:
  namespace: metallb-system
  name: config
data:
  config: |
    address-pools:
    - name: default
      protocol: layer2
      addresses:
      - 192.168.111.2-192.168.111.100

위와같이 Metal Loadbalancer 에서 사용할 외부 주소 IP 주소 대역을 할당해 준다.

또, 이제 Metallb 의 컴포넌트의 통신을 보호하기 위해서 Secret 를 다음과 같이 생성해 준다.

metallb 를 위한 Secret 생성
ZSH
1
2
]$ kubectl create secret generic -n metallb-system memberlist --from-literal=secretkey="$(openssl rand -base64 128)" -o yaml --dry-run=client > metallb-secret.yaml
]$ kubectl apply -f metallb-secret.yaml

Ingress-nginx 설치

테스트를 위해서 Ingress-nginx 를 설치해 본다. Ingress-nginx 를 설치하게되면 서비스에 Loadbalancer 타입으로 설치가 되는데, EXTERNAL-IP 가 Metallb 에서 할당해준 IP가 할당이 된다.

metallb 의 EXTERNAL-IP 할당
ZSH
1
2
3
4
$ kubectl get svc
NAME                          TYPE           CLUSTER-IP   EXTERNAL-IP     PORT(S)                      AGE
ingress-nginx-nginx-ingress   LoadBalancer   10.32.0.46   192.168.111.2   80:32558/TCP,443:30684/TCP   22h
kubernetes                    ClusterIP      10.32.0.1    <none>          443/TCP                      96d

EXTERNAL-IP 에 할당한 IP 로 웹 접속을 하게되면 nginx 가 나오게 된다.

쿠버네티스 수동 설치

쿠버네티스 설치는 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} \\
  --allow-privileged=true \\
  --apiserver-count=3 \\
  --audit-log-maxage=30 \\
  --audit-log-maxbackup=3 \\
  --audit-log-maxsize=100 \\
  --audit-log-path=/var/log/audit.log \\
  --authorization-mode=Node,RBAC \\
  --bind-address=0.0.0.0 \\
  --client-ca-file=/var/lib/kubernetes/ca.pem \\
  --enable-admission-plugins=NamespaceLifecycle,NodeRestriction,LimitRanger,ServiceAccount,DefaultStorageClass,ResourceQuota \\
  --enable-swagger-ui=true \\
  --etcd-cafile=/var/lib/kubernetes/ca.pem \\
  --etcd-certfile=/var/lib/kubernetes/kubernetes.pem \\
  --etcd-keyfile=/var/lib/kubernetes/kubernetes-key.pem \\
  --etcd-servers=https://${IP kmaster1}:2379,https://${IP master2}:2379,https://${IP master3}:2379 \\
  --event-ttl=1h \\
  --experimental-encryption-provider-config=/var/lib/kubernetes/encryption-config.yaml \\
  --kubelet-certificate-authority=/var/lib/kubernetes/ca.pem \\
  --kubelet-client-certificate=/var/lib/kubernetes/kubernetes.pem \\
  --kubelet-client-key=/var/lib/kubernetes/kubernetes-key.pem \\
  --kubelet-https=true \\
  --runtime-config=api/all=true \\
  --service-account-signing-key-file=/var/lib/kubernetes/service-account-key.pem \\
  --service-account-issuer=api \\
  --service-account-api-audiences=api,vault \\
  --service-account-key-file=/var/lib/kubernetes/service-account.pem \\
  --service-cluster-ip-range=10.32.0.0/24 \\
  --service-node-port-range=30000-32767 \\
  --tls-cert-file=/var/lib/kubernetes/kubernetes.pem \\
  --tls-private-key-file=/var/lib/kubernetes/kubernetes-key.pem \\
  --v=2
Restart=on-failure
RestartSec=5
 
[Install]
WantedBy=multi-user.target
EOF
$ sudo systemctl daemon-reload
$ sudo systemctl enable kube-apiserver.service --now

여기서 –service-cluster-ip-range 를 잘 봐야 한다. 이것은 쿠버네티스 내부의 네트워크 주소 범위에 속한다. 앞에서 kubernetes 의 인증서를 작성할때에 이 주소 범위의 맨 앞의 주소인 10.32.0.1 을 넣어줬었다. 반드시 인증서에 포함되는 주소를 적어줘야 한다.

–service-account-signing-key-file, –service-account-issuer, –service-account-api-audiences 은 새롭게 추가된 기능으로 자세한 사항을 확인해 볼 필요가 있다.

쿠버네티스 Controller Manager 설정

앞에 api server 설치를 위해서 인증서를 모두 복사를 해뒀다. 컨틀로러 매니저를 위해서 kubeconfig 파일이 필요하다. 이를 복사해 준다.

kube-controller-manager.kubeconfig 파일 복사
ZSH
1
$ sudo mv -vv kube-controller-manager.kubeconfig /var/lib/kubernetes/

kube-controller-manager.service 파일을 다음과 같이 작성해 준다.

kube-controller-manager를 위한 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
$ cat <<EOF | sudo tee /etc/systemd/system/kube-controller-manager.service
[Unit]
Description=Kubernetes Controller Manager
Documentation=https://github.com/kubernetes/kubernetes
 
[Service]
ExecStart=/usr/local/bin/kube-controller-manager \\
  --address=0.0.0.0 \\
  --allocate-node-cidrs=true \\
  --cluster-cidr=10.31.0.0/16 \\
  --cluster-name=kubernetes \\
  --cluster-signing-cert-file=/var/lib/kubernetes/ca.pem \\
  --cluster-signing-key-file=/var/lib/kubernetes/ca-key.pem \\
  --kubeconfig=/var/lib/kubernetes/kube-controller-manager.kubeconfig \\
  --leader-elect=true \\
  --root-ca-file=/var/lib/kubernetes/ca.pem \\
  --service-account-private-key-file=/var/lib/kubernetes/service-account-key.pem \\
  --service-cluster-ip-range=10.32.0.0/24 \\
  --use-service-account-credentials=true \\
  --v=2
Restart=on-failure
RestartSec=5
 
[Install]
WantedBy=multi-user.target
EOF
$ sudo systemctl daemon-reload
$ sudo systemctl enable kube-controller-manager.service --now

–cluster-cidr 은 kubeadm 을 이용해 설치할때에 –pod-network-cidr 에 해당한다.

쿠버네티스 Scheduler 설정

kubeconfig 를 복사 해준다.

kube-scheduler.kubeconfig 를 복사
ZSH
1
sudo mv kube-scheduler.kubeconfig /var/lib/kubernetes/

kube-scheduler 를 위한 설정파일을 다음과 같이 작성해 준다.

kube-scheduler.yaml 설정 파일 작성
ZSH
1
2
3
4
5
6
7
8
9
$ sudo mkdir -p /etc/kubernetes/config
$ cat <<EOF | sudo tee /etc/kubernetes/config/kube-scheduler.yaml
apiVersion: kubescheduler.config.k8s.io/v1beta1
kind: KubeSchedulerConfiguration
clientConnection:
  kubeconfig: "/var/lib/kubernetes/kube-scheduler.kubeconfig"
leaderElection:
  leaderElect: true
EOF

kube-scheduler.service 유닛 파일을 다음과 같이 작성해 준다.

kube-scheduler.service 유닛 파일 작성
ZSH
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
$ sudo cat <<EOF | sudo tee /etc/systemd/system/kube-scheduler.service
[Unit]
Description=Kubernetes Scheduler
Documentation=https://github.com/kubernetes/kubernetes
 
[Service]
ExecStart=/usr/local/bin/kube-scheduler \\
  --config=/etc/kubernetes/config/kube-scheduler.yaml \\
  --v=2
Restart=on-failure
RestartSec=5
 
[Install]
WantedBy=multi-user.target
EOF
$ sudo systemctl daemon-reload
$ sudo systemctl enable kube-scheduler.service --now

Kubelet 인증을 위한 RBAC

쿠버네티스는 kubectl 을 이용해 명령을 받는다. 그러면 api server 에서 받고, 이것을 워커 서버에 kubelet 이 실행시키는 구조다. 문제는 api server 가 워커 노드에 kubelet 에 액세스를 할려면 RBAC 권한이 필요하다는 데 있다. RBAC(Role-Based Access Control) 는 사용자 역할 기반 접근 제어 방법이다.

system:kube-apiserver-to-kubelet ClusterRole 생성

system:kube-apiserver-to-kubelet 유닛 파일 작성
ZSH
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
$ cat <<EOF | kubectl apply --kubeconfig admin.kubeconfig -f -
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  annotations:
    rbac.authorization.kubernetes.io/autoupdate: "true"
  labels:
    kubernetes.io/bootstrapping: rbac-defaults
  name: system:kube-apiserver-to-kubelet
rules:
  - apiGroups:
      - ""
    resources:
      - nodes/proxy
      - nodes/stats
      - nodes/log
      - nodes/spec
      - nodes/metrics
    verbs:
      - "*"
EOF

쿠버네티스 API 서버는 –kubelet-client-certificate 플래그에 정의된 클라이언트 인증서를 사용해 kubernetes 사용자로 Kubelet 에 인증한다.

앞에서 생성한 ClusterRole 을 kubernetes 사용자에게 바인딩(binding) 해준다.

system:kube-apiserver-to-kubelet 룰 바인딩
ZSH
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
$ cat <<EOF | kubectl apply --kubeconfig admin.kubeconfig -f -
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: system:kube-apiserver
  namespace: ""
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: system:kube-apiserver-to-kubelet
subjects:
  - apiGroup: rbac.authorization.k8s.io
    kind: User
    name: kubernetes
EOF

확인

컨트롤 플레인이 잘 설정 되었는지 다음과 같이 확인할 수 있다.

쿠버네티스 컴포넌트 확인
ZSH
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
$ kubectl get componentstatuses --kubeconfig admin.kubeconfig -o yaml | egrep "kind|name|message"
Warning: v1 ComponentStatus is deprecated in v1.19+
  - message: ok
  kind: ComponentStatus
    name: controller-manager
  - message: ok
  kind: ComponentStatus
    name: scheduler
  - message: '{"health":"true"}'
  kind: ComponentStatus
    name: etcd-0
  - message: '{"health":"true"}'
  kind: ComponentStatus
    name: etcd-2
  - message: '{"health":"true"}'
  kind: ComponentStatus
    name: etcd-1
kind: List

로드 밸런서에서 응답이 정상으로 나오는지도 확인할 수 있다.

haproxy 로드 밸런서 확인
ZSH
1
2
3
4
5
6
7
8
9
10
11
12
$ curl --cacert /var/lib/kubernetes/ca.pem https://haproxy.systemv.local:6443/version
{
  "major": "1",
  "minor": "20",
  "gitVersion": "v1.20.6",
  "gitCommit": "8a62859e515889f07e3e3be6a1080413f17cf2c3",
  "gitTreeState": "clean",
  "buildDate": "2021-04-15T03:19:55Z",
  "goVersion": "go1.15.10",
  "compiler": "gc",
  "platform": "linux/amd64"
}

Worker 노드 설치

이제 워커 노드 작업을 진행 해야 한다. 여기서 한가지 결정해야 한다. 인터넷에 메뉴얼들을 보면 워커 노드의 컨테이너엔진을 RunC, Docker 등으로 나뉘어 있다. 여기서는 Docker 를 사용하는 것으로 진행 했다.

필수 패키지 및 Docker 설치

다음과 같이 필수 패키지를 설치해 준다. socat 은 kubectl port-forward 명령을 쓸때 사용한다고 한다.

필수 패키지 설치
ZSH
1
2
3
$ sudo apt clean all
$ sudo apt update
$ sudo apt install socat conntrack ipset

다음과 같이 Docker 를 설치 해준다. Docker 설치는 공식 메뉴얼 대로 해줬다.

Docker 설치
ZSH
1
2
3
4
5
6
7
8
9
10
11
12
$ sudo apt install \
    apt-transport-https \
    ca-certificates \
    curl \
    gnupg \
    lsb-release
$ curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /usr/share/keyrings/docker-archive-keyring.gpg
$ echo \
  "deb [arch=amd64 signed-by=/usr/share/keyrings/docker-archive-keyring.gpg] https://download.docker.com/linux/ubuntu \
  $(lsb_release -cs) stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null
$ sudo apt update
$ sudo apt install docker-ce docker-ce-cli containerd.io

일반 사용자도 Docker 를 이용할 수 있도록 해준다.

systemv 일반 사용자도 Docker 이용할 수 있도록 설정
ZSH
1
$ sudo usermod -aG docker systemv

시스템 설정을 해준다. 이 설정은 쿠버네티스 문서에 나와 있다.

시스템 모듈 및 파라메터 설정
ZSH
1
2
3
4
5
6
7
8
9
$ sudo cat <<EOF | sudo tee /etc/modules-load.d/k8s.conf
br_netfilter
EOF
 
$ sudo cat <<EOF | sudo tee /etc/sysctl.d/k8s.conf
net.bridge.bridge-nf-call-ip6tables = 1
net.bridge.bridge-nf-call-iptables = 1
EOF
$ sudo sysctl --system

kubectl, kubelet, kube-proxy 설치.

워커 노드 작동을 위한 바이너리 다운로드 및 설치해 준다.

kubectl, kubelet, kube-proxy 바이너리 다운로드 및 설치
ZSH
1
2
3
4
5
$ curl -LO https://dl.k8s.io/v1.20.6/bin/linux/amd64/kubectl
$ curl -LO https://dl.k8s.io/v1.20.6/bin/linux/amd64/kubelet
$ curl -LO https://dl.k8s.io/v1.20.6/bin/linux/amd64/kube-proxy
$ chmod +x kubectl kube-proxy kubelet
$ sudo mv kubectl kube-proxy kubelet /usr/local/bin

설치 디렉토리를 생성해 준다.

필요한 디렉토리 생성
ZSH
1
2
3
4
$ sudo mkdir -p /var/lib/kubelet \
   /var/lib/kube-proxy \
   /var/lib/kubernetes \
   /var/run/kubernetes

kubelet 설정

워크 노드 인증 키와 설정 파일 복사
ZSH
1
2
3
$ sudo mv -vv kworker1-key.pem kworker1.pem /var/lib/kubelet/
$ sudo mv -vv kworker1.kubeconfig /var/lib/kubelet/kubeconfig
$ sudo mv ca.pem /var/lib/kubernetes/

kubelet 설정 파일을 작성해 준다.

kubelet 설정 파일 생성
ZSH
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
$ cat <<EOF | sudo tee /var/lib/kubelet/kubelet-config.yaml
apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
authentication:
  anonymous:
    enabled: false
  webhook:
    enabled: true
  x509:
    clientCAFile: "/var/lib/kubernetes/ca.pem"
authorization:
  mode: Webhook
clusterDomain: "cluster.local"
clusterDNS:
  - "10.32.0.10"
runtimeRequestTimeout: "15m"
tlsCertFile: "/var/lib/kubelet/kworker1.pem"
tlsPrivateKeyFile: "/var/lib/kubelet/kworker1-key.pem"
EOF

kubelet를 위한 systemd 유닛 파일을 작성해 준다.

kubelet 을 위한 systemd 유닛 파일 작성
ZSH
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
$ cat <<EOF | sudo tee /etc/systemd/system/kubelet.service
[Unit]
Description=Kubernetes Kubelet
Documentation=https://github.com/kubernetes/kubernetes
After=containerd.service
Requires=containerd.service
 
[Service]
ExecStart=/usr/local/bin/kubelet \\
  --config=/var/lib/kubelet/kubelet-config.yaml \\
  --container-runtime=docker \\
  --image-pull-progress-deadline=2m \\
  --kubeconfig=/var/lib/kubelet/kubeconfig \\
  --network-plugin=cni \\
  --register-node=true \\
  --v=2
Restart=on-failure
RestartSec=5
 
[Install]
WantedBy=multi-user.target
EOF

kube-proxy 설정

proxy 설정 파일을 복사해 준다.

kube-proxy 설정 파일 복사
ZSH
1
$ sudo mv kube-proxy.kubeconfig /var/lib/kube-proxy/kubeconfig

kube-proxy-config.yaml 설정 파일을 만들어 준다.

kube-proxy 설정 작성
ZSH
1
2
3
4
5
6
7
8
$ cat <<EOF | sudo tee /var/lib/kube-proxy/kube-proxy-config.yaml
apiVersion: kubeproxy.config.k8s.io/v1alpha1
kind: KubeProxyConfiguration
clientConnection:
  kubeconfig: "/var/lib/kube-proxy/kubeconfig"
mode: "iptables"
clusterCIDR: "10.31.0.0/16"
EOF

마지막으로 systemd 유닛 파일을 생성해 준다.

kube-proxy 을 위한 systemd 유닛 파일 작성
ZSH
1
2
3
4
5
6
7
8
9
10
11
12
13
14
$ cat <<EOF | sudo tee /etc/systemd/system/kube-proxy.service
[Unit]
Description=Kubernetes Kube Proxy
Documentation=https://github.com/kubernetes/kubernetes
 
[Service]
ExecStart=/usr/local/bin/kube-proxy \\
  --config=/var/lib/kube-proxy/kube-proxy-config.yaml
Restart=on-failure
RestartSec=5
 
[Install]
WantedBy=multi-user.target
EOF

서비스를 기동해 준다.

서비스 기동
ZSH
1
2
$ sudo systemctl daemon-reload
$ sudo systemctl enable kubelet.service kube-proxy.serivce --now

이렇게 한 후에 kmaster1 서버에서 다음과 같이 노드를 확인해보자.

노드 확인
ZSH
1
2
3
4
5
$ kubectl get nodes --kubeconfig admin.kubeconfig
NAME                     STATUS   ROLES    AGE    VERSION
kworker1.systemv.local   NotReady    <none>   102m   v1.20.6
kworker2.systemv.local   NotReady    <none>   65m    v1.20.6
kworker3.systemv.local   NotReady    <none>   53m    v1.20.6

NotReady 로 나와야 한다. 그리고 kubelet 로그에는 cni network 가 없다는 메시지가 올라 온다.

CNI 네트워크 설치

CNI 네트워크까지 수동으로 설치할려면 머리가 아프다. 그래서 그냥 간단하게 이것을 pod 컨테이너로 구현하면 된다. 그것도 제공해주는 yaml 파일을 이용해서.

여기서는 Calico 를 이용했다. 50 node 이하에서 사용할 경우를 가정했다. 50 노드 이상이면 Typha 를 설치해줘야 한다.

Calico CNI 네트워크 설치
ZSH
1
2
$ curl https://docs.projectcalico.org/manifests/calico.yaml -O
$ kubectl apply -f calico.yaml

시간이 좀 지난후에 노드를 살펴보고 Ready 가 되어 있을 것이다.

원격 접속을 위한 kubectl 설정

지금까지 kubectl 명령어를 사용할려면 admin.kubeconfig 파일이 있어야 했다. 이 설정파일은 –server=https://127.0.0.1:6443 으로 로컬 호스트 api server 를 지칭하도록 만들어 졌다. 만일 kubectl 명령어를 외부에서 사용할려면 어떻게 해야할까?

admin 사용자를 위한 설정을 다시 해주면 된다.

원격 접속을 위한 설정
ZSH
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
$ kubectl config set-cluster kubernetes-the-hard-way \
    --certificate-authority=ca.pem \
    --embed-certs=true \
    --server=https://haproxy.systemv.local:6443
Cluster "kubernetes-the-hard-way" set.
$ kubectl config set-credentials admin \
    --client-certificate=admin.pem \
    --client-key=admin-key.pem
User "admin" set.
$ kubectl config set-context kubernetes-the-hard-way \
    --cluster=kubernetes-the-hard-way \
    --user=admin
Context "kubernetes-the-hard-way" created.
$ kubectl config use-context kubernetes-the-hard-way
Switched to context "kubernetes-the-hard-way".
$ kubectl get nodes
NAME                     STATUS   ROLES    AGE   VERSION
kworker1.systemv.local   Ready    <none>   61m   v1.20.6
kworker2.systemv.local   Ready    <none>   24m   v1.20.6
kworker3.systemv.local   Ready    <none>   12m   v1.20.6

위 내용을 자세히 보면 kubeconfig 파일을 작성할때에 어느 파일에 저장할지에 대한 –kubeconfig=admin.kubeconfig 옵션이 존재하지 않는다. 이렇게 될 경우에 사용자의 홈디렉토리에 .kube/config 파일에 저장이 된다.

그리고 kubectl 명령어는 명시적으로 –kubeconfig admin.kubeconfig 를 주지 않는 이상 .kube/config 파일을 자동으로 읽어서 수행하게 된다.

Kube-dns 설치.

kube-dns 는 pods 에서 도메인 네임을 처리해 주는 서비스라고 보면 된다. pods 도메인을 할당라고 리절빙을 해준다.

kube-dns 설치
ZSH
1
2
3
4
5
6
7
$ curl -LO https://storage.googleapis.com/kubernetes-the-hard-way/kube-dns.yaml
$ vim kube-dns.yaml
....
apiVersion: apps/v1
kind: Deployment
....
$ kubectl apply -f kube-dns.yaml

중간에 apiVersion: extension/v1 이라고 되어 있는 것을 위와 같이 바꿔 준다.

kube-dns 설치 상태 확인
ZSH
1
2
3
$ kubectl get pods -l k8s-app=kube-dns -n kube-system
NAME                        READY   STATUS    RESTARTS   AGE
kube-dns-7854dfc8c7-d69g5   3/3     Running   0          7m37s

정상적으로 작동되는 것을 볼 수 있다.

이로써 모든 설치가 완료 됐다.

Docker, Kubernetes 네트워크

인터넷 검색을 하다보면 Docker, Kubernetes 네트워크에 관한 글이 많이 보인다. 기본적인 이론에서부터 응용까지 잘 설명된 글들이 꽤 많은데, 나는 눈에 보이는 상태를 한번 살펴보기로 했다.

Docker 네트워크

Docker 를 처음 설치하면 어떤 상태일까? 먼저 Docker 를 설치한 리눅스 시스템의 네트워크 상태는 다음과 같다.

Docker 네트워크
ZSH
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
$ ip -c -br link
lo               UNKNOWN        00:00:00:00:00:00 <LOOPBACK,UP,LOWER_UP>
enp0s3           UP             08:00:27:e3:f6:8b <BROADCAST,MULTICAST,UP,LOWER_UP>
docker0          DOWN           02:42:be:90:93:52 <NO-CARRIER,BROADCAST,MULTICAST,UP>
 
$ ip a
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
2: enp0s3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 08:00:27:e3:f6:8b brd ff:ff:ff:ff:ff:ff
    inet 192.168.96.39/20 brd 192.168.111.255 scope global dynamic noprefixroute enp0s3
       valid_lft 4524sec preferred_lft 4524sec
    inet6 fe80::d52d:e84a:d820:3cf/64 scope link noprefixroute
       valid_lft forever preferred_lft forever
3: docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default
    link/ether 02:42:be:90:93:52 brd ff:ff:ff:ff:ff:ff
    inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0
       valid_lft forever preferred_lft forever

docker0 라는 네트워크 인터페이스가 생성되면서 172.17.0.1/16 아이피가 할당되었다. 그리고 이 인터페이스는 Bridge 다.하지만 인터페이스는 DOWN 상태다. Docker 를 막 설치하고 난 후에 이런 모습이다.

Bridge 상태는 다음의 명령으로 확인이 가능하다.

docker0 Type 확인
ZSH
1
2
3
4
5
6
$ nmcli connection show --active
NAME     UUID                                  TYPE      DEVICE  
enp0s3   9d696977-82ab-4f36-b2be-fccaf5bcee5c  ethernet  enp0s3  
docker0  fd2e456f-93ea-43cf-8fd7-46aefe11a4a4  bridge    docker0
$ bridge link show
$

nmcli 를 보면 TYPE 에 bridge 라고 나온다. 그리고 이 docker0 인터페이스는 docker 네트워크에서 Bridge 네트워크에 해당한다고 다음과 같이 확인해 볼수 있다.

docker network 상태 확인
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
50
51
$ sudo docker network ls
NETWORK ID     NAME      DRIVER    SCOPE
11c5b343044e   bridge    bridge    local
7019c2852833   host      host      local
11786973bc6f   none      null      local
$ sudo docker network inspect bridge
[
    {
        "Name": "bridge",
        "Id": "11c5b343044e1c1e84a1e0cd241b580bdae8e5cfffcce4428931f4fe553aa188",
        "Created": "2021-04-28T20:38:11.485806876+09:00",
        "Scope": "local",
        "Driver": "bridge",
        "EnableIPv6": false,
        "IPAM": {
            "Driver": "default",
            "Options": null,
            "Config": [
                {
                    "Subnet": "172.17.0.0/16",
                    "Gateway": "172.17.0.1"
                }
            ]
        },
        "Internal": false,
        "Attachable": false,
        "Ingress": false,
        "ConfigFrom": {
            "Network": ""
        },
        "ConfigOnly": false,
        "Containers": {
            "6d93a395f09203085ae7789d9b38825c4cbcfaa7b92cbcdeca1c567f1aa2fb74": {
                "Name": "doc1",
                "EndpointID": "15227e807ea614fd2adfa752470b776f8783157a48a738422a018fbb80de8342",
                "MacAddress": "02:42:ac:11:00:02",
                "IPv4Address": "172.17.0.2/16",
                "IPv6Address": ""
            }
        },
        "Options": {
            "com.docker.network.bridge.default_bridge": "true",
            "com.docker.network.bridge.enable_icc": "true",
            "com.docker.network.bridge.enable_ip_masquerade": "true",
            "com.docker.network.bridge.host_binding_ipv4": "0.0.0.0",
            "com.docker.network.bridge.name": "docker0",
            "com.docker.network.driver.mtu": "1500"
        },
        "Labels": {}
    }
]

“com.docker.network.bridge.name”: “docker0” 로 Docker Bridge 가 docker0 호스트 네트워크 인터페이스라는 걸 말해주고 있으며 여기에 붙은 Container 인 doc1 에 대한 정보를 보여주고 있다. doc1 컨테이너의 IP 는 172.17.0.2/16 이다.

bridge 명령어에서는 아무것도 안나온다. 이제 Docker 컨테이너를 하나 실행해 본다.

docker 컨테이너 생성
ZSH
1
2
3
4
5
6
$ docker pull alpine
$ docker run -dit --name doc1 alpine ash
6d93a395f09203085ae7789d9b38825c4cbcfaa7b92cbcdeca1c567f1aa2fb74
$ sudo docker ps -a
CONTAINER ID   IMAGE     COMMAND   CREATED         STATUS         PORTS     NAMES
6d93a395f092   alpine    "ash"     9 seconds ago   Up 7 seconds             doc1

이렇게 Docker 컨테이너를 하나 생성하면 docker0 브릿지 인터페이스는 Down -> Up 상태로 변경되며 여기에 veth 가상의 인터페이스가 하나 붙는다.

호스트 인터페이스 상태
ZSH
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
]$ ip -c a
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
2: enp0s3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 08:00:27:e3:f6:8b brd ff:ff:ff:ff:ff:ff
    inet 192.168.96.39/20 brd 192.168.111.255 scope global dynamic noprefixroute enp0s3
       valid_lft 1577sec preferred_lft 1577sec
    inet6 fe80::d52d:e84a:d820:3cf/64 scope link noprefixroute
       valid_lft forever preferred_lft forever
3: docker0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default
    link/ether 02:42:be:90:93:52 brd ff:ff:ff:ff:ff:ff
    inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0
       valid_lft forever preferred_lft forever
    inet6 fe80::42:beff:fe90:9352/64 scope link
       valid_lft forever preferred_lft forever
9: veth46d3de6@if8: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master docker0 state UP group default
    link/ether 3a:59:a3:03:e4:a9 brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet6 fe80::3859:a3ff:fe03:e4a9/64 scope link
       valid_lft forever preferred_lft forever

“veth46d3de6@if8” 가 보인다. 이것은 필시 doc1 컨테이너가 실행되면서 생성되었을게 분명하다. 이것과 doc1 과는 무슨 상관일까?

Docker 네트워크 및 호스트 네트워크 인터페이스
ZSH
1
2
3
4
5
6
7
8
9
10
11
12
13
14
$ sudo docker exec 6d93a395f092 ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN 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
8: eth0@if9: <BROADCAST,MULTICAST,UP,LOWER_UP,M-DOWN> mtu 1500 qdisc noqueue state UP
    link/ether 02:42:ac:11:00:02 brd ff:ff:ff:ff:ff:ff
    inet 172.17.0.2/16 brd 172.17.255.255 scope global eth0
       valid_lft forever preferred_lft forever
$ ip -c a
9: veth46d3de6@if8: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master docker0 state UP group default
    link/ether 3a:59:a3:03:e4:a9 brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet6 fe80::3859:a3ff:fe03:e4a9/64 scope link
       valid_lft forever preferred_lft forever

doc1 컨테이너의 네트워크 인터페이스 eth0 는 8번이다. 그리고 if9 로 인터페이스 9번을 가리키고 있다고 명시하고 있다. 아래 호스트 네트워크 인터페이스를 보면 veth 라고 나오는데, if8 로 인터페이스 8번을 가리고 있다. 인터페이스 8번은 doc1 컨테이너의 네트워크 인터페이스를 말한다.

doc1 의 route 명령어 결과
ZSH
1
2
3
4
5
$ sudo docker exec 6d93a395f092 route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         172.17.0.1      0.0.0.0         UG    0      0        0 eth0
172.17.0.0      *               255.255.0.0     U     0      0        0 eth0

그러니까 네트워크 인터페이스에 번호로 서로 연관성을 보여주고 있다는 걸 알수 있다.

veth 인터페이스 보기
ZSH
1
2
3
$ ip -c link show type veth
9: veth46d3de6@if8: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master docker0 state UP mode DEFAULT group default
    link/ether 3a:59:a3:03:e4:a9 brd ff:ff:ff:ff:ff:ff link-netnsid 0

ip 명령어를 통해서 veth 인터페이스만 뽑아 볼 수 있다. veth 는 가상 이더넷(Virtual Ethernet) 인데, Docker 컨테이너가 생성될때마다 가상 이더넷 카드가 호스트에 하나 생성되고 이런 가상 이더넷은 Docker 컨테이너의 기본 네트워크 인터페이스 카드와 연결된다.

docker0 는 Docker 에 기본 Bridge 인터페이스이며 Docker 컨테이너가 하나도 없으면 DOWN 상태가 되며 단 하나의 컨테이너가 실행될 경우에 UP 상태로 변경되고 가상 이더넷을 생성하고 Bridge 에 붙이게 된다.

Kubernetes 네트워크

Kubernetes 를 설치하고 난후에 상태는 Docker 만 설치한 것과 동일하다. Kubernetes 는 CNI 를 설치를 해줘야 한다. CNI 는 Kubernetes 에 네트워크를 담당할 기능을 붙이기 위한 인터페이스로 다양한 네트워크 기능들을 제공하는 프로그램들이 있다.

Flannel, Weave, Calico 등등이 자주 쓰인다.

한가지 의문(?) 혹은 문제는 이 쿠버네티스 CNI 들은 구조가 모두 다르다. 테스트를 위해서 Flannel 을 사용했다.

flannel cni 설치
ZSH
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
$ kubectl apply -f https://raw.githubusercontent.com/flannel-io/flannel/master/Documentation/kube-flannel.yml
Warning: policy/v1beta1 PodSecurityPolicy is deprecated in v1.21+, unavailable in v1.25+
podsecuritypolicy.policy/psp.flannel.unprivileged created
clusterrole.rbac.authorization.k8s.io/flannel created
clusterrolebinding.rbac.authorization.k8s.io/flannel created
serviceaccount/flannel created
configmap/kube-flannel-cfg created
daemonset.apps/kube-flannel-ds created
$ kubectl get pod -o wide -A
NAMESPACE     NAME                             READY   STATUS    RESTARTS   AGE    IP              NODE     NOMINATED NODE   READINESS GATES
kube-system   coredns-558bd4d5db-5hhxr         1/1     Running   0          138m   10.31.0.2       ubuntu   <none>           <none>
kube-system   coredns-558bd4d5db-g97bd         1/1     Running   0          138m   10.31.0.3       ubuntu   <none>           <none>
kube-system   etcd-ubuntu                      1/1     Running   0          138m   192.168.96.37   ubuntu   <none>           <none>
kube-system   kube-apiserver-ubuntu            1/1     Running   0          138m   192.168.96.37   ubuntu   <none>           <none>
kube-system   kube-controller-manager-ubuntu   1/1     Running   0          138m   192.168.96.37   ubuntu   <none>           <none>
kube-system   kube-flannel-ds-6bl8f            1/1     Running   0          16m    192.168.96.39   vknode   <none>           <none>
kube-system   kube-flannel-ds-k9cpz            1/1     Running   0          16m    192.168.96.37   ubuntu   <none>           <none>
kube-system   kube-proxy-6lz88                 1/1     Running   0          138m   192.168.96.37   ubuntu   <none>           <none>
kube-system   kube-proxy-md4s7                 1/1     Running   0          133m   192.168.96.39   vknode   <none>           <none>
kube-system   kube-scheduler-ubuntu            1/1     Running   0          138m   192.168.96.37   ubuntu   <none>           <none>

정상적으로 설치되었다면 Flannel 이 Pod 로 올라온다. 더불어서 CoreDNS 도 정상으로 나온다.

한가지 쿠버네티스에 대해서 짚고 넘어가야 할게 있는데, 쿠버네티스는 마스터 노드라 불리는 Controller 와 워커 노드로 나뉜다. 적어도 2대의 호스트 서버가 필요하고 여기에 설치가 진행 된다.

Flannel 을 설치하고 nginx 파드(pod) 를 생성한 후에 워커 노드 상태다.

워커 노드에 네트워크 인터레이스 상태
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
ip -c a
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
2: enp0s3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 08:00:27:e3:f6:8b brd ff:ff:ff:ff:ff:ff
    inet 192.168.96.39/20 brd 192.168.111.255 scope global dynamic noprefixroute enp0s3
       valid_lft 5059sec preferred_lft 5059sec
    inet6 fe80::d52d:e84a:d820:3cf/64 scope link noprefixroute
       valid_lft forever preferred_lft forever
3: docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default
    link/ether 02:42:e4:22:b1:58 brd ff:ff:ff:ff:ff:ff
    inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0
       valid_lft forever preferred_lft forever
4: flannel.1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue state UNKNOWN group default
    link/ether 82:14:e6:a1:21:43 brd ff:ff:ff:ff:ff:ff
    inet 10.31.1.0/32 brd 10.31.1.0 scope global flannel.1
       valid_lft forever preferred_lft forever
    inet6 fe80::8014:e6ff:fea1:2143/64 scope link
       valid_lft forever preferred_lft forever
5: cni0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue state UP group default qlen 1000
    link/ether 56:a6:dd:5f:19:b3 brd ff:ff:ff:ff:ff:ff
    inet 10.31.1.1/24 brd 10.31.1.255 scope global cni0
       valid_lft forever preferred_lft forever
    inet6 fe80::54a6:ddff:fe5f:19b3/64 scope link
       valid_lft forever preferred_lft forever
6: veth2b86d0e3@if3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue master cni0 state UP group default
    link/ether 92:07:4d:10:b7:9b brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet6 fe80::9007:4dff:fe10:b79b/64 scope link
       valid_lft forever preferred_lft forever

위 상태를 보면, cni0 네트워크 인터페이스가 보인다. 이는 Flannel 에서 생성한 것으로 Bridge 다.

워커 노드에 브릿지 네트워크
ZSH
1
2
3
4
5
6
$ ip -c link show type bridge
ip -c link show type bridge
3: docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN mode DEFAULT group default
    link/ether 02:42:e4:22:b1:58 brd ff:ff:ff:ff:ff:ff
5: cni0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue state UP mode DEFAULT group default qlen 1000
    link/ether 56:a6:dd:5f:19:b3 brd ff:ff:ff:ff:ff:ff

위에 보면 Bridge 네트워크 인터페이스를 볼 수 있는데, Docker0 는 DOWN 이며 cni0 는 UP 상태다. 이 cni0 에 연결된 네트워크 인터페이스는 다음과 같이 확인할 수 있다.

마스터 노드에 브릿지 네트워크 cni0 에 연결된 네트워크
ZSH
1
2
3
$ ip -c link show master cni0
6: veth2b86d0e3@if3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue master cni0 state UP mode DEFAULT group default
    link/ether 92:07:4d:10:b7:9b brd ff:ff:ff:ff:ff:ff link-netnsid 0

이 인터페이스는 필히 nginx 파드에 것이다. master 브릿지로 cni0 를 사용하고 있다.

그러면, flannel.1 인터페이스는 대체 무엇일까? 다음의 명령어로 확인해 보자.

flannel.1 네트워크 인터페이스
ZSH
1
2
3
4
ip -c -d link show flannel.1
4: flannel.1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue state UNKNOWN mode DEFAULT group default
    link/ether 82:14:e6:a1:21:43 brd ff:ff:ff:ff:ff:ff promiscuity 0 minmtu 68 maxmtu 65535
    vxlan id 1 local 192.168.96.39 dev enp0s3 srcport 0 0 dstport 8472 nolearning ttl auto ageing 300 udpcsum noudp6zerocsumtx noudp6zerocsumrx addrgenmode eui64 numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535

“vxlan id 1 local 192.168.96.39 dev enp0s3” 로컬 호스트의 enp0s3 에 연결된 vxlan 이라고 나온다.

Flannel 은 VXLAN 기반으로 호스트가 서로 다른 파드에 대한 연결을 만들어주게 되어 있다. 마스터 노드에서 다음의 명령어를 실행해 보자.

Worker 노드에 대한 Annotation 설명
ZSH
1
2
3
4
5
$ kubectl describe node vknode | grep -A3 Annotations
Annotations:        flannel.alpha.coreos.com/backend-data: {"VNI":1,"VtepMAC":"82:14:e6:a1:21:43"}
                    flannel.alpha.coreos.com/backend-type: vxlan
                    flannel.alpha.coreos.com/kube-subnet-manager: true
                    flannel.alpha.coreos.com/public-ip: 192.168.96.39

backend-type: vxlan 이라고 나오고 있으며 VTEP 도 보인다. 이 장치에 대한 Mac 주소도 나오는데, 이것은 flannel.1 에 있는것과 같다.

파드의 네트워크는 veth 장치를 통해서 패킷이 나가고 이것을 cni0 브릿지가 받는다. 그리고 flannel 이 이것을 flannel.1 장치로 보내게 된다.

이렇게 하는 이유가 있는데, Flannel 은 L2 Layer 스위치다. L2 Layer 스위치는 ARP 라우팅만 가능하다. 파드(Pod) 가 같은 호스트에 있는 경우에는 ARP 라우팅만으로 서로 통신이 가능하겠지만 호스트가 다를 경우, IP 대역이 변경될 경우에는 원격 호스트에 있는 파드를 ARP 라우팅만으로 찾을 수 없다.

그래서 Flannel 은 L3 Layer 계층의 가상의 스위칭 장비를 만들고, 이렇게 만들어진 각 호스트의 가상의 스위칭을 하나로 연결하는데 이것이 바로 VXLAN 이다. 가상의 스위칭 장비가 flannel.1 네트워크 인터페이스 이다. 이때, cni0 에서 올라온 데이터는 L2 Layer 에서 만든 프레임(Frame)으로 이것을 UDP 패킷형태로 IP 를 붙여 캡슐화 한다. 그리면 flannel.1 인터페이스는 다른 호스트와 연결된 또 다른 flannel.1 인터페이스로 브로드캐스팅을 한다.

다른 호스트로 받은 UDP 패킷은 flannel.1 장치에 의해서 까지고(디캡슐화) 자신의 네트워크 대역과 비교하는데, 맞으면 받은 프레임에 destination mac address 를 자신의 mac address 로 넣고 다시 UDP로 캡슐화해 돌려보낸다. 이렇게 함으로써 호스트가 다른 파드의 이더넷 주소(맥주소)를 얻게되어 연결이 이루어지는데, 이게 VXLAN 의 동작 방법이다.

VXLAN 는 L2 Layer 프레임을 UDP L3 Layer 로 캡슐화해 브로드캐스팅하고 목적지 맥주소를 얻는데 있다.

Flannel 은 이렇게 작동하지만 Calico 는 또 다르다. Calico 는 BGP 연결을 통해서 아예 L3 Layer 를 구현 한다. 완전한 Pure L3 Switch 기능을 제공하기 때문에 처음부터 IP 라우팅이 가능해진다. Calico 는 Tunnel.0 인터페이스를 통해서 서로 다른 호스트와 Peer to Peer 연결되어 있어서 IP 라우팅만으로 대상 호스트의 파드를 알아낼 수 있다. 그래서 동작 방법은 (Flannel 보다) 훨씬 간단하다.

메트릭 서버(Metric Server) 설치에 관한 오류들…

다양한 메트릭 서버 설치에 관한 오류들을 알아보자.

kubectl top node Error from server (ServiceUnavailable): the server is currently unable to handle the request (get nodes.metrics.k8s.io)

Kubectl top nodes 오류
ZSH
1
2
$ kubectl top pod
Error from server (ServiceUnavailable): the server is currently unable to handle the request (get pods.metrics.k8s.io)

메트릭 서버(Metric Server) 의 파드(Pod)가 정상적으로 Running 상태라 하더라도 이와같은 오류 메시지를 만날 수 있다. 이 오류는 kube-apiserver 의 로그에 다음과 같이 관련 오류가 나온다.

systemctl status kube-apiserver
ZSH
1
Apr 23 15:49:33 kmaster1.systemv.local kube-apiserver[4598]: E0423 15:49:33.330967    4598 available_controller.go:508] v1beta1.metrics.k8s.io failed with: Operation cannot be fulfilled on apiservices.apir>Apr 23 15:49:38 kmaster1.systemv.local kube-apiserver[4598]: E0423 15:49:38.332227    4598 available_controller.go:508] v1beta1.metrics.k8s.io failed with: failing or missing response from https://10.32.0.>Apr 23 15:49:43 kmaster1.systemv.local kube-apiserver[4598]: E0423 15:49:43.333609    4598 available_controller.go:508] v1beta1.metrics.k8s.io failed with: failing or missing response from https://10.32.0.

뒤쪽에 삭제된 부분은 “net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers)” 이다. 응답커넥션을 맺다가 안되서 timeout 으로 끝난 것이다.

이것은 kube-apiserver 다음의 커맨드 파라메터를 추가해줘야 한다.

  • –enable-aggregator-routing=true

메트릭 서버의 0.4.3 버전부터는 쿠버네티스의 Aggregator Layer 를 이용한다. API 서버가 실행중인 호스트에 kube-proxy 가 없을 경우에 위 파라메터를 추가해줘야 한다.

워커 노드 메트릭 수집 안됨

워커노드 정보 수집 안됨.
ZSH
1
2
3
4
5
$ kubectl top nodes
NAME                     CPU(cores)   CPU%   MEMORY(bytes)   MEMORY%    
kworker1.systemv.local   <unknown>          <unknown>     <unknown>           <unknown>        
kworker2.systemv.local   <unknown>          <unknown>     <unknown>           <unknown>        
kworker3.systemv.local   <unknown>          <unknown>     <unknown>           <unknown>

쿠버네티스의 Deployments.apps 리소스에 배포된 Metric Server 메니페스트를 다음과 같이 수정해 줘야 한다.

Metric Server 메니페스트 수정
ZSH
1
2
3
4
$ kubectl edit deployment.apps/metrics-server -n kube-system
      dnsPolicy: ClusterFirst
      hostNetwork: true
      nodeSelector:

hostNetwork: true 를 추가해줘야 한다.

extension-apiserver 란?

쿠버네티스(Kubernetes)가 발전에 따라서 많은 변화를 겪었다. 최신의 버전에서 extension apiserver 라는 것을 필요로하는 경우가 많다. 이것은 쿠버네티스 문서에서는 aggregation layer 라고 설명하고 있다.

Configuring the aggregation layer allows the Kubernetes apiserver to be extended with additional APIs, which are not part of the core Kubernetes APIs

애그리게이션 레이어 설정은 쿠버네티스 API 코어의 일부가 아닌 추가적인 API를 가지고 확장될 수 있는 쿠버네티스 apiserver 를 가능하게 한다.

Configure the Aggregarion Layer

최근에 구축한 쿠버네티스 서버에 메트릭 서버(Metric Server) 를 설치했는데 제대로 작동되지 않아 왜 그런가 봤더니 바로 이 문제였다. 메트릭 서버 파드(Pod) 에 로그는 다음과 같다.

메트릭 서버 로그
1
2
3
4
$ kubectl logs metrics-server-57b8795b4c-hgnlt -n kube-system
E0423 10:51:25.342066       1 configmap_cafile_content.go:243] kube-system/extension-apiserver-authentication failed with : missing content for CA bundle "client-ca::kube-system::extension-apiserver-authentication::requestheader-client-ca-file"
E0423 10:51:25.342153       1 configmap_cafile_content.go:243] key failed with : missing content for CA bundle "client-ca::kube-system::extension-apiserver-authentication::requestheader-client-ca-file"
E0423 10:51:25.347263       1 configmap_cafile_content.go:243] kube-system/extension-apiserver-authentication failed with : missing content for CA bundle "client-ca::kube-system::extension-apiserver-authentication::requestheader-client-ca-file"

메시지를 보면 extension-apiserver-authentication 등의 메시지를 볼 수 있다. 문제는 이런 로그가 남는다고 해서 메트릭 서버 파드의 상태가 Running 으로 된다는 것이다. 파트 상태가 Running 이라고 해서 메트릭 서버가 정상으로 작동되는 것은 아닌게 문제의 핵심이다.

이 문제를 해결하기 위해서는 extension-apiserver 기능을 apiserver 가 가지도록 해야 한다. 이것은 kube-apiserver 에 커맨드 파라메터를 다음과 같이 추가 해주고 재시작 해줘야 한다.

메트릭 서버 로그
1
2
3
4
5
6
7
--requestheader-client-ca-file=<path to="" aggregator="" ca="" cert="">
--requestheader-allowed-names=front-proxy-client
--requestheader-extra-headers-prefix=X-Remote-Extra-
--requestheader-group-headers=X-Remote-Group
--requestheader-username-headers=X-Remote-User
--proxy-client-cert-file=<path to="" aggregator="" proxy="" cert="">
--proxy-client-key-file=<path to="" aggregator="" proxy="" key="">

요구사항을 보면 인증서가 필요하다는 것을 알게 된다. 인증서 제작은 Kubernetes Hard Way 문서에 잘 정리되어 있다. 필자는 쿠버네티스 하드 웨이 방법을 구축한 서버이기에 이 과정을 진행해 볼 수 있었다.

extension apiserver 를 위한 인증서 작성

인증서 작성은 다음과같이 CSR 파일을 작성함으로서 시작된다.

proxy-client-csr.json 작성
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
$ cat > proxy-client-csr.json <<EOF
{
  "CN": "front-proxy-client",
  "key": {
    "algo": "rsa",
    "size": 2048
  },
  "names": [
    {
      "C": "US",
      "L": "Portland",
      "O": "system:masters",
      "OU": "Kubernetes The Hard Way",
      "ST": "Oregon"
    }
  ]
}
EOF

여기서 주의해야 할 것이 조직(O) 를 system:masters 로 해야 하며, CN 은 –requestheader-allowed-names 파라메터의 값과 동일해야 한다. 이제 다음과 같이 인증서를 제작한다.

proxy-client 인증서 작성
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
$ cfssl gencert \
  -ca=ca.pem \
  -ca-key=ca-key.pem \
  -config=ca-config.json \
  -profile=kubernetes \
  proxy-client-csr.json | cfssljson -bare proxy-client
2021/04/23 14:54:09 [INFO] generate received request
2021/04/23 14:54:09 [INFO] received CSR
2021/04/23 14:54:09 [INFO] generating key: rsa-2048
2021/04/23 14:54:09 [INFO] encoded CSR
2021/04/23 14:54:09 [INFO] signed certificate with serial number 534282701421151901323513822674041149219991213452
2021/04/23 14:54:09 [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").
$ ls proxy-client*
proxy-client.csr  proxy-client-csr.json  proxy-client-key.pem  proxy-client.pem

이제 이것을 각 master 서버에 배포를 해준다.

proxy-client 인증서 마스터 서버에 배포.
1
2
3
$ sudo cp proxy-client*.pem /var/lib/kubernetes/
$ scp proxy-client*.pem systemv@kmaster2.systemv.local:./
$ scp proxy-client*.pem systemv@kmaster3.systemv.local:./

kube-apiserver 커맨드 파라메터 수정

배포를 모두 했다면, 이제 kube-apiserver 에 커맨드 파라메터를 수정해 줘야 한다. systemd 에 kube-apiservere 를 등록했기 때문에 유닛 파일을 수정해주면 된다.

kube-apiserver systemd 등록 파일 수정
1
2
3
4
5
6
7
8
9
10
11
$ sudo vim /etc/systemd/system/kube-apiserver.service
  --requestheader-client-ca-file=/var/lib/kubernetes/ca.pem \
  --requestheader-allowed-names=front-proxy-client \
  --requestheader-extra-headers-prefix=X-Remote-Extra- \
  --requestheader-group-headers=X-Remote-Group \
  --requestheader-username-headers=X-Remote-User \
  --proxy-client-cert-file=/var/lib/kubernetes/proxy-client.pem \
  --proxy-client-key-file=/var/lib/kubernetes/proxy-client-key.pem \
  --enable-aggregator-routing=true \
$ sudo systemctl daemon-reload
$ sudo systemctl restart kube-apiserver

정상적으로 구동이 되었다면 이제 메트릭 서버를 재설치하면 정상적으로 작동 된다.

정상적인 metric-server 로그
1
2
3
4
5
6
7
8
9
10
11
12
13
14
$ kubectl logs metrics-server-57b8795b4c-cn8x5 -n kube-system
I0423 15:24:40.014008       1 serving.go:325] Generated self-signed cert (/tmp/apiserver.crt, /tmp/apiserver.key)
I0423 15:24:40.367149       1 requestheader_controller.go:169] Starting RequestHeaderAuthRequestController
I0423 15:24:40.367169       1 shared_informer.go:240] Waiting for caches to sync for RequestHeaderAuthRequestController
I0423 15:24:40.367192       1 configmap_cafile_content.go:202] Starting client-ca::kube-system::extension-apiserver-authentication::client-ca-file
I0423 15:24:40.367196       1 shared_informer.go:240] Waiting for caches to sync for client-ca::kube-system::extension-apiserver-authentication::client-ca-file
I0423 15:24:40.367205       1 configmap_cafile_content.go:202] Starting client-ca::kube-system::extension-apiserver-authentication::requestheader-client-ca-file
I0423 15:24:40.367208       1 shared_informer.go:240] Waiting for caches to sync for client-ca::kube-system::extension-apiserver-authentication::requestheader-client-ca-file
I0423 15:24:40.367785       1 secure_serving.go:197] Serving securely on [::]:4443
I0423 15:24:40.368038       1 dynamic_serving_content.go:130] Starting serving-cert::/tmp/apiserver.crt::/tmp/apiserver.key
I0423 15:24:40.368072       1 tlsconfig.go:240] Starting DynamicServingCertificateController
I0423 15:24:40.467350       1 shared_informer.go:247] Caches are synced for client-ca::kube-system::extension-apiserver-authentication::requestheader-client-ca-file
I0423 15:24:40.467480       1 shared_informer.go:247] Caches are synced for client-ca::kube-system::extension-apiserver-authentication::client-ca-file
I0423 15:24:40.467636       1 shared_informer.go:247] Caches are synced for RequestHeaderAuthRequestController

Kubernetes, Terminated 테스트

Pod 의 Terminated 테스트를 위한 테스트 배포는 다음과 같다.

Pod 의 Terminated 테스트를 위한 배포
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
kind: Pod
apiVersion: v1
metadata:
  name: terminated-pod
  namespace: default
spec:
  containers:
  - name: test-pod
    image: gcr.io/google_containers/busybox:1.24
    command:
    - "/bin/sh"
    args:
    - "-c"
    - "sleep 5 && exit 1"
  restartPolicy: "Never"

위 Manifest 를 배포하면 Pod 의 Terminated 를 테스트 할 수 있다.

Kubernetes 에 Grafana 설치

Grafana 는 TimeSeries 데이터베이스의 데이터를 불러와 시각화를 해주는 솔루션이다. 특히 TimeSeries 데이터베이스 Prometheus를 지원하고 있어 Kubernetes 에 각종 메트릭을 Grafana 로 시각화해서 볼 수 있다.

이번에는 Kubernetes 에 Grafana 설치 에 대해서 다룬다. Grafana 설치를 하기전에 Prometheus 가 이미 설치되어 있어야 한다.

Grafana 를 위한 PV, PVC

Grafana 도 데이터파일을 가지고 있다. 각종 그래프 정보과 설정 내용들을 저장하기위해 데이터파일을 사용한다. 이 데이터파일의 위치는 특별하게 지정하지 않는한 /var/lib/grafana 이며 이것을 PV 에 마운트해 영구저장소에 저장되도록 하면 된다.

Grafana를 위한 PV, PVC 생성
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
# vim grafana-pv.yaml
apiVersion: v1
kind: PersistentVolume
metadata:
  name: grafana-pv
  namespace: monitoring
  labels:
    app: grafana
    type: local
spec:
  storageClassName: manual
  volumeMode: Filesystem
  accessModes:
    - ReadWriteOnce
  persistentVolumeReclaimPolicy: Retain
  capacity:
    storage: 2Gi
  hostPath:
    path: /opt/grafana
    type: DirectoryOrCreate
  nodeAffinity:
    required:
      nodeSelectorTerms:
      - matchExpressions:
        - key: kubernetes.io/hostname
          operator: In
          values:
          - knode
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: grafana-pvc
  namespace: monitoring
  labels:
    app: grafana
    type: local
spec:
  accessModes:
    - ReadWriteOnce
  volumeMode: Filesystem
  resources:
    requests:
      storage: 1Gi
  storageClassName: manual
  selector:
    matchLabels:
      app: grafana
      type: local

knode 에 /opt/grafana 디렉토리를 마운트 하도록 했다. 그리고 PVC 가 반납되더라도 PV 는 데이터를 그대로 유지하도록 retain 으로 설정했다. 이제 생성해 준다.

Grafana 를 위한 PV, PVC 생성
ZSH
1
2
3
4
5
6
$ kubectl apply -f grafana-pv.yaml
persistentvolume/grafana-pv created
persistentvolumeclaim/grafana-pvc created
$ kubectl get pv,pvc
NAME                             CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS   CLAIM                       STORAGECLASS   REASON   AGE
persistentvolume/grafana-pv      2Gi        RWO            Retain           Bound    monitoring/grafana-pvc      manual                  3d

정상적으로 생성이 되었다면 PVC 의 상태가 Bound 로 보인다.

Secret 생성

Kubernetes 는 Secret 객체를 제공 한다. 이것을 이용하면 패스워드와 같은 비밀이 필요한 필드 값들을 암호화해서 저장할 수 있다. 이렇게 하는 이유는 Pod 에 배포되는 소프트웨어들은 비상태여야 하며 언제든지 Pod 는 삭제되어 질 수 있어야 하기 때문에 각종 설정에 필요한 파라메터들도 외부에서 관리되어져야 한다.

Grafana 설치를 하는데 있어 Secret 를 이용하는 이유는 Grafana 의 관리자 계정 때문이다. 아무나 Grafana를 조작하지 못하도록 계정 정책을 가지고 있는데, ID 와 패스워드를 발급해야 한다. 관리자의 경우에 ID 는 admin 이고 패스워드는 설치할때에 지정해 줄 수 있는데 이것을 Kubernetes 의 Secret 으로 등록해 Pod 가 생성될때에 적용되게 한다.

Grafana 를 Secret 생성
1
2
3
4
5
6
7
8
9
10
# vim grafana-secret.yaml
apiVersion: v1
kind: Secret
data:
  admin-password: YWRtaW4=
  admin-username: YWRtaW4=
metadata:
  name: grafana
  namespace: monitoring
type: Opaque

Secret 은 Key – Value 쌍으로 간단하게 정의할 수 있다. 다음과 같이 적용한다.

Grafana 를 Secret 생성
ZSH
1
2
$ kubectl apply -f grafana-secret.yaml
secret/grafana created

Grafana Deployment

PV, Secret 을 생성했다면 이제 Deployment 를 만들어 Pod 를 생성해보자. Deployment 에는 Secret, PV 를 적용시켜야 한다.

Grafana 를 Deployment 생성
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
50
51
52
53
54
# vim grafana-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: grafana
  namespace: monitoring
  labels:
    app: grafana
spec:
  replicas: 1
  selector:
    matchLabels:
      app: grafana
  template:
    metadata:
      name: grafana
      labels:
        app: grafana
    spec:
      containers:
      - name: grafana
        image: grafana/grafana:latest
        imagePullPolicy: IfNotPresent
        ports:
        - name: grafana
          containerPort: 3000
        env:
        - name: GF_AUTH_BASIC_ENABLED
          value: "true"
        - name: GF_SECURITY_ADMIN_USER
          valueFrom:
            secretKeyRef:
              name: grafana
              key: admin-username
        - name: GF_SECURITY_ADMIN_PASSWORD
          valueFrom:
            secretKeyRef:
              name: grafana
              key: admin-password
        - name: GF_AUTH_ANONYMOUS_ENABLED
          value: "false"
        readinessProbe:
          httpGet:
            path: /
            port: 3000
        volumeMounts:
        - name: grafana-persistent-storage
          mountPath: /var/lib/grafana
      nodeSelector:
        kubernetes.io/hostname: knode
      volumes:
      - name: grafana-persistent-storage
        persistentVolumeClaim:
          claimName: grafana-pvc

nodeSelector 를 이용해 knode 에 생성하도록 했다. 앞에서 생성한 PVC 를 사용하도록 했으며 secretKeyRef 를 이용해 Grafana 의 변수에 Secret 에 초기 아이디, 패스워드를 지정해주고 있다.

다음과 같이 적용해 준다.

Grafana 를 Deployment 생성
ZSH
1
2
$ kubectl apply -f grafana-deployment.yaml
deployment.apps/grafana created

NodePort 서비스 생성

Grafana 가 제대로 설치되었는지를 확인하기 위해서 외부에서 접속이 되도록 NodePort 로 Service 를 생성해 보자.

Grafana 를 Service 생성
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
# vim grafana-service.yaml
apiVersion: v1
kind: Service
metadata:
  name: grafana
  namespace: monitoring
  annotations:
      prometheus.io/scrape: 'true'
      prometheus.io/port:   '3000'
spec:
  selector:
    app: grafana
  type: NodePort
  ports:
    - port: 3000
      targetPort: 3000
      nodePort: 30004

Service 에 대한 포트는 3000 이며 Pod 에 포트도 3000 이여서 targetPort 를 3000 으로 지정했다. 그리고 nodePort 를 30004 으로 지정했다.

다음과 같이 적용해 준다.

Grafana 를 Service 생성
ZSH
1
2
3
4
5
$ kubectl apply -f grafana-service.yaml
service/grafana created
$ kubectl get svc -n monitoring
NAME                 TYPE       CLUSTER-IP      EXTERNAL-IP   PORT(S)          AGE
grafana              NodePort   10.103.62.228   <none>        3000:30004/TCP   2m38s

이렇게 하면 Kmaster 서버의 IP:30004 로 웹 접속을 하면 Grafana 화면이 보여야 한다.

Grafana 에서 Prometheus 데이터소스 추가

Grafana 와 Prometheus 는 Kubernetes 상에서 작동되고 있다. Kubernetes 에서 서비스에 접속을 하기 위해서는 Service 객체에 등록해 IP와 Port를 할당하면 Kubernetes Cluster 내에서는 Service 객체에 등록한 IP:Port 로 접속이 가능하다.

Grafana 에 성공적으로 접속을 했다면 TimeSeries 데이터소스를 추가해줘야 한다. Prometheus 를 지원하고 있기 때문에 접속 URL 을 입력해줘야 하는데, 이때 Prometheus 가 Kubernetes 상에서 작동되고 있다는 것을 상기해야 하며 Service 객체에 등록되어 Cluster IP:Port 를 입력해 줘야 한다.

Service 객체를 확인한다.

Service 확인
ZSH
1
2
3
4
$ kubectl get svc -n monitoring
NAME                 TYPE       CLUSTER-IP      EXTERNAL-IP   PORT(S)          AGE
grafana              NodePort   10.103.62.228   <none>        3000:30004/TCP   2m38s
prometheus-service   NodePort   10.103.84.171   <none>        8080:30003/TCP   3d1h

확인된 내용은 10.103.84.171 과 8080 이다. 이것이 Prometheus 에 Cluster 내에 접속 지점이 된다.

Kubernetes Monitoring – Prometheus 설치

이 글은 Kubernetes 에 모니터링을 위해 Prometheus 설치에 대한 것이다. Kubernetes 는 여러가지 오브젝트들과 컴포넌트들로 구성 된다. 각각에 구성요소들은 컴퓨터의 자원을 사용하게 되는데 이러한 자원 사용량은 metric-server 를 설치함으로써 CLI 를 통해서 실시간으로 모니터링이 가능하다.

하지만 CLI 를 하나하나 다 치면서 하는데에는 한계가 있어, 각종 구성요소들의 자원 사용량을 데이터베이스로 저장하고 이것을 기반으로 그래프로 보여주는 것이 훨씬 좋을 것이다. 특히나 각종 자원의 모니터링은 시인성이 아주 좋아야 하는게 핵심이기도 한데 Kubernetes 는 이를 위해서 Prometheus 를 공식적(?) 으로 밀고 있다.

Prometheus

프로메테우스(Prometheus) 는 한 회사에서 만들기 시작해 오픈소스화 되었으며 현재는 Kubernetes 를 제작지원하는 CNCF(Cloud Native Computing Foundation) 의 두번째 프로젝트다. 이렇게 되면 당연히 Kubernetes 에서 Prometheus 는 거의 표준 모니터링 시스템이라고 봐야 한다.

인터넷을 검색해보면 위와같은 그림을 볼 수 있는데, 처음 접하는 사람들은 당연히 이게 뭔지 잘 모른다. Prometheus 를 이루는 기본 요소는 단 두개다.

  1. Prometheus Server
  2. Node Exporter

간단하게 Server/Client 구조를 가지는 것인데, 특이한 것은 Prometheus Server 가 데이터를 가지고 오는 방법이다. Node Exporter 는 어떤 정보를 수집할지에 대해서 정의를 해두고 정해진 시간마다 정보를 수집한다. 그리고네트워크를 통해서 Prometheus Server 가 가지고 갈 수 있도록 네트워크 데몬으로 존재한다.

Prometheus Server 는 Node Exporter 목록을 가지고 있으면서 주기적으로 접속해서 데이터를 긁어온다. 이렇게 긁어온 데이터는 Prometheus 가 TimeSeries 데이터베이스로 저장하게 된다.

위 그림에 왼쪽 아래쪽에 KUBERNETES NODES 로 향하는 화살표에 Pull 이라고 적혀있는데, 이것이 Prometheus 가 Node Exporter 에 접속해 데이터를 긁어오는 것을 말하는 것이다.

metric-server, metric-state-server

Kubernetes 는 자신의 상태를 자동으로 모니터링해서 보여주지 않는다. 이것도 관리자가 설치해야 한다. 이를 위해서 인터넷을 검색해보면 다음과 같이 두가지 정도가 나온다.

  • metric-server
  • kube-state-metrics

metric-server 는 Kubernetes 자신에 대한 자원 모니터링으로 Node, Pod 등의 자원을 모니터링 한다. 이것은 Resource Metrics API 를 구현한 것으로 보면 된다. 이를 설치하면 HPA(Horizontal Pod Autoscaler), Scheduler 등에서 활용하게 된다.

HPA, Scheduler 등은 실시간으로 CPU, Memory 등에 변화를 감지해야 하며 이를 통해서 액션을 취해야하기 때문에 Kubernetes 의 Health 상태도 더블어 체크 된다. 자원이 Health 상태가 되지 않는다면 Kubernetes 의 상태를 Unknown 으로 바꾸놓을 가능성이 있다. 그리고 이 상태가 지속되면 Terminated 시켜버리고 다른 오브젝트를 올릴려고 할 것이다.

문제는 Prometheus 에서 이들에 대해서 스크랩을 할 수 없다는데 있다.

kube-state-metrics 는 Kubernetes 자원의 Health 상태를 전혀 고려하지 않는다. 그냥 자원에 대한 정보를 뿌려줄뿐이고 어떤 원인으로 인해서 자원 모니터링이 안된다면 그냥 정보를 안 뿌려준다. 따라서 이렇게 되며 이것을 가지고 HPA, Scheduler 에서 사용하기가 불가능해진다.

대신, kube-state-metrics 는 Prometheus 에서 스크랩이 가능하다. 따라서 Prometheus 를 이용한 모니터링을 구축하기 위해서는 반드시 kube-state-metrics 를 설치해주는 걸 권장한다.

kube-state-metrics 설치

Prometheus 설치의 시작은 kube-state-metrics 설치로부터 시작 된다. 이것이 없으면 Prometheus 설치/운영을 못하는 것은 아니지만 Kubernetes 의 컴포넌트의 자세한 정보를 가지고 올 수 없다.

설치는 kube-state-metrics 의 GitHub 를 이용하면 간단하게 해결된다. 한 가지 주의해야 할 것은 Kubernetes 버전을 확인해 지원되는 버전을 설치해야 한다는 것이다.

소스코드를 clone 한 후에 다음과 같이 설치를 해준다. Kubernetes 가 최신버전이라 별도의 작업은 필요 없다.

kube-state-metrics 설치
ZSH
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
$ git clone https://github.com/kubernetes/kube-state-metrics.git
$ cd kube-state-metrics
$ kubectl apply -f examples/standard
clusterrolebinding.rbac.authorization.k8s.io/kube-state-metrics created
clusterrole.rbac.authorization.k8s.io/kube-state-metrics created
deployment.apps/kube-state-metrics created
serviceaccount/kube-state-metrics created
service/kube-state-metrics created
$ kubectl get po -n kube-system
NAME                                       READY   STATUS    RESTARTS   AGE
calico-kube-controllers-578894d4cd-ks46s   1/1     Running   1          18h
calico-node-b5zb5                          1/1     Running   1          18h
calico-node-kvrjr                          1/1     Running   1          18h
coredns-66bff467f8-dp6m5                   1/1     Running   1          18h
coredns-66bff467f8-gqq6m                   1/1     Running   1          18h
etcd-kmaster                               1/1     Running   1          18h
kube-apiserver-kmaster                     1/1     Running   1          18h
kube-controller-manager-kmaster            1/1     Running   1          18h
kube-proxy-hcfkw                           1/1     Running   1          18h
kube-proxy-ssdbw                           1/1     Running   1          18h
kube-scheduler-kmaster                     1/1     Running   1          18h
kube-state-metrics-5c5cb55b4-gkh4m         1/1     Running   0          103s
metrics-server-5f4ffd464c-7dxxr            1/1     Running   1          18h

정상적으로 설치가 되었다면 kube-system 네임스페이스에 pod 가 보인다.

Prometheus 설치

먼저 Prometheus 설치하는 방법에는 다양한 방법이 존재한다. helm 을 이용해도 되고 Prometheus Operator 를 이용해도 된다. 하지만 수동으로 설치를 해봐야 Kubernetes 에서 프로그램 배포를 위해서 필요한 것들이 무엇인지를 알게 된다. 따라서 여기서는 모든걸 수동으로 한번 해보도록 하겠다.

계획

일단, 계획이 필요한데 뭔가 대단한게 아니라 Prometheus 를 운영하는데 필요한 설정과 파일들을 어떻게 할 것인가에 대한 것이다.

먼저, Prometheus 를 위한 네임스페이스를 별도로 만든다. Kubernetes 는 네임스페이스 개념이 존재한다. 일종의 격리되는 그룹같은 것인데, Prometheus 를 위한 네임스페이스로 montoring 을 만들 것이다.

Prometheus 는 설정 파일과 데이터 저장 파일 크게 두가지로 나뉜다. 설정 파일은 그야말로 메트릭 수집과 운영에 대한 것으로 text 파일이며 데이터 저장 파일은 수집된 정보를 저장하는 TimeSeries 데이터 파일이다.

  • prometheus.yaml
  • tdb

Kubernetes 는 배포되는 프로그램의 각종 설정들을 pod 자체에 가지고 있게 하지 않는다. 이것은 pod 가 비상태 운영을 기본원칙으로 하기 때문이다. pod 는 언제든지 사라지고 만들어지고 해야 한다. pod 내에 배포되는 프로그램들의 설정파일을 pod 에 내장하게 되면 뭐하나 바꿀때마다 pod 를 손대야 한다.

ConfigMap 은 이렇게 Kubernetes 의 비상태 운영 원칙을 위한 것이다. 설정 맵은 그야말로 다양한 설정들의 내용을 Kubernetes 가 대신 가지고 있게 해준다. 예를들어 Prometheus 의 설정파일인 prometheus.yaml 은 text 파일인데, 이것을 ConfigMap 에 등록하고 Pod 생성시에 이것을 가지고와서 파일로 굽게 된다. 설정파일을 Kubernetest 가 가지고 있기 때문에 설정 편집을 위해서 pod 에 손을 댈 일은 없다.

데이터 저장 파일은 영구적인 저장 파일이다. Pod 에 내장되어 있다면 Pod 가 재시작될때마다 데이터 저장 파일은 삭제되었다 재 생성되는 과정을 반복할 것이다. 하지만 Pod 의 재시작과는 상관없이 데이터는 영구적으로 보존 되어야 하기 때문에 Pod 에 영구볼륨(Persistant Volume) 을 붙여서 데이터 저장 파일을 Pod 와 분리할 것이다.

추가로 Prometheus 나 exporter 들이 Kubernetes 의 API 에 접근할 수 있도록 계정과 권한도 부여할 것이다.

monitoring 네임스페이스 생성

Kubernetes 의 네임스페이스 생성은 아주 간단다. CLI 명령어로 간단하게 생성할 수 있다.

namespace 생성
ZSH
1
2
$ kubectl create ns monitoring
namespace/monitoring created

ClusterRole 생성

Kubernetes 의 자원에 대한 접근은 API 를 통해서 이루어 진다. API 접근은 Kubernetes 의 보안 부분으로 엄격하게 통제되고 있는데, Prometheus 가 이 API 에 접근해 자원에 대한 메트릭을 생성해야 하기 때문에 이에 대한 접근 권한이 필요하게 된다.

Kubernetes 의 API 에 대한 권한은 Role 개념으로 정립되어 있으며 이 Role 에 기반한 퍼미션을 부여하고 이것을 다시 특정한 계정과 바인딩 함으로써 접근제어는 마무리 된다.

Prometheus 를 위한 Role 과 Binding
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
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: prometheus
  namespace: monitoring
rules:
- apiGroups: [""]
  resources:
  - nodes
  - nodes/proxy
  - services
  - endpoints
  - pods
  verbs: ["get", "list", "watch"]
- apiGroups:
  - extensions
  resources:
  - ingresses
  verbs: ["get", "list", "watch"]
- nonResourceURLs: ["/metrics"]
  verbs: ["get"]
---
apiVersion: v1
kind: ServiceAccount
metadata:
  name: prometheus
  namespace: monitoring
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: prometheus
  namespace: monitoring
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: prometheus
subjects:
- kind: ServiceAccount
  name: prometheus
  namespace: monitoring

위와같이 ClusterRole 을 작성한 후에 적용해 준다.

ClusterRole 적용
ZSH
1
2
3
$ kubectl apply -f prometheus-cluster-role.yaml
clusterrole.rbac.authorization.k8s.io/prometheus created
clusterrolebinding.rbac.authorization.k8s.io/prometheus created

Prometheus 를 위한 영구볼륨 생성

Kubernetes 에서 영구 볼륨은 Persistant Volume 과 Claim 개념으로 다루어 진다. PV 는 영구저장소 미디어 특성을 고려한 일종의 드라이버 개념이고 Claim 은 영구저장소 미디어와는 상관없는 추상적 개층으로 PV 와 연결되어 작동된다.

Prometheus 는 데이터베이스 파일을 영구적으로 저장할 필요성이 있기 때문에 Kubernetes 의 PV, PVC 를 이용할 필요가 있다.

먼저 다음과 같이 PV 를 만든다.

Prometheus 를 위한 PV
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
apiVersion: v1
kind: PersistentVolume
metadata:
  name: prometheus-pv
  namespace: monitoring
  labels:
    type: local
    app: prometheus
spec:
  capacity:
    storage: 2Gi
  accessModes:
  - ReadWriteOnce
  persistentVolumeReclaimPolicy: Retain
  storageClassName: manual
  hostPath:
    path: /opt/prometheus
    type: DirectoryOrCreate
  nodeAffinity:
    required:
      nodeSelectorTerms:
      - matchExpressions:
        - key: kubernetes.io/hostname
          operator: In
          values:
          - knode

중요한 것은 영구저장소를 이용할 Kubernetes 의 Node 를 지정해 주었고, 사용할 저장소는 디렉토리이며 없으면 생성하도록 했다. 거기다 ReclaimPolicy 를 Retain 으로 함으로써 PVC 와 연결이 해제되더라도 PV 는 그대로 데이터를 보존하도록 했다. 사용할 디렉토리 경로는 /opt/prometheus 로 지정 했다.

다음과 같이 생성해 준다.

Prometheus 를 위한 PV 생성
ZSH
1
2
3
4
5
$ kubectl apply -f prometheus-pv.yaml
persistentvolume/prometheus-pv created
$ kubectl get pv -n monitoring
NAME            CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS      CLAIM   STORAGECLASS   REASON   AGE
prometheus-pv   2Gi        RWO            Retain           Available           manual                  64s

이제 PV 를 가져다 쓸 PVC 를 생성해야 한다.

Prometheus 를 위한 PVC
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: prometheus-pvc
  namespace: monitoring
  labels:
    type: local
    app: prometheus
spec:
  storageClassName: manual
  accessModes:
    - ReadWriteOnce
  volumeMode: Filesystem
  resources:
    requests:
      storage: 1Gi
  selector:
    matchLabels:
      app: prometheus
      type: local

PVC 를 생성할 때에는 PV 에서 가져다 쓸 용량도 함께 기재한다. 당연한 이야기지만 PV 보다 많은 용량은 허용되지 않는다. 한가지 주의해야 할 것은 PV 의 Label 과 StorageClass 를 맞춰야 한다. 이게 어긋날 경우에는 PVC 가 제대로 연결되지 않는다.

다음과 같이 생성해 준다.

Prometheus 를 위한 PVC 생성
ZSH
1
2
3
4
5
6
7
8
$ kubectl apply -f prometheus-pvc.yaml
persistentvolumeclaim/prometheus-pvc created
$ kubectl get pv,pvc -n monitoring
NAME                             CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS   CLAIM                       STORAGECLASS   REASON   AGE
persistentvolume/prometheus-pv   2Gi        RWO            Retain           Bound    monitoring/prometheus-pvc   manual                  4m36s
 
NAME                                   STATUS   VOLUME          CAPACITY   ACCESS MODES   STORAGECLASS   AGE
persistentvolumeclaim/prometheus-pvc   Bound    prometheus-pv   2Gi        RWO            manual         11s

정상적으로 생성이 되면 위와같이 PVC 의 Status 가 Bound 로 표시 된다.

Prometheus 를 위한 ConfigMap 생성

앞에서도 이야기 했지만, Kubernetes 에서 Pod 는 비상태여야 한다. Pod 는 Replica 정책에 의해서 항상 특정한 수를 유지하도록 하는데, 간혹 Pod 가 알수 없는 이유로 재생성되는 경우가 발생하는데 이럴때에 Pod 가 상태를 가지는 파일을 가지고 있게 되면 데이터 손실이 발생하게 된다.

그래서 각종 서버에 대한 설정파일들을 Kubernetes 에 ConfigMap 으로 등록하고 Pod가 생성될때에 이를 가져다 설정파일로 만들도록 권장하고 있다.

ConfigMap 을 만드는 방법에는 크게 두가지로 나뉜다. 첫번째는 ConfigMap 메니페스트 파일에 설정 내용을 모두 함께 기술하는 것과 서버 설정파일을 특정한 디렉토리에 만든 다음에 kubectl 명령어로 ConfigMap 을 만드는 것이다. 어떤 방법을 쓰던지 결과는 동일하다.

여기선 설정 파일을 특정 디렉토리 별도로 만들어서 kubectl 명령어를 이용해 ConfigMap 을 작성하는 것으로 한다.

Prometheus 를 위한 설정 파일은 prometheus.yml 파일이다. 단 하나의 파일로 모두 가능하지만 rules 같은 경우에는 별도의 파일로 작성해 include 문을 작성해 연결 시킬 수 있다. 여기서는 두개의 파일로 제작했다.

Prometheus 를 위한 rules 파일
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
$ vim prometheus.rules
groups:
- name: container memory alert
  rules:
  - alert: container memory usage rate is very high( > 55%)
    expr: sum(container_memory_working_set_bytes{pod!="", name=""}) / sum (kube_node_status_allocatable_memory_bytes) * 100 > 55
    for: 1m
    labels:
      severity: fatal
    annotations:
      summary: High Memory Usage on {{ $labels.instance }}
      identifier: "{{ $labels.instance }}"
      description: "{{ $labels.job }} Memory Usage: {{ $value }}"
- name: container CPU alert
  rules:
  - alert: container CPU usage rate is very high( > 10%)
    expr: sum (rate (container_cpu_usage_seconds_total{pod!=""}[1m])) / sum (machine_cpu_cores) * 100 > 10
    for: 1m
    labels:
      severity: fatal
    annotations:
      summary: High Cpu Usage

prometheus.rules 파일에 rules 만 정의했다. 내용을 보면 Prometheus 에 알람을 보내는 Rule 을 적은 것이다. 이 파일은 prometheus.yml 파일에 include 문을 통해서 포함 된다.

Prometheus 를 위한 yaml 파일
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
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
$ vim prometheus.yml
global:
  scrape_interval: 10s
  evaluation_interval: 10s
rule_files:
  - /etc/prometheus/prometheus.rules
alerting:
  alertmanagers:
  - scheme: http
    static_configs:
    - targets:
      - "alertmanager.monitoring.svc:9093"
 
scrape_configs:
  - job_name: 'kubernetes-apiservers'
 
    kubernetes_sd_configs:
    - role: endpoints
    scheme: https
 
    tls_config:
      ca_file: /var/run/secrets/kubernetes.io/serviceaccount/ca.crt
    bearer_token_file: /var/run/secrets/kubernetes.io/serviceaccount/token
 
    relabel_configs:
    - source_labels: [__meta_kubernetes_namespace, __meta_kubernetes_service_name, __meta_kubernetes_endpoint_port_name]
      action: keep
      regex: default;kubernetes;https
 
  - job_name: 'kubernetes-nodes'
 
    scheme: https
 
    tls_config:
      ca_file: /var/run/secrets/kubernetes.io/serviceaccount/ca.crt
    bearer_token_file: /var/run/secrets/kubernetes.io/serviceaccount/token
 
    kubernetes_sd_configs:
    - role: node
 
    relabel_configs:
    - action: labelmap
      regex: __meta_kubernetes_node_label_(.+)
    - target_label: __address__
      replacement: kubernetes.default.svc:443
    - source_labels: [__meta_kubernetes_node_name]
      regex: (.+)
      target_label: __metrics_path__
      replacement: /api/v1/nodes/${1}/proxy/metrics
 
 
  - job_name: 'kubernetes-pods'
 
    kubernetes_sd_configs:
    - role: pod
 
    relabel_configs:
    - source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_scrape]
      action: keep
      regex: true
    - source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_path]
      action: replace
      target_label: __metrics_path__
      regex: (.+)
    - source_labels: [__address__, __meta_kubernetes_pod_annotation_prometheus_io_port]
      action: replace
      regex: ([^:]+)(?::\d+)?;(\d+)
      replacement: $1:$2
      target_label: __address__
    - action: labelmap
      regex: __meta_kubernetes_pod_label_(.+)
    - source_labels: [__meta_kubernetes_namespace]
      action: replace
      target_label: kubernetes_namespace
    - source_labels: [__meta_kubernetes_pod_name]
      action: replace
      target_label: kubernetes_pod_name
 
  - job_name: 'kube-state-metrics'
    static_configs:
      - targets: ['kube-state-metrics.kube-system.svc:8080']
 
  - job_name: 'kubernetes-cadvisor'
 
    scheme: https
 
    tls_config:
      ca_file: /var/run/secrets/kubernetes.io/serviceaccount/ca.crt
    bearer_token_file: /var/run/secrets/kubernetes.io/serviceaccount/token
 
    kubernetes_sd_configs:
    - role: node
 
    relabel_configs:
    - action: labelmap
      regex: __meta_kubernetes_node_label_(.+)
    - target_label: __address__
      replacement: kubernetes.default.svc:443
    - source_labels: [__meta_kubernetes_node_name]
      regex: (.+)
      target_label: __metrics_path__
      replacement: /api/v1/nodes/${1}/proxy/metrics/cadvisor
 
  - job_name: 'kubernetes-service-endpoints'
 
    kubernetes_sd_configs:
    - role: endpoints
 
    relabel_configs:
    - source_labels: [__meta_kubernetes_service_annotation_prometheus_io_scrape]
      action: keep
      regex: true
    - source_labels: [__meta_kubernetes_service_annotation_prometheus_io_scheme]
      action: replace
      target_label: __scheme__
      regex: (https?)
    - source_labels: [__meta_kubernetes_service_annotation_prometheus_io_path]
      action: replace
      target_label: __metrics_path__
      regex: (.+)
    - source_labels: [__address__, __meta_kubernetes_service_annotation_prometheus_io_port]
      action: replace
      target_label: __address__
      regex: ([^:]+)(?::\d+)?;(\d+)
      replacement: $1:$2
    - action: labelmap
      regex: __meta_kubernetes_service_label_(.+)
    - source_labels: [__meta_kubernetes_namespace]
      action: replace
      target_label: kubernetes_namespace
    - source_labels: [__meta_kubernetes_service_name]
      action: replace
      target_label: kubernetes_name

prometheus.yml 파일의 내용을 보면 어떤 정보를 수집할지에 대해서 기술하고 있다. 전체적으로 10s 단위로 메트릭 정보를 수집하도록 하고 있으며 kube-state-metrics 에 대해서는 도메인 호출을해서 스크랩을 하도록 하고 있다. 그밖에 각종 Kubernetes 컴포넌트들에 대해서도 Kubernetes 의 API 서버를 통해서 메트릭을 수집하도록 설정하고 있다.

이렇게 설정내용을 파일로 작성하였다면 kubectl 명령어를 이용해 ConfigMap 을 다음과 같이 생성할 수 있다.

Prometheus config 파일
ZSH
1
2
3
4
$ ls
prometheus.rules  prometheus.yml
$ kubectl create configmap prometheus-config -n monitoring --from-file=./
configmap/prometheus-config created

정상적으로 생성이 되었을 것이다.

이제 필요한 제반 사항들은 모두 만들어 졌다. 실제 Prometheus 배포로 Pod 를 생성해 보자.

Prometheus 를 위한 Deployment

Kubernetes 가 버전이 높아지면 Deployment 를 기반으로 여러개의 Pod 를 생성하도록 변경되었다. 여기서는 Prometheus 를 만들어야 하는데, 단순하게 Pod 만 생성하는게 아니라 Deployment 를 이용해서 Pod 를 생성 한다.

Prometheus 를 위한 Deployment
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
apiVersion: apps/v1
kind: Deployment
metadata:
  name: prometheus-deployment
  namespace: monitoring
  labels:
    app: prometheus-server
spec:
  replicas: 1
  selector:
    matchLabels:
      app: prometheus-server
  template:
    metadata:
      labels:
        app: prometheus-server
    spec:
      serviceAccountName: prometheus
      containers:
        - name: prometheus
          image: prom/prometheus
          args:
            - "--config.file=/etc/prometheus/prometheus.yml"
            - "--storage.tsdb.path=/prometheus/"
          ports:
            - containerPort: 9090
          volumeMounts:
            - name: prometheus-config-volume
              mountPath: /etc/prometheus/
            - name: prometheus-storage-volume
              mountPath: /prometheus/
      nodeSelector:
        kubernetes.io/hostname: knode
      volumes:
        - name: prometheus-config-volume
          configMap:
            defaultMode: 420
            name: prometheus-config
 
        - name: prometheus-storage-volume
          persistentVolumeClaim:
            claimName: prometheus-pvc

지금까지 만들었던 제반사항들이 모두 포함되어 있다. ServiceAccount 의 경우에는 Deployment.spec.serviceAccountName 에 prometheus 로 지정해 ClusterBinding 으로 묶인 메트릭 수집을 위한 API 접근을 부여하고 있다. Volume 마운트 에서는 ConfigMap 을 마운트해 파일을 작성과 PVC 를 마운트해 Prometheus 의 데이터 저장 디렉토리로 마운트 해주고 있다.

다음과 같이 생성해 준다.

Prometheus 를 위한 Deployment 생성
ZSH
1
2
3
4
5
$ kubectl apply -f prometheus-deployment.yaml
deployment.apps/prometheus-deployment created
$ kubectl get po -n monitoring
NAME                                     READY   STATUS   RESTARTS   AGE
prometheus-deployment-84468df555-5jdnq   0/1     Error    4          2m11s

처음 실행을 하면 위와 같이 에러가 발생 한다. 로그를 한번 보자.

Prometheus 를 위한 Deployment 에러 로그
ZSH
1
2
3
4
5
6
7
8
9
$ kubectl logs prometheus-deployment-84468df555-5jdnq -n monitoring
level=error ts=2020-08-25T05:25:06.038Z caller=query_logger.go:87 component=activeQueryTracker msg="Error opening query log file" file=/prometheus/queries.active err="open /prometheus/queries.active: permission denied"
panic: Unable to create mmap-ed active query log
 
goroutine 1 [running]:
github.com/prometheus/prometheus/promql.NewActiveQueryTracker(0x7ffd40076e44, 0xc, 0x14, 0x30898a0, 0xc0005e28d0, 0x30898a0)
        /app/promql/query_logger.go:117 +0x4cd
main.main()
        /app/cmd/prometheus/main.go:374 +0x4f08

“permission denied” 이 에러는 PV 에서 생성한 /opt/prometheus 디렉토리에 대한 권한이 없어서 나는 것이다. PV 를 생성한 Node 에 다음과 같이 퍼미션을 부여 한다.

/opt/prometheus 디렉토리 퍼미션 조정
ZSH
1
# chmod 757 /opt/prometheus

위와같이 퍼미션을 조정해 주면 자동으로 Pod 가 재배포 되면서 정상화 된다.

접속을 위한 Service 배포

Kubernetes 는 기본적으로 Cluster 내에서의 접속만 허용 한다. 외부에서 접속이 되게 하기 위해서는 Service 배포를 통해서 NodPort 를 열거나 아니면 Port-Forward 를 설정을 해서 접속을 해야 한다.

여기선 Service 배포를 통해서 NodePort 를 배포해 준다.

Service 배포를 통한 NodePort 오픈
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
$ vim prometheus-service.yml
apiVersion: v1
kind: Service
metadata:
  name: prometheus-service
  namespace: monitoring
  annotations:
      prometheus.io/scrape: 'true'
      prometheus.io/port:   '9090'
 
spec:
  selector:
    app: prometheus-server
  type: NodePort
  ports:
    - port: 8080
      targetPort: 9090
      nodePort: 30003

Deployment 에서 Container 포트를 9090 으로 해줬다. Service 에서는 targetPort 로 Container 포트를 인식시켜주고 Service 에서 사용할 포트 8080 과 연결해준다. Cluster 내에서 8080 포트로 접속을 하면 Deployment 의 Container 에 9090 와 연결되어 응답이 오게 된다.

nodePort 를 지정해줘서 외부에서도 접속할 수 있도록 오픈해 준다.

다음과 같이 배포를 진행 한다.

Service 배포
ZSH
1
2
$ kubectl apply -f prometheus-service.yaml
service/prometheus-service created

Node Exportor

Node Exportor 는 Kubernetes 의 Node 에 대한 정보를 수집해 준다. Kubernetes 는 모든 것을 Pod 로 작동되는데, Node 에 하나씩만 작동되어야 하며 Kubernetes 클러스터와는 별도로 Node 자체에 데몬(Daemon) 처럼 동작해야 한다. 이를 위해서 DaemonSet 오브젝트로 만들어야 한다.

DeamonSet 내용
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
$ vim prometheus-node-exporter.yaml
apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: node-exporter
  namespace: monitoring
  labels:
    k8s-app: node-exporter
spec:
  selector:
    matchLabels:
      k8s-app: node-exporter
  template:
    metadata:
      labels:
        k8s-app: node-exporter
    spec:
      containers:
      - image: prom/node-exporter
        name: node-exporter
        ports:
        - containerPort: 9100
          protocol: TCP
          name: http
---
apiVersion: v1
kind: Service
metadata:
  labels:
    k8s-app: node-exporter
  name: node-exporter
  namespace: kube-system
spec:
  ports:
  - name: http
    port: 9100
    nodePort: 31672
    protocol: TCP
  type: NodePort
  selector:
    k8s-app: node-exporter

위 내용을 배포하게 되면 Node Exportor 가 DaemonSet 으로 동작한다. 그리고 Prometheus 는 정해진 시간마다 Node Exportor 에 접속해 메트릭을 수집하고 저장하게 된다.

마치며

Prometheus 는 Kubernetes 와 잘 작동 한다. Kubernetes 를 하면서 다양한 방법으로 설치를 진행할 수 있는데, 한번 쯤은 수동으로 모두 해보는 것을 권장하고 한번 공부해보길 권장한다. 그것만으로도 Kubernetes 에 대해서 상당히 많은 부분을 익힐 수가 있다.

그런 면에서 Prometheus 를 수동으로 모두 설치해보는 것은 가치가 있다.

Deployment, Unavailable 테스트

Kubernetes 의 Deployment 에서 pod 의 Unavailable 상태를 확인하기 위한 코드는 다음과 같다.

Deployment, Unavailable 테스트 코드
YAML
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
apiVersion: apps/v1
kind: Deployment
metadata:
  name: unavailable-deployment
  labels:
    app: nginx
spec:
  replicas: 2
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: test-pod
        image: gcr.io/google_containers/busybox:1.24
        command:
        - "/bin/sh"
        args:
        - "-c"
        - "sleep 5 && exit 1"
      restartPolicy: "Always"

이것을 배포를 하면 Deployment 에 Pod가 Unavailable 상태를 보이게 된다.