letsencrypt 인증서 발급/갱신

letencrypt 는 무료로 발급 받을 수 있는 도메인 인증서이다. 도메인 인증서는 서버와 클라이언트간에 HTTP 통신을 암호화하는데 필요한 것이다. 원래는 돈을 주고 구매해야 하지만 letsencrypt 는 무료로 사용할 수 있게 해준다.

대부분의 발급 절차를 서버의 CLI 를 통해서 이루어진다. 따라서 서버가 있어야 하며 터미널 접속이 가능해야 한다. 또, Python 을 필요로 한다. 인증서를 발급 받기위해서 프로그램을 사용하는데 이것이 Python 을 필요로 한다.

certbot 설치

certbot 은 letsencrypt 인증서를 발급받기 위한 CLI 명령어 세트다. 다음과 같이 다운로드 할 수 있다.

복제된 디렉토리에는 letsencrypt 인증서를 위한 모든 내용이 포함되어 있다.

주도메인, 멀티도메인

발급 받기전에 한가지 생각해봐야 할게 있다. 인증서는 주도메인 인증서와 멀티도메인 인증서로 크게 나뉜다. 예를들면 다음과 같다.

  • systemv.pe.kr – 주도메인 인증서
  • *.systemv.pe.kr – 멀티도메인 인증서

많은 사람들이 실수하는 것이 멀티도메인 인증서를 발급받고 systemv.pe.kr 도메인으로 접속할려고 한다는 것이다. 멀티도메인 인증서의 *. 이것이 주도메인을 포함하지 않는다. 따라서 반드시 따로 도메인 인증서를 발급 받아야 한다.

수동 도메인 인증서 발급

도메인 인증서를 발급 받를때에 해줘야 하는 거이 Validation 이다. 이것이 실제로 인증서를 사용 가능한 발급요청인지를 체크한다. 이 체크를 위한 방법은 두가지가 있다.

  1. DNS TXT 레코드를 이용.
  2. HTTP 를 이용한 특정 디렉토리에 파일 접근.

멀티 도메인 인증서를 발급 받을때는 DNS TXT 레코드를 이용하는 방법이 좋다. 주도메인(단일도메인) 을 발급 받을때는 HTTP 를 이용한 파일 접근으로 유요한 요청인지를 인증하면 된다.

발급을 위해서 시스템의 슈퍼유저 계정으로 실행 한다.

위와같이 특정 디렉토리에 외부에서 접근 가능한 파일을 작성해 위에서 출력한 데이터를 작성하고 저장한다. 이렇게 한 후에 진행을 하면 Letsencrypt 에서 파일에 접근해 유요한 요청인지를 확인하고 인증서를 발급해 준다.

멀티도메인처럼 하나의 인증서로 여러 도메인을 인증하기 위해선 DNS TXT 레코드 인증을 이용하는 것이 편하다.

위와같이 하면 화면에 TXT 레코드를 입력하라는 메시지가 나온다. 그것을 다음과 같이 DNS 에 입력해 준다.

_acme-challenge.systemv.pe.kr 도메인으로 하는 TXT 를 입력해 주는 것이다. 그리고 반드시 DNS 서버를 재시작해 적용해 준다.

정상적으로 발급이 되었다면 /etc/letsencrypt/live 디렉토리에 도메인으로 디렉토리가 생성되고 인증서가 발급된다.

Tomcat 서버 로케일 설정

Windows 에서 Tomcat 9 서버를 CMD 에서 시작하면 화면에 뿌려지는 로그들이 한글이 깨진채 표시가 된다. 이것은 한글 로케일로 되어 있어서 Tomcat 서버가 한글로 뿌려주지만 CMD 가 한글을 표시할 수 없어 생기는 문제다.

이 문제를 해결하는 방법은 간단하다. CMD 의 로케일을 다음과 같이 변경해 주면 된다.

65001 은 UTF-8 을 의미한다. 이렇게 변경한 후에 Tomcat 을 재 실행하면 한글이 제대로 표시 된다.

하지만 Tomcat stdout 로그를 영문으로 바꾸고자 한다면 위 방법으로 되지 않는다. 이것은 Tomcat 서버가 Windows 10 의 기본 로케일을 자동으로 인식해 적용하기 때문이다. 만일 이것을 영문으로 바꾸고자 한다면 다음과 같이 해야 한다.

JAVA_OPTS 환경 변수에 user.language, region 을 정의해 주면 된다. 그러면 Tomcat 서버가 구동될때에 JAVA 파라메터로 추가해 로케일을 적용해 주면 UTF-8 에 Windows 10 에 로케일을 버리고 English 언어와 US 로케일이 적용되어 영문으로 로그가 출력된다.

Kubernetes, Terminated 테스트

Pod 의 Terminated 테스트를 위한 테스트 배포는 다음과 같다.

