Tagged: K8s

Ingress-Nginx 설치

Kubernetes 에서 인기있는 Ingress Controller 로 Nginx 가 있다. 설치는 Helm 을 이용하면 된다.

Helm 을 이용한 Ingress-Nginx 설치
ZSH
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
helm upgrade ingress-nginx ingress-nginx/ingress-nginx \
--install \
--namespace ingress-nginx --create-namespace \
--set controller.metrics.enabled=true \
--set-string controller.podAnnotations."prometheus\.io/scrape"="true" \
--set-string controller.podAnnotations."prometheus\.io/port"="10254" \
--set controller.metrics.serviceMonitor.enabled=true \
--set controller.metrics.serviceMonitor.additionalLabels.release="prometheus"
Release "ingress-nginx" does not exist. Installing it now.
NAME: ingress-nginx
LAST DEPLOYED: Sun Apr  6 00:11:07 2025
NAMESPACE: ingress-nginx
STATUS: deployed
REVISION: 1
TEST SUITE: None
NOTES:
The ingress-nginx controller has been installed.
It may take a few minutes for the load balancer IP to be available.
You can watch the status by running 'kubectl get service --namespace ingress-nginx ingress-nginx-controller --output wide --watch'
 
An example Ingress that makes use of the controller:
  apiVersion: networking.k8s.io/v1
  kind: Ingress
  metadata:
    name: example
    namespace: foo
  spec:
    ingressClassName: nginx
    rules:
      - host: www.example.com
        http:
          paths:
            - pathType: Prefix
              backend:
                service:
                  name: exampleService
                  port:
                    number: 80
              path: /
    # This section is only required if TLS is to be enabled for the Ingress
    tls:
      - hosts:
        - www.example.com
        secretName: example-tls
 
If TLS is enabled for the Ingress, a Secret containing the certificate and key must also be provided:
 
  apiVersion: v1
  kind: Secret
  metadata:
    name: example-tls
    namespace: foo
  data:
    tls.crt: <base64 encoded cert>
    tls.key: <base64 encoded key>
  type: kubernetes.io/tls

설치 명령어를 보면, 여러가지 파라메터가 보이는데 kube-prometheus-stack 으로 설치한 prometheus 까지 고려한 것이다.

관련 명령어나 파라메터는 다음의 주소에 매우 잘 설명되어 있어서 별도로 추가설명은 하지 않는다.

쿠버네티스 prometheus 설정

Helm 을 이용해 kube-prometheus-stack 을 설치하게 되면, Grafana 를 통해서 통계 그래프를 볼 수 있다. 그런데, 몇몇 대쉬보드는 나타나지 않는데 여기서는 이 문제를 해결하는 방법을 알아본다.

Prometheus

프로메테스에서 Status > Target health 에서 상태를 같이 보면서 해결하면 좋다. 어떻게 스크랩이 설정되어 있는데, 상태가 DOWN 인 부분을 잘 살펴보면 된다.

CoreDNS

CoreDNS 대쉬보드가 아무것도 나오지 않는다. Service 에 kube-dns 혹은 Helm 으로 설치할 경우에 coredns 로 나오는데, describe 를 한번 해본다.

describe coredns
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
]$ kubectl describe svc/coredns -n kube-system
Name:              coredns
Namespace:         kube-system
Labels:            app.kubernetes.io/instance=coredns
                   app.kubernetes.io/managed-by=Helm
                   app.kubernetes.io/name=coredns
                   helm.sh/chart=coredns-1.39.2
                   k8s-app=coredns
                   kubernetes.io/cluster-service=true
                   kubernetes.io/name=CoreDNS
Annotations:       meta.helm.sh/release-name: coredns
                   meta.helm.sh/release-namespace: kube-system
Selector:          app.kubernetes.io/instance=coredns,app.kubernetes.io/name=coredns,k8s-app=coredns
Type:              ClusterIP
IP Family Policy:  SingleStack
IP Families:       IPv4
IP:                10.96.0.10
IPs:               10.96.0.10
Port:              udp-53  53/UDP
TargetPort:        53/UDP
Endpoints:         10.42.217.130:53
Port:              tcp-53  53/TCP
TargetPort:        53/TCP
Endpoints:         10.42.217.130:53
Session Affinity:  None
Events:            <none>

