본 문서는 공식 Documents 를 참고하여 작성하였습니다.

https://docs.openshift.com/container-platform/4.12/applications/index.html

https://docs.openshift.com/container-platform/4.12/networking/configuring_ingress_cluster_traffic/configuring-ingress-cluster-traffic-load-balancer.html

응용프로그램을 생성하고 관리하는 방법에 대해 기술합니다.

응용프로그램은 프로젝트 내에서 생성되고 가동 되므로 프로젝트 관리부터 시작합니다.

1. 프로젝트 관리

1) 프로젝트 생성

관리자 권한으로 변경합니다.

# export KUBECONFIG=/root/installation_directory/auth/kubeconfig

# oc whoami

system:admin

project412 라는 프로젝트를 생성합니다.

# oc new-project project412 --description="This is an example project" --display-name="Hello OpenShift"

프로젝트 리스트를 확인합니다.

# oc get projects

생성한 프로젝트를 선택합니다.

# oc project project412

현재 프로젝트의 상태를 출력합니다.

# oc status

* 참고 : 현재 프로젝트에서 다른 프로젝트로 변경

# oc project <프로젝트명>

* 참고 : 다른 사용자로 프로젝트 생성

# oc new-project <프로젝트명> --as=<사용자명> --as-group=system:authenticated --as-group=system:authenticated:oauth

다음은 project412 프로젝트를 수정하고 삭제하는 방법이지만,

예제를 계속 이어나가기 위해 참고로만 알아두고 건너뜁니다.

2) 프로젝트 수정

기본 프로젝트 템플릿을 생성합니다.

# oc adm create-bootstrap-project-template -o yaml > template.yaml

수정 후 적용 (예 : openshift-config 프로젝트)

# oc create -f template.yaml -n openshift-config

3) 프로젝트 삭제

# oc delete project project412

2. 응용프로그램 생성

응용프로그램 생성 방식에는 여러 가지가 있습니다.

- Git 저장소를 통해 생성하는 방법

- Docker 이미지를 통해 생성하는 방법

- Template 를 통해 생성하는 방법

여기에서는 Docker image 를 받아서 응용프로그램으로 배포하는 방식을 설명하겠습니다.

1) 응용프로그램 생성 (배포)

도커 이미지를 다운로드 하기 위해 docker 패키지를 설치합니다.

# yum -y install docker

docker 데몬이 가동되어 있어야 다운로드가 됩니다.

# systemctl enable docker

# systemctl start docker

nginx 응용프로그램을 배포해보겠습니다.

nginx 최신 버전을 다운로드 합니다.
# docker pull nginx:latest

Openshift 에서 응용프로그램 생성은 oc new-app 명령을 이용합니다.

이 방식을 사용하면 어플리케이션을 생성할때 Deployment 와 Service 가 함께 생성됩니다.

# oc new-app docker.io/nginx:latest

응용프로그램 생성이 잘 되었는지 확인합니다.

생성은 되었으나 사용할 준비가 되지 않았고, CrashLoopBackOff 상태인 것이 확인됩니다.

# oc get pods
NAME                     READY   STATUS             RESTARTS     AGE
nginx-5fb558b844-qg99g   0/1     CrashLoopBackOff   1 (2s ago)   9s

로그를 확인합니다.

# oc logs nginx-5fb558b844-qg99g

...

2023/02/16 23:04:53 [warn] 1#1: the "user" directive makes sense only if the master process runs with super-user privileges, ignored in /etc/nginx/nginx.conf:2
nginx: [warn] the "user" directive makes sense only if the master process runs with super-user privileges, ignored in /etc/nginx/nginx.conf:2
2023/02/16 23:04:53 [emerg] 1#1: mkdir() "/var/cache/nginx/client_temp" failed (13: Permission denied)
nginx: [emerg] mkdir() "/var/cache/nginx/client_temp" failed (13: Permission denied)

에러가 출력되면 Pod, Deployment, Service 를 지우고, Security Context Constraints 권한을 부여한뒤 다시 설치하면 됩니다.

# oc delete pod nginx-5fb558b844-qg99g

# oc delete deployment nginx

# oc delete service nginx

# oc adm policy add-scc-to-user anyuid -z default
clusterrole.rbac.authorization.k8s.io/system:openshift:scc:anyuid added: "default"

다시 설치를 해봅니다.

# oc new-app docker.io/nginx:latest

nginx 가 정상 구동 된것을 확인하였습니다.

# oc get pods
NAME                     READY   STATUS    RESTARTS   AGE
nginx-5fb558b844-jp4jt   1/1     Running   0          11s

설치가 다 되었으므로 위에서 주었던 권한을 제거 합니다.

# oc adm policy remove-scc-from-user anyuid -z default
clusterrole.rbac.authorization.k8s.io/system:openshift:scc:anyuid removed: "default"

--------------------------------------------------

* 참고 : MySQL 설치시 에러가 발생할때

MySQL 설치시 에러가 출력되는데 이는 다음과 같이 해결이 가능합니다.

# oc new-app docker.io/mysql:latest

# oc get pods
NAME                     READY   STATUS             RESTARTS      AGE
mysql-cb5c58bfc-n2zmq   0/1     CrashLoopBackOff   4 (28s ago)   2m5s

# oc logs mysql-cb5c58bfc-n2zmq
2023-02-16 00:19:35+00:00 [Note] [Entrypoint]: Entrypoint script for MySQL Server 8.0.32-1.el8 started.
2023-02-16 00:19:35+00:00 [ERROR] [Entrypoint]: Database is uninitialized and password option is not specified
    You need to specify one of the following as an environment variable:
    - MYSQL_ROOT_PASSWORD
    - MYSQL_ALLOW_EMPTY_PASSWORD
    - MYSQL_RANDOM_ROOT_PASSWORD

데이터베이스가 초기화되지 않았으며 암호 옵션이 지정되지 않았다고 합니다.

Pod, Deployment, Service 를 지우고, 아래와 같이 환경 변수를 포함하여 MySQL 응용프로그램을 다시 배포 합니다.

# oc delete pod mysql-cb5c58bfc-n2zmq

# oc delete deployment mysql

# oc delete service mysql

# oc new-app docker.io/mysql:latest -e MYSQL_ROOT_PASSWORD=<mysql root 패스워드>

* 참고 : 컨테이너 환경 변수 확인

# oc set env pod <Pod 이름> --list
# pods/mysql-bd544cdb8-2w8dz, container mysql
MYSQL_ROOT_PASSWORD=12345678

--------------------------------------------------

2) 응용프로그램 삭제 

응용프로그램을 삭제할때는 Pod 와 Deployment, Service 까지 지워줍니다.

(1) Pod 확인 후 삭제

# oc get pods
NAME                    READY   STATUS             RESTARTS      AGE
mysql-cb5c58bfc-n2zmq   0/1     CrashLoopBackOff   3 (34s ago)   90s

# oc delete pod mysql-cb5c58bfc-n2zmq
pod "mysql-cb5c58bfc-n2zmq" deleted

(2) Deployments 확인 후 삭제

# oc get deployments
NAME    READY   UP-TO-DATE   AVAILABLE   AGE
mysql   0/1     1            0           30m
# oc delete deployments mysql
deployment.apps "mysql" deleted

(3) Service 확인 후 삭제

# oc get services
NAME    TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)              AGE
mysql   ClusterIP  172.30.186.165   <none>        3306/TCP,33060/TCP   26m
# oc delete service mysql
service "mysql" deleted

3) 응용프로그램 컨테이너 접근

컨테이너 쉘을 통하여 nginx 서비스에 접근하는 방법입니다. (rsh : remote shell)

# oc rsh nginx-5fb558b844-jp4jt

# hostname
nginx-5fb558b844-jp4jt

# pwd
/
# whoami
root

4) 라우팅 설정

외부에서 컨테이너 접근이 가능하도록 포트를 노출시킵니다.

뒤에 --port 80 옵션은 추가하지 않아도 컨테이너의 열려진 포트로 자동 설정됩니다.

# oc expose service nginx --port 80
route.route.openshift.io/nginx exposed
# oc get route
NAME    HOST/PORT                               PATH   SERVICES   PORT   TERMINATION   WILDCARD
nginx   nginx-project412.apps.az1.sysdocu.kr           nginx      80                   None

출력된 호스트명과 포트로 서비스 접근을 확인합니다.