위 Manifest 를 배포하면 Pod 의 Terminated 를 테스트 할 수 있다.

Kubernetes 에 Grafana 설치

Grafana 는 TimeSeries 데이터베이스의 데이터를 불러와 시각화를 해주는 솔루션이다. 특히 TimeSeries 데이터베이스 Prometheus를 지원하고 있어 Kubernetes 에 각종 메트릭을 Grafana 로 시각화해서 볼 수 있다.

이번에는 Kubernetes 에 Grafana 설치 에 대해서 다룬다. Grafana 설치를 하기전에 Prometheus 가 이미 설치되어 있어야 한다.

Grafana 를 위한 PV, PVC

Grafana 도 데이터파일을 가지고 있다. 각종 그래프 정보과 설정 내용들을 저장하기위해 데이터파일을 사용한다. 이 데이터파일의 위치는 특별하게 지정하지 않는한 /var/lib/grafana 이며 이것을 PV 에 마운트해 영구저장소에 저장되도록 하면 된다.

knode 에 /opt/grafana 디렉토리를 마운트 하도록 했다. 그리고 PVC 가 반납되더라도 PV 는 데이터를 그대로 유지하도록 retain 으로 설정했다. 이제 생성해 준다.

정상적으로 생성이 되었다면 PVC 의 상태가 Bound 로 보인다.

Secret 생성

Kubernetes 는 Secret 객체를 제공 한다. 이것을 이용하면 패스워드와 같은 비밀이 필요한 필드 값들을 암호화해서 저장할 수 있다. 이렇게 하는 이유는 Pod 에 배포되는 소프트웨어들은 비상태여야 하며 언제든지 Pod 는 삭제되어 질 수 있어야 하기 때문에 각종 설정에 필요한 파라메터들도 외부에서 관리되어져야 한다.

Grafana 설치를 하는데 있어 Secret 를 이용하는 이유는 Grafana 의 관리자 계정 때문이다. 아무나 Grafana를 조작하지 못하도록 계정 정책을 가지고 있는데, ID 와 패스워드를 발급해야 한다. 관리자의 경우에 ID 는 admin 이고 패스워드는 설치할때에 지정해 줄 수 있는데 이것을 Kubernetes 의 Secret 으로 등록해 Pod 가 생성될때에 적용되게 한다.

Secret 은 Key – Value 쌍으로 간단하게 정의할 수 있다. 다음과 같이 적용한다.

Grafana Deployment

PV, Secret 을 생성했다면 이제 Deployment 를 만들어 Pod 를 생성해보자. Deployment 에는 Secret, PV 를 적용시켜야 한다.

nodeSelector 를 이용해 knode 에 생성하도록 했다. 앞에서 생성한 PVC 를 사용하도록 했으며 secretKeyRef 를 이용해 Grafana 의 변수에 Secret 에 초기 아이디, 패스워드를 지정해주고 있다.

다음과 같이 적용해 준다.

NodePort 서비스 생성

Grafana 가 제대로 설치되었는지를 확인하기 위해서 외부에서 접속이 되도록 NodePort 로 Service 를 생성해 보자.

Service 에 대한 포트는 3000 이며 Pod 에 포트도 3000 이여서 targetPort 를 3000 으로 지정했다. 그리고 nodePort 를 30004 으로 지정했다.

다음과 같이 적용해 준다.

이렇게 하면 Kmaster 서버의 IP:30004 로 웹 접속을 하면 Grafana 화면이 보여야 한다.

Grafana 에서 Prometheus 데이터소스 추가

Grafana 와 Prometheus 는 Kubernetes 상에서 작동되고 있다. Kubernetes 에서 서비스에 접속을 하기 위해서는 Service 객체에 등록해 IP와 Port를 할당하면 Kubernetes Cluster 내에서는 Service 객체에 등록한 IP:Port 로 접속이 가능하다.

Grafana 에 성공적으로 접속을 했다면 TimeSeries 데이터소스를 추가해줘야 한다. Prometheus 를 지원하고 있기 때문에 접속 URL 을 입력해줘야 하는데, 이때 Prometheus 가 Kubernetes 상에서 작동되고 있다는 것을 상기해야 하며 Service 객체에 등록되어 Cluster IP:Port 를 입력해 줘야 한다.

Service 객체를 확인한다.

확인된 내용은 10.103.84.171 과 8080 이다. 이것이 Prometheus 에 Cluster 내에 접속 지점이 된다.

Kubernetes Monitoring – Prometheus 설치

이 글은 Kubernetes 에 모니터링을 위해 Prometheus 설치에 대한 것이다. Kubernetes 는 여러가지 오브젝트들과 컴포넌트들로 구성 된다. 각각에 구성요소들은 컴퓨터의 자원을 사용하게 되는데 이러한 자원 사용량은 metric-server 를 설치함으로써 CLI 를 통해서 실시간으로 모니터링이 가능하다.