위에 내용을 보면 k8s-app=coredns 가 보인다. 이제 Service 에 prometheus-coredns 를 한번 보자.

describe svc/prometheus-kube-prometheus-coredns
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
]$ kubectl describe svc/prometheus-kube-prometheus-coredns -n kube-system
Name:              prometheus-kube-prometheus-coredns
Namespace:         kube-system
Labels:            app=kube-prometheus-stack-coredns
                   app.kubernetes.io/instance=prometheus
                   app.kubernetes.io/managed-by=Helm
                   app.kubernetes.io/part-of=kube-prometheus-stack
                   app.kubernetes.io/version=70.4.1
                   chart=kube-prometheus-stack-70.4.1
                   heritage=Helm
                   jobLabel=coredns
                   release=prometheus
Annotations:       meta.helm.sh/release-name: prometheus
                   meta.helm.sh/release-namespace: monitoring
Selector:          k8s-app=kube-dns
Type:              ClusterIP
IP Family Policy:  SingleStack
IP Families:       IPv4
IP:                None
IPs:               None
Port:              http-metrics  9153/TCP
TargetPort:        9153/TCP
Endpoints:         <none>
Session Affinity:  None
Events:            <none>

Selector 를 보면 k8s-app=kube-dns 로 보인다. 이것이 맞지 않아서 관련 내용을 가지고 오지 못하는 원인다. 이것을 k8s-app=coredns 로 바꿔 준다.

이렇게 하고 Prometheus 에 Status > Target health 에서 coredns 를 보면 스크랩이 잘되는 것으로 바뀐다.

Etcd

Prometheus 에서 Status > Target health 에서 ‘http://192.168.96.60:2381/metrics‘ 로 EndPoint 로 설정되어 있다. curl 로 긁어보면 다음과 같이 나온다.

curl etcd endpoint 접속 테스트
ZSH
1
2
]$ curl http://192.168.96.60:2381/metrics
curl: (7) Failed to connect to 192.168.96.60 port 2381: 연결이 거부됨

Etcd 의 경우에는 상태 모니터링을 위한 파라메터 설정을 해줘야 한다. 하지만 kubeadm 으로 K8S 를 설치한 경우에 etcd 는 Master Controll Plane 으로 동작하기 때문에 파라메터 수정을 위해서는 manifest 파일을 수정으로 해야 한다.

1
2
3
4
]$ vim /etc/kubernetes/manifests/etcd.yaml
    - --listen-client-urls=https://127.0.0.1:2379,https://192.168.96.60:2379
    - --listen-metrics-urls=http://127.0.0.1:2381
    - --listen-peer-urls=https://192.168.96.60:2380

2381 포트를 보면, 127.0.0.1 만 엔드포인트로 되어 있다. 192.168.96.60 을 추가해 준다. 그러면 정상화 된다.

Controller Manager

Prometheus 에서 Status > Target health 에서 ‘dial tcp 192.168.96.60:10257: connect: connection refused’ 에러 메시지가 나타난다.

Controller Manager 또한 Master Controller Plane 이기 때문에 manifest 파일을 수정해줘야 한다.

controller-manager 메니페스트 파일
ZSH
1
2
3
4
]$ vim /etc/kubernetes/manifest/kube-controller-manager.yaml
    - --authorization-kubeconfig=/etc/kubernetes/controller-manager.conf
    - --bind-address=127.0.0.1
    - --client-ca-file=/etc/kubernetes/pki/ca.crt

bind-address 주소가 localhost 로 되어 있기 때문에 refused 된 것으로 보인다. 0.0.0.0 으로 바꾼다.

kube-scheduler

kube-scheduler 도 위에 controller manager 처럼 bind-address 가 localhost 로 되어 있다. 0.0.0.0 으로 바꾼다.