# curl --head nginx-project412.apps.az1.sysdocu.kr

HTTP/1.1 200 OK
server: nginx/1.23.3
date: Thu, 16 Feb 2023 23:19:57 GMT
content-type: text/html
content-length: 615
last-modified: Tue, 13 Dec 2022 15:53:53 GMT
etag: "6398a011-267"
accept-ranges: bytes
set-cookie: 7769a7256fe4dda43770015df5735002=e53f29e3aa14fd7cc39e7efd9f5e8535; path=/; HttpOnly
cache-control: private

3. 스케일 아웃 (Replica)

1) Pod 복제

스케일 아웃은 성능 향상 및 부하 분산을 위해 사용하며, 동일한 Pod 가 복제 구성 되어집니다.

위에서 경험했듯 nginx 는 Pod 생성 전에 SCC 권한을 부여해야 합니다.

그리고 replica 를 2 로 조정하면 2개의 Pod 가 자동 생성되어집니다.

# oc adm policy add-scc-to-user anyuid -z default

# oc scale deployment nginx --replicas=2
deployment.apps/nginx scaled

복제되는 과정에서 컨테이너 양만큼 시간이 소요되며 모니터링을 해보면 아래와 같이 Ready 와 AVAILABLE 값이 2까지 늘어나는 것이 보입니다.

# oc get deployment nginx

NAME    READY   UP-TO-DATE   AVAILABLE   AGE
nginx   2/2     2            2           17m

Pod 와 엔드포인트도 replica 개수대로 늘어난 것을 확인할 수 있습니다.

# oc get pods
NAME                     READY   STATUS    RESTARTS   AGE
nginx-5fb558b844-8nz5f   1/1     Running   0          2m7s
nginx-5fb558b844-jp4jt   1/1     Running   0          19m

# oc get ep nginx
NAME    ENDPOINTS                       AGE
nginx   10.128.2.56:80,10.131.1.42:80   19m

Pod 가 추가 생성이 확인 되었으므로 SCC 권한을 제거 합니다.

# oc adm policy remove-scc-from-user anyuid -z default

Pod 하나를 삭제 해보세요. 또다른 이름의 Pod 가 자동 생성되어 replica 개수 2 로 유지하는 것을 볼 수 있습니다.

2) 클러스터 접근 허용 설정

현재의 서비스 정보에서 nginx type 이 ClusterIP 로 되어있습니다.

# oc get service
NAME    TYPE        CLUSTER-IP     EXTERNAL-IP   PORT(S)   AGE
nginx   ClusterIP   172.30.252.2   <none>        80/TCP    20m

기존 서비스를 삭제하고 LoadBalancer 형태로 다시 생성해 줍니다.

# oc delete service nginx
service "nginx" deleted

# oc expose deployment nginx --type=LoadBalancer --port 80
service/nginx exposed

다시 서비스 정보를 출력해보면 nginx 가 LoadBalancer 형태로 바뀌었습니다.

# oc get service
NAME    TYPE           CLUSTER-IP      EXTERNAL-IP   PORT(S)        AGE
nginx   LoadBalancer   172.30.167.95   <pending>     80:31574/TCP   31s

(이부분 생략, 위에서 했었음)

외부에서 컨테이너 접근이 가능하도록 포트를 노출시킵니다.

# oc expose service nginx --port 80
route.route.openshift.io/nginx exposed
# oc get route
NAME    HOST/PORT                               PATH   SERVICES   PORT   TERMINATION   WILDCARD
nginx   nginx-project412.apps.az1.sysdocu.kr           nginx      80                   None

route 정보에 출력된 호스트명과 포트로 서비스에 접근할 수 있는데,

두개의 컨테이너에 번갈아 가며 접근하는 것이 확인됩니다.

확인을 위해 각각의 컨테이너 쉘로 로그인하여 index.html 파일 내용을 변경합니다.

# oc rsh nginx-5fb558b844-8nz5f
# echo "one" > /usr/share/nginx/html/index.html
# exit

# oc rsh nginx-5fb558b844-jp4jt
# echo "two" > /usr/share/nginx/html/index.html
# exit

curl 명령을 반복하여 호출하는 페이지 내용을 확인합니다.

# curl nginx-project412.apps.az1.sysdocu.kr
one
# curl nginx-project412.apps.az1.sysdocu.kr
one
# curl nginx-project412.apps.az1.sysdocu.kr
two
# curl nginx-project412.apps.az1.sysdocu.kr
one

본 문서는 공식 Documents 를 참고하여 작성하였습니다.

https://docs.openshift.com/container-platform/4.12/authentication/understanding-identity-provider.html

OpenShift 컨테이너 플랫폼 마스터에는 OAuth 서버가 내장되어 있습니다.

개발자 및 관리자는 OAuth 액세스 토큰을 취득하여 API 에 대해 자신을 인증할 수 있습니다.

처음 클러스터를 구성하면 모든 Openshift 관리 권한을 가진 kubeadmin 이라는 계정만 존재하게 됩니다.

여기에 동일한 권한의 관리자 계정이나 프로젝트 단위의 권한이 작은 사용자 계정을 추가할 수 있습니다.

ID 생성을 위해 ID 제공자를 선택해야 하는데, ID 제공자는 htpasswd, Keystone, LDAP, Basic authentication, Request header, GitHub or GitHub Enterprise, GitLab, Google, OpenID Connect 가 있습니다.

여기에서는 우리에게 친숙한 htpasswd 를 통하여 계정 생성하는 방법과

웹콘솔에 접근하기 위해 사용되는 기본계정 kubeadmin 을 대체하는 방법을 알아봅니다.

1. 프로젝트 (Namespace) 생성

현재 사용자를 확인합니다.

# export KUBECONFIG=/root/installation_directory/auth/kubeconfig

# oc whoami

system:admin

testwork 라는 프로젝트 (Namespace) 를 생성합니다.

# oc create ns testwork
namespace/testwork created

생성한 프로젝트를 확인합니다.

testwork 프로젝트는 물론이고 Openshift 를 구성하는 모든 프로젝트가 출력됩니다.

# oc get ns

또는

# oc get projects

2. 계정 관리

1) 계정 추가

우선 htpasswd 명령어를 사용하기 위해 패키지를 하나 설치 합니다.

# yum -y install httpd-tools

옵션 뒤에 파일명, ID, PW 순서로 생성을 원하는 계정정보 입력 후 실행합니다.

# htpasswd -c -B -b list.txt sysdocu 12345678
Adding password for user sysdocu

한개의 계정을 추가로 입력합니다.

# htpasswd -B -b list.txt fntop abcdABCD

Adding password for user fntop

계정 정보가 파일에 잘 입력되었는지 확인합니다.

# cat list.txt

sysdocu:$2y$05$0SIDRCNuYNZIQngZBdWzN.UlaA5CY6XM6wPQLMuAy908B7v.Y62mW

fntop:$2y$05$YW1tslShApDQEMxDfsfJUuck0adzlArLWiznqzTtDZVNTcDfvTgYq

계정정보가 들어있는 파일을 이용하여 위에서 생성한 testwork 프로젝트에 생성합니다.

myusers 라는 계정들의 별칭을 짓고 list.txt 파일 내용 (sysdocu, fntop 계정 정보) 를 입력합니다.

# oc create secret generic myusers --from-file=htpasswd=list.txt -n testwork

secret/myusers created

2) 계정 업데이트

계정을 생성하는 또 다른 방법과 기존 계정을 삭제하는 방법 입니다.

'계정 업데이트' 내용이 필요하지 않을 경우 건너뛰어도 됩니다.

(1) 현재 정보 저장

현재 HTPasswd secret 정보를 파일로 추출 (아래 {.data.htpasswd} 문자 그대로 입력)
$ oc get secret myusers -ojsonpath={.data.htpasswd} -n testwork | base64 --decode > current_list.txt

(2-1) 새 사용자 추가
$ htpasswd -bB current_list.txt <username> <password>

(2-2) 기존 사용자 삭제
$ htpasswd -D current_list.txt <username>

(3) 변경 정보 갱신

생성한 시크릿을 testwork 프로젝트 (Namespace) 에 갱신
$ oc create secret generic myusers --from-file=htpasswd=current_list.txt --dry-run=client -o yaml -n testwork | oc replace -f -

(4) 사용자 및 리소스 삭제

하나 이상의 사용자를 삭제한 경우 각 사용자의 기존 리소스를 추가로 제거해야 합니다.

