Tagged: Kubernetes Install

쿠버네티스 수동 설치

쿠버네티스 설치는 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

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

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

Kubernetes 설치

Kubernetes 설치에 대해서 다룬다. 이번에는 Ubuntu 20.04 LTS, Centos 8.2 기반으로 진행했으며 이전에 설치에서 CNI 를 Calico 로 진행 했다. 더 나가 Helm, Metric Server 까지 진행 한다.

설치 환경은 다음과 같다.

  • Master
    • Distribution: Ubuntu 20.04
    • IP: 192.168.96.31
    • Hostname: kmaster
    • account: systemv
  • Worker Node
    • Distribution: CentOS 8.2
    • IP: 192.168.96.32
    • Hostname: knode
    • account: systemv
  • CNI: Calico
  • Helm 설치
  • Metric Server 설치

공통 설정 부분

Master, Node 두 서버 모두 Static IP 주소를 가지고 있어야 한다. 그리고 모두 일반 계정을 가지고 있어야 하며 이 일반 계정은 sudo 사용 권한을 가지고 있어야 한다.

sudo 권한 부여

CentOS 8.2 의 경우에 일반 계정을 생성한 후에 sudo 권한을 주고 싶다면 다음과 같이 하면 된다.

CentOS 8.2 에서 systemv 계정에 sudo 권한 부여하기
Shell
1
usermode -aG wheel systemv

CentOS 8.2 에는 wheel 라고 하는 특수한 그룹이 존재하는데, sudo 설정에는 이 그룹에 한해 sudo 사용 권한을 부여하고 있어 일반 계정 systemv 에 sudo 를 사용하게하고 싶다면 wheel 그룹에 포함시키면 된다.

Ubuntu 20.04 에서는 다음과 같이 일반계정에 sudo 권한을 부여할 수 있다.

Ubuntu 20.04 에서 systemv 계정에 sudo 권한 부여하기
Shell
1
usermode -aG sudo systemv

br_netfilter 모듈 로딩

br_netfilter 커널 모듈을 로딩해 줘야 한다. 기존에는 modprobe 설정으로 했지만 이제는 systemd 를 활용하면 되는데 ubuntu 20.04, CentOS 8.2 이 모두 이를 사용하고 있어서 적용 가능하다.

다음과 같이 모듈이름으로 conf 파일을 생성해 준다.

br_netfilter 커널 모듈 적재
ZSH
1
2
3
4
]$ sudo vim /etc/modules-load.d/br_netfilter.conf
# Load br_netfilter.ko at boot
br_netfilter
]$ sudo systemctl restart  systemd-modules-load.service

물론 이렇게 하면 시스템을 재부팅을 하더라도 자동으로 모듈이 로딩 된다.

커널 네트워크 파라메터

다음과 같이 커널 파라메터를 수정해 줘야 한다.

network 커널 파라메터 설정
ZSH
1
2
3
4
5
6
7
]# cat <<EOF > /etc/sysctl.d/k8s.conf
net.bridge.bridge-nf-call-ip6tables = 1
net.bridge.bridge-nf-call-iptables = 1
net.bridge.bridge-nf-call-arptables = 1
net.ipv4.ip_forward = 1
EOF
]# sysctl --system

/etc/hosts 파일 편집

Master, Node 서버 양쪽 모두에 /etc/hosts 파일에 각 서버 정보를 다음과 같이 입력해준다.

hosts 파일 편집
ZSH
1
2
3
]# vim /etc/hosts
192.168.96.31  kmaster
192.168.96.32  knode

swapoff 설정

kubernetes 는 swap 파티션이 존재할 경우에 동작하지 않을 수 있다. 예를들어, kubeadm 명령어로 뭔가를 할려고 할경우에 swap 파티션이 존재할 경우에 오류를 내면서 작동되지 않는다.

Master, Worke 양쪽 모두에 swap 을 off 로 해준다.

swapoff 실행
ZSH
1
]# swapoff -a

이렇게 하면 swap 이 비활성화 된다. 그리고 반드시 /etc/fstab 에서 swap 관련 마운트 설정을 주석처리 해준다.

CentOS 8.2 에서 설정

SELinux off

CentOS 8.2 에서 설정은 SELinux 설정이다. 다음과 같이 해준다.

