13. 리소스 로깅과 모니터링

이 문서는 인프런 강의 "데브옵스를 위한 쿠버네티스 마스터"을 듣고 작성되었습니다. 최대한 요약해서 강의 내용을 최소로 하는데 목표를 두고 있어서, 더 친절하고 정확한 내용을 원하신다면 강의를 구매하시는 것을 추천드립니다. => 강의 링크

쿠버네티스 모니터링 아키텍처

k8s의 모니터링 아키텍처는 다음과 같다.

기본적으로 k8s에서의 메트릭 수집은 다음 컴포넌트들로 데이터를 수집한다.

• metrics-server (kubectl top 명령어 사용 가능, 단기 메모리 저장소)
• cAdvisor (컨테이너 메트릭 수집)

로그는 Docker가 저장하는 로그를 수집한다. 경로는 다음과 같다.

• /var/lib/docker/containers//-json.log

이러한 것들을 이용해서 k8s의 모니터링 시스템을 구축할 수 있다. 사용 가능한 시스템은 다음과 같다.

• 리소스 사용량 모니터링 시스템
  • k8s-dashboard
  • Prometheus-Grafana
• 로그 모니터링
  • Kibana-Elasticsearch-FluentBit-FluentD

쿠버네티스 메트릭 수집 파이프라인의 이해

이번 절은 VM에서 진행한다. 앞서 말했듯이 k8s의 메트릭 수집은 cAdvisor와 metric-server가 기본이다. cAdvisor는 컨테이너들의 메트릭을 수집하는 도구이며 metrics-server는 메트릭의 단기 메모리 저장소로써 kubectl top 명령어를 지원해 리소스 사용량을 보다 쉽게 확인할 수 있다.

 

이제 metrics-server를 쿠버네티스 클러스터에 구성해보자. 터미널에 다음을 입력한다.

$ kubectl apply -f https://github.com/kubernetes-sigs/metrics-server/releases/latest/download/components.yaml

$ kubectl get pod -n kube-system -w
NAME                              READY   STATUS    RESTARTS   AGE
coredns-558bd4d5db-5z4jv          1/1     Running   14         51d
coredns-558bd4d5db-z45ck          1/1     Running   11         40d
etcd-master                       1/1     Running   17         51d
kube-apiserver-master             1/1     Running   2          4d
kube-controller-manager-master    1/1     Running   18         51d
kube-proxy-hvpz5                  1/1     Running   18         51d
kube-proxy-kdtb5                  1/1     Running   16         51d
kube-proxy-qthkm                  1/1     Running   14         51d
kube-scheduler-master             1/1     Running   18         51d
# 새롭게 생김.
metrics-server-6dfddc5fb8-fhw9f   0/1     Running   0          40s

weave-net-46bsq                   2/2     Running   31         51d
weave-net-fgxbv                   2/2     Running   31         51d
weave-net-qr5v6                   2/2     Running   36         51d

 

리소스는 생성되지만 kubectl get pod 명령어로 확인해보면 만들어진 후 "READY" 상태가 "0/1"에서 변하지 않음을 알 수 있다.

현재는 VM에서 돌기 때문에 실제 TLS 통신이 잘 이루어지지 않기 때문이다. 컨테이너 실행 옵션을 변경해주어야 한다. 터미널에 다음을 입력한다.

$ kubectl edit deploy -n kube-system metrics-server

 

그럼 VIM 창에 다음 yaml 파일이 보일 것이다. Pod.spec.containers.args에서 - --kubelet-insecure-tls를 추가한다.

apiVersion: apps/v1
kind: Deployment
...
spec:
  progressDeadlineSeconds: 600
  replicas: 1
  revisionHistoryLimit: 10
  selector:
    matchLabels:
      k8s-app: metrics-server
  strategy:
    rollingUpdate:
      maxSurge: 25%
      maxUnavailable: 0
    type: RollingUpdate
  template:
    metadata:
      creationTimestamp: null
      labels:
        k8s-app: metrics-server
    spec:
      containers:
        - args:
          - --cert-dir=/tmp
          - --secure-port=443
          - --kubelet-preferred-address-types=InternalIP,ExternalIP,Hostname
          - --kubelet-use-node-status-port
          - --metric-resolution=15s
          # 추가
          - --kubelet-insecure-tls
      image: k8s.gcr.io/metrics-server/metrics-server:v0.5.0
      ...

 