삭제하지 않으면 토큰이 만료되지 않은 한 계속 사용할 수 있습니다.

# oc delete user <username>

# oc delete identity my_htpasswd_provider:<username>

// my_htpasswd_provider 는 identityProviders 이름 입니다.

3. web-console 계정 교체

새 클러스터 관리자를 생성한 후 kubeadmin 을 제거하여 클러스터 보안을 개선할 수 있습니다.
다른 사용자가 cluster-admin 이 되기 전에 kubeadmin 계정을 삭제 할 경우 OpenShift Container Platform 을 다시 설치해야 합니다.

이 명령은 취소가 안되므로 반드시 하나 이상의 계정에 cluster-admin 역할을 추가하고 로그인이 되는것을 확인합니다.

그리고 kubeadmin 계정을 삭제 해야 합니다.

1) 계정 추가

계정은 위에서 생성한 sysdocu 계정을 사용하도록 하겠습니다.

openshift-config 프로젝트에 계정을 생성합니다.

# oc create secret generic myusers --from-file=htpasswd=list.txt -n openshift-config

커스텀 리소스를 yaml 파일로 생성합니다.

# vi htpasswd.yaml

identityProviders: name: 사용자를 구분짓는 별칭

identityProviders: type: 생성했던 계정의 ID 제공자

htpasswd: fileData: name: openshift-config 프로젝트에 생성했던 계정들 별칭으로 위 예제에서는 sysdocu, fntop 두 개의 계정입니다.

정의된 커스텀 리소스를 적용하여 웹 콘솔에서 로그인이 가능하도록 합니다.

# oc apply -f htpasswd.yaml
oauth.config.openshift.io/cluster configured

브라우저로 웹 콘솔 페이지에 접속하면 기존과 다르게, 먼저 아래 두가지 사용자에 대해 선택하도록 되어 있습니다.

- kube:admin

- my_htpasswd_provider

아래 my_htpasswd_provider 를 선택하고 위에서 생성한 계정 sysdocu 로 로그인합니다.

로그인이 확인되면 kubeadmin 계정을 지우도록 합니다.

2) kubeadmin 계정 삭제
삭제 명령은 다음과 같습니다.
# oc delete secrets kubeadmin -n kube-system

4. 권한 관리

RBAC (Role-Based Access Control) 를 사용한 권한 정의 및 적용 방법 입니다.

RBAC 는 오브젝트에 따라 사용자의 권한이 결정되고 프로젝트 내에서 지정된 작업을 수행합니다.

[ RBAC 의 두가지 레벨 ]

- Cluster RBAC : cluster-admin 에 해당되는 권한으로 클러스터 내 모든 프로젝트에 접근하거나 관리가 가능합니다.

- Local RBAC : 지정된 프로젝트에만 접근하거나 관리가 가능합니다.

[ Openshift 구축시 제공되는 기본 클러스터 역할 (role) ]

- admin : 프로젝트 매니저로서 프로젝트의 리소스를 보고 수정하는 권한을 가지고 있습니다.
- basic-user : 프로젝트 및 사용자에 대한 기본 정보를 얻을 수 있는 사용자입니다.
- cluster-admin : 모든 프로젝트에서 모든 작업을 수행할 수 있는 슈퍼 사용자 (최상위 관리자) 입니다.

                           로컬 바인딩을 가진 사용자에게 바인드되어 할당량을 완전히 제어할 수 있습니다.

                           프로젝트의 모든 리소스에 대한 모든 작업을 수행할 수 있습니다.
- cluster-status : 기본 클러스터 상태 정보를 가져올 수 있는 사용자입니다.
- cluster-reader : 대부분의 개체를 가져오거나 볼 수 있지만 수정할 수 없습니다.
- edit : 프로젝트의 대부분의 개체를 수정할 수 있지만 역할 또는 바인딩을 보거나 수정 권한이 없는 사용자입니다.
- self-provisioner : 자신의 프로젝트를 생성할 수 있는 사용자입니다.
- view : 변경할 수 없지만 대부분의 개체를 볼 수 있는 사용자입니다.

            프로젝트, 역할 또는 바인딩을 보거나 수정할 수 없습니다.

1) 계정과 역할 연결 (Binding)

생성된 계정과 Role 을 연결하여, 계정에 역할을 부여하는 작업을 바인딩 이라고 합니다.

현재 생성되어진 sysdocu 계정에는 admin 권한을 바인딩하고, fntop 계정은 그대로 두어 프로젝트 접근 여부를 비교해 보도록 합니다.

testwork 프로젝트의 sysdocu 계정에 admin 역할을 연결 (binding) 합니다.

# oc adm policy add-role-to-user admin sysdocu -n testwork

clusterrole.rbac.authorization.k8s.io/admin added: "sysdocu"

testwork 프로젝트의 로컬 역할 바인딩을 보려면 아래와 같이 실행합니다.

# oc describe rolebinding.rbac -n testwork

2) 권한 비교

sysdocu 계정으로 전환하고 프로젝트 리스트를 확인합니다.

# oc login -u sysdocu

Password: (패스워드 입력)

You have access to 68 projects, the list has been suppressed. You can list all projects with 'oc projects'

Using project "default".

// 68개 프로젝트 접근 가능 확인

# oc whoami

sysdocu

# oc get ns

...

// 68개 프로젝트 출력

fntop 계정으로 전환하고 프로젝트 리스트를 확인합니다.

# oc login -u fntop

Password: (패스워드 입력)

You don't have any projects. You can try to create a new project, by running

oc new-project <projectname>

// 프로젝트 없음 확인

# oc whoami

fntop

# oc get ns

Error from server (Forbidden): namespaces is forbidden: User "fntop" cannot list resource "namespaces" in API group "" at the cluster scope

// 권한 없음 확인

원래의 admin 계정으로 전환합니다.

# oc login -u system:admin

You have access to 68 projects, the list has been suppressed. You can list all projects with 'oc projects'
Using project "default".

// 68개 프로젝트 접근 가능 확인

# oc whoami

system:admin

# oc get ns

...

// 68개 프로젝트 출력

Cluster Operators 상태 확인 명령중 machine-config 에서 아래와 같은 오류가 출력되었습니다.

필수 시스템 구성 풀 동기화 중 오류 발생한 내용으로 출력되며,

이에대한 조치는 다음과 같이 할 수 있습니다.

[ 에러 ]

# oc get co machine-config
NAME             VERSION   AVAILABLE   PROGRESSING   DEGRADED   SINCE   MESSAGE
machine-config   4.12.0    True        False         True       4d17h   Failed to resync 4.12.0 because: error during syncRequiredMachineConfigPools: [timed out waiting for the condition, error pool master is not ready, retrying. Status: (pool degraded: true total: 3, ready 0, updated: 0, unavailable: 2)]

[ 시도 ]

Machine Config 정보를 확인합니다.

# oc get mc
NAME                                               GENERATEDBYCONTROLLER                      IGNITIONVERSION   AGE
00-master                                          2b3eba74dd9e4371f35ab41dbda02642f60707ec   3.2.0             4d18h
00-worker                                          2b3eba74dd9e4371f35ab41dbda02642f60707ec   3.2.0             4d18h
01-master-container-runtime                        2b3eba74dd9e4371f35ab41dbda02642f60707ec   3.2.0             4d18h
01-master-kubelet                                  2b3eba74dd9e4371f35ab41dbda02642f60707ec   3.2.0             4d18h
01-worker-container-runtime                        2b3eba74dd9e4371f35ab41dbda02642f60707ec   3.2.0             4d18h
01-worker-kubelet                                  2b3eba74dd9e4371f35ab41dbda02642f60707ec   3.2.0             4d18h
99-master-generated-registries                     2b3eba74dd9e4371f35ab41dbda02642f60707ec   3.2.0             4d18h
99-master-ssh                                                                                 3.2.0             4d20h
99-worker-generated-registries                     2b3eba74dd9e4371f35ab41dbda02642f60707ec   3.2.0             4d18h
99-worker-ssh                                                                                 3.2.0             4d20h
rendered-master-66a1694f13f84151e53205fd83d336d0   2b3eba74dd9e4371f35ab41dbda02642f60707ec   3.2.0             16h
rendered-worker-bb1960e620ab292f59adbe8549700341   2b3eba74dd9e4371f35ab41dbda02642f60707ec   3.2.0             20h
rendered-worker-e04ed26b510360ba9a8ccbba6aa7382e   2b3eba74dd9e4371f35ab41dbda02642f60707ec   3.2.0             4d18h