kube-proxy

kube-proxy 는 DaemonSet 오브젝트다. 설정 파일이 있는 것처럼 나오지만 설정파일은 없고, 대신 ConfigMap 으로 존재한다. 이 ConfigMap 에 metricsBindAddress 값이 없다. 이 값을 0.0.0.0 으로 지정해 준다.

metricbindaddresses 설정
ZSH
1
2
]$ kubectl edit cm kube-proxy -n kube-system
   metricsBindAddress: 0.0.0.0

DaemonSet 은 자동으로 재시작되지 않는다. Rollout 업데이트를 해준다.

ZSH
1
2
]$ kubectl rollout restart ds/kube-proxy -n kube-system
daemonset.apps/kube-proxy restarted

kube-prometheus-stack 설치

기존에 prometheus 설치를 했었는데, 버전을 올릴겸해서 다시 설치를 했다. 설치는 Helm 을 이용했고, 기존에 설치된 버전을 삭제 처리 했다.

환경

K8S 환경이 매우 중요하다. 필자의 환경은 Handy way 방법으로 설치를 진행한 상황이기 때문에 etcd, apiserver, scheduler 가 OS 데몬으로 운영되고 있다. 따라서 Master, Worker 노드의 IP 를 필요로 한다.

만일 kubeadm 으로 설치했다면 selector 를 이용해서 라벨을 선택해주면 된다.

삭제

Helm 을 이용해서 설치했기 때문에 Helm 으로 삭제를 해야 한다. 여기서 한가지 주의해야 하는 것이 있는데, Helm 으로 삭제를 하여도 CRD(Custom Resource Definition) 은 삭제되지 않기 때문에 수동으로 삭제를 해줘야 한다.

prometheus 삭제
ZSH
1
2
3
4
5
6
7
8
9
10
11
12
~$ helm delete prometheus -n monitoring
~$ kubectl get crd | grep monitoring
alertmanagerconfigs.monitoring.coreos.com             2025-04-02T09:45:05Z
alertmanagers.monitoring.coreos.com                   2025-04-02T09:45:05Z
podmonitors.monitoring.coreos.com                     2025-04-02T09:45:05Z
probes.monitoring.coreos.com                          2025-04-02T09:45:06Z
prometheusagents.monitoring.coreos.com                2025-04-02T09:45:06Z
prometheuses.monitoring.coreos.com                    2025-04-02T09:45:06Z
prometheusrules.monitoring.coreos.com                 2025-04-02T09:45:07Z
scrapeconfigs.monitoring.coreos.com                   2025-04-02T09:45:07Z
servicemonitors.monitoring.coreos.com                 2025-04-02T09:45:07Z
thanosrulers.monitoring.coreos.com                    2025-04-02T09:45:08Z

남아 있는 crd 가 다를 수가 있지만, 반드시 삭제를 해줘야 문제가 발생하지 않는다. crd 는 다른 프로그램에서도 삭제가 되지 않는 경우가 많다.

Helm repo update

Helm 저장소를 업데이트를 해야 한다.

ZSH
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
~$ helm repo list
NAME                    URL                                                
stable                  https://charts.helm.sh/stable                      
prometheus-community    https://prometheus-community.github.io/helm-charts
ingress-nginx           https://kubernetes.github.io/ingress-nginx        
coredns                 https://coredns.github.io/helm                    
istio                   https://istio-release.storage.googleapis.com/charts
~$ helm repo update
Hang tight while we grab the latest from your chart repositories...
...Successfully got an update from the "coredns" chart repository
...Successfully got an update from the "ingress-nginx" chart repository
...Successfully got an update from the "istio" chart repository
...Successfully got an update from the "prometheus-community" chart repository
...Successfully got an update from the "stable" chart repository
Update Complete. ⎈Happy Helming!⎈

Download a chart and untar

Helm Chart 를 다운로드하고 압축해제 한다. 이렇게 함으로써 values.yaml 파일을 수정할 수 있게된다.