그 후 다시 kubectl get pod 명령어를 이용해서 컨테이너들을 관찰해보자.

$ kubectl get pod -w -n kube-system
NAME                              READY   STATUS    RESTARTS   AGE
...
metrics-server-6dfddc5fb8-bvf4x   0/1     Running   0          2m44s
metrics-server-77946fbff9-pqk2d   0/1     Running   0          9s
...
metrics-server-77946fbff9-pqk2d   1/1     Running   0          30s
metrics-server-6dfddc5fb8-bvf4x   0/1     Terminating   0          3m5s
metrics-server-6dfddc5fb8-bvf4x   0/1     Terminating   0          3m5s
metrics-server-6dfddc5fb8-bvf4x   0/1     Terminating   0          3m6s
metrics-server-6dfddc5fb8-bvf4x   0/1     Terminating   0          3m6s

 

새 포드가 실행되면서 기존에 있던 metrics-server 포드가 삭제된다. 이제 kubectl top 명령어를 실행시켜보자.

$ kubectl top pods -n kube-system
W0823 20:31:03.776705   14026 top_pod.go:140] Using json format to get metrics. Next release will switch to protocol-buffers, switch early by passing --use-protocol-buffers flag
NAME                              CPU(cores)   MEMORY(bytes)   
coredns-558bd4d5db-5z4jv          2m           11Mi            
coredns-558bd4d5db-z45ck          2m           11Mi            
etcd-master                       9m           92Mi            
kube-apiserver-master             44m          294Mi           
kube-controller-manager-master    14m          45Mi            
kube-proxy-hvpz5                  1m           16Mi            
kube-proxy-kdtb5                  1m           16Mi            
kube-proxy-qthkm                  1m           17Mi            
kube-scheduler-master             2m           16Mi            
metrics-server-77946fbff9-pqk2d   5m           15Mi            
weave-net-46bsq                   1m           69Mi            
weave-net-fgxbv                   1m           70Mi            
weave-net-qr5v6                   1m           67Mi      

 

이런 리소스 사용량을 수집하여 k8s-dashboard나 Prometheus, Grafana를 이용하여 쿠버네티스 리소스 모니터링 시스템을 구축할 수 있다.

쿠버네티스 로그 수집 파이프라인의 이해

k8s에서 로그는 다음 명령어로 확인할 수 있다.

$ kubectl logs <pod name> [<container name>]

 

이는 Docker의 로그를 가져온것과 닽다.

$ docker logs <container_name>

 

이런 컨테이너의 로그파일들은 /var/log/containers 경로에 존재한다. 어떤 로그 파일이 존재하는지 확인해보자.