Machine Config Poll 을 확인합니다.

# oc get mcp
NAME     CONFIG                                             UPDATED   UPDATING   DEGRADED   MACHINECOUNT   READYMACHINECOUNT   UPDATEDMACHINECOUNT   DEGRADEDMACHINECOUNT   AGE
master                                                      False     True       True       3              0                   0                     3                      16h
worker   rendered-worker-e04ed26b510360ba9a8ccbba6aa7382e   False     True       True       2              0                   0                     1                      4d19h

위에서 master 만의 문제라면 아래 명령 만으로 상태 제거 (시간이 지나면 다시 자동으로 생성 됌) 하면 되겠지만

# oc delete mcp master

실 사례 에서는 worker 노드까지 문제가 발생한 것으로 확인되었습니다.

머신의 구성 풀을 조사하면, 문제의 원인이 설정 변경 때문인지 아닌지를 판단할 수 있습니다.

# oc describe mcp worker |grep -i node
        f:nodeSelector:
            f:node-role.kubernetes.io/worker:
  Node Selector:
      node-role.kubernetes.io/worker:  
    Message:               All nodes are updating to rendered-worker-bb1960e620ab292f59adbe8549700341
    Message:               Node worker01.az1.sysdocu.kr is reporting: "Error checking type of update image: failed to run command podman (6 tries): [timed out waiting for the condition, running podman pull -q --authfile /var/lib/kubelet/config.json quay.io/openshift-release-dev/ocp-v4.0-art-dev@sha256:6db665511f305ef230a2c752d836fe073e80550dc21cede3c55cf44db01db365 failed: Error: initializing source docker://quay.io/openshift-release-dev/ocp-v4.0-art-dev@sha256:6db665511f305ef230a2c752d836fe073e80550dc21cede3c55cf44db01db365: reading manifest sha256:6db665511f305ef230a2c752d836fe073e80550dc21cede3c55cf44db01db365 in quay.io/openshift-release-dev/ocp-v4.0-art-dev: unauthorized: access to the requested resource is not authorized\n: exit status 125]"
    Reason:                1 nodes are reporting degraded status on sync
    Type:                  NodeDegraded

worker01.az1.sysdocu.kr 노드의 상태를 좀 더 자세히 확인합니다.

# oc describe node/worker01.az1.sysdocu.kr

...

Annotations:        machineconfiguration.openshift.io/controlPlaneTopology: HighlyAvailable
                    machineconfiguration.openshift.io/currentConfig: rendered-worker-e04ed26b510360ba9a8ccbba6aa7382e
                    machineconfiguration.openshift.io/desiredConfig: rendered-worker-bb1960e620ab292f59adbe8549700341
                    machineconfiguration.openshift.io/desiredDrain: uncordon-rendered-worker-e04ed26b510360ba9a8ccbba6aa7382e
                    machineconfiguration.openshift.io/lastAppliedDrain: uncordon-rendered-worker-e04ed26b510360ba9a8ccbba6aa7382e
                    machineconfiguration.openshift.io/reason:
                      Error checking type of update image: failed to run command podman (6 tries): [timed out waiting for the condition, running podman pull -q ...
                      : exit status 125]
                    machineconfiguration.openshift.io/ssh: accessed
                    machineconfiguration.openshift.io/state: Degraded
                    volumes.kubernetes.io/controller-managed-attach-detach: true

...

노드 상태는 여전히 Degraded 로 확인되었습니다.

[ 해결 ]

insights 항목의 오류 부분을 해결하고자 오류 이벤트를 전송하지 않도록 disable 해놨었는데,

그것이 원인이 되어 machine-config 가 에러 발생한 것이였습니다.

insights 를 disable 하지 않아도 어차피 오류 정보는 전송이 안될테니까 아래 내용으로 돌려놨더니

machine-config 가 정상으로 돌아왔습니다.

# oc get co insights
NAME       VERSION   AVAILABLE   PROGRESSING   DEGRADED   SINCE   MESSAGE
insights   4.12.0    False       False         True       7d16h   Unable to report: unable to build request to connect to Insights server: Post "https://console.redhat.com/api/ingress/v1/upload": x509: certificate is valid for *.apps.az1.sysdocu.kr, not console.redhat.com

# oc get co machine-config
NAME             VERSION   AVAILABLE   PROGRESSING   DEGRADED   SINCE   MESSAGE
machine-config   4.12.0    True        False         False      7d18h  

로그인 창이 뜨기도 전에 접근이 안된다면 도메인 문제는 아닌가 확인해보세요.

[ 에러 ]
아래와 같은 OpenShift web-console URL 을 브라우저에서  접근하려 할때 접근 불가 메세지 출력

(예 : 도메인에 오타가 있는지 살펴보세요. 등)
https://console-openshift-console.apps.az1.sysdocu.kr


[ 조치 ]
실제로 사용하지 않는 테스트 도메인을 입력 후 연결하려 하였을때 발생합니다.
접근하려는 작업 PC 에서 아래와 같이 OpenShift web-console 에 접근하기 위해 사용하는 도메인 두개와 서버 IP 를 hosts 에 등록하면 됩니다.

# vi /etc/hosts
...
192.168.0.2 console-openshift-console.apps.az1.sysdocu.kr oauth-openshift.apps.az1.sysdocu.kr

아래와 같은 명령으로 insights 항목에 에러가 출력된 경우

[ 에러 ]
# oc get co insights
insights                                   4.12.0    False       False         True       3d20h   Unable to report: unable to build request to connect to Insights server: Post "https://console.redhat.com/api/ingress/v1/upload": x509: certificate is valid for *.apps.az1.sysdocu.kr, not console.redhat.com

[ 원인 ]
insights 는 윈도우즈나 다른 응용프로그램처럼 프로그램 개선에 참여하기 위해 오류 정보를 SW 개발사로 전송하여 버그 수정 및 패치에 도움을 주고자 하는 일을 담당합니다.
이를 비활성화하여 오류 정보를 보내지 않도록 합니다.

[ 조치 ]
1) 애초에 Openshift 설치시 install-config.yaml 파일에서 Pull secret 값을 입력하지 않습니다.
2) 모르고 설치한 경우 Pull secret 파일을 추출하여 인증값을 제거, 업데이트 합니다.
# oc extract secret/pull-secret -n openshift-config --to=.
# vi .dockerconfigjson

아래 형식으로 남게끔 .dockerconfigjson 파일을 수정합니다.
(앞부분 항목 1개와 중괄호 한개만 지우고, hash 와 email 은 수정하지 않아도 됩니다.)
"cloud.openshift.com":{"auth":"<hash>","email":"<email_address>"}

저장 후 아래와 같이 Pull secret 을 업데이트 합니다.
# oc set data secret/pull-secret -n openshift-config --from-file=.dockerconfigjson

어느정도 시간이 소요되어 결과를 다시 확인하면 아래와 같이 disabled 되었다는 표시가 출력됩니다.
# oc get co insights
insights                                   4.12.0    False       False         False      3d20h   Health reporting is disabled

[ 참고 ]

insights 를 비활성화 하면 machine-config 에서 에러가 발생하는 현상이 확인되었습니다.

되돌리면 정상으로 출력되나 다시 insights 에러가 나타나는데 원인은 아직 미확인 되었습니다.

(어쩌면 insights 를 사용 안하려는 목적이였으므로 에러난 채로 두어도 되지 않을까 생각함)

# oc get co machine-config
NAME             VERSION   AVAILABLE   PROGRESSING   DEGRADED   SINCE   MESSAGE
machine-config   4.12.0    True        False         True       4d19h   Failed to resync 4.12.0 because: error during syncRequiredMachineConfigPools: [timed out waiting for the condition, error pool worker is not ready, retrying. Status: (pool degraded: true total: 2, ready 0, updated: 0, unavailable: 0)]

[출처] https://docs.openshift.com/container-platform/4.12/support/remote_health_monitoring/opting-out-of-remote-health-reporting.html#insights-operator-new-pull-secret_opting-out-remote-health-reporting

Openshift 의 무료 버전이 있습니다. 예전 커뮤니티 버전 Openshift origin 이 새 이름 OKD 로 배포되고 있는데요.