하지만 CLI 를 하나하나 다 치면서 하는데에는 한계가 있어, 각종 구성요소들의 자원 사용량을 데이터베이스로 저장하고 이것을 기반으로 그래프로 보여주는 것이 훨씬 좋을 것이다. 특히나 각종 자원의 모니터링은 시인성이 아주 좋아야 하는게 핵심이기도 한데 Kubernetes 는 이를 위해서 Prometheus 를 공식적(?) 으로 밀고 있다.

Prometheus

프로메테우스(Prometheus) 는 한 회사에서 만들기 시작해 오픈소스화 되었으며 현재는 Kubernetes 를 제작지원하는 CNCF(Cloud Native Computing Foundation) 의 두번째 프로젝트다. 이렇게 되면 당연히 Kubernetes 에서 Prometheus 는 거의 표준 모니터링 시스템이라고 봐야 한다.

인터넷을 검색해보면 위와같은 그림을 볼 수 있는데, 처음 접하는 사람들은 당연히 이게 뭔지 잘 모른다. Prometheus 를 이루는 기본 요소는 단 두개다.

  1. Prometheus Server
  2. Node Exporter

간단하게 Server/Client 구조를 가지는 것인데, 특이한 것은 Prometheus Server 가 데이터를 가지고 오는 방법이다. Node Exporter 는 어떤 정보를 수집할지에 대해서 정의를 해두고 정해진 시간마다 정보를 수집한다. 그리고네트워크를 통해서 Prometheus Server 가 가지고 갈 수 있도록 네트워크 데몬으로 존재한다.

Prometheus Server 는 Node Exporter 목록을 가지고 있으면서 주기적으로 접속해서 데이터를 긁어온다. 이렇게 긁어온 데이터는 Prometheus 가 TimeSeries 데이터베이스로 저장하게 된다.

위 그림에 왼쪽 아래쪽에 KUBERNETES NODES 로 향하는 화살표에 Pull 이라고 적혀있는데, 이것이 Prometheus 가 Node Exporter 에 접속해 데이터를 긁어오는 것을 말하는 것이다.

metric-server, metric-state-server

Kubernetes 는 자신의 상태를 자동으로 모니터링해서 보여주지 않는다. 이것도 관리자가 설치해야 한다. 이를 위해서 인터넷을 검색해보면 다음과 같이 두가지 정도가 나온다.

  • metric-server
  • kube-state-metrics

metric-server 는 Kubernetes 자신에 대한 자원 모니터링으로 Node, Pod 등의 자원을 모니터링 한다. 이것은 Resource Metrics API 를 구현한 것으로 보면 된다. 이를 설치하면 HPA(Horizontal Pod Autoscaler), Scheduler 등에서 활용하게 된다.

HPA, Scheduler 등은 실시간으로 CPU, Memory 등에 변화를 감지해야 하며 이를 통해서 액션을 취해야하기 때문에 Kubernetes 의 Health 상태도 더블어 체크 된다. 자원이 Health 상태가 되지 않는다면 Kubernetes 의 상태를 Unknown 으로 바꾸놓을 가능성이 있다. 그리고 이 상태가 지속되면 Terminated 시켜버리고 다른 오브젝트를 올릴려고 할 것이다.

문제는 Prometheus 에서 이들에 대해서 스크랩을 할 수 없다는데 있다.

kube-state-metrics 는 Kubernetes 자원의 Health 상태를 전혀 고려하지 않는다. 그냥 자원에 대한 정보를 뿌려줄뿐이고 어떤 원인으로 인해서 자원 모니터링이 안된다면 그냥 정보를 안 뿌려준다. 따라서 이렇게 되며 이것을 가지고 HPA, Scheduler 에서 사용하기가 불가능해진다.

대신, kube-state-metrics 는 Prometheus 에서 스크랩이 가능하다. 따라서 Prometheus 를 이용한 모니터링을 구축하기 위해서는 반드시 kube-state-metrics 를 설치해주는 걸 권장한다.

kube-state-metrics 설치

Prometheus 설치의 시작은 kube-state-metrics 설치로부터 시작 된다. 이것이 없으면 Prometheus 설치/운영을 못하는 것은 아니지만 Kubernetes 의 컴포넌트의 자세한 정보를 가지고 올 수 없다.

설치는 kube-state-metrics 의 GitHub 를 이용하면 간단하게 해결된다. 한 가지 주의해야 할 것은 Kubernetes 버전을 확인해 지원되는 버전을 설치해야 한다는 것이다.

소스코드를 clone 한 후에 다음과 같이 설치를 해준다. Kubernetes 가 최신버전이라 별도의 작업은 필요 없다.

정상적으로 설치가 되었다면 kube-system 네임스페이스에 pod 가 보인다.

Prometheus 설치