SELinux 비활성화
ZSH
1
2
]# setenforce 0
]# sed -i 's/^SELINUX=enforcing$/SELINUX=disabled/' /etc/selinux/config

firewalld 비활성화

이것은 systemctl 로 다음과 같이 가능하다.

firewalld 비활성화
ZSH
1
2
]# systemctl stop firewalld
]# systemctl disable firewalld

패키지 설치

필수 패키지 설치
ZSH
1
2
3
]# dnf install -y yum-utils \
  device-mapper-persistent-data \
  lvm2

Ubuntu 에서 설정

패키지 설치

필수 패키지 설치
ZSH
1
2
3
4
5
6
]# apt install \
    apt-transport-https \
    ca-certificates \
    curl \
    gnupg-agent \
    software-properties-common

Docker 설치 및 설정

Kubernetes 는 Docker 를 기반으로하는 서비스다. 당연히 설치를 해줘야 하는데, 설치 관련 내용은 다음에 링크에서 각 배포판마다 잘 설명되어 있다.

한가지, Docker 설치를 위한 패키지 저장소는 명령어와 파일을 생성하는 방법 두가지가 있다.

Ubuntu 20.04

ubuntu 에서는 add-apt-repository 명령어로 저장소 URL 을 추가 가능하다. 예를 들면 다음과 같다.

저장소 주소 추가
ZSH
1
2
3
4
5
]# curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add -
]# add-apt-repository \
   "deb [arch=amd64] https://download.docker.com/linux/ubuntu \
   $(lsb_release -cs) \
   stable"

저장소 추가가 되었다면 다음과 같이 Docker 를 설치해 준다.

Docker 설치
ZSH
1
2
]# apt update
]# apt install docker-ce docker-ce-cli containerd.io

CentOS 8.2

CentOS 8.2 에서는 yum-config-manager 명령어를 이용해서 추가할 수 있다. 이 명령어는 yum-utils 패키지에 포함되어 있어 설치하면 사용할 수 있다.

필수 유틸 프로그램 설치
ZSH
1
2
3
4
]# dnf install dnf-utils
]# yum-config-manager \
    --add-repo \
    https://download.docker.com/linux/centos/docker-ce.repo

저장소 추가가 되었다면 다음과 같이 Docker 를 설치해 준다.

CentOS 8.2 에서 Docker 설치
ZSH
1
2
3
4
5
6
7
8
9
10
11
12
13
14
]# dnf install docker-ce docker-ce-cli containerd.io
Docker CE Stable - x86_64                                                                                                                                                275 kB/s |  25 kB     00:00    
오류:
문제: package docker-ce-3:19.03.12-3.el7.x86_64 requires containerd.io >= 1.2.2-3, but none of the providers can be installed
  - cannot install the best candidate for the job
  - package containerd.io-1.2.10-3.2.el7.x86_64 is filtered out by modular filtering
  - package containerd.io-1.2.13-3.1.el7.x86_64 is filtered out by modular filtering
  - package containerd.io-1.2.13-3.2.el7.x86_64 is filtered out by modular filtering
  - package containerd.io-1.2.2-3.3.el7.x86_64 is filtered out by modular filtering
  - package containerd.io-1.2.2-3.el7.x86_64 is filtered out by modular filtering
  - package containerd.io-1.2.4-3.1.el7.x86_64 is filtered out by modular filtering
  - package containerd.io-1.2.5-3.1.el7.x86_64 is filtered out by modular filtering
  - package containerd.io-1.2.6-3.3.el7.x86_64 is filtered out by modular filtering
(try to add '--skip-broken' to skip uninstallable packages or '--nobest' to use not only best candidate packages)

현시점에서 위와같은 오류가 발생한다. CentOS 8 에 대한 containerd 저장소가 존재하지 않기 때문에 필요한 정보만 출력하고 오류를 낸다. 수동으로 필요한 패키지를 다운받아서 해결한다.

containerd 패키지 수동 설치
ZSH
1
2
]# wget https://download.docker.com/linux/centos/7/x86_64/stable/Packages/containerd.io-1.2.13-3.2.el7.x86_64.rpm
]# dnf localinstall containerd.io-1.2.13-3.2.el7.x86_64.rpm

