[Kubernetes] 홈 서버에 minikube 환경 구축하기 4 - Kubernetes Dashboard 배포 + Nginx Gateway Fabric 연동

mrcocoball·2024년 11월 10일

KubernetesDashboard NginxGatewayFabric kubernetes minikube

Kubernetes

목록 보기

8/8

개요

클라우드 환경에서 관리형 쿠버네티스 서비스를 사용할 경우 현재 관리 중인 클러스터에 대한 전반적인 모니터링 대시보드를 제공한다.
보통 노드 / 네임스페이스 / 워크로드의 상태나 이벤트 등을 볼 수 있는데 메트릭이나 로깅 등은 Prometheus-Grafana, Fluentbit / Fluentd 등을 따로 세팅해서 봐야 하지만 그래도 전반적인 현황을 볼 수 있어서 요긴하게 쓰인다.

이러한 대시보드는 쿠버네티스에서도 기본적으로 제공을 하고 있는데, minikube만 해도 가이드라인에 대시보드 플러그인을 설치하는 항목이 나와 있으며, 설치가 매우 간단한 편이다.

다만 일반적으로 나와 있는 가이드라인에서는 대시보드를 배포하고 Kong Proxy의 포트를 포트 포워딩하여 웹에서 접근하도록 하고 있으나, 앞서 필자는 Nginx Gateway Fabric을 배포하였으므로 그런 과정이 필요가 없게 되었다.

Kubernetes Dashboard 배포

필자는 Helm을 통해 Kubernetes Dashboard를 배포하였는데, 관리 용이성을 위해 values.yaml을 커스텀하는 식으로 설정하였다.
(물론 건드린 부분은 딱 한 군데 뿐이지만...)

일단 Helm Repo를 추가해야 한다.

helm repo add kubernetes-dashboard https://kubernetes.github.io/dashboard/

Helm Repo를 추가했다면 다음 values.yaml을 작성한다. 여기서 변경된 부분은 Kong Proxy에 대한 설정인데, 이유는 후술한다.
참고로 Kong Proxy는 Kubernetes Dashboard의 인증, API, 웹 서비스 엔드포인트를 하나로 묶으면서 SSL 접근하도록 도와주는 역할을 한다.

# https://github.com/kubernetes/dashboard/blob/master/charts/kubernetes-dashboard/values.yaml

kong:
  proxy:
    http:
      enabled: true

그리고 Dashboard에 대한 접근 제어를 위해 ServiceAccount, ClusterRoleBinding, Secert 리소스를 작성한 후 배포한다.

# dashboard-sa.yaml
apiVersion: v1
kind: ServiceAccount
metadata:
  name: admin-user
  namespace: kubernetes-dashboard

# dashboard-sa-crb.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

# dashboard-sa-secret.yaml
apiVersion: v1
kind: Secret
metadata:
  name: admin-user
  namespace: kubernetes-dashboard
  annotations:
    kubernetes.io/service-account.name: "admin-user"   
type: kubernetes.io/service-account-token

kubectl apply -f dashboard-sa.yaml
kubectl apply -f dashboard-sa-crb.yaml
kubectl apply -f dashboard-sa-secret.yaml

모든 준비가 끝났다면 helm install을 통해 배포한다.

helm install kubernetes-dashboard/kubernetes-dashboard --name kubernetes-dashboard -f values.yaml

잘 배포가 되었는지 확인을 하려면 kubectl get all -n kubernetes-dashboard 로 확인하면 된다.
여기서 kong.proxy.http.enabled=true 를 했기 때문에 kubernetes-dashboard-kong-proxy의 포트가 80, 443 2개가 열린 것을 확인할 수 있다 (원래는 443 포트만 열린다)

Nginx Gateway Fabric과의 연동

일반적으로 Nginx Gateway Fabric이나 Nginx Ingress Controller가 없었다면 kubernetes-dashboard-kong-proxy를 포트 포워딩한 후, 이를 홈 서버의 Nginx에서 도메인 이름으로 분기 처리하여 연결했을 것이다.