먼저 Prometheus 설치하는 방법에는 다양한 방법이 존재한다. helm 을 이용해도 되고 Prometheus Operator 를 이용해도 된다. 하지만 수동으로 설치를 해봐야 Kubernetes 에서 프로그램 배포를 위해서 필요한 것들이 무엇인지를 알게 된다. 따라서 여기서는 모든걸 수동으로 한번 해보도록 하겠다.

계획

일단, 계획이 필요한데 뭔가 대단한게 아니라 Prometheus 를 운영하는데 필요한 설정과 파일들을 어떻게 할 것인가에 대한 것이다.

먼저, Prometheus 를 위한 네임스페이스를 별도로 만든다. Kubernetes 는 네임스페이스 개념이 존재한다. 일종의 격리되는 그룹같은 것인데, Prometheus 를 위한 네임스페이스로 montoring 을 만들 것이다.

Prometheus 는 설정 파일과 데이터 저장 파일 크게 두가지로 나뉜다. 설정 파일은 그야말로 메트릭 수집과 운영에 대한 것으로 text 파일이며 데이터 저장 파일은 수집된 정보를 저장하는 TimeSeries 데이터 파일이다.

  • prometheus.yaml
  • tdb

Kubernetes 는 배포되는 프로그램의 각종 설정들을 pod 자체에 가지고 있게 하지 않는다. 이것은 pod 가 비상태 운영을 기본원칙으로 하기 때문이다. pod 는 언제든지 사라지고 만들어지고 해야 한다. pod 내에 배포되는 프로그램들의 설정파일을 pod 에 내장하게 되면 뭐하나 바꿀때마다 pod 를 손대야 한다.

ConfigMap 은 이렇게 Kubernetes 의 비상태 운영 원칙을 위한 것이다. 설정 맵은 그야말로 다양한 설정들의 내용을 Kubernetes 가 대신 가지고 있게 해준다. 예를들어 Prometheus 의 설정파일인 prometheus.yaml 은 text 파일인데, 이것을 ConfigMap 에 등록하고 Pod 생성시에 이것을 가지고와서 파일로 굽게 된다. 설정파일을 Kubernetest 가 가지고 있기 때문에 설정 편집을 위해서 pod 에 손을 댈 일은 없다.

데이터 저장 파일은 영구적인 저장 파일이다. Pod 에 내장되어 있다면 Pod 가 재시작될때마다 데이터 저장 파일은 삭제되었다 재 생성되는 과정을 반복할 것이다. 하지만 Pod 의 재시작과는 상관없이 데이터는 영구적으로 보존 되어야 하기 때문에 Pod 에 영구볼륨(Persistant Volume) 을 붙여서 데이터 저장 파일을 Pod 와 분리할 것이다.

추가로 Prometheus 나 exporter 들이 Kubernetes 의 API 에 접근할 수 있도록 계정과 권한도 부여할 것이다.

monitoring 네임스페이스 생성

Kubernetes 의 네임스페이스 생성은 아주 간단다. CLI 명령어로 간단하게 생성할 수 있다.

ClusterRole 생성

Kubernetes 의 자원에 대한 접근은 API 를 통해서 이루어 진다. API 접근은 Kubernetes 의 보안 부분으로 엄격하게 통제되고 있는데, Prometheus 가 이 API 에 접근해 자원에 대한 메트릭을 생성해야 하기 때문에 이에 대한 접근 권한이 필요하게 된다.

Kubernetes 의 API 에 대한 권한은 Role 개념으로 정립되어 있으며 이 Role 에 기반한 퍼미션을 부여하고 이것을 다시 특정한 계정과 바인딩 함으로써 접근제어는 마무리 된다.

위와같이 ClusterRole 을 작성한 후에 적용해 준다.

Prometheus 를 위한 영구볼륨 생성

Kubernetes 에서 영구 볼륨은 Persistant Volume 과 Claim 개념으로 다루어 진다. PV 는 영구저장소 미디어 특성을 고려한 일종의 드라이버 개념이고 Claim 은 영구저장소 미디어와는 상관없는 추상적 개층으로 PV 와 연결되어 작동된다.

Prometheus 는 데이터베이스 파일을 영구적으로 저장할 필요성이 있기 때문에 Kubernetes 의 PV, PVC 를 이용할 필요가 있다.

먼저 다음과 같이 PV 를 만든다.

중요한 것은 영구저장소를 이용할 Kubernetes 의 Node 를 지정해 주었고, 사용할 저장소는 디렉토리이며 없으면 생성하도록 했다. 거기다 ReclaimPolicy 를 Retain 으로 함으로써 PVC 와 연결이 해제되더라도 PV 는 그대로 데이터를 보존하도록 했다. 사용할 디렉토리 경로는 /opt/prometheus 로 지정 했다.

다음과 같이 생성해 준다.

이제 PV 를 가져다 쓸 PVC 를 생성해야 한다.