수동으로 설치는 정상적으로 진행된다. 그리고 다음과 같이 Docker 를 설치해 준다.

Docker 설치
ZSH
1
]# dnf install docker-ce docker-ce-cli iproute-tc

CentOS 8.2 에서 Docker 를 설치하면 필요한 서비스가 자동으로 시작되지 않는다. 이를 위해서 다음과 같이 systemd 를 설정해주고 시작해준다.

Docker 서비스 시작
ZSH
1
2
3
4
]# systemctl enable containerd
]# systemctl start containerd
]# systemctl enable docker
]# systemctl start docker

CGroup Driver 설정

Ubuntu, CentOS 모두 공통으로 Docker 를 설정해 주는 부분이 존재한다. 바로 Driver 를 systemd 로 바꿔줘야 한다.

Kubernetes 를 설치할때에 Cgroup driver 를 systemd 로 추천하고 있다. 그래서 Kubernetes 만 systemd 로 드라이버를 교체하면 docker 와 통신이 되지 않는다. 이것을 위해서 Docker 에서도 드라이버를 systemd 로 교체해 준다.

CGoup Driver 설정
ZSH
1
2
3
4
5
6
7
8
9
10
11
12
13
]# cat > /etc/docker/daemon.json <<EOF
{
"exec-opts": ["native.cgroupdriver=systemd"],
"log-driver": "json-file",
"log-opts": {
"max-size": "100m"
},
"storage-driver": "overlay2",
"dns": ["8.8.8.8", "8.8.4.4"]
}
EOF
]# systemctl daemon-reload
]# systemctl restart docker

다음과 같이 확인이 가능하다.

CGroup Driver 확인
ZSH
1
2
3
4
]$ docker info
Logging Driver: json-file
Cgroup Driver: systemd
Plugins:

Kubernetes 설치

Ubuntu 20.04

Master 로 사용될 Ubuntu 20.04 에서 다음과 같이 Kubernetes 패키지 저장소를 추가 한다.

Kubernetes 설치를 위한 저장소 추가
ZSH
1
2
]# curl -s https://packages.cloud.google.com/apt/doc/apt-key.gpg | apt-key add -
]# apt-add-repository "deb http://apt.kubernetes.io/ kubernetes-xenial main"

xenial 은 Ubuntu 16.04 를 말하는데 Ubuntu 20.04 에 설치하는데 아무런 문제가 없다.

다음과 같이 kubeadm, kubelet, kubectl 을 설치해 준다.

Kubernetes 컴포넌트 설치
ZSH
1
]# apt install -y kubelet kubeadm kubectl

CentOS 8.2

CentOS 8.2 에서는 다음과 같이 Kubernetes 패키지 저장소를 추가 한다.

CentOS 8 에서 Kubernetes 를 설치를 위한 저장소 추가
ZSH
1
2
3
4
5
6
7
8
9
]# cat <<EOF > /etc/yum.repos.d/kubernetes.repo
[kubernetes]
name=Kubernetes
baseurl=https://packages.cloud.google.com/yum/repos/kubernetes-el7-x86_64
enabled=1
gpgcheck=1
repo_gpgcheck=1
gpgkey=https://packages.cloud.google.com/yum/doc/yum-key.gpg https://packages.cloud.google.com/yum/doc/rpm-package-key.gpg
EOF

그리고 다음과 같이 Kubernetes 를 설치해 준다.

CentOS 8 에서 Kubernetes 를 설치를 위한 저장소 추가
ZSH
1
2
3
]# dnf install -y kubeadm --disableexcludes=kubernetes
]# systemctl enable kubelet
]# systemctl start kubelet

Master 설정

Master 를 다른 말로 Control Plaine 이라고도 한다. 이것을 만드는 것은 kubeadm 을 이용한다. 일반 계정으로 실행 한다.