Download and Untar
ZSH
1
~$ helm pull prometheus-community/kube-prometheus-stack --untar

다운로드와 함께 압축을 해제해 준다.

Values.yaml 파일 수정

어떤 내용들을 수정할지는 어떤 것을 모니터링 할지, 어떤 부분이 있는지에 따라서 달라진다. 변경된 내용은 대략 다음과 같다.

values.yaml 파일 수정 내용
diff
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
--- values.yaml 2025-04-02 16:05:17.534060819 +0000
+++ /home/systemv/kube-prometheus-stack/values.yaml     2025-04-02 16:23:06.908277193 +0000
@@ -1049,7 +1049,8 @@
     ## Define which Nodes the Pods are scheduled on.
     ## ref: https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/#nodeselector
     ##
-    nodeSelector: {}
+    nodeSelector:
+      system.rule: monitoring
 
     ## Define resources requests and limits for single Pods.
     ## ref: https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/
@@ -1775,10 +1776,10 @@
   ## If your kube controller manager is not deployed as a pod, specify IPs it can be found on
   ##  
-  endpoints: []
-  # - 10.141.4.22
-  # - 10.141.4.23
-  # - 10.141.4.24
+  endpoints:
+    - 192.168.96.46
+    - 192.168.96.47
+    - 192.168.96.48
 
   ## If using kubeControllerManager.endpoints only the port and targetPort are used
   ##
@@ -1888,8 +1889,8 @@
       enabled: false
       ipFamilies: ["IPv6", "IPv4"]
       ipFamilyPolicy: "PreferDualStack"
-    # selector:
-    #   k8s-app: kube-dns
+    selector:
+      k8s-app: coredns
   serviceMonitor:
     enabled: true
     ## Scrape interval. If not set, the Prometheus default scrape interval is used.
@@ -2062,10 +2063,10 @@
 
   ## If your etcd is not deployed as a pod, specify IPs it can be found on
   ##
-  endpoints: []
-  # - 10.141.4.22
-  # - 10.141.4.23
-  # - 10.141.4.24
+  endpoints:
+    - 192.168.96.46
+    - 192.168.96.47
+    - 192.168.96.48
 
   ## Etcd service. If using kubeEtcd.endpoints only the port and targetPort are used
   ##
@@ -2171,10 +2172,10 @@
 
   ## If your kube scheduler is not deployed as a pod, specify IPs it can be found on
   ##
-  endpoints: []
-  # - 10.141.4.22
-  # - 10.141.4.23
-  # - 10.141.4.24
+  endpoints:
+    - 192.168.96.46
+    - 192.168.96.47
+    - 192.168.96.48
 
   ## If using kubeScheduler.endpoints only the port and targetPort are used
   ##
@@ -2277,10 +2278,10 @@
 
   ## If your kube proxy is not deployed as a pod, specify IPs it can be found on
   ##
-  endpoints: []
-  # - 10.141.4.22
-  # - 10.141.4.23
-  # - 10.141.4.24
+  endpoints:
+    - 192.168.96.46
+    - 192.168.96.47
+    - 192.168.96.48
 
   service:
     enabled: true
@@ -2790,7 +2791,8 @@
       ## Define which Nodes the Pods are scheduled on.
       ## ref: https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/#nodeselector
       ##
-      nodeSelector: {}
+      nodeSelector:
+        system.rule: monitoring
 
       ## Tolerations for use with node taints
       ## ref: https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/
@@ -3145,7 +3147,8 @@
   ## Define which Nodes the Pods are scheduled on.
   ## ref: https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/#nodeselector
   ##
-  nodeSelector: {}
+  nodeSelector:
+    system.rule: monitoring
 
   ## Tolerations for use with node taints
   ## ref: https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/
@@ -3997,7 +4000,8 @@
     ## Define which Nodes the Pods are scheduled on.
     ## ref: https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/#nodeselector
     ##
-    nodeSelector: {}
+    nodeSelector:
+      system.rule: monitoring
 
     ## Secrets is a list of Secrets in the same namespace as the Prometheus object, which shall be mounted into the Prometheus Pods.
     ## The Secrets are mounted into /etc/prometheus/secrets/. Secrets changes after initial creation of a Prometheus object are not
