OKD 개요 -2

Gyullbb·2022년 3월 13일

OKD

목록 보기

3/3

이전에 OKD에 대해 간략한 소개를 했다면, 이번에는 OKD 의 대표적인 특징들에 대해 공유를 하고자 한다.

1) Ignition 파일

앞서 말했듯이 OKD4는 Fedora CoreOS 기반으로 설치 및 구성이 된다. OKD4가 Fedora CoreOS를 기본 OS로 사용하면서 이용한 특징은 바로 Ignition이다.

1-1) Ignition 이란?

Ignition은 JSON 형식의 구성 파일을 읽고 해당 구성을 기반으로 Fedora CoreOS 시스템을 프로비저닝하는 프로비저닝 유틸리티이다.

Ignition은 시스템을 처음 부팅하는 동안 한 번만 실행되게 되는데, 부팅 프로세스 초기에 실행 시 디스크 분할, 파티션 포멧, 파일 쓰기(일반 파일, systemd) 및 사용자 구성을 읽고 이 구성을 적용한다. 그렇기 때문에 systemd 서비스는 systemd가 시작될 때 이미 구성이 디스크에 기록되어 있어 부팅 시간을 단축시킬 수 있다.

1-2) Ignition 프로세스

Ignition이 작동하는 프로세스는 다음과 같다.

1) YAML 형식의 Butane 구성을 생성한다.
2) Butane 을 실행하여 YAML 파일을 Ignition(JSON) 구성으로 변환한다.
3) Ignition 구성으로 Fedora CoreOS를 부팅한다.

여기서 Butane이란 사람이 쉽게 이해할 수 있도록 작성된 YAML을 기계가 읽을 수 있는 Igniton(JSON)으로 변환시키는 도구로, 사람과 기계에게 모두 친숙한 환경을 만드는데 도움을 준다. Butane이 YAML파일을 JSON 형식으로 변환하면서 YAML 파일의 문법을 점검하기 때문에 부팅 전 YAML파일 오류를 잡을 수 있다.

1-3) OKD4와 Ignition

OKD4는 클러스터를 생성할 때 Cluster name, Base domain, Pull secret, SSH key 등의 내용이 담긴 install-config.yaml을 기반으로 생성하게 된다.

OKD4에서 제공하는 클러스터 생성 스크립트를 돌리면 Butane이 install-config.yaml 파일을 Ignition(JSON) 구성으로 변환한다. 이 Ignition 내부의 내용을 기반으로 Fedora CoreOS가 부팅을 하면서 설정 값에 맞게 클러스터를 구성하게 된다.

AWS, GCP, Azure 등 Public Cloud에서는 Terraform을 통해 Ignition 구성에 맞게 클러스터를 생성하게 된다. 결과론적으로는 YAML파일 하나와 클러스터 생성 스크립트 하나만으로 손쉽게 클러스터를 만들 수 있는 것이다.

2) OAuth server

OKD4 클러스터는 허가된 사용자가 로그인 한 후에 접근을 할 수 있게 함으로써 보안성이 높은 구조를 가진다. 이 구성을 가능하게 하는 것이 바로 OAuth server이다.

OKD4 마스터에는 내장 OAuth 서버가 포함되어 있는데, 사용자는 API 인증을 위해서 OAuth 액세스 토큰을 가져오게 된다.

사용자가 새 OAuth 토큰을 요청하면 OAuth 서버는 ID 공급자를 사용하여 요청자의 ID를 확인한다. 이 후 사용자가 인증이 되면, 사용자에게 클러스터에 접속이 가능한 액세스 토큰을 제공한다.

제공되는 액세스 토큰은 기본적으로 24시간이며, 이 설정을 변환하고 싶으면 다음과 같이 OAuth kind의 accessTokenMaxAgeSeconds를 설정하는 config를 생성하면 된다.

apiVersion: config.openshift.io/v1
kind: OAuth
metadata:
  name: cluster
spec:
  tokenConfig:
    accessTokenMaxAgeSeconds: 172800

클러스터에서 생성된 토큰을 확인하는 방법은 다음과 같다.

$ oc get useroauthaccesstokens

클러스터를 처음 생성하게 되면 기본적으로 kubeadmin이라는 사용자와 패스워드가 주어지게 된다. 보안성을 조금 더 높이기 위해서는 ID 공급자를 구성하는 CR(사용자 정의 리소스)를 생성한 후, 기본적으로 주어진 kubeadmin 사용자를 제거해야 한다.