$ ll /var/log/containers/
total 68
drwxr-xr-x  2 root root   4096  8월 23 20:09 ./
drwxrwxr-x 15 root syslog 4096  8월 23 20:09 ../
lrwxrwxrwx  1 root root     82  8월 23 20:09 etcd-master_kube-system_etcd-112e33e56b045a3eda1daeedf4e653d8b99a1916e23fb825937389b0f202b03b.log -> /var/log/pods/kube-system_etcd-master_d0eb798391c9389c9721c4631c28dc9a/etcd/17.log
lrwxrwxrwx  1 root root     82  8월 20 19:38 etcd-master_kube-system_etcd-586980d2076e5120a2a5384fdffa17b83c5d57dc309c699793a83356d760f972.log -> /var/log/pods/kube-system_etcd-master_d0eb798391c9389c9721c4631c28dc9a/etcd/16.log
lrwxrwxrwx  1 root root    101  8월 20 19:38 kube-apiserver-master_kube-system_kube-apiserver-9a8bcfa900bdcf87aa83e4996557a8d74e9ee26f8d858245bb0cee18fe17c79c.log -> /var/log/pods/kube-system_kube-apiserver-master_3433142ae02bfb6edeabf681740ad71a/kube-apiserver/1.log
lrwxrwxrwx  1 root root    101  8월 23 20:09 kube-apiserver-master_kube-system_kube-apiserver-d8b76b7439acad3478c1aabeef674e87d941ec552478da795b0f93af7b06bad6.log -> /var/log/pods/kube-system_kube-apiserver-master_3433142ae02bfb6edeabf681740ad71a/kube-apiserver/2.log
lrwxrwxrwx  1 root root    120  8월 23 20:09 kube-controller-manager-master_kube-system_kube-controller-manager-9c79e0aa530960818abc06dfdbff9d1d7e5e09ab5b41616728386c9bd7bee013.log -> /var/log/pods/kube-system_kube-controller-manager-master_683f32b0119799727621446455e8d131/kube-controller-manager/18.log
lrwxrwxrwx  1 root root    120  8월 20 19:38 kube-controller-manager-master_kube-system_kube-controller-manager-f23c9ad664f0218f8346b72d75acb7c68ee6f18fa32a1d66311a36085ee1169c.log -> /var/log/pods/kube-system_kube-controller-manager-master_683f32b0119799727621446455e8d131/kube-controller-manager/17.log
lrwxrwxrwx  1 root root     97  8월 20 19:39 kube-proxy-hvpz5_kube-system_kube-proxy-b7e348aefdc91115874409e25cee6787991ba4858bb1509ce534db86cce02b59.log -> /var/log/pods/kube-system_kube-proxy-hvpz5_676e7f6d-825c-43b6-92ea-a1b891092eb4/kube-proxy/17.log
lrwxrwxrwx  1 root root     97  8월 23 20:09 kube-proxy-hvpz5_kube-system_kube-proxy-f2f6db41d2eef96687d3d7121ed37a1a1d7ac890c8f6d18ab799fb32b157c616.log -> /var/log/pods/kube-system_kube-proxy-hvpz5_676e7f6d-825c-43b6-92ea-a1b891092eb4/kube-proxy/18.log
lrwxrwxrwx  1 root root    102  8월 20 19:38 kube-scheduler-master_kube-system_kube-scheduler-3e11bb53acea876604d9b5f3d0b9a4232227aa55df9b6c58f2a792e4333a47d7.log -> /var/log/pods/kube-system_kube-scheduler-master_35ae2ec46407146c0fe6281c2c3292ce/kube-scheduler/17.log
lrwxrwxrwx  1 root root    102  8월 23 20:09 kube-scheduler-master_kube-system_kube-scheduler-d0298c9f461c68aee56d96d1b4c35d317f58801ae4ddf631f1f96a8dc0f3c63a.log -> /var/log/pods/kube-system_kube-scheduler-master_35ae2ec46407146c0fe6281c2c3292ce/kube-scheduler/18.log
lrwxrwxrwx  1 root root     91  8월 20 19:39 weave-net-qr5v6_kube-system_weave-abd3c25de9d5c5f7205b00e368003ab2e4708668968f67a84a9d1c7719704224.log -> /var/log/pods/kube-system_weave-net-qr5v6_52d850d7-c8e4-4b75-93c5-2dd97237b818/weave/18.log
lrwxrwxrwx  1 root root     91  8월 23 20:09 weave-net-qr5v6_kube-system_weave-fe71c90bdd5406fcc09815ee7625098dcedb395b1fd0a7fadd13dcd238e022c2.log -> /var/log/pods/kube-system_weave-net-qr5v6_52d850d7-c8e4-4b75-93c5-2dd97237b818/weave/19.log
lrwxrwxrwx  1 root root     95  8월 23 20:09 weave-net-qr5v6_kube-system_weave-init-9a565e054c960af3d572068ddcc879f25f571e22b59e748899f49f4e248ccc8f.log -> /var/log/pods/kube-system_weave-net-qr5v6_52d850d7-c8e4-4b75-93c5-2dd97237b818/weave-init/1.log
lrwxrwxrwx  1 root root     95  8월 23 20:09 weave-net-qr5v6_kube-system_weave-npc-852e9874115dca8882e09432e9a51a44bbabc5de4cd78d00e8f2820210b0e0af.log -> /var/log/pods/kube-system_weave-net-qr5v6_52d850d7-c8e4-4b75-93c5-2dd97237b818/weave-npc/17.log
lrwxrwxrwx  1 root root     95  8월 20 19:39 weave-net-qr5v6_kube-system_weave-npc-e326ff0c9686dec980a9b57f45247b39a86ffd0203eba270df8accd265e4e54b.log -> /var/log/pods/kube-system_weave-net-qr5v6_52d850d7-c8e4-4b75-93c5-2dd97237b818/weave-npc/16.log

 

