Tagged: Kubernetes

kubeadm join 시 discovery-file 이용하기

새로운 Worker 노드를 추가하기 위한 문법은 대략 다음과 같다.

새로운 Worker 노드 추가
1
2
]$ sudo kubeadm join klab-master1.systemv.local:6443 --token z49lc6.uz8qf3gwsjecttj6 \
        --discovery-token-ca-cert-hash sha256:f092db77bacfb82dc8541ac0c18421ede18716a81fef69313a085ec34fa4b65f

그런데, token 값은 시간이 지나면 만료되 사용할 수 없게 된다. 설사 token 을 알아도 ca-cert-hash 값을 알아야 한다. 이를 위해서 K8S 의 루트 CA 인증서를 이용해 hash 값을 알아내는 명령어를 사용한다.

K8S 루트 CA 인증서의 SHA256 Hash 값 확인
ZSH
1
2
]# openssl x509 -pubkey -in /etc/kubernetes/pki/ca.crt | openssl rsa -pubin -outform der 2>/dev/null | openssl dgst -sha256 -hex | sed 's/^.* //'
f092db77bacfb82dc8541ac0c18421ede18716a81fef69313a085ec34fa4b65f

Discovery-file 만들기

하지만 이 방법외에도 discovery-file 을 이용하는 방법도 있다. 이는 kube-public 네임스페이스에 ConfigMap 에서 cluster-info 의 정보를 가지고 오면 된다. 다음과 같다.

Discovery-file 작성
ZSH
1
]$ kubectl get cm cluster-info -o json -n kube-public | jq -r '.data.kubeconfig' > discovery-file.yaml

위 파일을 추가하고자 하는 새로운 Worker 노드에 복사해준다.

Discovery-file 을 이용한 새로운 Worker 노드 추가

이제 discovery-file 를 이용해 새로운 Worker 노드를 추가할 수 있다. 다음과 같다.

discovery-file 파일 이용한 새로운 worker 노드 추가
ZSH
1
]$ sudo kubeadm join --tls-bootstrap-token=jt0pr4.d57slk512u0c9dj8 --discovery-file=./discovery-config.yaml

CSR Approved

이렇게 한 후에 csr 을 보면 pending 상태의 인증서들이 보인다. 이를 Approved 해주면 된다.

CSR 보기
ZSH
1
2
3
4
5
6
7
]$ kubectl get csr
NAME        AGE     SIGNERNAME                                    REQUESTOR                                REQUESTEDDURATION   CONDITION
csr-bjz7l   26m     kubernetes.io/kubelet-serving                 system:node:klab-worker2.systemv.local   <none>              Pending
csr-ls7qw   5m15s   kubernetes.io/kubelet-serving                 system:node:klab-worker2.systemv.local   <none>              Pending
csr-nvgdd   26m     kubernetes.io/kube-apiserver-client-kubelet   system:bootstrap:jt0pr4                  <none>              Approved,Issued
csr-xvpqh   11m     kubernetes.io/kubelet-serving                 system:node:klab-worker2.systemv.local   <none>              Pending
]$ kubectl certificate approve csr-nvgdd

쿠버네티스, 새로운 Worker 노드 Join 시 토큰 값 확인하기

쿠버네티스(Kubernetes) 를 운영하다가 새로운 Worker 노드를 추가할때에 kubeadm 명령어와 함께 join 옵션을 함께 쓴다. 이때 token 값과 hash 값을 줘야 하는데, 최초 설치할때에 값을 출력해주지만 시간이 지나서 잃어버리면 어떻게 해야 할까..

Token 확인

불행하게도 Token 값은 영구적이지 않다. 어디다 잘 적어놨어도 시간이 지나면 자동으로 폐기되도록 되어 있다.

Kubernetes Token 확인
ZSH
1
2
]$ kubeadm token list
]$

아무것도 안나온다. 이는 자동 폐기 됐기 때문이다.

Token 생성

Token 값을 확인할 수 없다면 새로운 worker 노드를 추가할 수 없다. 아니, 정확하게는 Token 값을 이용해 추가할 수 없다. Token 값을 이용하기 위해서는 새로운 Token 값을 만들어 주면 된다.

Token 생성
ZSH
1
2
3
4
5
]$ kubeadm token create
jt0pr4.d57slk512u0c9dj8
]$ kubeadm token list
TOKEN                     TTL         EXPIRES                USAGES                   DESCRIPTION                                                EXTRA GROUPS
jt0pr4.d57slk512u0c9dj8   23h         2024-01-28T13:36:10Z   authentication,signing   <none>                                                     system:bootstrappers:kubeadm:default-node-token

위와같이 새로운 토큰이 생성되었다. 만료일이 기재되어 있어 이 기간동안만 유효하다.

Kubernetes 관련 기술 스택..