공식 홈페이지는 https://www.okd.io 이며, 관련 문서는 https://docs.okd.io/ 에서 확인하실 수 있습니다.

그리고 Openshift 의 Documents 는 다음과 같습니다.

https://docs.openshift.com/container-platform/4.12/welcome/index.html

양쪽 Documents 를 살펴보니 설치와 운영상의 차이는 없어보이고, master 노드와 worker 노드에 사용되는 운영체제가 각각 FCOS (OKD), RHCOS (Openshift) 이라는게 눈에 띄는데요. OKD 가 무료이면 Openshift 는 유료인가 싶어서 레드햇사에 문의를 해보았더니 배포되는 Openshift 이미지로 서비스를 만들어서 무료 제공하면 괜찮지만, 유료로 판매하면 안된다고 하였습니다. 하지만 OKD 는 서비스 구성후 상업용으로 판매해도 된다고 확인하였으며, 운영 환경에서 발생되는 다양한 오류나 버그는 직접 해결해야하는 단점이 있다고 하였습니다.

여기에서는 테스트 목적이므로 Openshift 기반으로 작성되었음을 알려드립니다.

[ 테스트에 사용된 서버 ]

- OCP 서버 제외하고, 기입된 CPU, RAM, Disk, IOPS 는 최소 리소스 요구사항입니다.

- 테스트를 진행했던 모든 서버는 공인 IP 1개씩만 사용하였습니다.

  혹시 공인 IP 로 테스트하기 어려운 환경일 경우 사설 IP 를 사용하고 마스커레이드 서버 (게이트웨이) 에서

  외부망으로 연결이 가능하도록 셋팅해 놓으면 됩니다.

- bootstrap 및 master (Control plane) 서버를 지원하는 유일한 운영체제는 RHCOS (Redhat CoreOS) 입니다.

  worker (Compute) 서버는 RHCOS, RHEL 8.4, RHEL 8.5 로 사용이 가능합니다.

- az1 은 클러스터명입니다. 여러개의 클러스터를 구분하기 위해 사용하였습니다.

- 공식 Document 상의 명칭 정리 : Control plane = master, Compute = worker

- 주 명령을 실행하는 첫번째 서버는 Bastion 서버라고도 불리는데 여기에서는 OCP 서버라고 명칭 하도록 하겠습니다.

* OS 이미지 다운로드

CentOS : https://centos.org/download/

RHCOS : https://mirror.openshift.com/pub/openshift-v4/x86_64/dependencies/rhcos/4.12

1. DNS 설치

Openshift 사용을 위해 내부 DNS 를 준비해야 합니다.

OCP 서버에서 DNS, LoadBalancer 및 http 파일 서버 역할을 담당하게 됩니다.

미리 준비가 된 OCP 서버 (CentOS 7) 에서 작업을 진행합니다.

# yum -y update

# yum -y upgrade

SELinux 비활성화 설정을 하고 적용합니다.

# vi /etc/selinux/config

# setenforce 0

호스트 네임을 적용 합니다.

예) hostnamectl set-hostname ocp.az1.sysdocu.kr

bind 패키지를 설치합니다.

# yum -y install bind bind-utils

정방향 및 역방향 zone 파일을 생성합니다. (둘 다 필요)

# vi /var/named/sysdocu.kr.zone

# vi /var/named/142.68.115.rev.zone

외부에서도 질의가 가능하도록 하고 zone 파일을 config 파일에 연결 합니다.

# vi /etc/named.conf

아래 파일에 zone 파일을 연결합니다.

# vi /etc/named.rfc1912.zones

데몬을 재시작하고 정방향과 역방향 질의가 잘 되는지 테스트 합니다.

# systemctl enable named

# systemctl start named

# nslookup ocp.az1.sysdocu.kr localhost
Server: localhost
Address: 127.0.0.1#53

Name: ocp.az1.sysdocu.kr
Address: 115.68.142.99

# nslookup 115.68.142.99 localhost
99.142.68.115.in-addr.arpa name = api-int.az1.sysdocu.kr.
99.142.68.115.in-addr.arpa name = api.az1.sysdocu.kr.

서버의 1차, 2차 네임서버를 지정합니다.

네트워크 설정 파일에서의 DNS 도 올바르게 입력해주세요.

NetworkManager 사용시 설정파일에서 바꾸고 데몬 재시작을 해주면 resolv.conf 에도 적용됩니다.

# cat /etc/resolv.conf

2. HTTP 파일 서버 설정

# vi /etc/yum.repos.d/nginx.repo

# yum -y install nginx
# systemctl start nginx

nginx 를 설정 파일을 열고 아래 내용으로 수정합니다.

# vi /etc/nginx/conf.d/default.conf

파일 서버로 사용할 디렉토리를 만듭니다.

# mkdir /usr/share/nginx/html/files

설정했던 내용이 적용되도록 합니다.

# systemctl reload nginx

방화벽 사용중일 경우 8080 포트 접근이 가능하도록 룰 추가 및 데몬 재시작을 해줍니다.

저는 테스트가 목적이므로 아래와 같이 모든 방화벽 룰을 내렸습니다.

하지만 실제 서비스 구성시 방화벽에 필요한 포트만 오픈하는것이 좋습니다.

# systemctl stop firewalld

웹브라우저로 OCP 서버 8080 포트로 접속하면 현재는 파일이 없으므로 상위 디렉토리 이동 링크만 확인됩니다.

http://115.68.142.99:8080

3. LB (LoadBalancer) 설정

LB 구성을 위해 haproxy 를 설치하고 설정파일을 아래 내용으로 변경 합니다.

# yum -y install haproxy

# cp -arp /etc/haproxy/haproxy.cfg /etc/haproxy/haproxy.cfg.ori
# vi /etc/haproxy/haproxy.cfg

데몬이 서버 부팅시 자동 구동 되도록 하고, 설정된 값은 재시작하여 적용합니다.

# systemctl enable haproxy

# systemctl start haproxy

참고로 HAproxy 로드발란서 상태 및 전송량 등 통계를 확인하려면 위에서 설정한대로 아래 URL 및 계정을 이용하여 로그인하면 됩니다.

http://115.68.142.99:1936/stats

계정 : admin / az1@

4. Openshift Installer 설치

Openshift Installer 는 Redhat 계정을 만들고 다운로드 해야 하지만 미러 서버에서도 설치 파일을 배포하고 있으므로

여기에서는 설치파일을 계정 없이 다운로드 받아 설치를 진행하겠습니다.

하지만 하단에서 secret 키가 필요하므로 반드시 Redhat 계정으로 로그인하여 확인하는 작업이 필요합니다.

다운로드 미러 서버 : https://mirror.openshift.com/pub/openshift-v4/clients/ocp/

1) install 및 client 파일 다운로드

설치 파일을 미러 서버에서 다운로드 받습니다.

# yum -y install wget

# wget https://mirror.openshift.com/pub/openshift-v4/clients/ocp/4.12.0/openshift-install-linux-4.12.0.tar.gz

압축을 해제 합니다.

# tar xvzf openshift-install-linux-4.12.0.tar.gz

# ./openshift-install version
./openshift-install 4.12.0
built from commit ba940311c8cb2a07173725e5c2f668df7c61924c
release image quay.io/openshift-release-dev/ocp-release@sha256:4c5a7e26d707780be6466ddc9591865beb2e3baa5556432d23e8d57966a2dd18
release architecture amd64

Client 파일을 다운로드 받아 설치합니다.

# wget https://mirror.openshift.com/pub/openshift-v4/clients/ocp/4.12.0/openshift-client-linux-4.12.0.tar.gz

# tar xvzf openshift-client-linux-4.12.0.tar.gz

# mv oc kubectl /usr/local/bin/

# oc version
Client Version: 4.12.0
Kustomize Version: v4.5.7

# kubectl version
WARNING: This version information is deprecated and will be replaced with the output from kubectl version --short.  Use --output=yaml|json to get the full version.
Client Version: version.Info{Major:"1", Minor:"24", GitVersion:"v1.24.1", GitCommit:"854f807d8a84dde710c062a5281bca5bc07cb562", GitTreeState:"clean", BuildDate:"2023-01-05T01:27:27Z", GoVersion:"go1.19.4", Compiler:"gc", Platform:"linux/amd64"}
Kustomize Version: v4.5.7
Error from server (NotFound): the server could not find the requested resource

2) ssh key 생성

클러스터 노드 SSH 접근을 위해 키를 생성합니다.