로그 파일은 다음 형식으로 저장된다.

# <pod-name>_<namespace>_<pod-container-id><???>.log
etcd-master_kube-system_etcd-112e33e56b045a3eda1daeedf4e653d8b99a1916e23fb825937389b0f202b03b.log

 

한 번 컨테이너들이 잘 매핑되는지 확인해보자.

$ sudo docker ps | grep "etcd"
112e33e56b04   0369cf4303ff             "etcd --advertise-cl…"   43 minutes ago   Up 43 minutes             k8s_etcd_etcd-master_kube-system_d0eb798391c9389c9721c4631c28dc9a_17
86e93bb11572   k8s.gcr.io/pause:3.4.1   "/pause"                 43 minutes ago   Up 43 minutes             k8s_POD_etcd-master_kube-system_d0eb798391c9389c9721c4631c28dc9a_18

 

결국 이렇게 수집된 로그들은 FluentD를 이용해서 ElasticSearch에 저장한 후 Kibana로 시각화하여 쿠버네티스 로그 모니터링 시스템을 구축할 수 있다.

쿠버네티스 리소스 모니터링 시스템 구축하기 (1) k8s-dashboard

이 절은 VM에서 진행한다. GKE의 경우 이미 구성되어 있다. 먼저 터미널에 다음을 입력한다.

$ kubectl apply -f https://raw.githubusercontent.com/kubernetes/dashboard/v2.3.1/aio/deploy/recommended.yaml
namespace/kubernetes-dashboard created
serviceaccount/kubernetes-dashboard created
service/kubernetes-dashboard created
secret/kubernetes-dashboard-certs created
secret/kubernetes-dashboard-csrf created
secret/kubernetes-dashboard-key-holder created
configmap/kubernetes-dashboard-settings created
role.rbac.authorization.k8s.io/kubernetes-dashboard created
clusterrole.rbac.authorization.k8s.io/kubernetes-dashboard created
rolebinding.rbac.authorization.k8s.io/kubernetes-dashboard created
clusterrolebinding.rbac.authorization.k8s.io/kubernetes-dashboard created
deployment.apps/kubernetes-dashboard created
service/dashboard-metrics-scraper created
deployment.apps/dashboard-metrics-scraper created

 

그럼 공식 문서에서 제공하는 방식으로 k8s-dashboard를 구성하기 위한 리소스들이 생성된다. 이제 터미널에 다음을 입력한다.

$ kubectl proxy
Starting to serve on 127.0.0.1:8001

 

위의 명령어는 기본적으로 HTTPS 동작하는 대시보드를 HTTP로 통신할 수 있게 만들어준다. "http://localhost:8001/api/v1/namespaces/kubernetes-dashboard/services/https:kubernetes-dashboard:/proxy/" 에 접속한다.

 