kubeadm 명령어를 통한 Master 생성
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
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
]$ sudo kubeadm init --apiserver-advertise-address=192.168.96.31 --pod-network-cidr=10.31.0.0/16
[sudo] password for systemv:
W0725 07:13:28.938671    1458 configset.go:202] WARNING: kubeadm cannot validate component configs for API groups [kubelet.config.k8s.io kubeproxy.config.k8s.io]
[init] Using Kubernetes version: v1.18.6
[preflight] Running pre-flight checks
[preflight] Pulling images required for setting up a Kubernetes cluster
[preflight] This might take a minute or two, depending on the speed of your internet connection
[preflight] You can also perform this action in beforehand using 'kubeadm config images pull'
[kubelet-start] Writing kubelet environment file with flags to file "/var/lib/kubelet/kubeadm-flags.env"
[kubelet-start] Writing kubelet configuration to file "/var/lib/kubelet/config.yaml"
[kubelet-start] Starting the kubelet
[certs] Using certificateDir folder "/etc/kubernetes/pki"
[certs] Generating "ca" certificate and key
[certs] Generating "apiserver" certificate and key
[certs] apiserver serving cert is signed for DNS names [kmaster kubernetes kubernetes.default kubernetes.default.svc kubernetes.default.svc.cluster.local] and IPs [10.96.0.1 192.168.96.31]
[certs] Generating "apiserver-kubelet-client" certificate and key
[certs] Generating "front-proxy-ca" certificate and key
[certs] Generating "front-proxy-client" certificate and key
[certs] Generating "etcd/ca" certificate and key
[certs] Generating "etcd/server" certificate and key
[certs] etcd/server serving cert is signed for DNS names [kmaster localhost] and IPs [192.168.96.31 127.0.0.1 ::1]
[certs] Generating "etcd/peer" certificate and key
[certs] etcd/peer serving cert is signed for DNS names [kmaster localhost] and IPs [192.168.96.31 127.0.0.1 ::1]
[certs] Generating "etcd/healthcheck-client" certificate and key
[certs] Generating "apiserver-etcd-client" certificate and key
[certs] Generating "sa" key and public key
[kubeconfig] Using kubeconfig folder "/etc/kubernetes"
[kubeconfig] Writing "admin.conf" kubeconfig file
[kubeconfig] Writing "kubelet.conf" kubeconfig file
[kubeconfig] Writing "controller-manager.conf" kubeconfig file
[kubeconfig] Writing "scheduler.conf" kubeconfig file
[control-plane] Using manifest folder "/etc/kubernetes/manifests"
[control-plane] Creating static Pod manifest for "kube-apiserver"
[control-plane] Creating static Pod manifest for "kube-controller-manager"
W0725 07:14:17.257414    1458 manifests.go:225] the default kube-apiserver authorization-mode is "Node,RBAC"; using "Node,RBAC"
[control-plane] Creating static Pod manifest for "kube-scheduler"
W0725 07:14:17.259815    1458 manifests.go:225] the default kube-apiserver authorization-mode is "Node,RBAC"; using "Node,RBAC"
[etcd] Creating static Pod manifest for local etcd in "/etc/kubernetes/manifests"
[wait-control-plane] Waiting for the kubelet to boot up the control plane as static Pods from directory "/etc/kubernetes/manifests". This can take up to 4m0s
[apiclient] All control plane components are healthy after 28.510647 seconds
[upload-config] Storing the configuration used in ConfigMap "kubeadm-config" in the "kube-system" Namespace
[kubelet] Creating a ConfigMap "kubelet-config-1.18" in namespace kube-system with the configuration for the kubelets in the cluster
[upload-certs] Skipping phase. Please see --upload-certs
[mark-control-plane] Marking the node kmaster as control-plane by adding the label "node-role.kubernetes.io/master=''"
[mark-control-plane] Marking the node kmaster as control-plane by adding the taints [node-role.kubernetes.io/master:NoSchedule]
[bootstrap-token] Using token: 5azn6k.npyqsyongk3rsmqq
[bootstrap-token] Configuring bootstrap tokens, cluster-info ConfigMap, RBAC Roles
[bootstrap-token] configured RBAC rules to allow Node Bootstrap tokens to get nodes
[bootstrap-token] configured RBAC rules to allow Node Bootstrap tokens to post CSRs in order for nodes to get long term certificate credentials
[bootstrap-token] configured RBAC rules to allow the csrapprover controller automatically approve CSRs from a Node Bootstrap Token
[bootstrap-token] configured RBAC rules to allow certificate rotation for all node client certificates in the cluster
[bootstrap-token] Creating the "cluster-info" ConfigMap in the "kube-public" namespace
[kubelet-finalize] Updating "/etc/kubernetes/kubelet.conf" to point to a rotatable kubelet client certificate and key
[addons] Applied essential addon: CoreDNS
[addons] Applied essential addon: kube-proxy
 
