Docker Desktop for Windows 기반의 Kubernetes 구성 (2) - WSL 2 인스턴스에 kind가 구성한 k8s 서비스 위치
지난 글에서 다룬 DockerDesktopVM의 경우,
Docker Desktop for Windows에서 DockerDesktopVM 기반의 Kubernetes 구성 (2) - k8s 서비스 위치
; https://www.sysnet.pe.kr/2/0/12576
k8s 관련 서비스를 Linux VM에 프로세스로 모두 올렸습니다. 반면, WSL 2 인스턴스에
kind로 k8s 환경을 구성하면 k8s 관련 서비스는 모두 (WSL 2 환경의 프로세스가 아닌) docker의 컨테이너로 실행이 됩니다. ("Kubernetes IN Docker"의 약자가 바로 kind입니다.)
아래의 결과는 클러스터를
WSL 2와 윈도우 호스트에서 각각 생성해 2개가 있는 것을 보여줍니다.
$ docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
62cd9120f957 kindest/node:v1.20.2 "/usr/local/bin/entr…" 36 hours ago Up 36 hours 127.0.0.1:20971->6443/tcp cluster2-control-plane
cbe98f7a0748 kindest/node:v1.20.2 "/usr/local/bin/entr…" 2 days ago Up 2 days 127.0.0.1:45381->6443/tcp cluster1-control-plane
그리고 그중의 하나를 들어가 보면,
/* cluster2를 호스팅하고 있는 docker 컨테이너 */
$ docker exec -it 62cd9120f957 /bin/bash
/* cluster1을 호스팅하고 있는 docker 컨테이너 */
$ docker exec -it cbe98f7a0748 /bin/bash
다음과 같이 해당 컨테이너에 k8s 관련 서비스들이 올라간 것을 확인할 수 있습니다.
root@cluster2-control-plane:/# ps -aux | grep kube
root 698 2.6 0.1 766528 98936 ? Ssl Mar24 58:53 kube-controller-manager --allocate-node-cidrs=true --authentication-kubeconfig=/etc/kubernetes/controller-manager.conf --authorization-kubeconfig=/etc/kubernetes/controller-manager.conf --bind-address=127.0.0.1 --client-ca-file=/etc/kubernetes/pki/ca.crt --cluster-cidr=10.244.0.0/16 --cluster-name=cluster2 --cluster-signing-cert-file=/etc/kubernetes/pki/ca.crt --cluster-signing-key-file=/etc/kubernetes/pki/ca.key --controllers=*,bootstrapsigner,tokencleaner --enable-hostpath-provisioner=true --kubeconfig=/etc/kubernetes/controller-manager.conf --leader-elect=true --port=0 --requestheader-client-ca-file=/etc/kubernetes/pki/front-proxy-ca.crt --root-ca-file=/etc/kubernetes/pki/ca.crt --service-account-private-key-file=/etc/kubernetes/pki/sa.key --service-cluster-ip-range=10.96.0.0/16 --use-service-account-credentials=true
root 710 0.3 0.1 750928 56900 ? Ssl Mar24 8:06 kube-scheduler --authentication-kubeconfig=/etc/kubernetes/scheduler.conf --authorization-kubeconfig=/etc/kubernetes/scheduler.conf --bind-address=127.0.0.1 --kubeconfig=/etc/kubernetes/scheduler.conf --leader-elect=true --port=0
root 717 7.2 0.6 1048596 352668 ? Ssl Mar24 159:10 kube-apiserver --advertise-address=172.18.0.4 --allow-privileged=true --authorization-mode=Node,RBAC --client-ca-file=/etc/kubernetes/pki/ca.crt --enable-admission-plugins=NodeRestriction --enable-bootstrap-token-auth=true --etcd-cafile=/etc/kubernetes/pki/etcd/ca.crt --etcd-certfile=/etc/kubernetes/pki/apiserver-etcd-client.crt --etcd-keyfile=/etc/kubernetes/pki/apiserver-etcd-client.key --etcd-servers=https://127.0.0.1:2379 --insecure-port=0 --kubelet-client-certificate=/etc/kubernetes/pki/apiserver-kubelet-client.crt --kubelet-client-key=/etc/kubernetes/pki/apiserver-kubelet-client.key --kubelet-preferred-address-types=InternalIP,ExternalIP,Hostname --proxy-client-cert-file=/etc/kubernetes/pki/front-proxy-client.crt --proxy-client-key-file=/etc/kubernetes/pki/front-proxy-client.key --requestheader-allowed-names=front-proxy-client --requestheader-client-ca-file=/etc/kubernetes/pki/front-proxy-ca.crt --requestheader-extra-headers-prefix=X-Remote-Extra- --requestheader-group-headers=X-Remote-Group --requestheader-username-headers=X-Remote-User --runtime-config= --secure-port=6443 --service-account-issuer=https://kubernetes.default.svc.cluster.local --service-account-key-file=/etc/kubernetes/pki/sa.pub --service-account-signing-key-file=/etc/kubernetes/pki/sa.key --service-cluster-ip-range=10.96.0.0/16 --tls-cert-file=/etc/kubernetes/pki/apiserver.crt --tls-private-key-file=/etc/kubernetes/pki/apiserver.key
root 810 2.8 0.1 10615796 73696 ? Ssl Mar24 62:07 etcd --advertise-client-urls=https://172.18.0.4:2379 --cert-file=/etc/kubernetes/pki/etcd/server.crt --client-cert-auth=true --data-dir=/var/lib/etcd --initial-advertise-peer-urls=https://172.18.0.4:2380 --initial-cluster=cluster2-control-plane=https://172.18.0.4:2380 --key-file=/etc/kubernetes/pki/etcd/server.key --listen-client-urls=https://127.0.0.1:2379,https://172.18.0.4:2379 --listen-metrics-urls=http://127.0.0.1:2381 --listen-peer-urls=https://172.18.0.4:2380 --name=cluster2-control-plane --peer-cert-file=/etc/kubernetes/pki/etcd/peer.crt --peer-client-cert-auth=true --peer-key-file=/etc/kubernetes/pki/etcd/peer.key --peer-trusted-ca-file=/etc/kubernetes/pki/etcd/ca.crt --snapshot-count=10000 --trusted-ca-file=/etc/kubernetes/pki/etcd/ca.crt
root 883 3.1 0.1 2763536 101264 ? Ssl Mar24 69:00 /usr/bin/kubelet --bootstrap-kubeconfig=/etc/kubernetes/bootstrap-kubelet.conf --kubeconfig=/etc/kubernetes/kubelet.conf --config=/var/lib/kubelet/config.yaml --container-runtime=remote --container-runtime-endpoint=unix:///run/containerd/containerd.sock --fail-swap-on=false --node-ip=172.18.0.4 --provider-id=kind://docker/cluster2/cluster2-control-plane --fail-swap-on=false --cgroup-root=/kubelet
root 1168 0.0 0.0 746368 46892 ? Ssl Mar24 0:30 /usr/local/bin/kube-proxy --config=/var/lib/kube-proxy/config.conf --hostname-override=cluster2-control-plane
root 252656 0.0 0.0 3276 816 pts/1 S+ 14:30 0:00 ...[생략]...
마찬가지로
관련 포트와,
root@cluster2-control-plane:/# apt-get update
root@cluster2-control-plane:/# apt-get upgrade -y
root@cluster2-control-plane:/# apt-get install net-tools
root@cluster2-control-plane:/# apt-get install inetutils-ping
root@cluster2-control-plane:/# netstat -atp | grep LISTEN
tcp 0 0 localhost:10248 0.0.0.0:* LISTEN 883/kubelet
tcp 0 0 localhost:10249 0.0.0.0:* LISTEN 1168/kube-proxy
tcp 0 0 cluster2-control-p:2379 0.0.0.0:* LISTEN 810/etcd
tcp 0 0 localhost:2379 0.0.0.0:* LISTEN 810/etcd
tcp 0 0 cluster2-control-p:2380 0.0.0.0:* LISTEN 810/etcd
tcp 0 0 localhost:2381 0.0.0.0:* LISTEN 810/etcd
tcp 0 0 127.0.0.11:36687 0.0.0.0:* LISTEN -
tcp 0 0 localhost:10257 0.0.0.0:* LISTEN 698/kube-controller
tcp 0 0 localhost:34097 0.0.0.0:* LISTEN 176/containerd
tcp 0 0 localhost:10259 0.0.0.0:* LISTEN 710/kube-scheduler
tcp6 0 0 [::]:10250 [::]:* LISTEN 883/kubelet
tcp6 0 0 [::]:6443 [::]:* LISTEN 717/kube-apiserver
tcp6 0 0 [::]:10256 [::]:* LISTEN 1168/kube-proxy
바이너리 파일 및,
root@cluster2-control-plane:/# ls /usr/bin/kube* -l
-rwxr-xr-x 1 root root 39206912 Jan 21 01:10 /usr/bin/kubeadm
-rwxr-xr-x 1 root root 40218624 Jan 21 01:10 /usr/bin/kubectl
-rwxr-xr-x 1 root root 61075784 Jan 21 01:10 /usr/bin/kubelet
인증서 위치까지 확인할 수 있습니다.
root@cluster2-control-plane:/# ls /etc/kubernetes/pki -l
total 60
-rw-r--r-- 1 root root 1135 Mar 24 02:04 apiserver-etcd-client.crt
-rw------- 1 root root 1679 Mar 24 02:04 apiserver-etcd-client.key
-rw-r--r-- 1 root root 1143 Mar 24 02:04 apiserver-kubelet-client.crt
-rw------- 1 root root 1679 Mar 24 02:04 apiserver-kubelet-client.key
-rw-r--r-- 1 root root 1310 Mar 24 02:04 apiserver.crt
-rw------- 1 root root 1679 Mar 24 02:04 apiserver.key
-rw-r--r-- 1 root root 1066 Mar 24 02:04 ca.crt
-rw------- 1 root root 1679 Mar 24 02:04 ca.key
drwxr-xr-x 2 root root 4096 Mar 24 02:04 etcd
-rw-r--r-- 1 root root 1078 Mar 24 02:04 front-proxy-ca.crt
-rw------- 1 root root 1675 Mar 24 02:04 front-proxy-ca.key
-rw-r--r-- 1 root root 1103 Mar 24 02:04 front-proxy-client.crt
-rw------- 1 root root 1679 Mar 24 02:04 front-proxy-client.key
-rw------- 1 root root 1679 Mar 24 02:04 sa.key
-rw------- 1 root root 451 Mar 24 02:04 sa.pub
인증서의 경우 한 가지 유의해야 할 점은, 여기 있는 인증서가 "Docker Desktop for Windows"가 가진 "%LOCALAPPDATA%\Docker\pki" 인증서와는 다르다는 점입니다.
DockerDesktopVM의 경우에는 "%LOCALAPPDATA%\Docker\pki" 인증서가 사용되었지만, kind는 이 위치의 인증서를 사용하지 않고, 독자적으로 클러스터마다 새로운 인증서를 구성합니다. (그럴 수밖에 없는 것이, kind의 입장에서는 docker가 구성된 환경이 중요한 것이지, 그것이 "Docker Desktop"으로 설치되었는지에 대해서는 고려하지 않습니다.)
DockerDesktopVM의 신비로운 네트워크 구성과는 달리, WSL 2의 경우에는 네트워크 구성이 잘 해석이 됩니다. 우선 WSL 2 고유의 네트워크 동작을 기반으로,
WSL 2의 네트워크 통신 방법
; https://www.sysnet.pe.kr/2/0/12347
kind는 k8s 관련 서비스를 docker 컨테이너 내에서 호스팅하기 때문에 컨테이너의 포트 매핑이 각각의 클러스터를 담당하는 k8s의 API 서버가 열고 있는 6443 포트로 향하고 있습니다.
/* C:\temp> docker ps */
$ docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
62cd9120f957 kindest/node:v1.20.2 "/usr/local/bin/entr…" 37 hours ago Up 37 hours 127.0.0.1:20971->6443/tcp cluster2-control-plane
cbe98f7a0748 kindest/node:v1.20.2 "/usr/local/bin/entr…" 2 days ago Up 2 days 127.0.0.1:45381->6443/tcp cluster1-control-plane
/* C:\temp> netstat -ano | findstr "20971 or 45381"
Proto Local Address Foreign Address State PID
TCP 127.0.0.1:20971 0.0.0.0:0 LISTENING 34208
TCP 127.0.0.1:45381 0.0.0.0:0 LISTENING 34208 */
$ sudo netstat -atp
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 localhost:45381 0.0.0.0:* LISTEN -
tcp 0 0 localhost:20971 0.0.0.0:* LISTEN -
또한 k8s 클러스터를 호스팅하는 컨테이너는 bridge 네트워크 유형으로 묶여 있습니다.
$ docker inspect 62cd9120f957 | grep NetworkID
"NetworkID": "7a0c4ee0661f2453159c25a2d4d28eabecfc6fc4bbc6e0f56c342d73a0e7ff05",
$ docker inspect cbe98f7a0748 | grep NetworkID
"NetworkID": "7a0c4ee0661f2453159c25a2d4d28eabecfc6fc4bbc6e0f56c342d73a0e7ff05",
$ docker network ls
NETWORK ID NAME DRIVER SCOPE
bdecc2f99649 bridge bridge local
6da0d557ef3c host host local
7a0c4ee0661f kind bridge local
6da27dbdfbb2 none null local
$ docker network inspect 7a0c4ee0661f
[
{
"Name": "kind",
"Id": "7a0c4ee0661f2453159c25a2d4d28eabecfc6fc4bbc6e0f56c342d73a0e7ff05",
...[생략]...
"Config": [
{
"Subnet": "172.18.0.0/16",
"Gateway": "172.18.0.1"
},
...[생략]...
]
},
...[생략]...
"Containers": {
"62cd9120f9578c9f7657bec5a544d3e851e487bacb6dbbbe060cae6f083a57e0": {
"Name": "cluster2-control-plane",
"EndpointID": "0b2f47d71cda265034f10a33afbed196c54cbe0603d679e530169255fc09cc64",
"MacAddress": "02:42:ac:12:00:04",
"IPv4Address": "172.18.0.4/16",
"IPv6Address": "fc00:f853:ccd:e793::4/64"
},
"cbe98f7a07488228482dcf6290a97912c1f67408b2eb457b7e1f32dfbf99695a": {
"Name": "cluster1-control-plane",
"EndpointID": "17445acec44cba5fb794ff3ea8d718d429a982dcc2799adb234148d5ea268d19",
"MacAddress": "02:42:ac:12:00:02",
"IPv4Address": "172.18.0.2/16",
"IPv6Address": "fc00:f853:ccd:e793::2/64"
}
},
"Options": {
"com.docker.network.bridge.enable_ip_masquerade": "true"
},
"Labels": {}
}
]
참고로
지난 글에서 kind로 구성한 k8s 클러스터에 만든 서비스(예를 들어 nginx)의 경우,
$ kubectl get pods
NAME READY STATUS RESTARTS AGE
nginx-app 1/1 Running 0 38h
$ kubectl get svc
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
kubernetes ClusterIP 10.96.0.1 <none> 443/TCP 2d11h
nginx-app NodePort 10.96.5.127 <none> 80:30518/TCP 38h
$ sudo netstat -atp
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 localhost:45381 0.0.0.0:* LISTEN -
tcp 0 0 localhost:20971 0.0.0.0:* LISTEN -
WSL 2 인스턴스나 윈도우 호스트 측에서 curl로 테스트할 때 접속이 안 된다고 했었습니다.
$ curl http://localhost:30518
curl: (7) Failed to connect to localhost port 30518: Connection refused
저도 아직 이 분야에 초보자라 확실한 것은 아니지만, kind는 k8s 클러스터를 docker의 컨테이너로 구성하면서, 그 k8s 클러스터에서 만드는 컨테이너들도 함께 내부에서 활성화시키는 듯합니다. (즉, "kubectl run ..."은 WSL 2 측의 docker에 컨테이너를 생성하지 않습니다.)
그렇기 때문에 kind가 만든 k8s 클러스터를 호스팅하는 컨테이너 내부로 들어가면 다음과 같이 curl 접속 테스트를 할 수 있습니다.
$ docker exec -it cbe98f7a0748 /bin/bash
root@cluster2-control-plane:/# netstat -atp | grep 30518
tcp 0 0 0.0.0.0:30518 0.0.0.0:* LISTEN 1145/kube-proxy
root@cluster1-control-plane:/# curl http://localhost:30518
<!DOCTYPE html>
<html>
<head>
...[생략]...
<p><em>Thank you for using nginx.</em></p>
</body>
</html>
그러니까, 결국 외부에서도 curl 접근을 하고 싶다면 kind가 만든 클러스터의 docker 컨테이너에 포트 매핑을 시켜 줘야 하는 것입니다. 바로 그 방법이 kind의 클러스터 생성 yml 파일에 containerPort를 지정하는 것이고,
# cluster-config.yml
kind: Cluster
name: cluster3
apiVersion: kind.x-k8s.io/v1alpha4
nodes:
- role: control-plane
extraPortMappings:
- containerPort: 30000
hostPort: 30001
protocol: TCP
c:\temp> kind create cluster --config=cluster-config.yml
kind는 이제 docker에 만드는 k8s 클러스터 용 컨테이너에 포트 매핑을 추가합니다.
C:\temp\wsl2> docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
c097c752c6cf kindest/node:v1.20.2 "/usr/local/bin/entr…" About a minute ago Up About a minute 0.0.0.0:30001->30000/tcp, 127.0.0.1:8876->6443/tcp cluster3-control-plane
C:\temp\wsl2> netstat -ano | findstr 30001
TCP 0.0.0.0:30001 0.0.0.0:0 LISTENING 34208 // com.docker.backend.exe
TCP [::]:30001 [::]:0 LISTENING 34208 // com.docker.backend.exe
TCP [::1]:30001 [::]:0 LISTENING 25360 // wslhost.exe
이 정도면 대충, 구조가 눈에 들어오시죠?!!! ^^
참고로 저렇게 포트 매핑을 하나씩 하는 것이 불편할 수 있는데요, 이에 대해 이슈가 있긴 하지만,
Allow port ranges in extraPortMappings
; https://github.com/kubernetes-sigs/kind/issues/1219
리눅스에서는 해당 노드의 IP로 접근이 되기 때문에 "docker desktop" 버전을 사용하는 Mac이나 윈도우에 한정된 문제이므로 별로 중요하게 여기지는 않는 듯합니다.
[이 글에 대해서 여러분들과 의견을 공유하고 싶습니다. 틀리거나 미흡한 부분 또는 의문 사항이 있으시면 언제든 댓글 남겨주십시오.]