쿠버네티스 관련된 기술들이 워낙 많다보니 뭘 어디서부터 손대야할지 모를때도 있고 하다보면 어디에 서 있는지도 모를때가 있다. 더 나가 쿠버네티스를 시작하려고할때에 이게 어디에 있는건지를 알고 싶을때가 종종 있는데, 웹 서핑을 하다가 주운걸 기록해본다.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
- K8S
Master Node 및 Worker Node의 동작 원리에 대한 이해
Master Node 클러스터링 경험, 폐쇄망 온프레미스 환경 구축 경험
 
- Dependency Tools 관련
Container 관련 지식
Repository, Registry(OS Package, Harbor..) 등 구성 경험 및 운
영 경험 등
 
- CPU, Memory Resource 관련
Deployment, Configmap, ReplicaSet..
HPA, VPA 등 Node, Pod 오토 스케일링 관련된 전반적인 지식
 
- Storage Resource 관련
Mount 방식 운영 예정 (정적 할당)
PV, PVC, Storage Class, CSI, 솔루션 등
 
-Network Resource 관련
SVC(Type별 이해 및 설계 지식), Ingress, DNS
CNI, Routing table, Network Inteface
 
- Management Tools
kubectl, kubelet 등에 관련된 전반적인 지식
Optional : kubespray, rancher, kops, kubeadm 등 배포 관리 도구 사용 여부
 
- CD 관련
CD 프로세스에 대한 전반적인 지식, 구성 경험, 운영 경험 등
다양한 CD 도구 사용 경험, CI 구성 경험, 운영 경험 등 (컨설팅이
필요할 수도 있음)
 
- 모니터링 관련
K8S Metric Data에 대한 모니터링 구성 경험, 운영 경험 등
다양한 Monitoring 도구 사용 경험

딱봐도 채용공고에 내용인데, 굵직하게 정리가 되어서 긁어왔다. 여기서 한가지 추가해야 한다면 IaC 부분인데, 요새는 쿠버네티스에 뭔가를 설치할때는 다음과 같은 걸 많이 사용한다.

  • Helm
  • Operator

ArgoCD 도 있지만 이것은 사실 애플리케이션 배포에 쓰인다고 보면 된다.

요새 하도 공부를 하지 않아서 잃어버리는 기억도 많고 이제는 쓰지 않는 기술들도 많은데, 슬슬 다시 공부를해야 겠다고 다짐한다. 해야할게 얼마나 많은지… 덕분에 잘 심심하지 않게 살수 있다는 것에 위안을 받는다.

컨테이너에서 Java 힙 덤프 뜨기

Kubernetes 에서 Java 애플리케이션을 운영할때에, Java 힙 덤프를 떠야하는 경우가 있다. 하지만 다음과 같이 덤프를 떠지지 않는다.

Kubernetes 에서 Java 힙 덤프
ZSH
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
$ kubectl exec -it employee-consumer-68cfc9864-kgx4w -- sh
/ # ps aux
PID   USER     TIME  COMMAND
    1 root      3:01 java -XX:+UseG1GC -XX:+UseStringDeduplication -XX:MetaspaceSize=128M -XX:MaxMetaspaceSize=128M -Djava.security.egd=file:/dev/./urandom -jar /app/employee-consumer.jar --spring.active.profile=${SPRING_PROFILES_ACTIVE}
   57 root      0:00 sh
   63 root      0:00 ps aux
/ # jcmd 1 VM.flags
1:
com.sun.tools.attach.AttachNotSupportedException: Unable to get pid of LinuxThreads manager thread
        at sun.tools.attach.LinuxVirtualMachine.<init>(LinuxVirtualMachine.java:86)
        at sun.tools.attach.LinuxAttachProvider.attachVirtualMachine(LinuxAttachProvider.java:63)
        at com.sun.tools.attach.VirtualMachine.attach(VirtualMachine.java:208)
        at sun.tools.jcmd.JCmd.executeCommandForPid(JCmd.java:147)
        at sun.tools.jcmd.JCmd.main(JCmd.java:131)
/ #
</init>

“Unable to get pid of LinuxThread manager thread” 오류가 발생한다.

이 오류가 나오는 이유는 Java 애플리케이션의 Pid 값이 1이기 때문이다. 이를 해결하는 방법을 소개한다.

Container 이미지에 tini 설치, 배포

먼저 Openjdk 의 컨테이너 이미지에 tini 프로그램을 설치해야 한다. 이 tini 라는 프로그램은 인자값을 받은 프로그램을 실행 시켜 준다. 이렇게 하면 tini 는 Pid 1을 가지지만 tini 가 실행시킨 프로그램은 1보다 큰 Pid 값을 가지게 된다.

문제는 Openjdk 에 tini 라는 프로그램이 없다. 더군다나 아무 컨테이너 이미지에 이것을 설치할 수 있는게 아니라 Alpine 기반 이미지에서 쉽게 설치가 가능하다. Alpine 에서는 패키지로 제공하기 때문에 명령어로 간단하게 설치할 수 있다.

Dockerfile 을 다음과 같이 수정한다.