PVC 를 생성할 때에는 PV 에서 가져다 쓸 용량도 함께 기재한다. 당연한 이야기지만 PV 보다 많은 용량은 허용되지 않는다. 한가지 주의해야 할 것은 PV 의 Label 과 StorageClass 를 맞춰야 한다. 이게 어긋날 경우에는 PVC 가 제대로 연결되지 않는다.

다음과 같이 생성해 준다.

정상적으로 생성이 되면 위와같이 PVC 의 Status 가 Bound 로 표시 된다.

Prometheus 를 위한 ConfigMap 생성

앞에서도 이야기 했지만, Kubernetes 에서 Pod 는 비상태여야 한다. Pod 는 Replica 정책에 의해서 항상 특정한 수를 유지하도록 하는데, 간혹 Pod 가 알수 없는 이유로 재생성되는 경우가 발생하는데 이럴때에 Pod 가 상태를 가지는 파일을 가지고 있게 되면 데이터 손실이 발생하게 된다.

그래서 각종 서버에 대한 설정파일들을 Kubernetes 에 ConfigMap 으로 등록하고 Pod가 생성될때에 이를 가져다 설정파일로 만들도록 권장하고 있다.

ConfigMap 을 만드는 방법에는 크게 두가지로 나뉜다. 첫번째는 ConfigMap 메니페스트 파일에 설정 내용을 모두 함께 기술하는 것과 서버 설정파일을 특정한 디렉토리에 만든 다음에 kubectl 명령어로 ConfigMap 을 만드는 것이다. 어떤 방법을 쓰던지 결과는 동일하다.

여기선 설정 파일을 특정 디렉토리 별도로 만들어서 kubectl 명령어를 이용해 ConfigMap 을 작성하는 것으로 한다.

Prometheus 를 위한 설정 파일은 prometheus.yml 파일이다. 단 하나의 파일로 모두 가능하지만 rules 같은 경우에는 별도의 파일로 작성해 include 문을 작성해 연결 시킬 수 있다. 여기서는 두개의 파일로 제작했다.

prometheus.rules 파일에 rules 만 정의했다. 내용을 보면 Prometheus 에 알람을 보내는 Rule 을 적은 것이다. 이 파일은 prometheus.yml 파일에 include 문을 통해서 포함 된다.

prometheus.yml 파일의 내용을 보면 어떤 정보를 수집할지에 대해서 기술하고 있다. 전체적으로 10s 단위로 메트릭 정보를 수집하도록 하고 있으며 kube-state-metrics 에 대해서는 도메인 호출을해서 스크랩을 하도록 하고 있다. 그밖에 각종 Kubernetes 컴포넌트들에 대해서도 Kubernetes 의 API 서버를 통해서 메트릭을 수집하도록 설정하고 있다.

이렇게 설정내용을 파일로 작성하였다면 kubectl 명령어를 이용해 ConfigMap 을 다음과 같이 생성할 수 있다.

정상적으로 생성이 되었을 것이다.

이제 필요한 제반 사항들은 모두 만들어 졌다. 실제 Prometheus 배포로 Pod 를 생성해 보자.

Prometheus 를 위한 Deployment

Kubernetes 가 버전이 높아지면 Deployment 를 기반으로 여러개의 Pod 를 생성하도록 변경되었다. 여기서는 Prometheus 를 만들어야 하는데, 단순하게 Pod 만 생성하는게 아니라 Deployment 를 이용해서 Pod 를 생성 한다.

지금까지 만들었던 제반사항들이 모두 포함되어 있다. ServiceAccount 의 경우에는 Deployment.spec.serviceAccountName 에 prometheus 로 지정해 ClusterBinding 으로 묶인 메트릭 수집을 위한 API 접근을 부여하고 있다. Volume 마운트 에서는 ConfigMap 을 마운트해 파일을 작성과 PVC 를 마운트해 Prometheus 의 데이터 저장 디렉토리로 마운트 해주고 있다.

다음과 같이 생성해 준다.

처음 실행을 하면 위와 같이 에러가 발생 한다. 로그를 한번 보자.

“permission denied” 이 에러는 PV 에서 생성한 /opt/prometheus 디렉토리에 대한 권한이 없어서 나는 것이다. PV 를 생성한 Node 에 다음과 같이 퍼미션을 부여 한다.

위와같이 퍼미션을 조정해 주면 자동으로 Pod 가 재배포 되면서 정상화 된다.

접속을 위한 Service 배포

Kubernetes 는 기본적으로 Cluster 내에서의 접속만 허용 한다. 외부에서 접속이 되게 하기 위해서는 Service 배포를 통해서 NodPort 를 열거나 아니면 Port-Forward 를 설정을 해서 접속을 해야 한다.

여기선 Service 배포를 통해서 NodePort 를 배포해 준다.

