Tagged: 쿠버네티스

04/29/2021

Docker, Kubernetes 네트워크

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

Docker 네트워크

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

$ 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

$ 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 상태는 다음의 명령으로 확인이 가능하다.

$ 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 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 네트워크에 해당한다고 다음과 같이 확인해 볼수 있다.

$ 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": {}
    }
]

$ 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 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 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 가상의 인터페이스가 하나 붙는다.

]$ 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

]$ 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 과는 무슨 상관일까?

$ 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

$ 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 컨테이너의 네트워크 인터페이스를 말한다.

$ 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

$ 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

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

$ 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 -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 을 사용했다.

$ 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>

$ 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) 를 생성한 후에 워커 노드 상태다.

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

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 다.

$ 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

$ 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 에 연결된 네트워크 인터페이스는 다음과 같이 확인할 수 있다.

$ 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

$ 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 인터페이스는 대체 무엇일까? 다음의 명령어로 확인해 보자.

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

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 기반으로 호스트가 서로 다른 파드에 대한 연결을 만들어주게 되어 있다. 마스터 노드에서 다음의 명령어를 실행해 보자.

$ 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

$ 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 보다) 훨씬 간단하다.

04/24/2021

메트릭 서버(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 pod
Error from server (ServiceUnavailable): the server is currently unable to handle the request (get pods.metrics.k8s.io)

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 의 로그에 다음과 같이 관련 오류가 나온다.

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.

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 가 없을 경우에 위 파라메터를 추가해줘야 한다.

워커 노드 메트릭 수집 안됨

$ 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>

$ 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 메니페스트를 다음과 같이 수정해 줘야 한다.

$ kubectl edit deployment.apps/metrics-server -n kube-system
      dnsPolicy: ClusterFirst
      hostNetwork: true
      nodeSelector:

$ kubectl edit deployment.apps/metrics-server -n kube-system

dnsPolicy: ClusterFirst

hostNetwork: true

nodeSelector:

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

04/24/2021

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) 에 로그는 다음과 같다.

$ 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"

$ 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 에 커맨드 파라메터를 다음과 같이 추가 해주고 재시작 해줘야 한다.

--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="">

--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 파일을 작성함으로서 시작된다.

$ 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

$ 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 파라메터의 값과 동일해야 한다. 이제 다음과 같이 인증서를 제작한다.

$ 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

$ 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 서버에 배포를 해준다.

$ sudo cp proxy-client*.pem /var/lib/kubernetes/
$ scp proxy-client*.pem systemv@kmaster2.systemv.local:./
$ scp proxy-client*.pem systemv@kmaster3.systemv.local:./

$ 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 를 등록했기 때문에 유닛 파일을 수정해주면 된다.

$ 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

$ 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

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

$ 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

$ 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

08/10/2020

Kubernetes 프로세스별 상태

Kubernetes 는 다양한 컴포넌트들로 인해서 작동된다. 이러한 컴포넌트들은 중요성에 있어서 약간의 차이가 있다. 예를들어 Worker Node 에서 docker 프로세스가 정지되거나 문제가 되었을때에 어떻게 될까? 혹은 Worker Node 에 kubelet 프로세스가 문제가 된다면?

이 문서는 Kubernetes 프로세스별 상태 에 대한 글이다.

환경

여기서 환경은 Kubernetes 의 객체를 말한다. 객체라함은 Pods, Deployments, Services, StatefulSet 으로 했다. 그밖에 다양한 객체가 있지만 이 정도 생성해서 진행해보기로 했다.

docker 정지

이것은 Work Node 에 docker 를 정지 시키는 것이다. 이렇게 되었을때에 Kubernetes 의 각종 컴포넌트들은 어떤 상태를 보일지 알아보자.

먼저, Nodes 상태는 ‘Notready’ 로 변경된다.

kubectl get nodes
NAME      STATUS     ROLES    AGE   VERSION
kmaster   Ready      master   16d   v1.18.6
knode     NotReady   <none>   15d   v1.18.6

kubectl get nodes

NAME STATUS ROLES AGE VERSION

kmaster Ready master 16d v1.18.6

knode NotReady <none> 15d v1.18.6

Node 의 자세한 상태를 describe 보면 다음과같이 몇가지 상태가 나온다.

Warning ContainerGCFailed 38s (x2 over 98s) kubelet, knode rpc error: code = Unknown desc = Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?

Conditions 는 다음과 같이 된다.

Conditions:
  Type                 Status  LastHeartbeatTime                 LastTransitionTime                Reason                       Message
  ----                 ------  -----------------                 ------------------                ------                       -------
  NetworkUnavailable   False   Mon, 10 Aug 2020 12:48:31 +0000   Mon, 10 Aug 2020 12:48:31 +0000   CalicoIsUp                   Calico is running on this node
  MemoryPressure       False   Mon, 10 Aug 2020 13:08:12 +0000   Mon, 10 Aug 2020 12:57:30 +0000   KubeletHasSufficientMemory   kubelet has sufficient memory available
  DiskPressure         False   Mon, 10 Aug 2020 13:08:12 +0000   Mon, 10 Aug 2020 12:57:30 +0000   KubeletHasNoDiskPressure     kubelet has no disk pressure
  PIDPressure          False   Mon, 10 Aug 2020 13:08:12 +0000   Mon, 10 Aug 2020 12:57:30 +0000   KubeletHasSufficientPID      kubelet has sufficient PID available
  Ready                False   Mon, 10 Aug 2020 13:08:12 +0000   Mon, 10 Aug 2020 13:07:52 +0000   KubeletNotReady              [container runtime is down, Container runtime not ready: RuntimeReady=false reason:DockerDaemonNotReady message:docker: failed to get docker version: Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?]

Conditions:

Type Status LastHeartbeatTime LastTransitionTime Reason Message

---- ------ ----------------- ------------------ ------ -------

NetworkUnavailable False Mon, 10 Aug 2020 12:48:31 +0000 Mon, 10 Aug 2020 12:48:31 +0000 CalicoIsUp Calico is running on this node

MemoryPressure False Mon, 10 Aug 2020 13:08:12 +0000 Mon, 10 Aug 2020 12:57:30 +0000 KubeletHasSufficientMemory kubelet has sufficient memory available

DiskPressure False Mon, 10 Aug 2020 13:08:12 +0000 Mon, 10 Aug 2020 12:57:30 +0000 KubeletHasNoDiskPressure kubelet has no disk pressure

PIDPressure False Mon, 10 Aug 2020 13:08:12 +0000 Mon, 10 Aug 2020 12:57:30 +0000 KubeletHasSufficientPID kubelet has sufficient PID available

Ready False Mon, 10 Aug 2020 13:08:12 +0000 Mon, 10 Aug 2020 13:07:52 +0000 KubeletNotReady [container runtime is down, Container runtime not ready: RuntimeReady=false reason:DockerDaemonNotReady message:docker: failed to get docker version: Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?]

두번째, Pods 상태.

상태가 STATUS 는 Completed 으로 나오고 READY 도 0/1 로 나온다. 정상으로 나오지 않는다. Pods 하나를 골라 describe 해보면 Ready 는 False 로 나온다.

