Category: Kubernetes

쿠버네티스에 관한 글들의 모음.

K8S dnstools 사용하기

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

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

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

Gitlab, Helm Chart CI 구축

Gitlab 은 Package Registry 라고 Helm 저장소를 지원한다. Helm Chart 를 만들고 이를 자동으로 빌드해서 Helm 저장소로 Push 하도록 만들어 보자.

Gitlab-runner

Gitlab 은 빌드를 위해서 Runner 라는 별도의 패키지를 소프트웨어를 제공한다. 이렇게 하면 서버를 여러대 둘 수 있고 각 빌드별 특성에 맞는 설정을 가진 Runner 를 셋업할 수 있다.

Helm 을 위해서는 당연히 helm 명령어가 설치되어 있어야 Runner 가 Helm 을 만들때 이용할 수 있다.

gitlab-ci.yml

Gitlab 은 CI 를 위해서 gitlab-ci.yml 파일을 이용한다. 이 파일이 있으면 자동으로 인식해 CI 를 실행해 준다. 이 파일에서 해줘야 할 것은 다음과 같다.

  • git 소스코드 clone
  • helm package 제작
  • gitlab 의 package registry 에 push

여기서 한가지 짚고 넘어가야하는 것이 Gitlab-Runner 는 Gitlab 에 이름으로 등록을 하게 된다. 이것을 이용하기 위해서는 gitlab-ci.yml 에서 지정을 해줘야 한다. 뼈대는 대략 다음과 같다.

기본적인 틀은 위와 같다. only 는 git 브랜치가 main 을 대상으로 한다는 것을 지정한다. tags 는 Gitlab-Runner 를 말한다. 어떤 Runner 를 사용할지는 빌드환경에 따라 다르다. 위의 경우에는 java-runner 인데, Runner 의 타입이 shell 로 되어 있다. 그래서 앞에서 helm 명령어를 설치해줬다.

이제 stage:package 를 완성해야 한다. 다음과 같이 한다.

기본뼈대에서 script 부분에 helm 을 패키징하기 위한 명령어를 넣으면 끝난다.

다음으로 stage:registry 부분은 다음과 같다.

package 를 하고 난후에 패키징된 파일의 확장자는 tgz 이다. 이것을 Shell 환경변수로 만들고 script 명령어에서 사용할 수 있다. curl 명령어중에서 –user 부분에 gitlab-ci-token 과 $CI_JOB_TOKEN 은 이미 정의된 사용자와 변수다. 이것은 Gitlab 에서 별도로 생성하지 않는다. 이미 있는 것이다. URL 에 있는 CI_API_V4_URL 과 CI_PROJECT_ID 도 이미 정의된 변수다. 알아서 맞게 파싱을 해준다.

Harbor, Helm chart 사용하기

Harbor 도 Helm Chart Repository 를 제공한다. 한가지, Harbor 최신 버전에서는 chartmuseum 이 제거 되었다. 과거 버전에서는 chartmuseum 을 플러그인으로 설치해야 Helm Chart 저장소를 사용할 수 있었지만 최신 버전에서는 Helm Chart 저장소가 내장됐다.

변화는 또 있다. Helm Chart 저장소가 OCI 타입이라는 것이다. OCI 타입이면 helm 명령어를 이용하는 방법도 다르다. 먼저, helm repo add 와 같이 repo 관련 명령어는 사용할 수 없다. 또, helm pull 에서 oci:// 를 붙여줘야 한다.

대략 다음과 같이 사용해야 한다.

Gitlab, Helm 저장소 사용하기

Gitlab 은 아주 좋은 툴이다. 단순하게 git 저장소 뿐만 아니라 Container 저장소, Package 저장소를 제공한다. 여기서 Package 저장소가 Helm chart 저장소이다. 이 문서는 Gitlab 에서 Helm 저장소를 이용하는 방법에 대해서 다룬다.

Project

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 를 위한 저장소 두개를 한꺼번에 운영할 수 있게 된다.

helm-employee-role 프로젝트

예를들어 설명하겠다. Gitlab 에서 helm-employee-role 이라는 프로젝트를 생성한다. 그리고 helm chart template 을 Git 코드 저장소에 저장을 한다. 이렇게 되면 다음과 같이 보인다.

Code Repository 에는 Helm Chart 의 텍스트를 저장하게 된다. 이것은 Helm Chart 의 소스코드라고 부르는 형태로 Package Registry 와는 다른 것이다.

이제 Package Registry 를 사용해 보자.

Personal Access Token

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 만 체크해주면 된다.

Publish a package

Gitlab 공식문서에는 Package Registry 에 Helm 을 올리는 것을 Publish 라고 표현하고 있다. 다음과 같은 방법으로 publish 한다.

결과가 성공적으로 생성이되었음을 알려주고 있다. 실제로 잘 되었는지를 Gitlab 웹 화면을 통해서 보면 다음과 같다.

위와 같이 나온다. 클릭해서 들어가면 다음과 같이 보인다.

아직 처음이라 별 내용은 보이지 않는다. 한가지, 저장되는 형태가 helm package 형태라는 것.

Gitlab 에 Helm 저장소 사용하기

Gitlab 의 Package Registry 에 Publish 가 되었으니 이제, 이것을 Helm 에서 사용해 봐야 한다.

위와같이 helm 을 사용할때에 Gitlab 저장소를 이용할 수 있다.

여기서 한가지 더, Gitlab 의 Package Registry 는 OCI 타입의 저장소가 아니다. 최근의 Harbor 의 경우, Helm Chart 저장소는 OCI 타입을 지원한다. OCI 타입을 Helm 에서 사용할 경우에 helm repo 명령어를 사용하지 않는다.

kubeadm join 시 discovery-file 이용하기

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

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

Discovery-file 만들기

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

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

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

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

CSR Approved

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

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

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

Token 확인

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

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

Token 생성

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

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