Your Kubernetes control-plane has initialized successfully!
 
To start using your cluster, you need to run the following as a regular user:
 
  mkdir -p $HOME/.kube
  sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
  sudo chown $(id -u):$(id -g) $HOME/.kube/config
 
You should now deploy a pod network to the cluster.
Run "kubectl apply -f [podnetwork].yaml" with one of the options listed at:
  https://kubernetes.io/docs/concepts/cluster-administration/addons/
 
Then you can join any number of worker nodes by running the following on each as root:
 
kubeadm join 192.168.96.31:6443 --token 5azn6k.npyqsyongk3rsmqq \
    --discovery-token-ca-cert-hash sha256:743df4adaa7bace459250fa858ed07f587f6f40c4f5cd0898e3407c5ae6505a4

Kubernetes Master 명령은 전부 일반계정으로 하도록 되어 있어 있다. 일반계정이 kube api 통신을 위한 설정을 위 출력에 나온데로 실행해주면 된다.

kube api 통신을 위한 환경 설정
ZSH
1
2
3
]$ mkdir -p $HOME/.kube
]$ sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
]$ sudo chown $(id -u):$(id -g) $HOME/.kube/config

하지만 문제가 있다. 다음을 보자.

master 상태
ZSH
1
2
3
4
5
6
7
8
9
10
11
12
systemv@kmaster:~$ kubectl get nodes
NAME      STATUS     ROLES    AGE     VERSION
kmaster   NotReady   master   6m49s   v1.18.6
systemv@kmaster:~$ kubectl get pods -o wide --all-namespaces
NAMESPACE     NAME                              READY   STATUS    RESTARTS   AGE     IP              NODE      NOMINATED NODE   READINESS GATES
kube-system   coredns-66bff467f8-7c8hr          0/1     Pending   0          6m57s   <none>          <none>    <none>           <none>
kube-system   coredns-66bff467f8-7t9z4          0/1     Pending   0          6m57s   <none>          <none>    <none>           <none>
kube-system   etcd-kmaster                      1/1     Running   0          7m6s    192.168.96.31   kmaster   <none>           <none>
kube-system   kube-apiserver-kmaster            1/1     Running   0          7m6s    192.168.96.31   kmaster   <none>           <none>
kube-system   kube-controller-manager-kmaster   1/1     Running   0          7m6s    192.168.96.31   kmaster   <none>           <none>
kube-system   kube-proxy-x76xr                  1/1     Running   0          6m57s   192.168.96.31   kmaster   <none>           <none>
kube-system   kube-scheduler-kmaster            1/1     Running   0          7m6s    192.168.96.31   kmaster   <none>           <none>

kmaster 가 ‘NotReady’ 나오고 coredns 상태가 ‘Pending’ 이다. kubelet 로그를 보자.

kubectl 로그
ZSH
1
2
3
Aug 30 00:29:03 kmaster kubelet[9751]: W0830 00:29:03.096595    9751 cni.go:213] Unable to update cni config: No networks found in /etc/cni/net.d
Aug 30 00:29:05 kmaster kubelet[9751]: E0830 00:29:05.155336    9751 kubelet.go:2169] Container runtime network not ready: NetworkReady=false reason:NetworkPluginNotReady message:docker: network plugin is not read
Aug 30 00:29:08 kmaster kubelet[9751]: W0830 00:29:08.096862    9751 cni.go:213] Unable to update cni config: No networks found in /etc/cni/net.d

NetworkPlugin 이 없어 오류가 나오는 것으로 이는 CNI(Container Network Interface) 를 필요로 한다.

Calico 설치

Calico 는 Flannel 처럼 Kubernetes Cluster 에 네트워킹을 가능하도록 해준다. CNI 를 위한 컴포넌트중에 하나라고 보면 되는데, 한가지 주의해야 할 것은 반드시 메뉴얼을 읽어보고 해야 한다는 것이다.

Calico 는 Kubernetes 가 운영되는 환경에 따라 설치과정에 차이가 있으며 심지여 같은 운영환경이라고 할지라도 node 의 수에 따라서 설치해줘야하는 것도 다르다.