세번째, Deployment 상태.

READY 가 0/3 으로 모두 문제가 있는 것으로 나온다.

네번째, Services 상태.

Service 에 상태는 없다.

다섯번째, StatefulSet 상태.

StatefulSet 상태로 READY 가 0/2 로 모두 문제가 있는 것으로 나온다. 하지만, Pods Status 에서는 “2 Running / 0 Waiting / 0 Succeeded / 0 Failed” 로 Pod 2개 Running 으로 나온다.

kubelet 정지

kubelet 은 Worker Node 에 명령을 수행하는 중요한 프로세스이다. 이를 정지했을때는 어떤 상태를 보일까..

Node 상태.

Node 상태는 NotReady 가 된다. 그리고 Conditions 상태는 다음과 같다.

Conditions:
  Type                 Status    LastHeartbeatTime                 LastTransitionTime                Reason              Message
  ----                 ------    -----------------                 ------------------                ------              -------
  NetworkUnavailable   False     Mon, 10 Aug 2020 13:35:04 +0000   Mon, 10 Aug 2020 13:35:04 +0000   CalicoIsUp          Calico is running on this node
  MemoryPressure       Unknown   Mon, 10 Aug 2020 13:34:54 +0000   Mon, 10 Aug 2020 13:37:42 +0000   NodeStatusUnknown   Kubelet stopped posting node status.
  DiskPressure         Unknown   Mon, 10 Aug 2020 13:34:54 +0000   Mon, 10 Aug 2020 13:37:42 +0000   NodeStatusUnknown   Kubelet stopped posting node status.
  PIDPressure          Unknown   Mon, 10 Aug 2020 13:34:54 +0000   Mon, 10 Aug 2020 13:37:42 +0000   NodeStatusUnknown   Kubelet stopped posting node status.
  Ready                Unknown   Mon, 10 Aug 2020 13:34:54 +0000   Mon, 10 Aug 2020 13:37:42 +0000   NodeStatusUnknown   Kubelet stopped posting node status.

Conditions:

Type Status LastHeartbeatTime LastTransitionTime Reason Message

---- ------ ----------------- ------------------ ------ -------

NetworkUnavailable False Mon, 10 Aug 2020 13:35:04 +0000 Mon, 10 Aug 2020 13:35:04 +0000 CalicoIsUp Calico is running on this node

MemoryPressure Unknown Mon, 10 Aug 2020 13:34:54 +0000 Mon, 10 Aug 2020 13:37:42 +0000 NodeStatusUnknown Kubelet stopped posting node status.

DiskPressure Unknown Mon, 10 Aug 2020 13:34:54 +0000 Mon, 10 Aug 2020 13:37:42 +0000 NodeStatusUnknown Kubelet stopped posting node status.

PIDPressure Unknown Mon, 10 Aug 2020 13:34:54 +0000 Mon, 10 Aug 2020 13:37:42 +0000 NodeStatusUnknown Kubelet stopped posting node status.

Ready Unknown Mon, 10 Aug 2020 13:34:54 +0000 Mon, 10 Aug 2020 13:37:42 +0000 NodeStatusUnknown Kubelet stopped posting node status.

Pods 상태

이상하게도 Pods 상태는 모두 정상으로 나온다. 하지만 Port-Foward 를 시도하면 되지 않는다.

Deployment 상태

비정상으로 나온다. READY 가 0/3 으로 표시된다.

StatefulSet 상태

비정상으로 나온다. READY 가 0/2 로 표시된다.

Worker Node 셧다운

이 상태는 kubelet 와 동일한 결과를 보여준다.

08/09/2020

StatefulSet 에서 로컬 디스크 사용

이 문서는 StatefulSet 에서 로컬 디스크 사용 에 대한 글이다. Kubernetes 에서 디스크 사용은 어려운감이 있다. PersistentVolume 과 PersistentVolumeClaim 이라는 것을 알아야하고 이를 알고나서도 여러가지 속성들때문에 헷깔리는 경우가 많다.

PersistentVolume 관련해서 문서를 보면 대부분 클라우드가 제공하는 스토리지를 이용하는 예제가 많다. 그것이 아니라면 nfs 를 이용하는 경우가 많아서 나처럼 집에 컴퓨터를 이용하는 경우에 실습해 보기가 쉽지 않은게 사실이다.

StatefulSet 의 경우가 바로 이런 경우였다. StatefulSet 을 연구하기 위해서 여러가지 예제를 찾아봤고 다음과 같은 파일을 찾아냈다.

---
apiVersion: v1
kind: Service
metadata:
  name: nginx
  namespace: perf-poc
  labels:
    app: nginx
spec:
  ports:
  - port: 80
    name: web
  clusterIP: None
  selector:
    app: nginx
---
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: web
  namespace: perf-poc
spec:
  selector:
    matchLabels:
      app: nginx
  serviceName: "nginx"
  replicas: 2
  template:
    metadata:
      labels:
        app: nginx
    spec:
      terminationGracePeriodSeconds: 10
      containers:
      - name: nginx
        image: k8s.gcr.io/nginx-slim:0.8
        ports:
        - containerPort: 80
          name: web
        volumeMounts:
        - name: www
          mountPath: /usr/share/nginx/html
      nodeSelector:
        kubernetes.io/hostname: knode
  volumeClaimTemplates:
  - metadata:
      name: www
      namespace: perf-poc
    spec:
      accessModes: [ "ReadWriteOnce" ]
      resources:
        requests:
          storage: 1Gi

---

apiVersion: v1

kind: Service

metadata:

namespace: perf-poc

labels:

app: nginx

spec:

ports:

- port: 80

clusterIP: None

selector:

app: nginx

---

apiVersion: apps/v1

kind: StatefulSet

metadata:

namespace: perf-poc

spec:

selector:

matchLabels:

app: nginx

serviceName: "nginx"

replicas: 2

template:

metadata:

labels:

app: nginx

spec:

terminationGracePeriodSeconds: 10

containers:

- name: nginx

image: k8s.gcr.io/nginx-slim:0.8

ports:

- containerPort: 80

volumeMounts:

- name: www

mountPath: /usr/share/nginx/html

nodeSelector:

kubernetes.io/hostname: knode

volumeClaimTemplates:

- metadata:

namespace: perf-poc

spec:

accessModes: [ "ReadWriteOnce" ]

resources:

requests:

storage: 1Gi

StatefulSet 은 비상태(stateless) 자원을 생성하는게 아니라 상태를 가지는 자원을 생성하게 해주는 Kubernetes 의 객체다. 대부분 Persistent Data 를 위한 것이기에 PersistentVolume 을 대부분 필요로 한다.

위 예제를 가지고 생성을 해보자.

]$ kubectl apply -f web.yaml
service/nginx created
statefulset.apps/web created

]$ kubectl apply -f web.yaml

service/nginx created

statefulset.apps/web created

