쿠버네티스 공부의 시작
C언어를 공부할 때 흔히 첫 프로그램으로 Hello C ! 를 출력하는 프로그램을 작성한다. 그런데 C 언어는 정말 컴파일러만 있으면 Notepad를 사용해서도 코딩을 할 수 있다. 그다지 복잡한 환경을 필요로 하지 않았다. 하지만 이젠 다르다. 뭐하나 공부하려면 통합개발환경(IDE) 프로그램을 설치해야 하고 IDE에 공부하려는 언어의 라이브러리를 설치해야 하고 해당 언어의 개발을 지원하는 각종 플러그인을 설치해야 한다.
뭐..이런 개발 환경은 노트북이나 데스크톱 컴퓨터 1대에 프로그램을 이것저것 설치하면 한두 시간이면 준비할 수 있다.
하지만 쿠버네티스를 공부하려면 시작하면 일단 쿠버네티스 환경을 설치할 하드웨어부터 준비해야 한다. 물론 PC 1대만 있어도 기본적인 테스트는 가능하다. 하지만 제대로 된 테스트 환경을 만들려면 최소 3개 이상의 가상머신을 구동할 수 있는 PC가 필요하다. 당연히 VMWare ESXi나 Proxmox VE 같은 가상화 서버를 구축해야 한다. 이런 환경을 필요로 하는 것은 쿠버네티스 학습의 시작을 방해하는 정말 커다란 장벽이다.
가상화 환경을 구축했다 하더라도 최소 4 GB 램을 가진 최소 3개의 리눅스 가상서버가 필요하다. 마스터 노드 1대와 워커노드 2대를 구동해야 하기 때문이다.
이 준비가 완료되면 이제 비로소 쿠버네티스를 설치할 수 있다. 마스터 노드와 워커노드의 역할에 따라 설치한다. 그리고 kubectl 명령을 통해 이런 저런 쿠버네티스 클러스터의 환경을 다루는 연습을 한다. 그러다 보면 매번 마스터 노드에 접속하는 것이 귀찮아 지고 kubectl 명령을 마스터 노드가 아닌 PC에 설치하고 원격에서 관리하는 방법이 없을까를 고민하기도 한다.
다음 단계는 Apache 웹서버, MySQL 등 이미 개발되어 있는 기본적인 응용프로그램을 Docker Hub에서 내려받아 최소한의 커스터마이즈 된 이미지를 빌드하여 워커노드에 배포한 다음 웹브라우저나 DB조회툴을 사용해 접속에 성공하는 것으로 다음 걸음을 내딛는다. 또한 NAS와 같은 공용 스토리지를 사용해 Persistent Volume을 생성하고 사용하는 테스트를 진행하는 순으로 쿠버네티스 환경을 하나씩 테스트해 나간다.
GitLab에 적용된 사설 인증서
이런 저런 테스트를 하다 보면 맞닥뜨리는 과제가 바로 CI/CD 파이프라인 구축이다. 필자는 형상관리시스템과 배포 시스템으로 GitLab을 선택했고 가상머신을 추가로 생성해 설치했다. 그런데 IP 주소만으로 모든 환경을 구축하는 것이 한계에 달했고 결국 시놀로지 NAS를 이용해 홈랩에서 사용할 내부망 DNS 서버를 구축했다.그리고 gitlab.blogger.local 이라는 도메인주소를 GitLab 서버에 할당했다.
그리고 테스트를 하는 과정에서 GitLab에 SSL 인증서를 설정하지 않으면 테스트가 매우 어려워진다는 것을 알게 되었다.이는 개발에서 운영시스템의 배포 파이프라인이 모두 자동화 되는데 중간에 신뢰할 수 없는 중간자가 끼어들어 해킹을 시도하는 것을 예방하기 위해서 서버간 통신에는 반드시 SSL인증서를 통한 상호 검증이 반드시 필요했다.
하지만 공인 인터넷 망이 아니기에 공인 인증서는 사용할 수 없다. 때문에 사설 인증서를 사용해야 하며 가능하다면 CA서버를 구축해 인증서 발급과 검증을 수행해주면 좋겠지만 테스트 환경에서 그렇게 까지 구현할 수는 없다. 그래서 서버에서 발급한 셀프사인 인증서를 사용해야 한다. 이렇게 생성해 서버에 등록된 사설인증서는 PC의 웹브라우저에서는 검증해줄 수 없기 때문에 붉은색으로 표시되는 안전하지 않은 사이트로 표시된다. 인증서 상세정보는 다음과 같다.
PC의 웹 브라우저에서는 주소창에 붉게 표시되는 정도로 끝나지만 REST API 등 https 기반의 API를 사용하게 되면 다음과 같이 에러가 발생하면서 API 연동이 불가능하게 되는 경우도 있다.
하지만 PC와 서버에서 이렇게 발급된 사설인증서 검증 시 에러가 발생하지 않게 하기 위해서는 이 사설인증서를 무조건 신뢰하도록 운영체제의 신뢰할 수 있는 인증서 목록에 추가해줘야 한다.
사설 인증서 만들고 GitLab에 적용하기
Gitlab이 설치된 서버에서 다음의 명령을 통해 인증서를 Gitlab에 적용한다.
$ sudo openssl req -x509 -nodes -days 3650 -newkey rsa:2048 \
-keyout /etc/gitlab/ssl/gitlab.blogger.local.key \
-out /etc/gitlab/ssl/gitlab.blogger.local.crt \
-subj "/CN=gitlab.blogger.local" \
-addext "subjectAltName=DNS:gitlab.blogger.local" \
-addext "keyUsage=digitalSignature,keyEncipherment" \
-addext "extendedKeyUsage=serverAuth"이명령을 실행하면 다음과 같이 두 개의 파일이 생성된다. 개인키 파일은 절대, 네버, 결코 이 서버 밖으로 유출되면 안된다. 백업을 위해 서버 밖으로 파일을 빼낸다면 반드시 암호키가 설정된 zip 파일로 안전한 USB 메모리에 넣어 잠금장치가 있는 안전한 장소에 보관해야 한다.
/etc/gitlab/ssl/gitlab.blogger.local.key → 개인키 (Private Key)
/etc/gitlab/ssl/gitlab.blogger.local.crt → 인증서 (Certificate)이 인증서를 생성할 때 사용한 옵션에 대해 간단히 설명하면 다음과 같다.
- x509 → X.509 형식의 인증서 생성
- nodes → 개인키를 암호화하지 않고 생성 (패스워드 입력 없이 사용 가능)
- days 3650 → 유효기간 3650일 (약 10년) – 가능하다면 최소 1년에 1회 교체를 권장함
- newkey rsa:2048 → 새 RSA 2048비트 키 생성
그리고 /etc/gitlab 디렉토리 아래에 있는 gitlab.rb 파일에도 도메인 주소를 넣어줘야 한다.
external_url과 registry_external_url 두 개다. external_url은 웹 접속 시 사용하게 되는 사설 인증서를 발급할 때 지정한 도메인 주소를 포함하는 URL이다.
그리고 registry_external_url을 반드시 설정해줘야 한다. 이 URL은 쿠버네티스에 배포할 컨테이너 이미지를 빌드한 다음 쿠버네티스가 이미지를 받아갈 수 있도록 등록할 레지스트리의 URL이다. 즉 GitLab이 컨테이너 레지스트리의 역할도 수행한다는 의미다. Github에도 ghrc.io 라는 컨테이너 레지스트리를 제공하든 GitLab도 기본적으로 컨테이너 레지스트리를 지원하고 있다. 하지만 처음 GitLab을 설치하면 컨테이너 레지스트리 기능은 비활성화 되어 있다. 이 설정을 추가하고 GitLab을 reconfigure 해줘야만 컨테이너 레지스트리 기능이 활성화 된다.
reconfigure 명령을 수행한 다음 GitLab의 프로젝트 메뉴에서 Settings – General 의 “Visibility, project features, permissions” 섹션을 보면 Container Registry 메뉴가 활성화 된 것을 볼 수 있다.
GitLab Runner 및 k8s 노드에 인증서 저장
GitLab 서버에 사설 인증서를 발급해 적용했다면 이제 GitLab 서버와 REST API 등을 통해 통신하는 Runner 노드와 k8s 노드에 공개키가 저장된 인증서를 신뢰할 수 있는 인증서로 등록해줘야 한다. 그래야 안전하게 k8s가 GitLab의 레지스트리에서 컨테이너 이미지를 받아올 수 있다.
명령어 3줄이면 되는 매우 단순한 작업이다.
$ openssl s_client -connect gitlab.blogger.local:5050 -showcerts </dev/null 2>/dev/null | openssl x509 -outform PEM > gitlab.crt
$ sudo cp gitlab.crt /usr/local/share/ca-certificates/
$ sudo update-ca-certificates
그런 다음 다시 GitLab 서버에 접속해보면 인증서 검증 오류가 발생하지 않는다.
#gitlab #사설인증서
답글 남기기