그럼 다음 화면이 보이는데 우리는 토큰을 만들지 않았다. 공식 문서에 따르면, 유저를 생성하기 위해서는 ServiceAccount와 RoleBinding AccessControl 리소스를 생성해주어야 한다. 먼저 ServiceAccount부터 생성한다. k8s-dashboard-sa.yaml을 다음과 같이 생성한다.

 

src/ch13/k8s/k8s-dashboard-sa.yaml

apiVersion: v1
kind: ServiceAccount
metadata:
  name: admin-user
  namespace: kubernetes-dashboard

 

간단하게 애플리케이션에 접근할 계정을 만들어준다. 그리고 이 계정에 권한을 부여하는 리소스가 RBAC이다. k8s-dashboard-rbac.yaml을 다음과 같이 생성한다.

 

src/ch13/k8s/k8s-dashboard-rbac.yaml

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: admin-user
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: cluster-admin
subjects:
  - kind: ServiceAccount
    name: admin-user
    namespace: kubernetes-dashboard

 

이제 리소소들을 생성한다.

$ kubectl create -f k8s-dashboard-sa.yaml
serviceaccount/admin-user created

$ kubectl create -f k8s-dashboard-rbac.yaml
clusterrolebinding.rbac.authorization.k8s.io/admin-user created

 

그 후 토큰을 얻기 위해서 다음 명령어를 입력한다.

$ kubectl -n kubernetes-dashboard get secret $(kubectl -n kubernetes-dashboard get sa/admin-user -o jsonpath="{.secrets[0].name}") -o go-template="{{.data.token | base64decode}}"
eyJhbGciOiJSUzI1NiIsImtpZCI6IkxzOF9JWUZFWElNb1E2bTlfdURPTW5uSjk5d2I2dGFPWWhGcjNzS1RCSGMifQ.eyJpc3MiOiJrdWJlcm5ldGVzL3NlcnZpY2VhY2NvdW50Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9uYW1lc3BhY2UiOiJrdWJlcm5ldGVzLWRhc2hib2FyZCIsImt1YmVybmV0ZXMuaW8vc2VydmljZWFjY291bnQvc2VjcmV0Lm5hbWUiOiJhZG1pbi11c2VyLXRva2VuLWoyOHg1Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9zZXJ2aWNlLWFjY291bnQubmFtZSI6ImFkbWluLXVzZXIiLCJrdWJlcm5ldGVzLmlvL3NlcnZpY2VhY2NvdW50L3NlcnZpY2UtYWNjb3VudC51aWQiOiIyZGQ2ZjM1Zi1kNmE1LTRmNTktYTQ5My1lODA3MDVkMDc2YzUiLCJzdWIiOiJzeXN0ZW06c2VydmljZWFjY291bnQ6a3ViZXJuZXRlcy1kYXNoYm9hcmQ6YWRtaW4tdXNlciJ9.FdWU4AWmgiKon5EPxU2Pa3V1AcOlV3rCb4CO33xIjUcNxS9NLb3Kt_1to9YckH-rG_GUJi2-I_uBoUT1SBiwXjPnE82cIvQxfI4fm6ps9uGDU8vxhoT1VV7CRjxQkw1ryaevRwlGPoVm7YubHpNmS5BJCtmBmPr_gUuK7MBPncnPungl9oAt6GrwXz4jBIY2zWkMdZnS76MV_tph_gGtbG6NDTomKyun09NtOmQNbCsRgSIFL0aBCm2E34qKnfLku1mq5K1Blj4DLUtpHa5EIr7y18c3cdtI_WpBrQl8kzhzPNzCjhvok1c15HOxz0kIDEOjuwxDPC1Ncjr5ITSoow

 

이 얻은 토큰을 아까 페이지에 입력을 해주면 된다. 그러면 이렇게 쿠버네티스 클러스터의 리소스들을 확인할 수 있다.

쿠버네티스 리소스 모니터링 시스템 구축하기 (2) Prometheus, Grafana