정상적으로 생성이 됐다고 나온다. 확인을 해보자.

]$ kubectl get po,svc,sts
NAME        READY   STATUS    RESTARTS   AGE
pod/web-0   0/1     Pending   0          2m7s

NAME                 TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)   AGE
service/kubernetes   ClusterIP   10.96.0.1    <none>        443/TCP   14d
service/nginx        ClusterIP   None         <none>        80/TCP    2m7s

NAME                   READY   AGE
statefulset.apps/web   0/2     2m7s

]$ kubectl get po,svc,sts

NAME READY STATUS RESTARTS AGE

pod/web-0 0/1 Pending 0 2m7s

NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE

service/kubernetes ClusterIP 10.96.0.1 <none> 443/TCP 14d

service/nginx ClusterIP None <none> 80/TCP 2m7s

NAME READY AGE

statefulset.apps/web 0/2 2m7s

Pod 생성이 Pending 상태를 보이고 있다. 왜 이럴까? 앞에서 객체 생성을 정의한 yaml 파일을 자세히 보면 Persistent Volume 을 요청하고 있다. volumeClaimTemplates 이 바로 그것이다. 이것은 PersistentVolumeClaim 을 요청하는 것으로 나타난다. 확인해 보자.

]$ kubectl get po,pvc
NAME                              STATUS    VOLUME   CAPACITY   ACCESS MODES   STORAGECLASS   AGE
persistentvolumeclaim/www-web-0   Pending                                                     5m29s

]$ kubectl get po,pvc

NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE

persistentvolumeclaim/www-web-0 Pending 5m29s

persistentvolumeclaim 이 Pending 상태이다. 결국에는 이것으로 인해서 Pod 생성도 Pending 이 된 것이다.

해결방안

PersistentVolumeClaim 은 PersistentVolume 이 있어야 한다. 그리고 이것을 묶어줘야하는데 이것을 Bound 라고 한다. 문제는 web.yaml 을 실행했을때에 생성되는 PersistentVolumeClaim 과 PersistentVolume 을 어떻게 연결할 것인가?

좀더 정확하게 말하면 StatefulSet 이 자동으로 생성하는 PersistentVolumeClaim 과 PersistentVolume 을 어떻게 연결할 것인가?

StatefulSet 의 특징은 생성하는 객체의 이름이 임의대로 정해지지 않는다. 정확하게 사람이 인식하기 쉬운 이름으로 결정된다. 앞에서보면 Pod 의 이름이 web-0 이다. 이는 Pod 이름에 Replicas 의 첫번째인 0 을 붙여서 만든다.

StatefulSet 에서 PersistentVolumeClaim 이름은 예측 가능한 패턴을 따른다. volumeclaimtemplates-name–statefulset-name–replica-index. 그래서 생성된 PersistentVolumeClaim 의 이름이 www-web-0 가 된 것이다.

PersistentVolumeClaim 은 PersistentVolume 을 필요로 한다. PersistentVolume 을 생성할때에 claimRef.name 을 PersistentVolumeClaim 이름으로 지정한다. 이렇게 하면 PersistentVolumeClaim 이 생성될때에 PersistentVolume 이 이름과 연결되어 자동으로 Bound 되어진다. 다음과 같이 PersistentVolume 을 만든다.

apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv-statefulset-demo-0
  namespace: perf-poc
spec:
  storageClassName: "example-storageclass"
  capacity:
    storage: 2Gi
  volumeMode: Filesystem
  accessModes:
    - ReadWriteOnce
  claimRef:
    namespace: perf-poc
    name: www-web-0
  persistentVolumeReclaimPolicy: Delete
  hostPath:
    path: /tmp/k8s-pv-statefulset-demo
    type: DirectoryOrCreate
  nodeAffinity:
    required:
      nodeSelectorTerms:
      - matchExpressions:
        - key: "kubernetes.io/hostname"
          operator: "In"
          values:
          - knode

apiVersion: v1

kind: PersistentVolume

metadata:

namespace: perf-poc

spec:

storageClassName: "example-storageclass"

capacity:

storage: 2Gi

volumeMode: Filesystem

accessModes:

- ReadWriteOnce

claimRef:

namespace: perf-poc

persistentVolumeReclaimPolicy: Delete

hostPath:

path: /tmp/k8s-pv-statefulset-demo

type: DirectoryOrCreate

nodeAffinity:

required:

nodeSelectorTerms:

- matchExpressions:

- key: "kubernetes.io/hostname"

operator: "In"

values:

- knode

이것은 Kubernetes Worker 호스트에 파일시스템에 특정 디렉토리를 PersistentVolume 으로 생성한다. 만일 디렉토리가 존재하지 않을 경우에는 생성하도록 한다. 그리고 PersistentVolumeClaim 이 삭제되면 이 볼륨도 함께 삭제되도록 했다.

여기서 중요한 것이 claimRef 필드이다. name 속성에 PersistentVolumeClaim 이름을 지정해준다.

또, nodeAffinity 필드를 이용해서 특정한 Worker 에서 생성되도록 했다.

StatefulSet 에서 replicas 를 2 로 했기 때문에 위 PersistentVolume 생성은 claimRef.name 이 www-web-0, www-web-1 로 두개가 필요하다.

두개의 PersistentVolume 을 생성하고 시간을 갖고 기다리면 다음과 같은 결과를 얻게 된다.

]$ kubectl get po,pv,pvc
NAME        READY   STATUS    RESTARTS   AGE
pod/web-0   1/1     Running   0          21m
pod/web-1   1/1     Running   0          33s

NAME                                     CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS   CLAIM               STORAGECLASS           REASON   AGE
persistentvolume/pv-statefulset-demo-0   2Gi        RWO            Delete           Bound    default/www-web-0   example-storageclass            57s
persistentvolume/pv-statefulset-demo-1   2Gi        RWO            Delete           Bound    default/www-web-1   example-storageclass            23s

NAME                              STATUS   VOLUME                  CAPACITY   ACCESS MODES   STORAGECLASS   AGE
persistentvolumeclaim/www-web-0   Bound    pv-statefulset-demo-0   2Gi        RWO                           21m
persistentvolumeclaim/www-web-1   Bound    pv-statefulset-demo-1   2Gi        RWO                           33s

]$ kubectl get po,pv,pvc

NAME READY STATUS RESTARTS AGE

pod/web-0 1/1 Running 0 21m

pod/web-1 1/1 Running 0 33s

NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE

persistentvolume/pv-statefulset-demo-0 2Gi RWO Delete Bound default/www-web-0 example-storageclass 57s

persistentvolume/pv-statefulset-demo-1 2Gi RWO Delete Bound default/www-web-1 example-storageclass 23s

NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE

persistentvolumeclaim/www-web-0 Bound pv-statefulset-demo-0 2Gi RWO 21m

persistentvolumeclaim/www-web-1 Bound pv-statefulset-demo-1 2Gi RWO 33s

Worker 호스트에 PersistentVolume 에서 생성한 디렉토리가 있는지 확인해 보자.