이 메뉴얼은 OnPremise 환경이며, 50 node 이하를 가지고 있음으로 아주 간단하게 다음과 같이 yaml 파일 하나만 다운로드 받아서 적용해주면 된다.

calico 설치를 위한 정의서 다운로드
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
$ curl https://docs.projectcalico.org/manifests/calico.yaml -O
$ kubectl apply -f calico.yaml
configmap/calico-config created
customresourcedefinition.apiextensions.k8s.io/bgpconfigurations.crd.projectcalico.org created
customresourcedefinition.apiextensions.k8s.io/bgppeers.crd.projectcalico.org created
customresourcedefinition.apiextensions.k8s.io/blockaffinities.crd.projectcalico.org created
customresourcedefinition.apiextensions.k8s.io/clusterinformations.crd.projectcalico.org created
customresourcedefinition.apiextensions.k8s.io/felixconfigurations.crd.projectcalico.org created
customresourcedefinition.apiextensions.k8s.io/globalnetworkpolicies.crd.projectcalico.org created
customresourcedefinition.apiextensions.k8s.io/globalnetworksets.crd.projectcalico.org created
customresourcedefinition.apiextensions.k8s.io/hostendpoints.crd.projectcalico.org created
customresourcedefinition.apiextensions.k8s.io/ipamblocks.crd.projectcalico.org created
customresourcedefinition.apiextensions.k8s.io/ipamconfigs.crd.projectcalico.org created
customresourcedefinition.apiextensions.k8s.io/ipamhandles.crd.projectcalico.org created
customresourcedefinition.apiextensions.k8s.io/ippools.crd.projectcalico.org created
customresourcedefinition.apiextensions.k8s.io/kubecontrollersconfigurations.crd.projectcalico.org created
customresourcedefinition.apiextensions.k8s.io/networkpolicies.crd.projectcalico.org created
customresourcedefinition.apiextensions.k8s.io/networksets.crd.projectcalico.org created
clusterrole.rbac.authorization.k8s.io/calico-kube-controllers created
clusterrolebinding.rbac.authorization.k8s.io/calico-kube-controllers created
clusterrole.rbac.authorization.k8s.io/calico-node created
clusterrolebinding.rbac.authorization.k8s.io/calico-node created
daemonset.apps/calico-node created
serviceaccount/calico-node created
deployment.apps/calico-kube-controllers created
serviceaccount/calico-kube-controllers created

이제 시간을 조금 기달려서 모든 pods 가 정상으로 Running 인지를 확인해 본다.

kubernetes 운영을 위한 pods 확인
ZSH
1
2
3
4
5
6
7
8
9
10
11
$ kubectl get pods -o wide --all-namespaces
NAMESPACE     NAME                                       READY   STATUS    RESTARTS   AGE   IP              NODE      NOMINATED NODE   READINESS GATES
kube-system   calico-kube-controllers-578894d4cd-892sz   1/1     Running   0          91s   10.31.189.3     kmaster   <none>           <none>
kube-system   calico-node-8btl4                          1/1     Running   0          91s   192.168.96.31   kmaster   <none>           <none>
kube-system   coredns-66bff467f8-7c8hr                   1/1     Running   0          8h    10.31.189.2     kmaster   <none>           <none>
kube-system   coredns-66bff467f8-7t9z4                   1/1     Running   0          8h    10.31.189.1     kmaster   <none>           <none>
kube-system   etcd-kmaster                               1/1     Running   0          8h    192.168.96.31   kmaster   <none>           <none>
kube-system   kube-apiserver-kmaster                     1/1     Running   0          8h    192.168.96.31   kmaster   <none>           <none>
kube-system   kube-controller-manager-kmaster            1/1     Running   0          8h    192.168.96.31   kmaster   <none>           <none>
kube-system   kube-proxy-x76xr                           1/1     Running   0          8h    192.168.96.31   kmaster   <none>           <none>
kube-system   kube-scheduler-kmaster                     1/1     Running   0          8h    192.168.96.31   kmaster   <none>           <none>

그리고 nodes 의 상태를 확인해 본다.

kubernetes 의 nodes 확인
ZSH
1
2
3
$ kubectl get nodes
NAME      STATUS   ROLES    AGE   VERSION
kmaster   Ready    master   8h    v1.18.6