생성된 키가 노드에 전달되면 클러스터 각 노드 SSH 원격 접속을 할 수 있습니다.

# ssh-keygen -t ed25519 -N '' -f ~/.ssh/id_ed25519

# cat ~/.ssh/id_ed25519.pub
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIMbzVOXu4A6uUsYyD0cbGAhWTF2HdqOIQaIwuk+b4qCQ root@ocp.az1.sysdocu.kr

아래 OpenShift 컨테이너 플랫폼을 설치할 때 설치 프로그램에 해당 키를 입력할 예정입니다.

3) 설치 구성 파일 생성

설치 디렉토리를 만들고 이동합니다.

# mkdir installation_directory
# cd installation_directory

Redhat 로그인 후 아래 URL (Downloads 메뉴) 페이지 맨 하단부에 Tokens 항목을 확인합니다.

https://console.redhat.com/openshift/downloads

'Pull secret' 이 있는데 행 끝에 'Copy' 버튼을 눌러 내용을 복사하고 기록해 둡니다.

아래 내용으로 yaml 파일을 생성합니다.

# vi install-config.yaml

baseDomain : DNS 서버 구축시 사용한 도메인

compute: replicas: 수동으로 연결해주어야 하기 때문에 반드시 0 으로 설정합니다.

metadata: name: 클러스터 이름

clusterNetwork : Pod IP 주소가 할당되는 범위

serviceNetwork : 서비스 IP 주소가 할당되는 범위

pullSecret : Redhat 홈페이지에서 복사한 Pull secret 키

sshKey : 위에서 ssh-keygen 으로 생성한 public key

               # cat ~/.ssh/id_ed25519.pub 으로 출력된 키 (행 전체)

networkType : 설치할 클러스터 네트워크 플러그인입니다. (설치 후 변경 불가)

                        지원되는 값은 OVNKubernetes (Default) 및 OpenShiftSDN 입니다.

install-config.yaml 파일에 대한 자세한 설명 : https://docs.openshift.com/container-platform/4.12/installing/installing_bare_metal/installing-bare-metal.html#installation-bare-metal-config-yaml_installing-bare-metal

아래에서 manifest 파일 생성시 install-config.yaml 파일이 삭제되므로 만일을 위해 백업을 해둡니다.

# cp -arp install-config.yaml install-config.yaml.bak

# cd ..

4) manifest 파일 생성

# ./openshift-install create manifests --dir installation_directory/

INFO Consuming Install Config from target directory 
WARNING Making control-plane schedulable by setting MastersSchedulable to true for Scheduler cluster settings 
INFO Manifests created in: installation_directory/manifests and installation_directory/openshift 

생성된 두 개의 디렉토리 안에 다양한 manifest 파일이 생성되었습니다.

# cd installation_directory

# ll
합계 12
-rw-r--r-- 1 root root 3572  1월 26 11:20 install-config.yaml.bak
drwxr-x--- 2 root root 4096  1월 26 11:21 manifests
drwxr-x--- 2 root root 4096  1월 26 11:21 openshift

* 참고

manifests/cluster-scheduler-02-config.yml 파일의 mastersSchedulable 파라미터 값은 아래와 같습니다.

- true : Master 에 POD 가 스케쥴링 될 수 있으며, Master 가 Worker 의 역할까지 수행 (Default 값)

- false : Master 는 컨트롤플레인의 역할만 하게 되어 Worker 노드가 추가로 필요 함. (권장 사항)

위 내용대로 리소스를 많이 사용하게 될 Worker 노드를 별도로 둘 예정이므로 yaml 파일을 수정합니다.

(mastersSchedulable: true -> false)

# sed -i 's/true/false/' manifests/cluster-scheduler-02-config.yml

5) ignition 파일 생성

CoreOS 를 초기 구성하는데 필요한 파일 ignition 파일을 생성합니다.

# cd ..
# ./openshift-install create ignition-configs --dir installation_directory/

INFO Consuming Openshift Manifests from target directory 
INFO Consuming Master Machines from target directory 
INFO Consuming Worker Machines from target directory 
INFO Consuming OpenShift Install (Manifests) from target directory 
INFO Consuming Common Manifests from target directory 
INFO Ignition-Configs created in: installation_directory and installation_directory/auth 

# cd installation_directory

# ll

합계 292
drwxr-x--- 2 root root     48  1월 26 11:38 auth
-rw-r----- 1 root root 280621  1월 26 11:38 bootstrap.ign
-rw-r--r-- 1 root root   3572  1월 26 11:20 install-config.yaml.bak

drwxr-x--- 2 root root   4096  1월 26 11:33 manifests.bak
-rw-r----- 1 root root   1719  1월 26 11:38 master.ign
-rw-r----- 1 root root     98  1월 26 11:38 metadata.json

drwxr-x--- 2 root root   4096  1월 26 11:33 openshift.bak
-rw-r----- 1 root root   1719  1월 26 11:38 worker.ign

생성된 ignition 파일들을 nginx 파일 서버 디렉토리로 복사하고 다운로드가 가능하도록 퍼미션을 조정합니다.

# cp -arp *.ign /usr/share/nginx/html/files/

# chmod 644 /usr/share/nginx/html/files/*

* 참고

추후 클러스터 명 변경 (예 : az1)을 위해 다시 ignition 파일을 생성할 경우 아래 파일은 덮어씌워지지 않으므로 

아래 파일을 수동으로 삭제 후 ignition 파일을 생성해야 합니다.

installation_directory/auth/.openshift_install_state.json

5. bootstrap 서버 설치

ISO 다운로드 : https://mirror.openshift.com/pub/openshift-v4/dependencies/rhcos/

위 URL 에서 RH CoreOS ISO 파일을 다운로드 하고, OS 설치를 위해 CD 굽기 또는 iODD 와 같은 장치에 넣어둡니다.

나머지 서버 6대 (bootstrap, master, worker) 에 설치를 해야 합니다.

- 파일명 : rhcos-4.12.0-x86_64-live.x86_64.iso

파일 URL 은 아래와 같은 명령으로도 쉽게 확인이 가능합니다. (위와 같은파일)

# ./openshift-install coreos print-stream-json | grep '\.iso[^.]' | grep x86_64
                "location": "https://rhcos.mirror.openshift.com/art/storage/prod/streams/4.12/builds/412.86.202212081411-0/x86_64/rhcos-412.86.202212081411-0-live.x86_64.iso",

* OCP 서버에서 작업합니다.

추후 bootstrap.ign 검증을 위해 해시값이 필요한데, 해시값의 길이가 길어 타이핑이 어려우므로 bootstrap.hash 파일에 해시값 넣습니다.

# cd /usr/share/nginx/html/files

# sha512sum bootstrap.ign |awk {'print $1'} > bootstrap.hash

# sha512sum master.ign |awk {'print $1'} > master.hash

# sha512sum worker.ign |awk {'print $1'} > worker.hash

* 여기부터 bootstrap 서버에서의 작업입니다.

bootstrap 서버에 CD 또는 iODD 장치를 연결하고 위에서 다운로드 받았던 RH CoreOS ISO 이미지로 부팅하면 시간이 지나 명령 수행이 가능한 쉘프롬프트로 떨어지게 됩니다.

우선 네트워크에 연결되어진 장치명을 확인하고 nmtui (Network Manager TUI) 명령을 이용하여 네트워크 설정을 진행합니다.

$ nmcli d

DEVICE  TYPE        STATE                                                    CONNECTION

eno2        ethernet    connecting (getting IP configuration)     Wired connection 2

eno1        ethernet    unavailable                                             --

lo             loopback   unmanaged                                            --

$ nmtui

* IPv4 설정에 아래 내용만 입력하면 됩니다. (IP 와 Subnet 같이 입력, 내부 DNS)

  DNS 는 내부 DNS 만 입력해주세요.

- Addresses : 115.68.142.100/27

- Gateway : 115.68.142.97

- DNS servers : 115.68.142.99

셋팅 후 자동으로 네트워크가 구성되는데, 간혹 네트워크 연결이 늦는 경우가 있어

sudo 를 붙여 root 권한으로 데몬을 재시작 해줍니다.

$ sudo systemctl restart NetworkManager

ignition 파일의 해시값을 변수에 저장하고 이를 이용하여 OS 설치를 진행합니다.

OS 설치 명령줄 앞에 sudo 를 붙여 root 권한으로 설치 해야 합니다.