$ ls -lh /tmp/
total 0
drwxr-xr-x 2 root root  6 Aug  8 21:42 k8s-pv-statefulset-demo-0
drwxr-xr-x 2 root root  6 Aug  8 21:44 k8s-pv-statefulset-demo-1

$ ls -lh /tmp/

total 0

drwxr-xr-x 2 root root 6 Aug 8 21:42 k8s-pv-statefulset-demo-0

drwxr-xr-x 2 root root 6 Aug 8 21:44 k8s-pv-statefulset-demo-1

이렇게 문제를 해결할 수 있다.

참고: StatefulSet 에서 기존 디스크 사용

07/26/2020

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 권한을 주고 싶다면 다음과 같이 하면 된다.

usermode -aG wheel systemv

1	usermode -aG wheel systemv

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

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

usermode -aG sudo systemv

1	usermode -aG sudo systemv

br_netfilter 모듈 로딩

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

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

]$ sudo vim /etc/modules-load.d/br_netfilter.conf
# Load br_netfilter.ko at boot
br_netfilter
]$ sudo systemctl restart  systemd-modules-load.service

]$ sudo vim /etc/modules-load.d/br_netfilter.conf

# Load br_netfilter.ko at boot

br_netfilter

]$ sudo systemctl restart systemd-modules-load.service

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

커널 네트워크 파라메터

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

]# 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

]# 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 파일에 각 서버 정보를 다음과 같이 입력해준다.

]# vim /etc/hosts
192.168.96.31  kmaster
192.168.96.32  knode

]# vim /etc/hosts

192.168.96.31 kmaster

192.168.96.32 knode

swapoff 설정

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

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

]# swapoff -a

1	]# swapoff -a

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

CentOS 8.2 에서 설정

SELinux off

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

]# setenforce 0
]# sed -i 's/^SELINUX=enforcing$/SELINUX=disabled/' /etc/selinux/config

1 2	]# setenforce 0 ]# sed -i 's/^SELINUX=enforcing$/SELINUX=disabled/' /etc/selinux/config

firewalld 비활성화

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

]# systemctl stop firewalld
]# systemctl disable firewalld

1 2	]# systemctl stop firewalld ]# systemctl disable firewalld

패키지 설치

]# dnf install -y yum-utils \
  device-mapper-persistent-data \
  lvm2

]# dnf install -y yum-utils \

device-mapper-persistent-data \

lvm2

Ubuntu 에서 설정

패키지 설치

]# apt install \
    apt-transport-https \
    ca-certificates \
    curl \
    gnupg-agent \
    software-properties-common

]# apt install \

apt-transport-https \

ca-certificates \

curl \

gnupg-agent \

software-properties-common

Docker 설치 및 설정

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

Docker Installation

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

Ubuntu 20.04

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

]# 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"

]# 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 를 설치해 준다.

]# apt update
]# apt install docker-ce docker-ce-cli containerd.io

1 2	]# apt update ]# apt install docker-ce docker-ce-cli containerd.io

CentOS 8.2

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

]# dnf install dnf-utils
]# yum-config-manager \
    --add-repo \
    https://download.docker.com/linux/centos/docker-ce.repo

]# dnf install dnf-utils

]# yum-config-manager \

--add-repo \

https://download.docker.com/linux/centos/docker-ce.repo

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

]# 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)

]# 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 저장소가 존재하지 않기 때문에 필요한 정보만 출력하고 오류를 낸다. 수동으로 필요한 패키지를 다운받아서 해결한다.

]# 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

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 를 설치해 준다.

]# dnf install docker-ce docker-ce-cli iproute-tc

1	]# dnf install docker-ce docker-ce-cli iproute-tc

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

]# systemctl enable containerd
]# systemctl start containerd
]# systemctl enable docker
]# systemctl start docker

]# 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 로 교체해 준다.

]# 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

]# 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

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

]$ docker info	 	 
Logging Driver: json-file	 	 
 Cgroup Driver: systemd	 	 
 Plugins:

]$ docker info

Logging Driver: json-file

Cgroup Driver: systemd

Plugins:

Kubernetes 설치

Ubuntu 20.04

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

]# 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"

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 을 설치해 준다.

]# apt install -y kubelet kubeadm kubectl

1	]# apt install -y kubelet kubeadm kubectl

CentOS 8.2

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

]# 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

]# 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 를 설치해 준다.

]# dnf install -y kubeadm --disableexcludes=kubernetes
]# systemctl enable kubelet
]# systemctl start kubelet

]# dnf install -y kubeadm --disableexcludes=kubernetes

]# systemctl enable kubelet

]# systemctl start kubelet

Master 설정

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

]$ 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

]$ 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 통신을 위한 설정을 위 출력에 나온데로 실행해주면 된다.

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

]$ mkdir -p $HOME/.kube

]$ sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config

]$ sudo chown $(id -u):$(id -g) $HOME/.kube/config

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

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>

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 로그를 보자.

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

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 파일 하나만 다운로드 받아서 적용해주면 된다.

$ 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

$ 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 인지를 확인해 본다.

$ 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>

$ 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 의 상태를 확인해 본다.

$ kubectl get nodes
NAME      STATUS   ROLES    AGE   VERSION
kmaster   Ready    master   8h    v1.18.6

$ 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 를 생성할때 보여준 값을 입력하면 된다.

$ sudo kubeadm join 192.168.96.31:6443 --token 5azn6k.npyqsyongk3rsmqq \
>     --discovery-token-ca-cert-hash sha256:743df4adaa7bace459250fa858ed07f587f6f40c4f5cd0898e3407c5ae6505a4

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 추가가 완료된 것이다.

$ kubectl get nodes 
NAME      STATUS   ROLES    AGE     VERSION
kmaster   Ready    master   9h      v1.18.6
knode     Ready    <none>   5m49s   v1.18.6

$ 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 설치는 스크립트로 제공한다.

$ 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

$ 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 version
version.BuildInfo{Version:"v3.2.4", GitCommit:"0ad800ef43d3b826f31a5ad8dfbb4fe05d143688", GitTreeState:"clean", GoVersion:"go1.13.12"}

1 2	$ helm version version.BuildInfo{Version:"v3.2.4", GitCommit:"0ad800ef43d3b826f31a5ad8dfbb4fe05d143688", GitTreeState:"clean", GoVersion:"go1.13.12"}

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

$ 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 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 를 다음과 같이 다운로드를 한다.

]$ wget https://github.com/kubernetes-sigs/metrics-server/releases/download/v0.3.7/components.yaml

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 를 사용하기 때문에 그냥 설치하면 문제가 된다.

]$ vim components.yaml
....
        args:
          - --cert-dir=/tmp
          - --secure-port=4443
          - --kubelet-insecure-tls
          - --kubelet-preferred-address-types=InternalIP,ExternalIP,Hostname
....

]$ 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 라고 한다.

$ 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

$ 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 가 제대로 되었는지를 살펴보면 된다.

]$ 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

]$ 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분을 기다리면 후에 다음과 같이 자원이 출력이 되는지를 보면 된다.

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

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 등과 같은 자원 현황이 출력이 되면 정상적으로 작동하는 것이다.

