Ingress-Nginx 설치
Kubernetes 에서 인기있는 Ingress Controller 로 Nginx 가 있다. 설치는 Helm 을 이용하면 된다.
Continue reading쿠버네티스에 관한 글들의 모음.
Kubernetes 에서 인기있는 Ingress Controller 로 Nginx 가 있다. 설치는 Helm 을 이용하면 된다.
Continue readingHelm 을 이용해 kube-prometheus-stack 을 설치하게 되면, Grafana 를 통해서 통계 그래프를 볼 수 있다. 그런데, 몇몇 대쉬보드는 나타나지 않는데 여기서는 이 문제를 해결하는 방법을 알아본다.
Continue reading기존에 prometheus 설치를 했었는데, 버전을 올릴겸해서 다시 설치를 했다. 설치는 Helm 을 이용했고, 기존에 설치된 버전을 삭제 처리 했다.
Continue readingK8S 를 사용하다보면 여러가지 검증을 위해 Pod 를 필요로 하는 경우가 있는데, dnstools 이 유용하다. 다음과 같이 사용할 수 있다.
1 |
~$ kubectl run -it --rm --restart=Never --image=infoblox/dnstools:latest dnstools |
Pod 가 생성되면서 dnstools 컨테이너에 진입하게 되고 exit 를 하게 되면 Pod 는 삭제된다.
혹은 curl 이미지를 이용하는 방법도 있다.
1 |
~$ kubectl run curl -it --rm --image curlimages/curl -- sh |
과거 Metallb 의 버전이 0.10 이였고 K8S 버전도 1.32 이여서 최신 버전으로 다시 설치를 해봤다.
Continue readingGitlab 은 Package Registry 라고 Helm 저장소를 지원한다. Helm Chart 를 만들고 이를 자동으로 빌드해서 Helm 저장소로 Push 하도록 만들어 보자.
Gitlab 은 빌드를 위해서 Runner 라는 별도의 패키지를 소프트웨어를 제공한다. 이렇게 하면 서버를 여러대 둘 수 있고 각 빌드별 특성에 맞는 설정을 가진 Runner 를 셋업할 수 있다.
Helm 을 위해서는 당연히 helm 명령어가 설치되어 있어야 Runner 가 Helm 을 만들때 이용할 수 있다.
1 2 3 |
]$ curl -fsSLO https://get.helm.sh/helm-v3.14.2-linux-amd64.tar.gz ]$ tar xvzf helm-v3.14.2-linux-amd64.tar.gz ]$ sudo mv helm /usr/local/bin/; sudo chmod +x /usr/local/bin/helm |
Gitlab 은 CI 를 위해서 gitlab-ci.yml 파일을 이용한다. 이 파일이 있으면 자동으로 인식해 CI 를 실행해 준다. 이 파일에서 해줘야 할 것은 다음과 같다.
여기서 한가지 짚고 넘어가야하는 것이 Gitlab-Runner 는 Gitlab 에 이름으로 등록을 하게 된다. 이것을 이용하기 위해서는 gitlab-ci.yml 에서 지정을 해줘야 한다. 뼈대는 대략 다음과 같다.
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 |
stages: - package - registry helm-package: stage: package scripts: - "" artifacts: paths: - "*.tgz" after_script: - echo 'build success!' tags: - java-runner only: - main helm-registry: stage: registry dependencies: - helm-package scripts: - "" tags: - java-runner only: - main |
기본적인 틀은 위와 같다. only 는 git 브랜치가 main 을 대상으로 한다는 것을 지정한다. tags 는 Gitlab-Runner 를 말한다. 어떤 Runner 를 사용할지는 빌드환경에 따라 다르다. 위의 경우에는 java-runner 인데, Runner 의 타입이 shell 로 되어 있다. 그래서 앞에서 helm 명령어를 설치해줬다.
이제 stage:package 를 완성해야 한다. 다음과 같이 한다.
1 2 3 4 5 6 7 8 9 10 11 12 13 |
helm-package: stage: package script: - "/usr/local/bin/helm package ." artifacts: paths: - "*.tgz" after_script: - echo 'build success!' tags: - java-runner only: - main |
기본뼈대에서 script 부분에 helm 을 패키징하기 위한 명령어를 넣으면 끝난다.
다음으로 stage:registry 부분은 다음과 같다.
1 2 3 4 5 6 7 8 9 10 11 12 |
helm-registry: stage: registry dependencies: - helm-package before_script: - PACKAGE=`ls *.tgz` script: - 'curl --request POST --form "chart=@${PACKAGE}" --user gitlab-ci-token:$CI_JOB_TOKEN "${CI_API_V4_URL}/projects/${CI_PROJECT_ID}/packages/helm/api/stable/charts"' tags: - java-runner only: - main |
package 를 하고 난후에 패키징된 파일의 확장자는 tgz 이다. 이것을 Shell 환경변수로 만들고 script 명령어에서 사용할 수 있다. curl 명령어중에서 –user 부분에 gitlab-ci-token 과 $CI_JOB_TOKEN 은 이미 정의된 사용자와 변수다. 이것은 Gitlab 에서 별도로 생성하지 않는다. 이미 있는 것이다. URL 에 있는 CI_API_V4_URL 과 CI_PROJECT_ID 도 이미 정의된 변수다. 알아서 맞게 파싱을 해준다.
Harbor 도 Helm Chart Repository 를 제공한다. 한가지, Harbor 최신 버전에서는 chartmuseum 이 제거 되었다. 과거 버전에서는 chartmuseum 을 플러그인으로 설치해야 Helm Chart 저장소를 사용할 수 있었지만 최신 버전에서는 Helm Chart 저장소가 내장됐다.
변화는 또 있다. Helm Chart 저장소가 OCI 타입이라는 것이다. OCI 타입이면 helm 명령어를 이용하는 방법도 다르다. 먼저, helm repo add 와 같이 repo 관련 명령어는 사용할 수 없다. 또, helm pull 에서 oci:// 를 붙여줘야 한다.
대략 다음과 같이 사용해야 한다.
1 2 3 |
$ helm registry login https://harbor.systemv.local/charts --ca-file /etc/docker/certs.d/harbor.systemv.local/ca.crt --username systemv --password 14321 $ helm registry push hello-helm-0.1.0.tgz https://harbor.systemv.local/charts/hello-helm:1.0.0 $ helm pull oci://harbor.systemv.local/charts/hello-helm --version 0.1.0 |
Gitlab 은 아주 좋은 툴이다. 단순하게 git 저장소 뿐만 아니라 Container 저장소, Package 저장소를 제공한다. 여기서 Package 저장소가 Helm chart 저장소이다. 이 문서는 Gitlab 에서 Helm 저장소를 이용하는 방법에 대해서 다룬다.
Gitlab 은 기본적으로 소스코드를 저장하기 위한 카테고리로 Project 를 만든다. 이렇게 하는 이유는 Gitlab 은 다양한 저장소 타입을 제공하기 때문에 딱히 Git 저장소 라고 불리기도 애매하기 때문이다. Gitlab 은 Git 명령어를 이용하지만 저장소는 Git, Container, Package, Terraform states, Terraform modules 등을 제공한다.
여기서 Helm 저장소를 Package Registry 로 부른다. 한가지 짚고 넘어가야하는 것은 Package Registry 는 소스코드를 저장하는 것이 아닌 Helm 의 Package 형태를 그대로 저장하는 것이다. Helm Package 라는 것이 Helm template 의 텍스트 파일을 압축한 형태의 결과물이고 이를 수정하기 위해서는 Helm chart 의 소스코드 형태로 가지고 있어야 한다.
Gitlab 은 텍스트 형태의 Git 저장소, Package Registry 를 하나의 프로젝트에서 관리할 수 있기 때문에 Helm Chart 를 위한 저장소 두개를 한꺼번에 운영할 수 있게 된다.
예를들어 설명하겠다. Gitlab 에서 helm-employee-role 이라는 프로젝트를 생성한다. 그리고 helm chart template 을 Git 코드 저장소에 저장을 한다. 이렇게 되면 다음과 같이 보인다.
Code Repository 에는 Helm Chart 의 텍스트를 저장하게 된다. 이것은 Helm Chart 의 소스코드라고 부르는 형태로 Package Registry 와는 다른 것이다.
이제 Package Registry 를 사용해 보자.
Gitlab 에는 Access Token 이 존재한다. 이는 Personal, Project, CI/CD Access Token 으로 세가지 형태가 있다. 각 Access Token 은 용도에 맞게 사용하게 되는데, 아무래도 Personal Access Token 이 권한 제약이 많다. 꼭 필요한 권한만을 가지고 있는 것이고, 보안상 최소한의 권한만을 부여한다는 방침을 따른다면 Personal Access Token 이 제일 적합하다.
Gitlab 에 로그인하고 ‘User settings -> Access Tokens’ 에서 토큰을 발행할 수 있다. 이때 스코프(Scope) 라고해서 Token 의 권한을 부여해야하는데, api 만 체크해주면 된다.
Gitlab 공식문서에는 Package Registry 에 Helm 을 올리는 것을 Publish 라고 표현하고 있다. 다음과 같은 방법으로 publish 한다.
1 2 3 4 5 |
]$ curl --request POST \ --form 'chart=@employee-role-0.1.0.tgz' \ --user systemv:glpat--W9yNk-99PLCrE8vrgSx \ https://gitlab.systemv.local:8001/api/v4/projects/23/packages/helm/api/stable/charts {"message":"201 Created"} |
결과가 성공적으로 생성이되었음을 알려주고 있다. 실제로 잘 되었는지를 Gitlab 웹 화면을 통해서 보면 다음과 같다.
위와 같이 나온다. 클릭해서 들어가면 다음과 같이 보인다.
아직 처음이라 별 내용은 보이지 않는다. 한가지, 저장되는 형태가 helm package 형태라는 것.
Gitlab 의 Package Registry 에 Publish 가 되었으니 이제, 이것을 Helm 에서 사용해 봐야 한다.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 |
]$ helm repo add --username systemv --password glpat--W9yNk-99PLCrE8vrgSx helm-employee-role https://gitlab.systemv.local:8001/api/v4/projects/23/packages/helm/stable "helm-employee-role" has been added to your repositories ]$ helm repo list NAME URL helm-employee-role https://gitlab.systemv.local:8001/api/v4/projects/23/packages/helm/stable ]$ helm search repo helm NAME CHART VERSION APP VERSION DESCRIPTION helm-employee-role/employee-role 0.1.0 1.16.0 A Helm chart for Kubernetes ]$ helm install employee-role helm-employee-role/employee-role --version 0.1.0 NAME: employee-role LAST DEPLOYED: Sun Feb 18 22:32:50 2024 NAMESPACE: default STATUS: deployed REVISION: 1 TEST SUITE: None ]$ helm list NAME NAMESPACE REVISION UPDATED STATUS CHART APP VERSION employee-role default 1 2024-02-18 22:32:50.463004041 +0900 KST deployed employee-role-0.1.0 1.16.0 |
위와같이 helm 을 사용할때에 Gitlab 저장소를 이용할 수 있다.
여기서 한가지 더, Gitlab 의 Package Registry 는 OCI 타입의 저장소가 아니다. 최근의 Harbor 의 경우, Helm Chart 저장소는 OCI 타입을 지원한다. OCI 타입을 Helm 에서 사용할 경우에 helm repo 명령어를 사용하지 않는다.
새로운 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 값을 알아내는 명령어를 사용한다.
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 을 이용하는 방법도 있다. 이는 kube-public 네임스페이스에 ConfigMap 에서 cluster-info 의 정보를 가지고 오면 된다. 다음과 같다.
1 |
]$ kubectl get cm cluster-info -o json -n kube-public | jq -r '.data.kubeconfig' > discovery-file.yaml |
위 파일을 추가하고자 하는 새로운 Worker 노드에 복사해준다.
이제 discovery-file 를 이용해 새로운 Worker 노드를 추가할 수 있다. 다음과 같다.
1 |
]$ sudo kubeadm join --tls-bootstrap-token=jt0pr4.d57slk512u0c9dj8 --discovery-file=./discovery-config.yaml |
이렇게 한 후에 csr 을 보면 pending 상태의 인증서들이 보인다. 이를 Approved 해주면 된다.
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 |
쿠버네티스(Kubernetes) 를 운영하다가 새로운 Worker 노드를 추가할때에 kubeadm 명령어와 함께 join 옵션을 함께 쓴다. 이때 token 값과 hash 값을 줘야 하는데, 최초 설치할때에 값을 출력해주지만 시간이 지나서 잃어버리면 어떻게 해야 할까..
불행하게도 Token 값은 영구적이지 않다. 어디다 잘 적어놨어도 시간이 지나면 자동으로 폐기되도록 되어 있다.
1 2 |
]$ kubeadm token list ]$ |
아무것도 안나온다. 이는 자동 폐기 됐기 때문이다.
Token 값을 확인할 수 없다면 새로운 worker 노드를 추가할 수 없다. 아니, 정확하게는 Token 값을 이용해 추가할 수 없다. Token 값을 이용하기 위해서는 새로운 Token 값을 만들어 주면 된다.
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 |
위와같이 새로운 토큰이 생성되었다. 만료일이 기재되어 있어 이 기간동안만 유효하다.