이번 절은 GKE에서 진행한다. 위의 절처럼 직접 구성하는 것도 매우 훌륭한 방법이지만, GKE 같은 경우 Market Place를 통해서 쿠버네티스 클러스터에 복잡한 시스템을 간단하게 구성할 수 있다. 이번 절에서는 k8s의 리소스를 모니터링할 수 있는 Prometheus 기반의 모니터링 시스템을 구축한다. 먼저 원활한 실습 진행을 위해서 쿠버네티스 클러스터의 cpu 사양 vCPUx2로 올린다.

 

그 후 "MarketPlace"를 클릭한다.

검색 창에 "prometheus & grafana"를 입력한 후 결과를 클릭한다.

"구성"을 클릭한다.

이제 왼쪽 탭에서 값을 알맞게 수정한 후 가장 아래에 "적용"을 클릭한다.

그럼 약 5-10분 정도 기다리면 모든 리소스가 생성된다. 이제 그라파나 접속을 위해 서비스를 다음과 같이 변경한다.

그라파나 접속을 위해 서비스를 다음과 같이 변경한다.

$ kubectl edit svc prometheus-grafana

 

서비스 타입을 ClusterIP에서 LoadBalancer로 변경한다.

 

그 후 서비스가 게시될때까지 다음 명령어로 기다린다.

$ kubectl get svc -n k8s-prometheus -w
NAME                               TYPE           CLUSTER-IP      EXTERNAL-IP   PORT(S)             AGE
prometheus-alertmanager            ClusterIP      10.108.14.188   <none>        9093/TCP            5m55s
prometheus-alertmanager-operated   ClusterIP      None            <none>        6783/TCP,9093/TCP   5m55s
prometheus-grafana                 LoadBalancer   10.108.7.193    <pending>     80:32718/TCP        5m56s
prometheus-kube-state-metrics      ClusterIP      10.108.15.171   <none>        8080/TCP,8081/TCP   5m57s
prometheus-prometheus              ClusterIP      10.108.11.97    <none>        9090/TCP            5m57s
prometheus-grafana                 LoadBalancer   10.108.7.193    34.64.89.220   80:32718/TCP        6m31s

 

변경이 되면 "EXTERNAL_IP"로 접속한다. 그럼 로그인 화면이 뜬다. 이 로그인 화면의 ID/PW 는 GCP 콘솔에서 "Kubernetes Engine > Application > Prometheus" 에서 찾을 수 있다.

이제 위 정보를 가지고 로그인을 한다. 그러면 다음 화면이 보인다.

그럼 왼쪽 탭의 2번째 아이콘 클릭 후 "Manage"를 누른다.

그 후 아무 대시보드나 들어가도 되지만 "Nodes"에 접속하자.

그럼 노드의 메트릭이 수집되는 것을 확인할 수 있다. 이렇게 매우 간단하게 GKE 내의 리소스를 모니터링할 수 있는 시스템을 갖추게 되었다.

쿠버네티스 로그 모니터링 시스템 구축하기 (1) EFK

이번 절은 GKE에서 진행한다. 이번 절에서는 쿠버네티스의 패키지 매니저라 할 수 있는 Helm Chart를 통해서 k8s 클러스터의 로그를 모니터링할 수 있는 EFK 기반의 시스템을 구축해보자.

 

먼저 Helm Chart를 설치한다. 터미널에 다음을 입력한다.

$ 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
Helm v3.6.3 is available. Changing from version v3.5.0.
Downloading https://get.helm.sh/helm-v3.6.3-linux-amd64.tar.gz
Verifying checksum... Done.
Preparing to install helm into /usr/local/bin
helm installed into /usr/local/bin/helm

$ helm version
version.BuildInfo{Version:"v3.6.3", GitCommit:"d506314abfb5d21419df8c7e7e68012379db2354", GitTreeState:"clean", GoVersion:"go1.16.5"}

 

먼저 실습을 위해서 네임스페이스를 만든다.

$ kubectl create namespace kube-logging
namespace/k8s-efk created

 

이제 Elasticsearch와 Kibana를 설치할 수 있는 Helm 레포지토리를 추가한다.