Deployment 에서 Container 포트를 9090 으로 해줬다. Service 에서는 targetPort 로 Container 포트를 인식시켜주고 Service 에서 사용할 포트 8080 과 연결해준다. Cluster 내에서 8080 포트로 접속을 하면 Deployment 의 Container 에 9090 와 연결되어 응답이 오게 된다.

nodePort 를 지정해줘서 외부에서도 접속할 수 있도록 오픈해 준다.

다음과 같이 배포를 진행 한다.

Node Exportor

Node Exportor 는 Kubernetes 의 Node 에 대한 정보를 수집해 준다. Kubernetes 는 모든 것을 Pod 로 작동되는데, Node 에 하나씩만 작동되어야 하며 Kubernetes 클러스터와는 별도로 Node 자체에 데몬(Daemon) 처럼 동작해야 한다. 이를 위해서 DaemonSet 오브젝트로 만들어야 한다.

위 내용을 배포하게 되면 Node Exportor 가 DaemonSet 으로 동작한다. 그리고 Prometheus 는 정해진 시간마다 Node Exportor 에 접속해 메트릭을 수집하고 저장하게 된다.

마치며

Prometheus 는 Kubernetes 와 잘 작동 한다. Kubernetes 를 하면서 다양한 방법으로 설치를 진행할 수 있는데, 한번 쯤은 수동으로 모두 해보는 것을 권장하고 한번 공부해보길 권장한다. 그것만으로도 Kubernetes 에 대해서 상당히 많은 부분을 익힐 수가 있다.

그런 면에서 Prometheus 를 수동으로 모두 설치해보는 것은 가치가 있다.

Deployment, Unavailable 테스트

Kubernetes 의 Deployment 에서 pod 의 Unavailable 상태를 확인하기 위한 코드는 다음과 같다.

이것을 배포를 하면 Deployment 에 Pod가 Unavailable 상태를 보이게 된다.

VIM, Yaml 문법 적용

이 문서는 VIM, Yaml 문법 적용에 관한 것이다.

YAML 은 각종 설정파일에서 자주 쓰인다. Kubernetes 에서는 manifest 파일로 쓰이고 있는데, VIM 을 이용해 Yaml 을 편집할때에 간단하게 사용할 수 있는 방법을 소개한다.

간단하게 .vimrc 파일에 다음과 같이 입력해주면 된다.

내용을 보면 금방 이해가 될 것이다.

Kubernetes 프로세스별 상태

Kubernetes 는 다양한 컴포넌트들로 인해서 작동된다. 이러한 컴포넌트들은 중요성에 있어서 약간의 차이가 있다. 예를들어 Worker Node 에서 docker 프로세스가 정지되거나 문제가 되었을때에 어떻게 될까? 혹은 Worker Node 에 kubelet 프로세스가 문제가 된다면?

이 문서는 Kubernetes 프로세스별 상태 에 대한 글이다.

환경

여기서 환경은 Kubernetes 의 객체를 말한다. 객체라함은 Pods, Deployments, Services, StatefulSet 으로 했다. 그밖에 다양한 객체가 있지만 이 정도 생성해서 진행해보기로 했다.

docker 정지

이것은 Work Node 에 docker 를 정지 시키는 것이다. 이렇게 되었을때에 Kubernetes 의 각종 컴포넌트들은 어떤 상태를 보일지 알아보자.

먼저, Nodes 상태는 ‘Notready’ 로 변경된다.

Node 의 자세한 상태를 describe 보면 다음과같이 몇가지 상태가 나온다.

  • Warning ContainerGCFailed 38s (x2 over 98s) kubelet, knode rpc error: code = Unknown desc = Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?

Conditions 는 다음과 같이 된다.

두번째, Pods 상태.

상태가 STATUS 는 Completed 으로 나오고 READY 도 0/1 로 나온다. 정상으로 나오지 않는다. Pods 하나를 골라 describe 해보면 Ready 는 False 로 나온다.

세번째, Deployment 상태.

READY 가 0/3 으로 모두 문제가 있는 것으로 나온다.

네번째, Services 상태.

Service 에 상태는 없다.

다섯번째, StatefulSet 상태.

StatefulSet 상태로 READY 가 0/2 로 모두 문제가 있는 것으로 나온다. 하지만, Pods Status 에서는 “2 Running / 0 Waiting / 0 Succeeded / 0 Failed” 로 Pod 2개 Running 으로 나온다.

kubelet 정지

kubelet 은 Worker Node 에 명령을 수행하는 중요한 프로세스이다. 이를 정지했을때는 어떤 상태를 보일까..

Node 상태.

Node 상태는 NotReady 가 된다. 그리고 Conditions 상태는 다음과 같다.

Pods 상태

이상하게도 Pods 상태는 모두 정상으로 나온다. 하지만 Port-Foward 를 시도하면 되지 않는다.

Deployment 상태

비정상으로 나온다. READY 가 0/3 으로 표시된다.