04/19/2020

Metric Server 설치하기

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

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

Downloads

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

]$ wget https://github.com/kubernetes-sigs/metrics-server/releases/download/v0.3.6/components.yaml

1	]$ wget https://github.com/kubernetes-sigs/metrics-server/releases/download/v0.3.6/components.yaml

2020.04.19 현 시점에서 v0.3.7 이 있지만 ErrorImagePull 에러가 발생하면서 설치가 진행되지 않는다. 따라서 v0.3.6 으로 설치한다.

TLS 수정

]$ vim components.yaml
....
        args:
          - --cert-dir=/tmp
          - --secure-port=4443
          - --kubelet-insecure-tls
          - --kubelet-preferred-address-types=InternalIP,ExternalIP,Hostname
....

]$ 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 라고 한다.

]$ 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 unchanged
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

]$ 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 unchanged

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 가 제대로 되었는지를 살펴보면 된다.

]$ kubectl get pods -n kube-system
]$ kubectl get deploy -n kube-system

1 2	]$ kubectl get pods -n kube-system ]$ kubectl get deploy -n kube-system

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

]$ kubectl top pods -n kube-system
NAME                                       CPU(cores)   MEMORY(bytes)
calico-kube-controllers-555fc8cc5c-57cj9   2m           6Mi
calico-node-knhlw                          19m          18Mi
calico-node-t6pzp                          19m          40Mi
coredns-66bff467f8-l9tpl                   3m           5Mi
coredns-66bff467f8-sb927                   2m           5Mi
etcd-kmaster                               18m          49Mi
kube-apiserver-kmaster                     36m          304Mi
kube-controller-manager-kmaster            11m          39Mi
kube-proxy-hm94h                           1m           12Mi
kube-proxy-tmjzx                           1m           8Mi
kube-scheduler-kmaster                     4m           11Mi
metrics-server-6cd998ff87-7fq2v            1m           11Mi

]$ kubectl top pods -n kube-system

NAME CPU(cores) MEMORY(bytes)

calico-kube-controllers-555fc8cc5c-57cj9 2m 6Mi

calico-node-knhlw 19m 18Mi

calico-node-t6pzp 19m 40Mi

coredns-66bff467f8-l9tpl 3m 5Mi

coredns-66bff467f8-sb927 2m 5Mi

etcd-kmaster 18m 49Mi

kube-apiserver-kmaster 36m 304Mi

kube-controller-manager-kmaster 11m 39Mi

kube-proxy-hm94h 1m 12Mi

kube-proxy-tmjzx 1m 8Mi

kube-scheduler-kmaster 4m 11Mi

metrics-server-6cd998ff87-7fq2v 1m 11Mi

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

09/01/2019

쿠버네티스(Kubernetes) 개념

쿠버네티스(Kubernetes) 처음 접하면 개념 잡기를 해야 한다. 쿠버네티스를 잘 사용하기 위한 사용법을 익히는것도 중요하지만 개념을 이해하고 나면 외워서 문제해결을 하는 것이 아닌 응용력이 생겨 예기치 않은 장애를 겪을때에 힘을 발휘한다.

개인적으로 쿠버네티스의 개념을 이해하는데 약간의 혼란이 있었다. 개념을 설명하는 용어와 실제 작업을 할때에 사용하는 단어, 명령어들이 다 틀리게 사용되고 있는데서 오는 것이였다.

Master/Worker

다들 알다시피 쿠버네티스는 Master Node와 Work Node 로 구성된다. 대부분 Work Node 가 Master Node 보다 훨씬 많고 대부분의 서비스들이 여기에 배포되어진다.

Node 라는 단어를 빼버리고 단순히 Master/Worker 라고도 하지만 그냥 Master/Node 라고 하기도 하는 모양이다. 하지만 정확하게는 Master Node, Worker Node 라고 불린다.

또, Master Node 를 Controller 라고도 한다. Master 의 역활이 Worker Node 를 모니터링, 감시를 하고 각종 명령어을 Master 가 받아서 처리한다. 이 Master Node 는 거대한 Controller 서버 역할이라고 보면 된다.

kubectl – ResTful API

Master 가 거대한 Controller 서버라면 클라이언트를 이용해서 이 서버에 명령을 보내면 될 것이다. 이 클라이언트가 바로 kubectl 이라는 커맨드가 수행한다. 서버-클라이언트 구조상 서버는 1대지만 클라이언트는 여러대 일 수 있다. 실제로 kubectl 은 단일한 명령어로서 도커(Docker), 컨테이너(Container) 등도 필요없이 동작한다. 그래서 클라이언트는 어느 머신이든지 다 설치/사용이 가능하다.

kubectl 은 클라이언트, Master Node 는 Controller 서버다. 이 둘이 명령어를 주고 받는 방법이 바로 RESTFul API 통신 방법이다.

ResTful API 는 HTTP 를 이요해 URI 에 자원(Resources) 을 명시하고 메소드(Method) 를 이용해 CRUD 연산을 수행한다.

쿠버네티스(Kubernetes) 에서 중요한 것이 바로 자원이다. ResTful API 를 이용해 어떤 작업을 명령할때에 반드시 대상이 필요한데, 이것이 바로 자원이다.

Object, Resource, Kind

쿠버네티스(Kubernetes) 에서 개념을 설명할때에 오브젝트(Object) 라는 말을 쓴다. 오브젝트라고하면 쿠버네티스를 구성요소쯤으로 이해하면 된다. 예를들어 Pods, Service, Volume, Namespace 등은 쿠버네티스의 기본 오브젝트라고 불린다.

문제는 이러한 오브젝트들이 때로는 자원(Resource), 때로는 종류(Kind) 로 불린다.

자원 ResTful API 관점에서 실체적인 존재로서 호출하는 오브젝트들이다. 실제로 kubectl 커맨드를 사용할때에는 ‘오브젝트를 명시한다’ 하지 않고 ‘자원을 명시한다’라고 한다. ResTful API 개념을 차용했기 때문에 ‘자원을 명시한다’라고 해야 맞다.

mint-Desktop:~$ kubectl api-resources
NAME                              SHORTNAMES   APIGROUP                       NAMESPACED   KIND
bindings                                                                      true         Binding
componentstatuses                 cs                                          false        ComponentStatus
configmaps                        cm                                          true         ConfigMap
endpoints                         ep                                          true         Endpoints
events                            ev                                          true         Event
limitranges                       limits                                      true         LimitRange
namespaces                        ns                                          false        Namespace
nodes                             no                                          false        Node
persistentvolumeclaims            pvc                                         true         PersistentVolumeClaim
persistentvolumes                 pv                                          false        PersistentVolume
pods                              po                                          true         Pod
podtemplates                                                                  true         PodTemplate
replicationcontrollers            rc                                          true         ReplicationController
resourcequotas                    quota                                       true         ResourceQuota
secrets                                                                       true         Secret
serviceaccounts                   sa                                          true         ServiceAccount
services                          svc                                         true         Service
mutatingwebhookconfigurations                  admissionregistration.k8s.io   false        MutatingWebhookConfiguration
validatingwebhookconfigurations                admissionregistration.k8s.io   false        ValidatingWebhookConfiguration
customresourcedefinitions         crd,crds     apiextensions.k8s.io           false        CustomResourceDefinition
apiservices                                    apiregistration.k8s.io         false        APIService
controllerrevisions                            apps                           true         ControllerRevision
daemonsets                        ds           apps                           true         DaemonSet
deployments                       deploy       apps                           true         Deployment
replicasets                       rs           apps                           true         ReplicaSet
statefulsets                      sts          apps                           true         StatefulSet
tokenreviews                                   authentication.k8s.io          false        TokenReview