“Ready” 상태가 되었음으로 이제 Worker Node 를 추가해 보자.

Worker Node 추가.

Worker Node 는 knode 서버에서 다음과 같이 Kubernetes Cluster 에 join 하겠다는 것으로 실현된다. join 을 위한 파라메터는 kmaster 에서 kubeadm 으로 cluster 를 생성할때 보여준 값을 입력하면 된다.

Worker Node 추가
ZSH
1
2
$ sudo kubeadm join 192.168.96.31:6443 --token 5azn6k.npyqsyongk3rsmqq \
>     --discovery-token-ca-cert-hash sha256:743df4adaa7bace459250fa858ed07f587f6f40c4f5cd0898e3407c5ae6505a4

이렇게 한 다음에 kmaster 서버에서 다음과 같이 knode 가 추가되고 상태가 Ready 된다면 Worker Node 추가가 완료된 것이다.

kubernetes 의 nodes 확인
ZSH
1
2
3
4
$ kubectl get nodes
NAME      STATUS   ROLES    AGE     VERSION
kmaster   Ready    master   9h      v1.18.6
knode     Ready    <none>   5m49s   v1.18.6

Helm 3 설치하기

Helm 은 Kubernetes 에서 작동하는 많은 Application 들을 손쉽게 설치하도록 도와주는 프로그램이다. 마치 Ubuntu 의 APT 나 CentOS 의 Yum 이 프로그램 설치를 손쉽게 해주는것과 같다.

한가지 변화가 있다. Helm 2 와 Helm 3 은 완전히 다르다고 생각해야 한다. Helm 2 는 Tiller 라고 해서 Helm 서버가 필요했지만 Helm 3 에서는 이것이 없어졌다.

Helm 3 는 설치 스크립트를 제공함으로 이것을 이용하면 손쉽게 설치할 수 있다. 설치 Node는 kubectl 을 사용할 수 있는 곳이라면 어디선든 사용이 가능하다.

Helm 3 설치

Helm 3 설치는 스크립트로 제공한다.

Helm 3 설치
ZSH
1
2
3
$ curl -fsSL -o get_helm.sh https://raw.githubusercontent.com/helm/helm/master/scripts/get-helm-3
$ chmod 700 get_helm.sh
$ ./get_helm.sh

설치는 그냥 바이너리를 다운로드 받아서 /usr/bin 에 helm 바이너리를 설치하는 것으로 끝난다.

정상적으로 설치됐는지 확인은 다음과 같이 한다.

Helm 3 설치 확인
ZSH
1
2
$ helm version
version.BuildInfo{Version:"v3.2.4", GitCommit:"0ad800ef43d3b826f31a5ad8dfbb4fe05d143688", GitTreeState:"clean", GoVersion:"go1.13.12"}

한가지 문제는 기본 repository 주소가 없어서 뭐든 설치할려면 설치가 안된다. 이를 위해서 다음과 같이 저장소를 추가해 준다.

Helm 3 저장소 추가
ZSH
1
2
3
4
5
6
7
8
$ helm search repo
Error: no repositories configured
$ helm repo add stable https://kubernetes-charts.storage.googleapis.com/
"stable" has been added to your repositories
$ helm repo update
Hang tight while we grab the latest from your chart repositories...
...Successfully got an update from the "stable" chart repository
Update Complete. ⎈ Happy Helming!⎈

Helm 3 은 이것으로 끝이다. 이전 Helm 2 버전에 비해 해줘야 하는 것이 없다.

Metric Server 설치

Kubernetes 를 설치하게 되면 자원에 대한 모니터링이 필요하다. 과거에는 Heapster 를 이용했지만 이것은 이제 더 이상 개발이 되지 않고 있으며 이를 대체하는 것이 Metric Server 이다.

Kubernetes 에서 뭔가를 설치하는 것은 대부분 Pods 를 설치하는 것이며 이것에 대한 Rules, Datastore 등도 한꺼번에 설정을 해준다.

Metric Server 를 설치하게 되면 Kubernetes 의 컴포넌트들에 대한 자원 모니터링이 가능해지며 이것을 이용해 Autoscaling 에도 사용이 가능해진다.

Downloads

Metric Server 를 다음과 같이 다운로드를 한다.