3) Operator

OKD4 클러스터를 설치한 후 다음과 같은 명령어로 Project를 확인해 보면 Operator라는 이름을 가진 Project가 많은 것을 확인할 수 있다.

$ oc get project
openshift-apiserver
openshift-apiserver-operator
openshift-authentication
openshift-dnss
openshift-dns-operator
openshift-etcd
openshift-etcd-operator
openshift-console
openshift-monitoring
…

Project란?

Kubernetes의 Namespace와 마찬가지로 격리 공간을 생성하는 단위이다.

Operator란 OKD 시스템 구성요소를 관리하고 현재 상태를 기준으로 의사결정을 내리는 객체이다. 즉 다시 말하면 OKD에 배포된 후 API 및 oc 도구를 통해 관리되는 애플리케이션들을 관리자 역할로 모니터링하고 관리하는 역할을 의미한다.

Operator는 다음과 같은 기능을 제공한다.

설치 및 업그레이드의 반복성 : 자동화
모든 시스템 구성 요소의 지속적인 상태 점검
Openshift 구성 요소에 대한 업데이트 : 애플리케이션 관리를 캡슐화 하여 사용자에게 전파

이 Operator는 OLM(Operator Lifecycle Manager)에 의해 설치, 업그레이드 및 RBAC이 제어된다.

Operator의 기능을 조금 더 쉽게 이해할 수 있도록 예시를 확인해보자.

3-1) Operator 예시

OKD4에는 openshift-monitoring이라는 Project가 존재한다. 이 프로젝트는 클러스터 전체를 모니터링하고 사용자에게 alert를 제공하는 Grafana, Prometheus, AlertManager 등의 리소스들이 설치되어 있다.

이 내부에는 cluster-monitoring-config라는 이름의 Pod가 존재하는데, 이것이 바로 openshift-monitoring 내부 리소스들을 관리 하는 operator이다. 이 operator에 alertmanager, grafana, prometheus의 설정 수정 값을 작성하면 각 리소스에 변경된 설정이 적용되게 된다.

Operator의 변경 없이 alertmanager, grafana, prometheus의 값을 변경하면 operator에 의해서 상태 점검 후 operator의 설정 값에 맞게 원복된다.

이렇든 Operator는 사용자가 리소스를 관리하기 편하도록 도움을 주며, 불필요한 변화가 일어나지 않도록 방지해주는 역할을 한다.

다음은 공식문서에 나온 Operator의 예시이다.

On-Demand Application 배포

Application 상태를 백업하고 복원

DB Schema, Config 등의 변경 사항에 따른 Application 코드 업데이트 처리

k8s API를 지원하지 않는 애플리케이션에 서비스를 게시하여 검색을 지원

클러스터의 전체 또는 일부에서 장애를 시뮬레이션하여 가용성 테스트

내부 멤버 선출 절차 없이 분산 애플리케이션의 리더를 선택

4) Network

OKD 공식 문서를 보면 OKD는 멀티 테넌트에 배포에 최적화된 쿠버네티스 배포판이라고 설명이 되어 있다.

멀티테넌시(Multitenancy)란?

단일 소프트웨어 인스턴스로 서로 다른 여러 사용자 그룹에 서비스를 제공할 수 있는 소프트웨어 아키텍처

이는 OKD에서 제공하는 3가지 Openshift SDN(Software Defined Network) 플러그인에 의해 가능한 사항이다.

4-1) ovs-networkpolicy

관리자가 자체 격리 정책을 구성할 수 있도록 한다.

아래 사진과 같이 자체 격리 정책을 구성할 수 있다. 첫 번째 사진은 모든 트래픽을 거부하는 설정이고, 두 번째 사진은 같은 네임스페이스의 트래픽만 허용하는 설정이다. 마지막 사진은 HTTP나 HTTPS로 들어오는 트래픽만 허용하는 설정이다.

이렇듯 자체 격리 정책을 생성함으로써 동일한 인스턴스임에도 사용자를 분리하여 여러 사용자 그룹에 서비스를 제공할 수 있다.

4-2) ovs-multitenant

Pod 및 Service에 대한 프로젝트 수준 격리를 제공한다. 각 프로젝트는 프로젝트에 할당된 포드의 트래픽을 식별하는 가상 네트워크 ID인 VNID를 받게 된다. 이 VNID를 통해서 트래픽이 통신되기 때문에 다른 프로젝트의 포드는 해당 프로젝트의 포드 및 서비스에 패킷을 주고받을 수 없다.