mint-Desktop:~$ kubectl api-resources

NAME SHORTNAMES APIGROUP NAMESPACED KIND

bindings true Binding

componentstatuses cs false ComponentStatus

configmaps cm true ConfigMap

endpoints ep true Endpoints

events ev true Event

limitranges limits true LimitRange

namespaces ns false Namespace

nodes no false Node

persistentvolumeclaims pvc true PersistentVolumeClaim

persistentvolumes pv false PersistentVolume

pods po true Pod

podtemplates true PodTemplate

replicationcontrollers rc true ReplicationController

resourcequotas quota true ResourceQuota

secrets true Secret

serviceaccounts sa true ServiceAccount

services svc true Service

mutatingwebhookconfigurations admissionregistration.k8s.io false MutatingWebhookConfiguration

validatingwebhookconfigurations admissionregistration.k8s.io false ValidatingWebhookConfiguration

customresourcedefinitions crd,crds apiextensions.k8s.io false CustomResourceDefinition

apiservices apiregistration.k8s.io false APIService

controllerrevisions apps true ControllerRevision

daemonsets ds apps true DaemonSet

deployments deploy apps true Deployment

replicasets rs apps true ReplicaSet

statefulsets sts apps true StatefulSet

tokenreviews authentication.k8s.io false TokenReview

위 결과를 보면 자원(Resource) 목록에서 오브젝트들도 볼 수 있다. 물론 오브젝트는 개념화된 추상적 그야말로 개념이고 자원을 실체적인 대상으로서 차이를 보이지만 이들에 명명된 말이 모두 같다. 맨 오른쪽에 KIND 도 보인다.

종류(Kind) 는 보통 Pods 를 생성하거나 업데이트를 하기위한 매니페스트(Manifest) 파일 작성시에 사용된다. 종류(Kind)는 쿠버네티스 자원 종류를 말한다. 매니페스트 파일은 JSON, YAML 포맷형태인데 예를들면 다음과 같다.

apiVersion: v1
kind: Pod
metadata:
  name: nginx

apiVersion: v1

kind: Pod

metadata:

kind: Pod 라는 것이 보인다. 매니페스트 파일에서 자원이라고 하면 그야말로 컨테이너가 사용할 컴퓨터 하드웨어 자원을 말한다. 그래서 Resource:Pod 라고 한다면 문제가 되니까 Kind 라는 것으로 바꾼거 짐작이 된다.

이 kind 가 궁금하다면 ‘kubectl api-resources’ 명령어를 호출하면 자원에 붙여진 kind 를 볼 수 있다.

어느 방향으로 이해하느냐가 관건

쿠버네티스가 다루는 자원의 방향으로 접근해 이해하는 것도 괜찮다. 아니면 추상화 개념으로서 개념을 이해하고 가는것도 괜찮다.

다만, 완전히 추상적인 개념과 실제적인 대상을 구분하고 연결짓는 것이 머리속에 체계적으로 저장하는 방법이 될 수 있다.

08/31/2019

kubectl 원격 접속 설정

kubectl 은 Kubernetes Client 이다. 이 명령어는 HTTP 통신을 기반으로 Kubernetes Controller 와 RestFul API 통신을 요청하고 결과를 받아 사용자에게 출력하게 하는 역할을 한다.

HTTP RESTFUL API 통신을 한다는 말을 듣는 순간 직감했겠지만 인터넷만 된다면 kubectl 은 어느 컴퓨터에서든 실행이 가능하다. 처음 Kubernetes 설치문서들을 보면 대부분 Master Node 에서 실행되도록 설정을 하는데, 여기서는 다른 컴퓨터에서 kubectl 만 설치해서 Kubernetes Controller 와 연결하는 방법에 대해서 살펴보도록 할 것이다.

설치환경

설치 환경은 Mint Linux 19.2 – XFCE4 환경에서 진행했다. kubectl 를 실행하는 환경는 다양하겠지만 제일 편한 것으로는 Unix 환경일 것이다. Mac OS X, Linux 가 가장 적합한데, 필자는 Mint Linux 19.2 – XFCE4 데스크탑을 사용하고 있음으로해서 이 환경에서 진행하게 됐다.

Mint Linux 19.2 는 Ubuntu 기반이기 때문에 Ubuntu 에서 설치, 설정 모두 동일하다고 생각하면 된다.

kubectl 설치하기

Mint Linux 19/2 에서 설치하는 방법은 Ubuntu 에서 설치하기와 동일하다. 단, 여기서는 kubectl 패키지만 설치하면 된다. root 계정으로 다음과 같이 한다.

mint-Desktop:~# sudo apt install \
    apt-transport-https \
    ca-certificates \
    curl \
    gnupg-agent \
    software-properties-common
mint-Desktop:~# curl -s https://packages.cloud.google.com/apt/doc/apt-key.gpg | apt-key add -
mint-Desktop:~# apt-add-repository "deb http://apt.kubernetes.io/ kubernetes-xenial main"
mint-Desktop:~# apt clean all
mint-Desktop:~# apt update
mint-Desktop:~# apt install kubectl

mint-Desktop:~# sudo apt install \

apt-transport-https \

ca-certificates \

curl \

gnupg-agent \

software-properties-common

mint-Desktop:~# curl -s https://packages.cloud.google.com/apt/doc/apt-key.gpg | apt-key add -

mint-Desktop:~# apt-add-repository "deb http://apt.kubernetes.io/ kubernetes-xenial main"

mint-Desktop:~# apt clean all

mint-Desktop:~# apt update

mint-Desktop:~# apt install kubectl

설치는 별다른 이상이 없는한 문제 없이 진행된다.

kubectl 설정하기

kubectl 명령은 일반계정으로 사용하길 권고 하기 있다. kubectl 은 일반 계정에서 .kube/config 파일을 참조한다. 파일의 내용을 볼수도 있지만 다음과 같이 명령어로도 같단히 확인할 수 있다.

kmaster:~/.kube$ kubectl config view 
apiVersion: v1
clusters:
- cluster:
    certificate-authority-data: DATA+OMITTED
    server: https://192.168.96.14:6443
  name: kubernetes
contexts:
- context:
    cluster: kubernetes
    user: kubernetes-admin
  name: kubernetes-admin@kubernetes
current-context: kubernetes-admin@kubernetes
kind: Config
preferences: {}
users:
- name: kubernetes-admin
  user:
    client-certificate-data: REDACTED
    client-key-data: REDACTED