@@ -5180,7 +5184,8 @@
     ## Define which Nodes the Pods are scheduled on.
     ## ref: https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/#nodeselector
     ##
-    nodeSelector: {}
+    nodeSelector:
+      system.rule: monitoring
 
     ## Define resources requests and limits for single Pods.
     ## ref: https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/

nodeSelector 에 system.rule: monitoring 이 보이는데, 이는 Worker 노드에 라벨을 말한다. 선택된 라벨을 가지고 있는 Worker 노드에 Prometheus 가 설치된다. 단, 이것도 상황에 따라서 달라지는데 Node exporter 의 경우에는 각 노드에 설치가 되어야 하기 때문에 라벨을 설정하지 않는다.

Node 라벨 생성

system.rule: monitoring 이라는 라벨을 생성해야 한다.

kworker3 노드에 라벨 추가
ZSH
1
2
3
4
5
6
7
$ kubectl get node --show-labels
NAME                     STATUS   ROLES    AGE   VERSION   LABELS
kworker1.systemv.local   Ready    <none>   97d   v1.20.6   beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,kubernetes.io/arch=amd64,kubernetes.io/hostname=kworker1.systemv.local,kubernetes.io/os=linux
kworker2.systemv.local   Ready    <none>   97d   v1.20.6   beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,kubernetes.io/arch=amd64,kubernetes.io/hostname=kworker2.systemv.local,kubernetes.io/os=linux
kworker3.systemv.local   Ready    <none>   97d   v1.20.6   beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,kubernetes.io/arch=amd64,kubernetes.io/hostname=kworker3.systemv.local,kubernetes.io/os=linux
$ kubectl label nodes kworker3.systemv.local system.rule=monitoring
node/kworker3.systemv.local labeled

이렇게 하면 kworker3 에 prometheus 가 설치된다.

Dependency Update

Helm 을 이용해서 설치해야 한다. 그전에 kube-prometheus-stack 에 의존성이 있는 패키지를 업데이트 해줘야 한다.

Dependency Update
ZSH
1
~$ helm dependency update

설치

Helm 을 이용해 수정한 values.yaml 을 가지고 설치를 한다.

kube-prometheus-stack 설치
ZSH
1
2
3
4
5
systemv@kmaster1:~/kube-prometheus-stack$ helm install -f values.yaml prometheus --namespace=monitoring .
systemv@kmaster1:~/kube-prometheus-stack$ helm list -A
NAME            NAMESPACE       REVISION        UPDATED                                 STATUS          CHART                           APP VERSION
coredns         kube-system     1               2025-04-01 15:27:24.120344029 +0000 UTC deployed        coredns-1.39.2                  1.12.0    
prometheus      monitoring      1               2025-04-02 09:45:15.385967452 +0000 UTC deployed        kube-prometheus-stack-70.4.0    v0.81.0

설치가 완료 되면 Pod, Service 에 Prometheus 가 올라오게 된다.

K8S dnstools 사용하기

K8S 를 사용하다보면 여러가지 검증을 위해 Pod 를 필요로 하는 경우가 있는데, dnstools 이 유용하다. 다음과 같이 사용할 수 있다.

dnstools 임시 Pod 생성
ZSH
1
~$ kubectl run -it --rm --restart=Never --image=infoblox/dnstools:latest dnstools

Pod 가 생성되면서 dnstools 컨테이너에 진입하게 되고 exit 를 하게 되면 Pod 는 삭제된다.

혹은 curl 이미지를 이용하는 방법도 있다.

cur 이미지 사용
ZSH
1
~$ kubectl run curl -it --rm --image curlimages/curl -- sh

Metallb v0.14.9 설치

과거 Metallb 의 버전이 0.10 이였고 K8S 버전도 1.32 이여서 최신 버전으로 다시 설치를 해봤다.

환경