VNID 0으로 설정한 프로젝트의 경우 다른 모든 Pod와 통신할 수 있다.

4-3) ovs-subnet

모든 포드가 다른 모든 포드 및 서비스와 통신할 수 있도록 네트워크를 제공하는 플러그인이다.

4-4) OVS란(Open vSwitch)?

OVS란 리눅스 기반의 가상 소프트웨어 스위치로 Apache 2.0 라이센스 하에서 오픈소스로 사용가능한 다계층 가상 스위치이다.

초기 분산 가상 스위치는 물리적인 NIC를 연결한 스위치를 가상화시키고 하나의 Hypervisor 환경에서의 서버 환경 구성만 가능하였다. 현재의 구성은 같은 물리적 스위치로 연결된 NIC를 합친 후 가상화를 함으로써 여러 개의 Hypervisor 환경 즉, 이기종간의 클라우드 환경 구성이 가능하다.

5) Web Console & Monitoring

OKD4 클러스터를 설치하면 기본적으로 Web Console을 제공한다. 추가 설치 없이도 클러스터 콘솔 접속 시 로그인 기능이 있으며 내부 OAuth 서버를 통해 인증을 받는다.

클러스터 Web Console에서는 다음과 같은 활동을 진행할 수 있다.

AlertManager와 Prometheus가 수집하는 실시간 상태 확인
클러스터 내부의 실시간 event 확인
cli 명령어 - UI 작업 진행

ex) yaml 파일 수정, Pod 접속 및 로그 확인 , User 관리, Grafana 대시보드 접속 등

기본적으로 설치되어 있는 웹 콘솔을 통해 기존에 Cli로만 작업할 수 있었던 작업들을 간단한 클릭만으로 수행할 수 있어 편리함을 준다.

6) Managed-Issue

다음은 OKD 환경을 운영하면서 발생한 이슈이다.

6-1) sysroot 파일시스템 증가

[이슈상황]

Fedora-CoreOS의 root 볼륨인 sysroot의 볼륨이 지속적으로 증가함. df 혹은 du 명령어로 확인 시 크게 차지 하는 용량의 파일이 없는 상태

[원인]

Node에 떠있는 일부 Pod의 컨테이너 프로세스에서 Host의 디스크 공간을 예약하는 모습을 보임

ex) filebeat - harvester

filebeat란 사용자가 지정한 로그 파일이나 위치를 모니터링하고 로그 이벤트를 수집하여 전달하여 중앙 집중화하기 위한 전달자이다. harvester는 지정한 파일에 이벤트 데이터를 전송하기 위한 수단이다.

harvester는 파일을 한줄 식 읽은 다음 내용을 출력으로 전송하게 되는데, harvester가 파일을 읽는 동안은 닫힐 때까지 디스크 공간을 예약하게 된다.

[해결]

위에서 말한 filebeat 같은 Pod를 재기동 시켜 sysroot 확보
sysroot가 80%가 넘어 Pod가 evicted날 위험성이 있다면 노드 cordon, drain 후 재기동 ( 운영 시 좋은 방법이 아니기 때문에 더 좋은 방법을 찾고 있음)

6-2) mc(machine config) 데몬의 작동

OKD4에는 Machine Config Operator라는 개념이 있다. Machine Config Operator는 커널과 kubelet 사이의 모든 것을 포함하여 기본 운영 체제 및 컨테이너 런타임의 구성 및 업데이트를 관리하고 적용한다.

Machine config operator에는 다음 네 가지 구성 요소가 있다.

machine-config-server : 클러스터에 가입하는 새 머신에 Ignition 구성을 제공
machine-config-controller : 오브젝트에서 정의한 구성으로 머신 업그레이드를 조정
machine-config-daemon : 업데이트 중에 새 머신 설정을 적용
machine-config : 머신을 설치, 시작 및 업데이트 하는 시스템 구성 소스 제공

[이슈 상황]

클러스터의 Pod 에 접속하거나 로그를 확인 시도 시 unable to upgrade connectin : Unauthorized 에러 및 You must be logged in to the server (the server has asked for the client to provide credentials) 에러발생

[상태]

oc get clusteroperator로 확인 시 machine-config의 Available이 False 상태
oc get mcp로 확인 시 실제로 Running 중인 Worker와 Available 한 Worker의 개수에 차이가 있음