Metric Server 설치 파일 다운로드
ZSH
1
]$ wget https://github.com/kubernetes-sigs/metrics-server/releases/download/v0.3.7/components.yaml

TLS 수정

Metric Server 를 설치할때에 주의해야 할 것은 Kube API 서버와의 통신에서 사용할 TLS 를 수정하는 것이다. Metric Server 는 Public TLS 를 기본으로 하지만 Kube API 는 Kube 자체의 TLS 를 사용하기 때문에 그냥 설치하면 문제가 된다.

Metric Server 설치 파일 TLS 수정
ZSH
1
2
3
4
5
6
7
8
]$ vim components.yaml
....
        args:
          - --cert-dir=/tmp
          - --secure-port=4443
          - --kubelet-insecure-tls
          - --kubelet-preferred-address-types=InternalIP,ExternalIP,Hostname
....

Deploy

이제 이것을 Deploy 해준다. Kubernetes 에서는 설치라는게 없다. 모두 다 pods 로 다 올라가기 때문에 Deploy 라고 한다.

Metric Server 배포
ZSH
1
2
3
4
5
6
7
8
9
10
$ kubectl apply -f components.yaml
clusterrole.rbac.authorization.k8s.io/system:aggregated-metrics-reader created
clusterrolebinding.rbac.authorization.k8s.io/metrics-server:system:auth-delegator created
rolebinding.rbac.authorization.k8s.io/metrics-server-auth-reader created
apiservice.apiregistration.k8s.io/v1beta1.metrics.k8s.io created
serviceaccount/metrics-server created
deployment.apps/metrics-server created
service/metrics-server created
clusterrole.rbac.authorization.k8s.io/system:metrics-server created
clusterrolebinding.rbac.authorization.k8s.io/system:metrics-server created

위와같이 관련된 설정과 pods, deploy, service 등이 생성이 된다.

확인

Metric Server 의 확인은 pods, deploy 가 제대로 되었는지를 살펴보면 된다.

Metric Server 배포 확인
ZSH
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
]$ kubectl get pods -n kube-system
NAME                                       READY   STATUS    RESTARTS   AGE
calico-kube-controllers-578894d4cd-892sz   1/1     Running   0          67m
calico-node-8btl4                          1/1     Running   0          67m
calico-node-kp5gm                          1/1     Running   0          58m
coredns-66bff467f8-7c8hr                   1/1     Running   0          9h
coredns-66bff467f8-7t9z4                   1/1     Running   0          9h
etcd-kmaster                               1/1     Running   0          9h
kube-apiserver-kmaster                     1/1     Running   0          9h
kube-controller-manager-kmaster            1/1     Running   0          9h
kube-proxy-2nklp                           1/1     Running   0          58m
kube-proxy-x76xr                           1/1     Running   0          9h
kube-scheduler-kmaster                     1/1     Running   0          9h
metrics-server-5f4ffd464c-s98nr            1/1     Running   0          77s
]$ kubectl get deploy -n kube-system
NAME                      READY   UP-TO-DATE   AVAILABLE   AGE
calico-kube-controllers   1/1     1            1           68m
coredns                   2/2     2            2           9h
metrics-server            1/1     1            1           92s

그리고 1~2분을 기다리면 후에 다음과 같이 자원이 출력이 되는지를 보면 된다.

Metric Server 작동 확인
ZSH
1
2
3
4
5
6
7
8
9
10
11
12
13
NAME                                       CPU(cores)   MEMORY(bytes)  
calico-kube-controllers-578894d4cd-892sz   1m           6Mi            
calico-node-8btl4                          24m          26Mi            
calico-node-kp5gm                          21m          45Mi            
coredns-66bff467f8-7c8hr                   4m           6Mi            
coredns-66bff467f8-7t9z4                   3m           6Mi            
etcd-kmaster                               20m          28Mi            
kube-apiserver-kmaster                     39m          325Mi          
kube-controller-manager-kmaster            14m          41Mi            
kube-proxy-2nklp                           1m           12Mi            
kube-proxy-x76xr                           1m           9Mi            
kube-scheduler-kmaster                     4m           12Mi            
metrics-server-5f4ffd464c-s98nr            1m           13Mi

CPU, Memory 등과 같은 자원 현황이 출력이 되면 정상적으로 작동하는 것이다.