kmaster:~/.kube$ kubectl config view

apiVersion: v1

clusters:

- cluster:

certificate-authority-data: DATA+OMITTED

server: https://192.168.96.14:6443

contexts:

- context:

cluster: kubernetes

user: kubernetes-admin

current-context: kubernetes-admin@kubernetes

kind: Config

preferences: {}

users:

- name: kubernetes-admin

user:

client-certificate-data: REDACTED

client-key-data: REDACTED

config 설정을 kubectl config 명령어를 통해서 가능하지만 복잡해 보인다. 손쉬운 방법을 찾게 되는데, 그 방법은 바로 Master Node 를 초기화 할때에 나오는 것을 참고하면 된다.

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

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

Master Node 초기화 때 나오는 출력에 설정관련 내용이 나온다. Master Node 에서 Mint Linux 19.2 에 일반계정으로 config 를 복사해보자.

mint-Desktop:~$ mkdir .kube
mint-Desktop:~$ cd .kube
mint-Desktop:~$ scp systemv@192.168.96.14:./.kube/config .
mint-Desktop:~$ systemv@192.168.96.14's password: 
config

mint-Desktop:~$ mkdir .kube

mint-Desktop:~$ cd .kube

mint-Desktop:~$ scp systemv@192.168.96.14:./.kube/config .

mint-Desktop:~$ systemv@192.168.96.14's password:

config

이렇게 한 후에 다음과 같이 샘플 명령어를 쳤을때에 나오면 정상이다.

mint-Desktop:~$ kubectl get nodes
NAME      STATUS   ROLES    AGE   VERSION
kmaster   Ready    master   44h   v1.15.3
knode     Ready    <none>   44h   v1.15.3

mint-Desktop:~$ kubectl get nodes

NAME STATUS ROLES AGE VERSION

kmaster Ready master 44h v1.15.3

knode Ready <none> 44h v1.15.3

08/29/2019

Kubernetes 설치

Kubernetes 설치에 대해서 다룬다. 설치를 위한 환경은 다음과 같다.

Master
- Distribution: Ubuntu 18.04
- IP: 192.168.96.14
- hostname: kmaster
- account: systemv
Worker Node
- Distribution: CentOS 7
- IP: 192.168.96.15
- hostname: knode
- account: systemv
CNI: Flannel

공통 설정 부분

sudo 권한 추가

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

]# usermod -aG wheel systemv

1	]# usermod -aG wheel systemv

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

Ubuntu 18.04 에서는 다음과 같이 일반계정을 sudo 권한을 줄 수 있다.

]# usermode -aG sudo systemv

1	]# usermode -aG sudo systemv

br_netfilter 모듈 로딩

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

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

]$ sudo vim /etc/modules-load.d/br_netfilter.conf
# Load br_netfilter.ko at boot
br_netfilter
]$ sudo systemctl restart  systemd-modules-load.service

]$ sudo vim /etc/modules-load.d/br_netfilter.conf

# Load br_netfilter.ko at boot

br_netfilter

]$ sudo systemctl restart systemd-modules-load.service

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

커널 네트워크 파라메터

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

]# 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

]# 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 파일에 각 서버 정보를 다음과 같이 입력해준다.

]# vim /etc/hosts
192.168.96.14  kmaster
192.168.96.15  knode

]# vim /etc/hosts

192.168.96.14 kmaster

192.168.96.15 knode

swap off 설정

양쪽 모두 swap 을 off 해준다.

]# swapoff -a

1	]# swapoff -a

그리고 반드시 /etc/fstab 에서 swap 관련 마운트 설정을 주석처리 해준다.

CentOS 7 에서 설정

SELinux off

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

]# setenforce 0
]# sed -i 's/^SELINUX=enforcing$/SELINUX=permissive/' /etc/selinux/config

1 2	]# setenforce 0 ]# sed -i 's/^SELINUX=enforcing$/SELINUX=permissive/' /etc/selinux/config

firewalld 비활성화

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

]# systemctl stop firewalld
]# systemctl disable firewalld

1 2	]# systemctl stop firewalld ]# systemctl disable firewalld

패키지 설치

sudo yum install -y yum-utils \
  device-mapper-persistent-data \
  lvm2

sudo yum install -y yum-utils \

device-mapper-persistent-data \

lvm2

Ubuntu 에서 설정

패키지 설치

]$ sudo apt-get install \
    apt-transport-https \
    ca-certificates \
    curl \
    gnupg-agent \
    software-properties-common

]$ sudo apt-get install \

apt-transport-https \

ca-certificates \

curl \

gnupg-agent \

software-properties-common

Docker 설치 및 설정

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

Docker Installation

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

ubuntu 18.04

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

]#curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add -
]# sudo add-apt-repository \
   "deb [arch=amd64] https://download.docker.com/linux/ubuntu \
   $(lsb_release -cs) \
   stable"

]#curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add -

]# sudo add-apt-repository \

"deb [arch=amd64] https://download.docker.com/linux/ubuntu \

$(lsb_release -cs) \

stable"

하지만 파일을 추가하는 방법으로 가능하다.

]# curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add -
]# cat <<EOF >/etc/apt/sources.list.d/docker.list
deb [arch=amd64] https://download.docker.com/linux/ubuntu bionic stable
EOF
]# apt update

]# curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add -

]# cat <<EOF >/etc/apt/sources.list.d/docker.list

deb [arch=amd64] https://download.docker.com/linux/ubuntu bionic stable

EOF

]# apt update

CentOS 7

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

]$ sudo yum-config-manager \
    --add-repo \
    https://download.docker.com/linux/centos/docker-ce.repo

]$ sudo yum-config-manager \

--add-repo \

https://download.docker.com/linux/centos/docker-ce.repo

다음과 같이 파일을 추가하는 방법도 있다.

Cgroup driver 설정

]# cat > /etc/docker/daemon.json <<EOF	 
{
 "exec-opts": ["native.cgroupdriver=systemd"],
 "log-driver": "json-file",
 "log-opts": {
 "max-size": "100m"
 },
 "storage-driver": "overlay2"
}
EOF
]# systemctl daemon-reload
]# systemctl restart docker

]# cat > /etc/docker/daemon.json <<EOF

{

"exec-opts": ["native.cgroupdriver=systemd"],

"log-driver": "json-file",

"log-opts": {

"max-size": "100m"

"storage-driver": "overlay2"

}

EOF

]# systemctl daemon-reload

]# systemctl restart docker

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

]$ docker info	 	 
Logging Driver: json-file	 	 
 Cgroup Driver: systemd	 	 
 Plugins:

]$ docker info

Logging Driver: json-file

Cgroup Driver: systemd

Plugins:

Kubernetes 설치

Ubuntu 18.04

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

]# curl -s https://packages.cloud.google.com/apt/doc/apt-key.gpg | apt-key add -
]# cat <<EOF >/etc/apt/sources.list.d/kubernetes.list
deb http://apt.kubernetes.io/ kubernetes-xenial main
EOF

]# #혹은 다음과 같이 해도 된다.

]# 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"

]# curl -s https://packages.cloud.google.com/apt/doc/apt-key.gpg | apt-key add -

]# cat <<EOF >/etc/apt/sources.list.d/kubernetes.list