StatefulSet 상태

비정상으로 나온다. READY 가 0/2 로 표시된다.

Worker Node 셧다운

이 상태는 kubelet 와 동일한 결과를 보여준다.

StatefulSet 에서 로컬 디스크 사용

이 문서는 StatefulSet 에서 로컬 디스크 사용 에 대한 글이다. Kubernetes 에서 디스크 사용은 어려운감이 있다. PersistentVolume 과 PersistentVolumeClaim 이라는 것을 알아야하고 이를 알고나서도 여러가지 속성들때문에 헷깔리는 경우가 많다.

PersistentVolume 관련해서 문서를 보면 대부분 클라우드가 제공하는 스토리지를 이용하는 예제가 많다. 그것이 아니라면 nfs 를 이용하는 경우가 많아서 나처럼 집에 컴퓨터를 이용하는 경우에 실습해 보기가 쉽지 않은게 사실이다.

StatefulSet 의 경우가 바로 이런 경우였다. StatefulSet 을 연구하기 위해서 여러가지 예제를 찾아봤고 다음과 같은 파일을 찾아냈다.

StatefulSet 은 비상태(stateless) 자원을 생성하는게 아니라 상태를 가지는 자원을 생성하게 해주는 Kubernetes 의 객체다. 대부분 Persistent Data 를 위한 것이기에 PersistentVolume 을 대부분 필요로 한다.

위 예제를 가지고 생성을 해보자.

정상적으로 생성이 됐다고 나온다. 확인을 해보자.

Pod 생성이 Pending 상태를 보이고 있다. 왜 이럴까? 앞에서 객체 생성을 정의한 yaml 파일을 자세히 보면 Persistent Volume 을 요청하고 있다. volumeClaimTemplates 이 바로 그것이다. 이것은 PersistentVolumeClaim 을 요청하는 것으로 나타난다. 확인해 보자.

persistentvolumeclaim 이 Pending 상태이다. 결국에는 이것으로 인해서 Pod 생성도 Pending 이 된 것이다.

해결방안

PersistentVolumeClaim 은 PersistentVolume 이 있어야 한다. 그리고 이것을 묶어줘야하는데 이것을 Bound 라고 한다. 문제는 web.yaml 을 실행했을때에 생성되는 PersistentVolumeClaim 과 PersistentVolume 을 어떻게 연결할 것인가?

좀더 정확하게 말하면 StatefulSet 이 자동으로 생성하는 PersistentVolumeClaim 과 PersistentVolume 을 어떻게 연결할 것인가?

StatefulSet 의 특징은 생성하는 객체의 이름이 임의대로 정해지지 않는다. 정확하게 사람이 인식하기 쉬운 이름으로 결정된다. 앞에서보면 Pod 의 이름이 web-0 이다. 이는 Pod 이름에 Replicas 의 첫번째인 0 을 붙여서 만든다.

StatefulSet 에서 PersistentVolumeClaim 이름은 예측 가능한 패턴을 따른다. volumeclaimtemplates-namestatefulset-namereplica-index. 그래서 생성된 PersistentVolumeClaim 의 이름이 www-web-0 가 된 것이다.

PersistentVolumeClaim 은 PersistentVolume 을 필요로 한다. PersistentVolume 을 생성할때에 claimRef.name 을 PersistentVolumeClaim 이름으로 지정한다. 이렇게 하면 PersistentVolumeClaim 이 생성될때에 PersistentVolume 이 이름과 연결되어 자동으로 Bound 되어진다. 다음과 같이 PersistentVolume 을 만든다.

이것은 Kubernetes Worker 호스트에 파일시스템에 특정 디렉토리를 PersistentVolume 으로 생성한다. 만일 디렉토리가 존재하지 않을 경우에는 생성하도록 한다. 그리고 PersistentVolumeClaim 이 삭제되면 이 볼륨도 함께 삭제되도록 했다.

여기서 중요한 것이 claimRef 필드이다. name 속성에 PersistentVolumeClaim 이름을 지정해준다.

또, nodeAffinity 필드를 이용해서 특정한 Worker 에서 생성되도록 했다.

StatefulSet 에서 replicas 를 2 로 했기 때문에 위 PersistentVolume 생성은 claimRef.name 이 www-web-0, www-web-1 로 두개가 필요하다.

두개의 PersistentVolume 을 생성하고 시간을 갖고 기다리면 다음과 같은 결과를 얻게 된다.

Worker 호스트에 PersistentVolume 에서 생성한 디렉토리가 있는지 확인해 보자.

이렇게 문제를 해결할 수 있다.

참고: StatefulSet 에서 기존 디스크 사용

GitLab-Runner 설치