$ hash=`curl http://115.68.142.99:8080/bootstrap.hash`

$ sudo coreos-installer install --copy-network --ignition-url http://115.68.142.99:8080/bootstrap.ign /dev/sda --ignition-hash sha512-${hash}

* 사용한 옵션

- 현재 네트워크 정보 복사 (/etc/NetworkManager/system-connections/ 디렉토리 아래 네트워크 설정 파일)

- 노드 유형의 ignition 파일

- 설치할 HDD 장치명

- 노드 유형의 ignition 파일 sha512 다이제스트 (해시값)

OS 가 설치 되면, 리부팅을 한 번 해줍니다.

정상 부팅이 될 경우 ignition 파일이 적용되면서 로그인 화면 상단에 아래와 같은 메세지가 출력됩니다.

Red Hat Enterprise Linux CoreOS 412.86.202212081411-0 (Optpa) 4.12

Ignition: ran on 2023/01/26 05:32:21 UTC (this boot)

Ignition: user-provided config was applied

SSH host key: SHA256:SOwMQInuqATecciNzA1NcTfAQRJvsn18EbXD9FX0Ycw (ECDSA)

SSH host key: SHA256:XvmtyNr1IWD4P+WNUhd6yIuu2b+7mEBEy+6k1swRIvu (ED25519)

SSH host key: SHA256:5ut4yCLOm0zuEmiBz9bfw75FSS8WjRt3EhyvthuV93A (RSA)

localhost login:

* 로그인 방법

OCP 서버에서 ssh 접근을 하면 패스워드 없이 로그인이 가능합니다.

# ssh core@115.68.142.100

접속후 서버 시간을 한국 표준시로 맞춰줍니다.

$ sudo ln -sf /usr/share/zoneinfo/Asia/Seoul /etc/localtime

* root 로그인 허용

core 계정이 아닌 root 계정으로 로그인하고 싶을 경우 아래와 같은 절차를 따릅니다.

# ssh core@115.68.142.100

[core@bootstrap ~]$ sudo su -

[root@bootstrap ~]# passwd    // 새 패스워드 두번 입력

[root@bootstrap ~]# vi /etc/ssh/sshd_config    // ssh 설정파일에서 아래 3가지 옵션 확인 및 수정

PermitRootLogin yes

PasswordAuthentication yes
ChallengeResponseAuthentication no

[root@bootstrap ~]# systemctl restart sshd    // ssh 데몬 재시작

이제 OCP 서버에서 다른 노드로 root 접속이 가능해 졌습니다.

* bootstrap 서버 네트워크 문제

bootstrap 서버의 네트워크가 연결 되지 않거나 연결중 끊어지는 경우 네트워크 상태를 확인해봐야 합니다.

연결 문제가 언제 발생할지 모르므로 단절 반복 주기인 5분 동안 (icmp_seq 300회 정도) 외부망 연결을 지켜 봅니다.

여기에서 테스트 할때는 원인은 찾지 못했지만 5분 단절, 5분 연결이 반복 되었기 때문입니다.

$ ping 8.8.8.8

끊어진다면 bootstrap 서버에서 NetworkManager 데몬을 몇차례 다시 재시작 해보고 5분 정도 추가 모니터링을 합니다.

끊김이 없다면 bootstrap 서버 설치를 완료한 것이므로 Kubernetes API 연결이 잘 되는지 아래 명령으로 확인해봅니다.

(OCP 서버에서)

# ./openshift-install --dir installation_directory wait-for bootstrap-complete --log-level=info
INFO Waiting up to 20m0s (until 9:17AM) for the Kubernetes API at https://api.az1.sysdocu.kr:6443... 
INFO API v1.25.4+77bec7a up                       
INFO Waiting up to 30m0s (until 9:36AM) for bootstrapping to complete...

지금까지의 설정이 올바로 되었다면 파란색 두줄이 출력됩니다. Kubernetes API 연결 확인이 잘 된 것입니다.

(최대 20분까지 대기하지만 이 경우 성공 가능성 낮음)

에러 출력시 --------------------

INFO Waiting up to 20m0s (until 4:03PM) for the Kubernetes API at https://api.az1.sysdocu.kr:6443... 
ERROR Attempted to gather ClusterOperator status after wait failure: listing ClusterOperator objects: Get "https://api.az1.sysdocu.kr:6443/apis/config.openshift.io/v1/clusteroperators": EOF 
INFO Use the following commands to gather logs from the cluster 
INFO openshift-install gather bootstrap --help    
ERROR Bootstrap failed to complete: Get "https://api.az1.sysdocu.kr:6443/version": EOF 
ERROR Failed waiting for Kubernetes API. This error usually happens when there is a problem on the bootstrap host that prevents creating a temporary control plane. 

이 경우 bootstrap 서버에서 도메인 질의가 잘 되는지 확인합니다.

구입해서 사용하는 도메인일 경우 외부 DNS 로 인해 도메인 연결이 안되는 경우가 있습니다.

(bootstrap 서버에서)

$ ping api.az1.sysdocu.kr

만약 연결이 안되는 것이 맞다면 내부 DNS 에 설정한 zone 파일 내용을 외부 DNS 에도 설정해주면 됩니다.

그리고 서버내 네임서버 설정도 확인이 필요합니다. 아래처럼 내부 DNS 만 있으면 됩니다.

$ cat /etc/resolv.conf

search az1.sysdocu.kr
nameserver 115.68.142.99

------------------------------------

이어서 master 노드를 설치합니다.

6. master 서버 설치

master 서버도 설치 방법은 bootstrap 서버와 같습니다.

설치에 사용되는 파일만 신경써서 작업해 줍니다.

- master 서버 : master.ign 파일 사용

설치 후 부팅이 완료되면 한국 표준시로 맞춰줍니다.

$ sudo ln -sf /usr/share/zoneinfo/Asia/Seoul /etc/localtime

그리고 master 서버들의 etcd 데몬 가동이 확인되고 네트워크 연결 (5분 이상) 이상없음이 확인되면

OCP 서버에서 아까와 같은 모니터링 명령으로 현재 상황을 확인해 봅니다. (최대 30분)

# ./openshift-install --dir installation_directory wait-for bootstrap-complete --log-level=info
INFO Waiting up to 20m0s (until 2:09PM) for the Kubernetes API at https://api.az1.sysdocu.kr:6443... 
INFO API v1.25.4+77bec7a up                       
INFO Waiting up to 30m0s (until 2:19PM) for bootstrapping to complete... 

INFO It is now safe to remove the bootstrap resources 
INFO Time elapsed: 15m7s 

master 3대 모두 설치하여 클러스터 구성이 완료되면 위와 같이 파란색으로 표시한 메세지가 출력됩니다.

이 시점에서 haproxy 내에 bootstrap 정보를 제거하고 bootstrap 서버를 종료 합니다. (더 이상 사용 안함)

- 로드밸런서에서 bootstrap 서버 정보 삭제

   > haproxy.conf 에서 bootstrap 관련 라인 2줄 주석 처리, 데몬 재시작

      # sed -i '/bootstrap/s/^/#/' /etc/haproxy/haproxy.cfg

      # systemctl restart haproxy
- bootstrap 서버 제거 (서버 종료)

OCP 로그인시 자동으로 쿠버네티스 관리자 계정을 설정하게 조치하고 현재 세션에도 적용합니다.

(OCP 서버에서)

# echo "export KUBECONFIG=/root/installation_directory/auth/kubeconfig" >> ~/.bash_profile

# export KUBECONFIG=/root/installation_directory/auth/kubeconfig

Openshift CLI 로 현재 사용자를 확인합니다.

# oc whoami
system:admin

연결된 노드를 확인합니다.
# oc get nodes
NAME                       STATUS   ROLES                  AGE   VERSION
master01.az1.sysdocu.kr   Ready    control-plane,master   50m   v1.25.4+77bec7a
master02.az1.sysdocu.kr   Ready    control-plane,master   37m   v1.25.4+77bec7a
master03.az1.sysdocu.kr   Ready    control-plane,master   21m   v1.25.4+77bec7a

7. worker 서버 설치

worker 서버도 설치 방법은 bootstrap 서버와 같습니다.

설치에 사용되는 파일만 신경써서 작업해 줍니다.

- worker 서버 : worker.ign 파일 사용

설치 후 부팅이 완료되면 한국 표준시로 맞춰줍니다.