deb http://apt.kubernetes.io/ kubernetes-xenial main

EOF

]# #혹은 다음과 같이 해도 된다.

]# 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"

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

]# apt install -y kubelet kubeadm kubectl

1	]# apt install -y kubelet kubeadm kubectl

CentOS 7

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

]# 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
]# yum install -y kubelet kubeadm kubectl --disableexcludes=kubernetes
]# systemctl enable --now kubelet

]# 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

]# yum install -y kubelet kubeadm kubectl --disableexcludes=kubernetes

]# systemctl enable --now kubelet

Master 설정

Master 를 만드는 것은 kubeadm 을 이용한다. 일반 계정으로 실행 한다.

]$ sudo kubeadm init --apiserver-advertise-address=192.168.96.14 --pod-network-cidr=172.16.0.0/16
....
....
[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.14:6443 --token 8mqysq.yb19ta1xl8ir9dkp \
    --discovery-token-ca-cert-hash sha256:03d65b22ec96af5a71801d923bc878b449bb3d8d10d632bced5d35878a9e02c3

]$ sudo kubeadm init --apiserver-advertise-address=192.168.96.14 --pod-network-cidr=172.16.0.0/16

....

[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.14:6443 --token 8mqysq.yb19ta1xl8ir9dkp \

--discovery-token-ca-cert-hash sha256:03d65b22ec96af5a71801d923bc878b449bb3d8d10d632bced5d35878a9e02c3

Kubernetes Master 명령은 전부 일반계정으로 하도록 되어 있는데, 위 출력에 나온대로 설정을 해준다.

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

]$ mkdir -p $HOME/.kube

]$ sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config

]$ sudo chown $(id -u):$(id -g) $HOME/.kube/config

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

systemv@kmaster:~$ kubectl get nodes
NAME      STATUS     ROLES    AGE     VERSION
kmaster   NotReady   master   3m53s   v1.15.3
systemv@kmaster:~$ kubectl get pods -o wide --all-namespaces
NAMESPACE     NAME                              READY   STATUS    RESTARTS   AGE     IP              NODE      NOMINATED NODE   READINESS GATES
kube-system   coredns-5c98db65d4-54qmn          0/1     Pending   0          3m51s   <none>          <none>    <none>           <none>
kube-system   coredns-5c98db65d4-sms7m          0/1     Pending   0          3m51s   <none>          <none>    <none>           <none>
kube-system   etcd-kmaster                      1/1     Running   0          2m44s   192.168.96.14   kmaster   <none>           <none>
kube-system   kube-apiserver-kmaster            1/1     Running   0          3m1s    192.168.96.14   kmaster   <none>           <none>
kube-system   kube-controller-manager-kmaster   1/1     Running   0          2m43s   192.168.96.14   kmaster   <none>           <none>
kube-system   kube-proxy-vtwbg                  1/1     Running   0          3m52s   192.168.96.14   kmaster   <none>           <none>
kube-system   kube-scheduler-kmaster            1/1     Running   0          2m53s   192.168.96.14   kmaster   <none>           <none>

systemv@kmaster:~$ kubectl get nodes

NAME STATUS ROLES AGE VERSION

kmaster NotReady master 3m53s v1.15.3

systemv@kmaster:~$ kubectl get pods -o wide --all-namespaces

NAMESPACE NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES

kube-system coredns-5c98db65d4-54qmn 0/1 Pending 0 3m51s <none> <none> <none> <none>

kube-system coredns-5c98db65d4-sms7m 0/1 Pending 0 3m51s <none> <none> <none> <none>

kube-system etcd-kmaster 1/1 Running 0 2m44s 192.168.96.14 kmaster <none> <none>

kube-system kube-apiserver-kmaster 1/1 Running 0 3m1s 192.168.96.14 kmaster <none> <none>

kube-system kube-controller-manager-kmaster 1/1 Running 0 2m43s 192.168.96.14 kmaster <none> <none>

kube-system kube-proxy-vtwbg 1/1 Running 0 3m52s 192.168.96.14 kmaster <none> <none>

kube-system kube-scheduler-kmaster 1/1 Running 0 2m53s 192.168.96.14 kmaster <none> <none>

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

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

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: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) 를 필요로 한다.

Flannel 설치

CNI 중에 Flannel 을 이용하려고 한다. 다음과 같이 설치를 해준다.

]$ sudo kubectl apply -f https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel.yml

1	]$ sudo kubectl apply -f https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel.yml

설치를 하고 기다리면 다음과 같이 오류가 발생한다.

systemv@kmaster:~$ kubectl get pods --all-namespaces
NAMESPACE     NAME                              READY   STATUS              RESTARTS   AGE
kube-system   coredns-5c98db65d4-54qmn          0/1     Pending             0          13m
kube-system   coredns-5c98db65d4-sms7m          0/1     Pending             0          13m
kube-system   etcd-kmaster                      1/1     Running             0          12m
kube-system   kube-apiserver-kmaster            1/1     Running             0          12m
kube-system   kube-controller-manager-kmaster   1/1     Running             0          12m
kube-system   kube-flannel-ds-amd64-fhxzj       0/1     Init:ErrImagePull   0          67s
kube-system   kube-proxy-vtwbg                  1/1     Running             0          13m
kube-system   kube-scheduler-kmaster            1/1     Running             0          12m

systemv@kmaster:~$ kubectl get pods --all-namespaces

NAMESPACE NAME READY STATUS RESTARTS AGE

kube-system coredns-5c98db65d4-54qmn 0/1 Pending 0 13m

kube-system coredns-5c98db65d4-sms7m 0/1 Pending 0 13m

kube-system etcd-kmaster 1/1 Running 0 12m

kube-system kube-apiserver-kmaster 1/1 Running 0 12m

kube-system kube-controller-manager-kmaster 1/1 Running 0 12m

kube-system kube-flannel-ds-amd64-fhxzj 0/1 Init:ErrImagePull 0 67s

kube-system kube-proxy-vtwbg 1/1 Running 0 13m

kube-system kube-scheduler-kmaster 1/1 Running 0 12m

잠깐 시간을 주고 기달리면 모두 Running 상태가 된다. 만일 오랜 시간이 지나도 Running 이 아니라면 kubelet 을 재시작 해준다.

]$ sudo systemctl restart kubelet.service

1	]$ sudo systemctl restart kubelet.service

Kubelet cgroup driver 교체

혹시나 kubelet 의 cgroup driver 를 교체 해줘야 한다면 다음의 파일을 열어서 드라이버를 교체 해주면 된다.

]# vim /var/lib/kubelet/kubeadm-flags.env
KUBELET_KUBEADM_ARGS="--cgroup-driver=systemd

1 2	]# vim /var/lib/kubelet/kubeadm-flags.env KUBELET_KUBEADM_ARGS="--cgroup-driver=systemd