Kubernetes 에서 Java 힙 덤프
diff
1
2
3
4
5
6
7
8
9
FROM openjdk:8-jdk-alpine
+ RUN apk add --no-cache tini
RUN mkdir -p /app
ARG JAR_FILE=target/*.jar
COPY ${JAR_FILE} /app/employee-consumer.jar
ENV SPRING_PROFILES_ACTIVE=kubernetes
 
- ENTRYPOINT ["java","-XX:+UseG1GC", "-XX:+UseStringDeduplication", "-XX:MetaspaceSize=128M", "-XX:MaxMetaspaceSize=128M", "-Djava.security.egd=file:/dev/./urandom","-jar","/app/employee-consumer.jar","--spring.active.profile=${SPRING_PROFILES_ACTIVE}"]
+ ENTRYPOINT ["/sbin/tini", "--", "java","-XX:+UseG1GC", "-XX:+UseStringDeduplication", "-XX:MetaspaceSize=128M", "-XX:MaxMetaspaceSize=128M", "-Djava.security.egd=file:/dev/./urandom","-jar","/app/employee-consumer.jar","--spring.active.profile=${SPRING_PROFILES_ACTIVE}"]

apk 명령어를 이용해 tini 를 설치해주고 ENTRYPOINT 에 실행 명령어에 tini 를 넣고 인자값으로 java 애플리케이션 명령어를 넣는다.

이렇게 컨테이너 이미지를 제작하고 배포를 한다.

tini 프로그램 이 후 Pid

tini 프로그램으로 Java 애플리케이션이 어떻게 실행되는 다음과 같이 확인 할 수 있다.

tini 로 실행되는 java 애플리케이션
ZSH
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
$ kubectl exec -it employee-consumer-cbfc7c94b-t65sz -- sh
/ # ps aux
PID   USER     TIME  COMMAND
    1 root      0:00 /sbin/tini -- java -XX:+UseG1GC -XX:+UseStringDeduplication -XX:MetaspaceSize=128M -XX:MaxMetaspaceSize=128M -Djava.security.egd=file:/dev/./urandom -jar /app/employee-consumer.jar --spring.active.profile=${SPRING_PROFILES_ACTIVE}
    7 root      1:04 java -XX:+UseG1GC -XX:+UseStringDeduplication -XX:MetaspaceSize=128M -XX:MaxMetaspaceSize=128M -Djava.security.egd=file:/dev/./urandom -jar /app/employee-consumer.jar --spring.active.profile=${SPRING_PROFILES_ACTIVE}
   56 root      0:00 sh
   63 root      0:00 ps aux
/ # jcmd 7 GC.heap_info
7:
garbage-first heap   total 162816K, used 62180K [0x00000000f0000000, 0x00000000f01004f8, 0x0000000100000000)
  region size 1024K, 11 young (11264K), 10 survivors (10240K)
Metaspace       used 53386K, capacity 56950K, committed 57216K, reserved 1099776K
  class space    used 6277K, capacity 6935K, committed 7040K, reserved 1048576K
/ # jcmd 7 VM.flags
7:
-XX:CICompilerCount=2 -XX:CompressedClassSpaceSize=125829120 -XX:ConcGCThreads=1 -XX:G1HeapRegionSize=1048576 -XX:InitialHeapSize=16777216 -XX:MarkStackSize=4194304 -XX:MaxHeapSize=268435456 -XX:MaxMetaspaceSize=134217728 -XX:MaxNewSize=160432128 -XX:MetaspaceSize=134217728 -XX:MinHeapDeltaBytes=1048576 -XX:+UseCompressedClassPointers -XX:+UseCompressedOops -XX:+UseG1GC -XX:+UseStringDeduplication

jcmd 뿐만 아니라 jstat, jmap 등 모든 명령어를 사용할 수 있다.

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

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

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

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

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

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

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

kubeadm-config 업데이트

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

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

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

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

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

apiserver.crt 파일 업데이트

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

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

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

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

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

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

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

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

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

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

클러스터 설정 업데이트

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

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

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

Kubernetes 의 Role Based Access Control(RBAC)

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

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

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

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

참고: Role Based Access Control (RBAC)

Istio, Pod CrashLoopBackOff 해결하기

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

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

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

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

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

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

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

문제점

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

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

Istio 설치

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

Istio 설치 방법

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

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

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

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

Download Istioctl

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

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

istio profile

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

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

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

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

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

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

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

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

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

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

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

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

demo profile 설치

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

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

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

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

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

istio 설치 확인

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

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

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

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

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

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

문제

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

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

쿠버네티스 curl 사용하기

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

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

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

Calico Metrics 모니터링 하기

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

calicoctl

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

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

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

Calico CRD

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

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

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

Monitor Calico component metrics

Felix configuration

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

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

Creating a service to expose Felix metrics

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

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

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

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

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

Confirm prometheus metrics port

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

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

Creating a service to expose kube-controllers metrics

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

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

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

Prometheus ServiceMonitor 생성

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

Felix 를 위한 ServiceMonitor

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

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

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

Calico Kube Controller ServiceMonitor

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

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

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