$ sudo ln -sf /usr/share/zoneinfo/Asia/Seoul /etc/localtime

worker 서버는 master 서버와 달리 부팅 후 자동으로 bootstrap 서버와 연결되지 않기때문에 수동으로 연결을 해주어야 합니다.

worker 노드가 부팅 되면 보류중인 CSR (Certificate Signing Requests) 의 이름 (맨 앞 NAME 값) 을 확인합니다.

(OCP 서버에서)

# oc get csr |grep Pending |grep node-bootstrapper
csr-c4zbq                                        9m10s   kubernetes.io/kube-apiserver-client-kubelet   system:serviceaccount:openshift-machine-config-operator:node-bootstrapper         <none>              Pending
csr-j29kg                                        13m     kubernetes.io/kube-apiserver-client-kubelet   system:serviceaccount:openshift-machine-config-operator:node-bootstrapper         <none>              Pending

이름을 이용하여 보류중인 CSR 을 승인합니다.

# oc adm certificate approve csr-c4zbq

certificatesigningrequest.certificates.k8s.io/csr-c4zbq approved
# oc adm certificate approve csr-j29kg

certificatesigningrequest.certificates.k8s.io/csr-j29kg approved

참고로 보류 중인 모든 CSR 을 승인하려면 다음 명령을 수행합니다.

# oc get csr -o go-template='{{range .items}}{{if not .status}}{{.metadata.name}}{{"\n"}}{{end}}{{end}}' | xargs --no-run-if-empty oc adm certificate approve

전체 승인에서 처리되지 않은 요청은 개별 승인을 진행해야 합니다.

CSR 값이 많을 경우 승인한 CSR 에 대해서 삭제하는것을 고려해볼 수 있을텐데, 만약 Approved 또는 Issued 상태의 CSR을 삭제하면 해당 CSR로 발급된 인증서는 여전히 유효하지만 해당 CSR에 대한 기록은 클러스터에서 삭제됩니다. 이는 나중에 인증서를 관리하거나 디버깅할 때 문제가 될 수 있습니다. 따라서 일반적으로 Approved 또는 Issued 상태의 CSR을 삭제하기 전에 해당 CSR을 사용하여 발급된 인증서를 확인하고 이후에 CSR을 삭제하는 것이 좋습니다.

- 한개의 CSR 을 삭제

# oc delete csr <CSR 이름>

- 모든 CSR 을 삭제

# oc delete csr --all

연결된 전체 노드를 출력합니다.

worker 노드가 NotReady 상태라 하더라도 시간이 조금 지나면 Ready 상태로 변경됩니다.

# oc get nodes
NAME                       STATUS   ROLES                  AGE    VERSION
master01.az1.sysdocu.kr   Ready    control-plane,master   131m   v1.25.4+77bec7a
master02.az1.sysdocu.kr   Ready    control-plane,master   118m   v1.25.4+77bec7a
master03.az1.sysdocu.kr   Ready    control-plane,master   102m   v1.25.4+77bec7a
worker01.az1.sysdocu.kr   Ready    worker                 39m    v1.25.4+77bec7a
worker02.az1.sysdocu.kr   Ready    worker                 33m    v1.25.4+77bec7a

아래와 같은 명령을 수행하여 클러스터 구성 요소가 모두 연결되었는지 확인합니다.

(AVAILABLE : True, PROGRESSING : False, DEGRADED : False)

시간이 걸려 값이 정상적으로 돌아오는 경우가 있으므로 조금 기다려 봅니다.

(PROGRESSING 항목이 True 인 경우 프로세스가 동작중이라는 뜻)

# oc get clusteroperators 또는

# oc get co

NAME                                       VERSION   AVAILABLE   PROGRESSING   DEGRADED   SINCE   MESSAGE
authentication                             4.12.0    True        False         False      29m     
baremetal                                  4.12.0    True        False         False      123m    
cloud-controller-manager                   4.12.0    True        False         False      130m    
cloud-credential                           4.12.0    True        False         False      3h38m   
cluster-autoscaler                         4.12.0    True        False         False      122m    
config-operator                            4.12.0    True        False         False      129m    
console                                    4.12.0    True        False         False      35m     
control-plane-machine-set                  4.12.0    True        False         False      123m    
csi-snapshot-controller                    4.12.0    True        False         False      129m    
dns                                        4.12.0    True        False         False      93m     
etcd                                       4.12.0    True        False         False      114m    
image-registry                             4.12.0    True        False         False      93m     
ingress                                    4.12.0    True        False         False      37m     
insights                                   4.12.0    True        False         False      99m     
kube-apiserver                             4.12.0    True        False         False      103m    
kube-controller-manager                    4.12.0    True        False         False      113m    
kube-scheduler                             4.12.0    True        False         False      105m    
kube-storage-version-migrator              4.12.0    True        False         False      93m     
machine-api                                4.12.0    True        False         False      123m    
machine-approver                           4.12.0    True        False         False      122m    
machine-config                             4.12.0    True        False         False      103m    
marketplace                                4.12.0    True        False         False      123m    
monitoring                                 4.12.0    True        False         False      24m     
network                                    4.12.0    True        False         False      129m    
node-tuning                                4.12.0    True        False         False      93m     
openshift-apiserver                        4.12.0    True        False         False      93m     
openshift-controller-manager               4.12.0    True        False         False      93m     
openshift-samples                          4.12.0    True        False         False      88m     
operator-lifecycle-manager                 4.12.0    True        False         False      124m    
operator-lifecycle-manager-catalog         4.12.0    True        False         False      129m    
operator-lifecycle-manager-packageserver   4.12.0    True        False         False      93m     
service-ca                                 4.12.0    True        False         False      129m    
storage                                    4.12.0    True        False         False      129m  

* 참고

insights 항목에 오류가 발생될 수 있으나, 이것은 운영중 버그나 오류 데이터를 redhat 에 보내 개선하기 위한 용도로 사용되는 항목으로써 클러스터 서비스에 영향 주는 부분은 아니니 무시하셔도 됩니다.

다만, 이 경우 모든 항목이 완료된 것이 아니기 때문에 아래 명령 결과는 출력되지 않습니다.

또는 다음 명령으로 모든 클러스터 구성이 완료되었는지 확인 할 수 있습니다.

모든 구성이 완료 되면 관리 콘솔 URL 과 접속 계정이 출력 됩니다. 이 정보는 다른 명령으로도 확인이 가능합니다.

# ./openshift-install --dir installation_directory/ wait-for install-complete
INFO Waiting up to 40m0s (until 4:28PM) for the cluster at https://api.az1.sysdocu.kr:6443 to initialize... 
INFO Checking to see if there is a route at openshift-console/console... 
INFO Install complete!                            
INFO To access the cluster as the system:admin user when using 'oc', run 'export KUBECONFIG=/root/installation_directory/auth/kubeconfig' 
INFO Access the OpenShift web-console here: https://console-openshift-console.apps.az1.sysdocu.kr 
INFO Login to the console with user: "kubeadmin", and password: "2DBdU-YmKbC-Cn5xF-tVvdF" 
INFO Time elapsed: 0s                             

웹콘솔 URL 주소는 아래 명령으로도 확인이 되고

# oc whoami --show-console
https://console-openshift-console.apps.az1.sysdocu.kr

비밀번호는 아래 파일에서 찾을 수도 있습니다.

# cat installation_directory/auth/kubeadmin-password

2DBdU-YmKbC-Cn5xF-tVvdF

웹콘솔 계정명은 kubeadmin 입니다.

이제 브라우저를 통해 웹 콘솔 접근이 가능합니다.

실제 존재하지 않는 도메인을 테스트로 설정하였을 경우, 접근하려는 작업 PC 에서 아래와 같이

OpenShift web-console 에 접근하기 위해 사용하는 도메인 두개와 서버 IP 를 hosts 에 추가하면 됩니다.

# vi /etc/hosts

* 참고

오퍼레이터 설정이 초기화 되지 않은 경우에는 아래와 같이 출력될 수 있으니 조금 더 기다려 보도록 합니다.

INFO Waiting up to 40m0s (until 4:55PM) for the cluster at https://api.az1.sysdocu.kr:6443 to initialize...

이제 설치에 사용되는 ignition 파일을 모두 배포하고 클러스터 구성을 마쳤으므로 nginx 는 중지해도 됩니다.

# systemctl stop nginx