K8S 환경에서 설치를 하지만 CNI 등을 고려해 설치를 진행해야 한다. 내가 설치한 환경은 좀 더 특이한데, K8S 를 Hand Way 방법으로 설치한 상태다. Hand Way 로 설치를 하게 되면 Kube-apiserver, controller, kubelet, kube-scheduler, kube-proxy 같은 것을 컨테이너 방법이 아닌 OS 프로그램 방법으로 설치를 하게 된다. K8S 에서 사용하는 인증서도 수동으로 해줘야 한다.

요약하면 다음과 같다.

  • K8S 설치: Handy way
  • K8S Version: 1.32.2
  • Containerd: 1.7.26
  • CNI: Calico

다운로드

다운로드는 CURL 이나 WGET 명령어를 이용하면 된다.

Metallb 다운로드
ZSH
1
wget https://raw.githubusercontent.com/metallb/metallb/v0.14.9/config/manifests/metallb-native.yaml

설치 문서를 보면 이 manifest 파일로 설치가 가능하다고 하지만 여러가지 환경으로 인해서 추가로 파일을 작성해야할 필요도 있다.

metallb 설치

다운로드 받은 metallb-native.yaml 파일을 적용해 설치해 준다.

metallb 설치
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
~$ kubectl apply -f metallb-native.yaml
namespace/metallb-system created
customresourcedefinition.apiextensions.k8s.io/bfdprofiles.metallb.io created
customresourcedefinition.apiextensions.k8s.io/bgpadvertisements.metallb.io created
customresourcedefinition.apiextensions.k8s.io/bgppeers.metallb.io created
customresourcedefinition.apiextensions.k8s.io/communities.metallb.io created
customresourcedefinition.apiextensions.k8s.io/ipaddresspools.metallb.io created
customresourcedefinition.apiextensions.k8s.io/l2advertisements.metallb.io created
customresourcedefinition.apiextensions.k8s.io/servicel2statuses.metallb.io created
serviceaccount/controller created
serviceaccount/speaker created
role.rbac.authorization.k8s.io/controller created
role.rbac.authorization.k8s.io/pod-lister created
clusterrole.rbac.authorization.k8s.io/metallb-system:controller created
clusterrole.rbac.authorization.k8s.io/metallb-system:speaker created
rolebinding.rbac.authorization.k8s.io/controller created
rolebinding.rbac.authorization.k8s.io/pod-lister created
clusterrolebinding.rbac.authorization.k8s.io/metallb-system:controller created
clusterrolebinding.rbac.authorization.k8s.io/metallb-system:speaker created
configmap/metallb-excludel2 created
secret/metallb-webhook-cert created
service/metallb-webhook-service created
deployment.apps/controller created
daemonset.apps/speaker created
validatingwebhookconfiguration.admissionregistration.k8s.io/metallb-webhook-configuration created

설치는 아무런 문제 없이 모두 잘 설치가 된다.

IPAddressPool 생성

Metallb 에서 사용할 고정IP 대역을 Pool 로 가지고 있어야 하는데, 이것을 생성해 줘야 한다.

IPAddressPool
YAML
1
2
3
4
5
6
7
8
apiVersion: metallb.io/v1beta1
kind: IPAddressPool
metadata:
  name: my-ippool
  namespace: metallb-system
spec:
  addresses:
  - 192.168.111.2-192.168.111.100

위와 같은 addresses 를 할당해 준다. 필자는 집에서 K8S 를 구축했기 때문에 Private IP 대역을 할당해 줬다.

IPAddressPool 생성 오류
ZSH
1
2
~$ kubectl apply -f metallb-ipaddress.yaml
Error from server (InternalError): error when creating "metallb-ipaddress.yaml": Internal error occurred: failed calling webhook "ipaddresspoolvalidationwebhook.metallb.io": failed to call webhook: Post "https://metallb-webhook-service.metallb-system.svc:443/validate-metallb-io-v1beta1-ipaddresspool?timeout=10s": context deadline exceeded

생성을 위해서 파일을 적용해 주면 위와같은 오류가 발생하게 된다.