$ helm repo add elastic https://helm.elastic.co

$ helm repo update

 

그 후 Elasticsearch를 설치한다. 먼저 설치할 Elasticsearch 리소스의 참조 파일인 esvalues.yaml을 다음과 같이 생성한다.

 

src/ch13/k8s/esvalues.yaml

---
service:
  type: LoadBalancer

 

위 파일은 Helm에서 Elasticsearch 리소스를 설치할 때 Service의 타입을 LoadBalancer로 만들게 한다. 기본은 ClusterIP이다. 이제 리소스를 설치하자.

$  helm install elasticsearch elastic/elasticsearch -n kube-logging -f esvalues.yaml
NAME: elasticsearch
LAST DEPLOYED: Mon Aug 30 11:26:17 2021
NAMESPACE: kube-logging
STATUS: deployed
REVISION: 1
NOTES:
1. Watch all cluster members come up.
  $ kubectl get pods --namespace=kube-logging -l app=elasticsearch-master -w
2. Test cluster health using Helm test.
  $ helm test elasticsearch

 

이렇게 helm install을 하게 되면 Elasticsearch를 실행할 때 필요한 모든 리소스가 생성된다. 조금의 시간이 지난 후 터미널에 다음을 입력하자.

$ kubectl get all -n kube-logging
NAME                         READY   STATUS    RESTARTS   AGE
pod/elasticsearch-master-0   1/1     Running   0          2m9s
pod/elasticsearch-master-1   1/1     Running   0          2m8s
pod/elasticsearch-master-2   1/1     Running   0          2m8s

NAME                                    TYPE           CLUSTER-IP   EXTERNAL-IP     PORT(S)                         AGE
service/elasticsearch-master            LoadBalancer   10.8.2.88    34.135.241.35   9200:32144/TCP,9300:30476/TCP   2m10s
service/elasticsearch-master-headless   ClusterIP      None         <none>          9200/TCP,9300/TCP               2m10s

NAME                                    READY   AGE
statefulset.apps/elasticsearch-master   3/3     2m10s

 

StatefulSet으로 3대가 구성되었으며, Service로 묶이는 것을 확인할 수 있다. 이제 시각화 도구인 Kibana를 설치하자. 역시 LoadBalancer로 서비스를 생성하도록 참조 파일인 kivalues.yaml을 생성한다.

 

src/ch13/k8s/kivalues.yaml

---
elasticsearchHosts: "http://elasticsearch-master:9200"
service:
  type: LoadBalancer #ClusterIP=

 

그 후 Helm을 통해서 Kibana를 설치한다.

$ helm install kibana elastic/kibana -n kube-logging -f kivalues.yaml
NAME: kibana
LAST DEPLOYED: Mon Aug 30 11:29:40 2021
NAMESPACE: kube-logging
STATUS: deployed
REVISION: 1
TEST SUITE: None

 

역시 시간이 조금 지난 후 다음 명령어로 생성된 리소스들을 확인할 수 있다.

$ kubectl get all -n kube-logging -l=app=kibana
NAME                                READY   STATUS    RESTARTS   AGE
pod/kibana-kibana-b4dfc69c7-m8bcf   1/1     Running   0          2m40s

NAME                    TYPE           CLUSTER-IP   EXTERNAL-IP     PORT(S)          AGE
service/kibana-kibana   LoadBalancer   10.8.0.168   34.66.232.227   5601:32252/TCP   2m40s

NAME                            READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/kibana-kibana   1/1     1            1           2m41s

NAME                                      DESIRED   CURRENT   READY   AGE
replicaset.apps/kibana-kibana-b4dfc69c7   1         1         1       2m41s

 

이 때 서비스의 "EXTERNAL-IP:PORT"로 접속하면 다음 화면을 확인할 수 있다.

 

이제 쿠버네티스 클러스터의 로그를 수집할 수 있도록 FluentBit을 설치할 것이다. 다음 Helm 레포지토리를 추가한다.

$ helm repo add fluent https://fluent.github.io/helm-charts