하지만 이미 Nginx Gateway Fabric이 있기 때문에 HTTPRoute를 통해 Gateway에서 Kubernetes Dashboard로 요청을 넘길 수 있다.
이를 위해 HTTPRoute 리소스 명세와 ReferenceGrant 리소스 명세를 작성한다.
(ReferenceGrant 리소스는 Gateway에게 요청을 받는 서비스 쪽에서도 Gateway를 참조할 수 있게 해주는 리소스이다)

# dashboard-httproute.yaml
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: dashboard-httproute
spec:
  parentRefs:
    - name: gateway
      sectionName: https
  hostnames:
    - "testdashboard.cocoball.info"
  rules:
    - matches:
        - path:
            type: PathPrefix
            value: /
      backendRefs:
        - name: kubernetes-dashboard-kong-proxy
          namespace: kubernetes-dashboard
          port: 80

# dashboard-referencegrant.yaml
apiVersion: gateway.networking.k8s.io/v1beta1
kind: ReferenceGrant
metadata:
  name: kubernetes-dashboard-kong-proxy
  namespace: kubernetes-dashboard
spec:
  from:
    - group: gateway.networking.k8s.io
      kind: HTTPRoute
      namespace: default
  to:
    - group: ""
      kind: Service

명세를 확인해보면, 다음 규칙에 대해

Gateway 리스너(parentRefs에서 지정한 gateway)에서 https 요청
호스트 헤더가 'testdashboard.cocoball.info'
path 규칙이 /인 것

다음과 같이 라우팅한다.

kubernetes-dashboard 네임스페이스의 kubernetes-dashboard-kong-proxy의
80번 포트로 라우팅

여기서 443번 포트가 아닌 80번 포트로 지정을 한 이유는, 현재 Gateway의 리스너 설정에서 HTTPS 프로토콜의 경우, TLS 모드가 'Terminate' 뿐이라서 백엔드 서비스로 요청을 전달할 때엔 TLS가 종료되기 때문에 Kong Proxy의 기본 설정 포트인 443 포트로 전달될 때 Bad Request가 발생하기 때문이다.

TLS Passthrough를 위한 TLSRoute와 BackendTLSPolicy 리소스의 경우 앞서 설명했던 것처럼 stable 버전이 아닌 실험 버전에 존재하기 때문에 아직 사용할 수 없어서 이렇게 처리를 했다. 만약 TLSRoute, BackendTLSPolicy가 stable 버전에도 업데이트가 된다면 설정을 변경해볼 예정이다.

어쨌든 위의 설정으로 다음과 같은 흐름으로 대시보드에 접근이 가능해진다.

Cloudflare에서 홈 서버의 Public IP에 CNAME으로 testdashboard.cocoball.info를 연결
testdashboard.cocoball.info로 접근 시 Nginx에서 Nginx Gateway Fabric (443번 포트)으로 라우팅
Nginx Gateway Fabric의 Gateway 리스너 (443번 포트) 는 이 요청을 TLS 종료 상태로 전달
HTTPRoute는 Gateway 리스너로부터 매칭 조건에 맞는 요청을 전달 받아서 Kubernetes Dashboard로 라우팅

대시보드 접속

도메인 주소를 통해 접근하면 로그인 페이지가 노출되는데, 여기서 토큰은 다음 명령어로 확인해서 입력할 수 있다.

kubectl get secret admin-user -n kubernetes-dashboard -o jsonpath={".data.token"} | base64 -d

다음 내용은

홈 서버의 가용 자원이 아주 크지 않아서 좀 더 고려를 해보긴 해야겠지만... 만약 추가를 한다면 다음 내용이 될 것 같다.

메트릭 확인 및 모니터링을 위한 Prometheus, Grafana 배포
GitOps를 위한 ArgoCD
로깅 파이프라인

다만 Prometheus가 생각보다 리소스를 많이 사용해서 홈 서버에 무리를 주지 않을지 좀 확인이 필요할 것 같다.
ArgoCD의 경우에도 현재 사이드 프로젝트가 많지 않아서 GitOps까지 적용해야 하나 싶긴 하고...
로깅 파이프라인의 경우 로그를 저장할 백엔드를 Elasticsearch를 썼었는데 이것도 리소스를 많이 사용해서.... 잘 모르겠다.

mrcocoball

Backend Developer

이전 포스트