Kubernetes 배포판 중의 하나인 OKD를 운영하는 입장에서 OKD에 대해 소개를 해보고자 해당 글을 작성한다.
OKD란 Red Hat Openshift라는 상업용 소프트웨어 제품의 오픈 소스이며 다양한 Kubernetes 배포판 중의 한 종류이다.
OKD는 Kubernetes 위에 효율적인 운영을 위한 콘솔 및 모니터링 도구를 포함한 제품이기 때문에, 신속하게 컨테이너 환경을 만들고 운영해야 할 경우 큰 장점을 가지고 있는 제품이다.
OKD는 현재 4버전까지 출시가 되었으며, 각 버전마다는 구성적인 차이가 존재한다. 특히 3버전에서 4버전으로 올라가면서 구조가 크게 변경되었다.
OKD 3 vs OKD 4
OKD3 | OKD4 | |
---|---|---|
OS | Fedora CoreOS, CentOS, RHEL | Fedora CoreOS |
Install | Update | Ansible Playbook | 자체 스크립트 |
default container runtime | docker | CRI-O |
CoreOS 관련 참조 글
https://www.redhat.com/ko/coreos
https://access.redhat.com/documentation/ko-kr/openshift_container_platform/4.6/html/architecture/architecture-rhcos
CRI-O 런타임관련 참조 글
https://www.projectatomic.io/blog/2017/06/6-reasons-why-cri-o-is-the-best-runtime-for-kubernetes
https://waspro.tistory.com/605
OKD 설치 방법은 공식문서에서 크게 AWS, Azure, GCP, Bare Metal의 경우에 따라 나뉘어져 있다. AWS환경에서 OKD4버전을 설치하는 방법은 해당 링크에 정리를 해두었다.
직접 설치를 해보면 느낌이 오겠지만 Kubernetes와 그 주변 시스템을 편리하게 사용하도록 만들어진 오픈소스인 만큼 기본적인 설정만 하고 주어진 스크립트를 작동시키면 서브넷 구성 부터 라우팅 설정과 방화벽, 모니터링 및 콘솔 화면까지 한번에 구성이 된다. 하지만 그 편리함에 못지 않은 단점도 가지고 있는데, 그것은 하단부에 작성을 하겠다.
OKD 환경을 설치하는 구성은 위와 같다. Installer 서버에서 OKD에서 제공하는 클러스터 생성 스크립트를 통해 클러스터를 생성하면 Bootstrap Node가 생성되어 Master Node를 생성한 후 사라진다. 이후 Workernode가 생성되면 해당 노드가 클러스터에 조인된다.
위 그림은 간단하게 외부에서 OKD로 들어오는 흐름을 정리한 것이다. 외부에서 LB나 WAF를 통해 들어온 트래픽은 OKD에서 제공하는 Router(HA Proxy 기반)을 통해 클러스터 내로 이동된다. 이 때 개인 설정에 따라 Public router와 Private router를 구분하여 트래픽을 처리할 수 있다.
Installer server같은 경우는 클러스터를 생성하고, 클러스터에 명령어를 통해 작업을 진행하는 역할을 하게 된다. 또한 OKD 기본 이미지에 대한 이미지 레지스트리 역할도 함으로써, OKD 기본 이미지가 노드에서 사라졌을 때 해당 서버에서 이미지를 가져오게 된다.
OKD를 설치하면 기본적인 프로젝트, 즉 네임스페이스가 설치된다. 운영 시 자주 참조하는 대표적인 네임스페이스에 대해 설명하겠다.
openshift-monitorng
OKD를 설치하면 기본적으로 구성되는 모니터링 관련된 리소스가 배치되는 네임스페이스이다. 기본적으로 alert-manager, prometheus, grafana pod가 배치된다. route와 service를 통해 외부에서 바로 그라파나 및 프로메테우스 콘솔에 접속할 수 있다.
(단, 기본적으로 설치되는 grafana는 viewer권한만 가지고 있기 때문에, 추가적인 설치를 하지 않고서는 OKD에서 기본적으로 제공하는 대시보드이외에 커스터마이징이 불가능하다)
링크 참조
openshift-ingress
외부에서 들어온 트래픽에 대해서 HA Proxy기반으로 라우팅을 해주는 리소스가 배치되는 네임스페이스이다.(pod 내부의 haproxy.conf파일을 통해 라우팅)
기본적으로 설치를 하면 default 라우팅 파드가 존재하며, 추후 설정에 따라 private용 라우팅 파드와 public용 라우팅 파드를 구분하여 트래픽을 분산할 수 있다.
openshift-dns
coredns가 배포 및 관리되며 openshift에서 dns 기반으로 Kubernetes 서비스 검색이 가능하도록 설정하는 네임스페이스이다.
openshift-XXX-operator
okd 내부 네임스페이스의 설정을 구성하는 상위네임스페이스 같은 역할로, 특정 네임스페이스 내부의 리소스를 구성하며 상태 체크를 하는 역할을 한다.
ELK
ELK의 경우 OKD3버전에서는 기본적으로 제공하는 로깅서비스였으나, OKD4로 오면서 기본 로깅서비스는 제공을 하지 않게 되었다. 따라서 사용용도에 따라 ElasticSearch, filebeat 등을 추가적으로 설치해야 한다.
OKD를 설치하면 기본적으로 클러스터의 상태를 저장하고 복구하는 스크립트가 제공된다. 해당 스크립트를 활용하여 주기적으로 etcd 상태를 로컬 호스트에 저장하는 방식으로 장애에 대비할 수 있다.
[스크립트 위치]
/usr/local/bin/cluster-backup.sh
[daemon과 타이머로 백업 설정]
/etc/systemd/system 하위에 service와 timer 생성 후 daemon을 통해 주기적인 스크립트 실행을 하여 백업을 받도록 설정하는 방식을 사용 중
[추가적인 리소스 yaml 백업]
velero 오픈 소스를 활용하여 리소스의 yaml 파일을 백업 받는 방식을 사용 중
다음은 OKD운영을 하며 느낀 장단점이다.
1) 장점
2) 단점
OKD4를 운영하면서 아무래도 사용하는 사람이 AWS EKS 및 Google GKE에 비해 현저히 적기 때문에 (아무래도 커스터마이징이 어렵다는 단점때문인 것 같다) 관련된 자료 또한 거의 없어 운영하는데 어려운 점이 많았다.
이 글은 전체적인 OKD 개요로 OKD를 소개하는 글이며, 추후 OKD를 운영하면서 생겼던 문제 및 추가적인 설정 방법에 대해서도 작성하도록 하겠다.
OKD 특성과 운영 장단점에 경험 내용 잘 봤습니다. 좋은 내용 감사합니다.
참고자료에 OKD 공식 문서 링크가 잘못되어 있는 것 같네요.