$ helm repo update

 

그 후, FluentBit이 참조할 수 있도록 fbvalues.yaml을 다음과 같이 생성한다.

 

src/ch13/k8s/fbvalues.yaml

---
config:
  service: |
    [SERVICE]
        Daemon Off
        Flush 1
        Log_Level {{ .Values.logLevel }}
        Parsers_File parsers.conf
        Parsers_File custom_parsers.conf
        HTTP_Server On
        HTTP_Listen 0.0.0.0
        HTTP_Port {{ .Values.service.port }}
        Health_Check On
  ## https://docs.fluentbit.io/manual/pipeline/inputs
  inputs: |
    [INPUT]
        Name tail
        Path /var/log/containers/*.log
        multiline.parser docker, cri
        Tag kube.*
        Mem_Buf_Limit 5MB
        Skip_Long_Lines On
    [INPUT]
        Name systemd
        Tag host.*
        Systemd_Filter _SYSTEMD_UNIT=kubelet.service
        Read_From_Tail On
  ## https://docs.fluentbit.io/manual/pipeline/filters
  filters: |
    [FILTER]
        Name kubernetes
        Match kube.*
        Merge_Log On
        Keep_Log Off
        K8S-Logging.Parser On
        K8S-Logging.Exclude On
  ## https://docs.fluentbit.io/manual/pipeline/outputs
  outputs: |
    [OUTPUT]
        Name es
        Match kube.*
        Host elasticsearch-master
        Logstash_Format On
        Retry_Limit False
    [OUTPUT]
        Name es
        Match host.*
        Host elasticsearch-master
        Logstash_Format On
        Logstash_Prefix node
        Retry_Limit False
  ## https://docs.fluentbit.io/manual/pipeline/parsers
  customParsers: |
    [PARSER]
        Name docker_no_time
        Format json
        Time_Keep Off
        Time_Key time
        Time_Format %Y-%m-%dT%H:%M:%S.%L

 

그 후 다음 명령어를 이용해 리소스를 생성한다.

$ helm install fluent-bit fluent/fluent-bit -n kube-logging -f fbvalues.yaml
NAME: fluent-bit
LAST DEPLOYED: Mon Aug 30 11:39:05 2021
NAMESPACE: kube-logging
STATUS: deployed
REVISION: 1
NOTES:
Get Fluent Bit build information by running these commands:

export POD_NAME=$(kubectl get pods --namespace kube-logging -l "app.kubernetes.io/name=fluent-bit,app.kubernetes.io/instance=fluent-bit" -o jsonpath="{.items[0].metadata.name}")
echo "curl http://127.0.0.1:2020 for Fluent Bit build information"
kubectl --namespace kube-logging port-forward $POD_NAME 2020:2020

 

이제 다음 명령어를 통해 생성된 리소스를 확인한다. 역시 얼마간의 시간이 필요하다.

$ kubectl get all -n kube-logging -l=app.kubernetes.io/instance=fluent-bit
NAME                   READY   STATUS    RESTARTS   AGE
pod/fluent-bit-7dffk   1/1     Running   0          2m26s
pod/fluent-bit-dwg94   1/1     Running   0          2m26s
pod/fluent-bit-k52vt   1/1     Running   0          2m26s

NAME                 TYPE        CLUSTER-IP    EXTERNAL-IP   PORT(S)    AGE
service/fluent-bit   ClusterIP   10.8.14.207   <none>        2020/TCP   2m27s

NAME                        DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR   AGE
daemonset.apps/fluent-bit   3         3         3       3            3           <none>          2m27s

 

그 후 "Analytics > Discover"에서 "logstash-*"이라는 인덱스를 추가하면 다음 화면을 확인할 수 있다.

"kubernetes" 관련 필드가 생성되어 있다면 성공이다. 뭐 "Canvas"와 "Dashboard"를 이용해서 더 멋진 모니터링 시스템을 구축할 수 있지만 이는 이 문서에서는 진행하지 않는다.