이 문서는 GitLab-Runner 설치 에 대한 것이다. GitLab 은 CI/CD 를 위해 외부 프로그램을 사용하는데, 이것이 바로 GitLab-Runner 이다. 외부 프로그램을 사용하기 때문에 반드시 GitLab 과 함께 있어야 하는것도 아니고 독립적으로 다양한 플랫폼에 설치해도 된다.

설치

설치는 아주 간단하다. 각 배포판, 플랫폼마다 패키지를 제공한다. 나는 Ubuntu 20.04 에 그것도 GitLab 서버에 설치할 예정이다. 다른 서버에 설치를 해도 되지만 테스트 삼아 설치하는 것이여서 이렇게 진행했다.

이렇게 설치를 하고 나면 /home/gitlab-runner 계정이 생성되며 systemd 에 gitlab-runner 서비스가 등록이되며 자동으로 실행이 된다.

우선 gitlab-runner 서비스를 중지를 해준다.

Gitlab 에 등록하기

GitLab-Runner 를 설치했다면 이제 이것을 GitLab 에 등록을 해줘야 한다. 이를 위해서 GitLab 에서 Runner 메뉴를 보고 URL 과 Token 값을 확인 한다.

gitlab-runner 셋업 정보

오른쪽에 보면 URL 과 token 값이 보인다. Gitlab-Runner 를 GitLab 서버에 등록을 해줘야 한다.

등록할때에 URL, Token 값을 입력해 준다. 그리고 무엇보다 중요한 executor 를 선택해줘야 한다. 나의 경우에 Java 컴파일을 해줘야 하기 때문에 executor 를 shell 로 선택해줬다. 이렇게 설정된 내용은 /etc/gitlab-runner/config.toml 파일에 기록된다.

정상적으로 완료됐다면 서비스를 시작해 준다. 그리고 GitLab 에서 다음과 같이 runner 가 보인다.

등록된 gitlab-runner

여기서 중요한 것이, config.toml 파일을 수동으로 조작한다고 해서 GitLab 서버에 등록이 되지 않는다. 반드시 register 를 이용해야만 등록이 가능하다.

Java 컴파일 환경 구축.

번외로 Java 컴파일 환경을 구축해 보겠다. gitlab-runner 의 프로세스를 보면 다음과 같다.

위 내용을 보면 working-directory 가 /home/gitlab-runner 이고 사용자가 gitlab-runner 이다. 따라서 /home/gitlab-runner 홈 디렉토리를 기반으로 runner 가 작동된다.

Java 컴파일 환경을 위해 다음의 필요하다.

  • java 1.8 컴파일러
  • maven

이 두가지를 gitlab-runner 계정에 설정을 해줘야 한다.

java 1.8 설정

java 1.8 은 Oracle JDK 가 아닌 오픈 소스인 Zulu JDK 를 사용하기로 했다. 현 시점에서 최신판을 다운로드 한다.

gitlab-runner 를 executor 로 작동하도록 했기 때문에 gitlab-runner 의 기본 쉘인 bash 를 기반이다. gitlab-runner 계정에 .bashrc 파일에 java 1.8 환경 변수를 등록해준다. gitlab-runner 는 서비스에 등록되어 동작은 root 계정으로 동작한다. 하지만 gitlab-runner 가 실행될때에 su 명령어로 gitlab-runner 계정으로 전환된다.

문제는 이때에 .bashrc 를 읽어들이지 않는다. 대신에 .profile 을 읽어들이게 된다. 따라서 각종 환경 변수들은 .profile 에 작성해야 한다.

maven 설치

maven 을 설치해준다.

이제 maven 을 위한 환경 변수를 등록해준다. 역시 .bashrc 파일에 해준다.

그리고 maven 에 setting.xml 파일을 수정해 의존성 패키지들의 저장소를 다음과 같이 바꿔 준다.

이로써 java 컴파일을 위한 gitlab-runner 설정을 완료됐다.

.gitlab-ci.yml 파일

Spring5MVC 프로젝트를 maven 으로 작성했다. Eclipse 를 쓴다면 간단하게 Spring5MVC 를 Maven 프로젝트로 손쉽게 제작할 수 있다. 이런 경우에 .gitlab-ci.yml 파일을 다음과 같이 간단하게 작성할 수 있다.

tags 는 gitlab-runner 에서 지정한 tag 를 말한다. gitlab-ci.yml 에서 gitlab-runner 를 구분하는 방법은 바로 tag 다. 이것은 GitLab 에서 gitlab-runner 를 수정하면서 함께 변경이 가능하다.

only 는 git 브랜치중에서 master 브랜치에 커밋이 발생했을때에 이를 실행하도록 한 것이다. git 는 전략적으로 브랜치를 자주 사용하는데, 전략에 따라서 특정 브랜치에 대해서만 작동하도록 할 수도 있다.

위 파일은 Deploy 는 없어서 단순하게 컴파일하는 것으로 끝난다. 나중에 Deploy 에 대해서 이야기 해보도록 하겠다.