이러한 오류는 validatingwebhookconfiguration 에 metallb-webhook-configuration 설정에서 문제가 된다. Webhook 이 필요한 것인데, 이에 대한 추가적인 설정을 해줘도 되지만 일단 삭제하는 것으로 처리 한다.

validatingwebhookconfiguration 에 metallb-webhook-configuration 삭제
ZSH
1
2
~$ kubectl delete ValidatingWebhookConfiguration/metallb-webhook-configuration
validatingwebhookconfiguration.admissionregistration.k8s.io "metallb-webhook-configuration" deleted

이렇게 한 후에 다시 metallb-ipaddress.yaml 파일을 적용하면 잘 된다.

L2 mode

필자의 경우에는 L2 mode 로 작동되도록 해야 한다. BGP 도 있기는 하지만, 필자의 경우에는 상관 없는 것이기 때문에 L2 mode 를 위해서 다음과 같이 manifest 파일을 작성한다.

L2 Mode 생성
YAML
1
2
3
4
5
6
7
8
apiVersion: metallb.io/v1beta1
kind: L2Advertisement
metadata:
  name: my-l2-advertise
  namespace: metallb-system
spec:
  ipAddressPools:
  - my-ippool

metallb-L2Advertisement.yaml 파일을 적용한다.

LoadBalancer 타입 변경

이제 고정 IP 를 필요로 하는 Service 에 타입을 ClusterIP 에서 LoadBalancer 로 변경해 본다. Metallb 설치가 정상적이라면 다음과 같이 된다.

Metallb 가 적용된 Service
ZSH
1
2
3
4
$ kubectl get svc -A
NAMESPACE        NAME                                                 TYPE           CLUSTER-IP    EXTERNAL-IP     PORT(S)                        AGE
default          employee-consumer                                    ClusterIP      10.32.0.187   <none>          80/TCP                         3y32d
default          employee-producer                                    LoadBalancer   10.32.0.74    192.168.111.3   8180:30701/TCP                 3y32d

EXTERNAL-IP 에 Metallb 의 IPAddresses Pool 중에 하나의 IP가 할당된다.

그리고 describe 결과는 다음과 같다.

Metallb 가 적용된 Service 에 Describe
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
$ kubectl describe svc/employee-producer -n default
Name:                     employee-producer
Namespace:                default
Labels:                   <none>
Annotations:              metallb.io/ip-allocated-from-pool: my-ippool
Selector:                 app=employee-producer
Type:                     LoadBalancer
IP Family Policy:         SingleStack
IP Families:              IPv4
IP:                       10.32.0.74
IPs:                      10.32.0.74
LoadBalancer Ingress:     192.168.111.3 (VIP)
Port:                     <unset>  8180/TCP
TargetPort:               8180/TCP
NodePort:                 <unset>  30701/TCP
Endpoints:                192.168.96.50:8180
Session Affinity:         None
External Traffic Policy:  Cluster
Internal Traffic Policy:  Cluster
Events:
  Type    Reason        Age                From                Message
  ----    ------        ----               ----                -------
  Normal  nodeAssigned  54m                metallb-speaker     announcing from node "kworker3.systemv.local" with protocol "layer2"
  Normal  nodeAssigned  53m (x4 over 54m)  metallb-speaker     announcing from node "kworker2.systemv.local" with protocol "layer2"
  Normal  IPAllocated   8m35s              metallb-controller  Assigned IP ["192.168.111.3"]
  Normal  nodeAssigned  3m29s              metallb-speaker     announcing from node "kworker1.systemv.local" with protocol "layer2"

EndPoints 는 Nodes IP가 보이고 Port 도 할당된게 보인다. 이건 아마도 Hand Way 설치로 인한 것으로 보인다. 원래 kubeadm 으로 설치를 하게 될 경우에 Node IP 조차도 K8S IP 여야 하는데, 여기서는 Node IP 자체가 OS 자체에 할당된 IP로 나타난다.

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 등 모든 명령어를 사용할 수 있다.