[ 참조 문서 ]

- 설치 : https://docs.openshift.com/container-platform/4.12/networking/metallb/metallb-operator-install.html

- 아이피 추가 : https://docs.openshift.com/container-platform/4.12/networking/metallb/metallb-configure-address-pools.html

AWS, MS Azure 등의 인프라에서 구성하는것이 아닌 BareMetal 형태의 단독 시스템들로 구성을 할 경우 LoadBalancer 제공을 위해 아래와 같이 추가 설정을 진행 할 수 있습니다.

클러스터 관리자는 MetalLB Operator 를 추가하여 클러스터 내의 MetalLB 인스턴스의 라이프사이클을 관리할 수 있습니다.

그러나 MetalLB 와 IP failover 는 호환되지 않습니다.

클러스터에서 IP failover 를 구성한 경우, Operator를 설치하기 전에 IP failover를 제거하는 단계를 수행해야 합니다. (제거 과정은 생략합니다)

1. MetalLB 설정

다음 명령을 실행하여 MetalLB Operator 네임스페이스를 만듭니다.

# oc create ns metallb-system
namespace/metallb-system created

OperatorGroup yaml 파일을 작성합니다.

# vi og.yaml

작성한 yaml 파일을 적용합니다.

# oc apply -f og.yaml
operatorgroup.operators.coreos.com/metallb-operator created

Operator 그룹이 네임스페이스에 설치되어 있는지 확인합니다.

# oc get operatorgroup -n metallb-system
NAME               AGE
metallb-operator   8s

사용자 지정 리소스 (CR) 를 사용하여 YAML 파일을 저장합니다.

# vi metallb-sub.yaml

적용하여 Subscription 을 생성합니다.

# oc apply -f metallb-sub.yaml
subscription.operators.coreos.com/metallb-operator-sub created

네임스페이스 라벨을 붙입니다.

# oc label ns metallb-system "openshift.io/cluster-monitoring=true"
namespace/metallb-system labeled

설치 계획이 네임스페이스에 있는지 확인합니다.

# oc get installplan -n metallb-system
NAME            CSV                                    APPROVAL    APPROVED
install-56ph2   metallb-operator.4.12.0-202303231115   Automatic   true

아래 명령으로 상태를 확인하면 시간이 지나 Installing 에서 Succeeded 로 변경되는 것이 확인됩니다.

# oc get clusterserviceversion -n metallb-system
NAME                                   DISPLAY            VERSION               REPLACES   PHASE
metallb-operator.4.12.0-202303231115   MetalLB Operator   4.12.0-202303231115              Succeeded

2. 클러스터에서 MetalLB 시작하기

MetalLB 생성을 위한 yaml 파일을 작성합니다.

# vi MetalLB.yaml

yaml 파일을 적용하여 MetalLB 를 생성합니다.

# oc apply -f MetalLB.yaml
metallb.metallb.io/metallb created

컨트롤러 생성이 확인되었습니다.

# oc get deployment -n metallb-system controller
NAME         READY   UP-TO-DATE   AVAILABLE   AGE
controller   1/1     1            1           45s

시간이 지나면서 speaker 준비 개수가 하나씩 오르는 것이 확인됩니다.

# oc get daemonset -n metallb-system speaker
NAME      DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR            AGE
speaker   5         5         5       5            5           kubernetes.io/os=linux   2m17s

3. Metal 을 위한 배포 사양

PriorityClass yaml 파일을 작성합니다.

여기에서는 high-priority 클래스를 사용합니다.

# vi PriorityClass.yaml

작성한 yaml 파일을 적용합니다.
# oc apply -f PriorityClass.yaml 
priorityclass.scheduling.k8s.io/high-priority created

MetalLB yaml 파일을 작성합니다.

priorityClassName 에 위에서 적용한 metadata: name: 값을 입력합니다.

# vi MetalLBPodConfig.yaml

작성한 yaml 파일을 적용합니다.

# oc apply -f MetalLBPodConfig.yaml
metallb.metallb.io/metallb configured

네임스페이스의 Pod 에 할당한 우선 순위 클래스를 표시합니다.

# oc get pods -n project412 -o custom-columns=NAME:.metadata.name,PRIORITY:.spec.priorityClassName
NAME                    PRIORITY
mysql-bd544cdb8-qvm59   <none>

4. MetalLB 배치에서의 Pod CPU 제한 설정

필요에 따라 다음에 포드 CPU 제한을 할당할 수 있습니다.

controller 와 speaker Pod 를 설정함으로써 MetalLB yaml 파일에서 CPU 제한을 정의 합니다.

controller 또는 speaker Pod 는 노드의 리소스를 관리하는 데 도움이 됩니다.

이를 통해 노드의 모든 Pod 가 워크로드 관리와 클러스터 하우스키핑에 필요한 컴퓨팅 리소스를 확보할 수 있습니다.

MetalLB yaml 파일을 작성합니다.

# vi CPULimits.yaml

작성한 yaml 파일을 적용합니다.
# oc apply -f CPULimits.yaml 
metallb.metallb.io/metallb configured

Pod 이름을 확인하고 적용 상태를 자세하게 확인합니다.

# oc describe pod mysql-bd544cdb8-qvm59

(출력 생략)

5. 컨테이너 런타임 클래스 설정

선택적으로 컨테이너 런타임 클래스를 다음에 할당할 수 있습니다.

Windows 작업 부하에 대해서는 pod에 Windows 런타임 클래스를 할당할 수 있습니다.

이렇게 하면 pod 내의 모든 컨테이너가 이 런타임 클래스를 사용하게 됩니다.

RuntimeClass yaml 파일을 작성합니다.

# vi myRuntimeClass.yaml

작성한 yaml 파일을 적용합니다.
# oc apply -f myRuntimeClass.yaml 
runtimeclass.node.k8s.io/myclass created

MetalLB yaml 파일을 작성합니다.

# vi MetalLBRuntime.yaml

작성한 yaml 파일을 적용합니다.
# oc apply -f MetalLBRuntime.yaml
metallb.metallb.io/metallb configured

Pod 의 컨테이너 런타임을 표시하려면 다음 명령을 실행합니다.

# oc get pod -o custom-columns=NAME:metadata.name,STATUS:.status.phase,RUNTIME_CLASS:.spec.runtimeClassName

6. MetalLB Address Pool 추가

클러스터 관리자는 IP 주소 풀 (address pool) 을 추가하거나 수정, 삭제 할 수 있습니다.

MetalLB Operator 는 주소 풀 커스텀 리소스를 사용하여 MetalLB가 서비스에 할당할 수 있는 IP 주소를 설정합니다.

예제에서는 metallb-system 네임스페이스를 사용한다고 가정합니다.

IPAddressPool yaml 파일을 작성합니다.

# vi ipaddresspool.yaml

작성한 yaml 파일은 MetalLB 의 IPAddressPool 리소스를 정의하는 예시입니다. 이 리소스는 MetalLB 에서 사용할 IP 주소 풀을 구성합니다. 각 IP 주소 풀은 addresses 필드에 지정된 IP 범위로 정의됩니다.

- metadata: labels: zone: 리소스에 할당할 라벨을 지정합니다.
- spec: addresses: IP 주소 풀을 지정하는 섹션입니다. 각 IP 주소 풀은 - 로 구분된 범위로 지정됩니다.

                              이 예시에서는 115.68.142.121 부터 115.68.142.126 까지의 IP 범위를 지정했습니다. (IP 6개를 로드발란서 IP 로 사용)

                              떨어져있는 IP 를 추가하고 싶을 경우 한 행을 더 추가하면 됩니다.
이렇게 정의된 IPAddressPool 리소스를 적용하면 MetalLB 에서 해당 IP 주소 풀을 사용하여 로드발란서 IP 주소를 할당할 수 있습니다.

작성한 yaml 파일을 적용합니다.

# oc apply -f ipaddresspool.yaml

ipaddresspool.metallb.io/doc-example created

추가된 Address Pool 을 확인합니다.

# oc describe -n metallb-system IPAddressPool doc-example

(출력 생략)

아래는 다른 적용 예시 입니다.

IPv4 와 CIDR 범위를 이용한 설정입니다.

MetalLB는 풀에서 IP 주소를 자동으로 할당하지 않도록 autoAssign 필드를 false 로 설정 할 수 있습니다.

서비스를 추가할 때, 풀에서 특정 IP 주소를 요청하거나 어노테이션에서 풀 이름을 지정하여 풀에서 사용 가능한 임의의 IP 주소를 요청할 수 있습니다.

Docker 이미지를 다운로드 받거나 아직 받지 않은 상태에서도 이미지명만 알고 있으면 쉘 접속이 가능합니다.

방법은 아래와 같습니다.

현재 다운로드 받은 이미지 확인

# docker images

docker.io/php                                                                  latest              3d07cacc45bb        8 days ago          485 MB

이미지 쉘 접속하기

예) docker run --rm -it <Docker 이미지명> sh

# docker run --rm -it docker.io/php sh

httpd 2.4 기준으로 테스트 하였으나 오랫동안 해온 방식이라 거의 대부분의 버전에서 적용될 것 같습니다.

httpd 2.4 의 경우 Thread 처리 방식이 세종류 (Prefork, Worker, Event) 있습니다.

소스파일을 수정하지 않으면 아무리 설정해도 높은값으로 구동이 안되고 특정 메세지 (AH00513: WARNING) 가 출력되는것을 볼 수 있습니다.

소스파일을 수정하고 컴파일 하면 메인보드 오버클럭 동작과 비슷하게 아파치 기본 한계치를 높여 좀 더 많은 사용자가 동시접속이 가능하게 할 수 있습니다. 다만 하드웨어 (CPU, RAM 등) 의 성능이 받춰줘야 많은 동시접속자를 수용해도 처리가 가능하므로, 저사양의 서버를 운영중인 분에게는 추천드리지 않습니다.

아파치를 설치하는 단계에서 조정해줘야 하는 부분이 있으므로 이미 설치하여 사용중인분은 페이지 맨 아랫부분 옵션 적용 먼저 해보고 Syntax 에러가 없으면 그대로 사용하셔도 됩니다.

에러가 발생하면 아파치를 재설치 해주어야 하는데, 아파치를 설치하기전 소스파일을 수정해야 합니다.

# wget https://archive.apache.org/dist/httpd/httpd-2.4.56.tar.gz

# tar xvzf httpd-2.4.56.tar.gz

# cd httpd-2.4.56

동시접속 최대값을 수정합니다.

여기에서는 2048명의 동시접속을 허용하도록 하겠습니다.

참고로 수정해야 할 곳 앞에 # 이 있는데 이는 주석이 아니므로 삭제하지 않도록 합니다.

# vi server/mpm/prefork/prefork.c

# vi server/mpm/worker/worker.c

# vi server/mpm/event/event.c

httpd 설치는 생략합니다. 설치는 다른 포스팅을 참고해 주시고 ( https://sysdocu.tistory.com/397 )

./configure 명령 실행할때 아래 처럼 원하는 MPM 을 옵션으로 추가하면 됩니다.

--with-mpm=worker

아래는 httpd 설치 후 확인 방법입니다.

사용하는 MPM 종류

# /usr/local/apache/bin/apachectl -V |grep MPM
Server MPM:     worker

모듈 로드 상태

# /usr/local/apache/bin/httpd -t -D DUMP_MODULES |grep mpm
mpm_worker_module (static)

예제에서는 worker 를 사용하는것이 확인되었습니다.

# vi /usr/local/apache/conf/httpd.conf

아래 값을 적절히 수정합니다. MaxRequestWorkers 부분이 최대 동시접속자 수 입니다.

# vi /usr/local/apache/conf/extra/httpd-mpm.conf

* 옵션 설명

- StartServers : Apache 서버 가동시 생성되는 프로세스 수

- ServerLimit : Apache 서버가 생성할 수 있는 최대 프로세스 수

                       값의 공식은 MaxRequestWorkers / ThreadsPerChild = ServerLimit 이지만 이와 같거나 큰 값으로 설정하는 것이 좋습니다.

                       (여기에서는 2048 / 64 = 32 이지만 두배 큰수로 64 를 입력)

                       이 값은 시스템의 하드웨어 성능과 용량에 따라 조정되어야 합니다.

- MinSpareThreads : 최소 유지 스레드 수

                                  프로세스는 항상 최소 설정값 (여기에서는 100) 만큼의 유휴 스레드를 유지하려고 노력합니다.

                                  이는 웹 서버의 성능을 유지하기 위해 필요한 최소한의 스레드 수입니다.

- MaxSpareThreads : 최대 유지 스레드 수

                                   웹 서버가 생성한 스레드 중에 유지할 수 있는 최대 스레드의 수 (여기에서는 500) 를 결정합니다.

                                   이 값 이상의 스레드가 생성되면, 일부 스레드는 자동으로 종료되어 시스템 자원을 절약합니다.

- ThreadsPerChild : 프로세스 당 스레드 수

                                ThreadsPerChild가 64로 설정되어 있고, MaxSpareThreads가 500으로 설정되어 있다면,

                                하나의 프로세스 내에서 최대 64개의 스레드를 생성할 수 있으며, 이 중 최대 500개의 스레드는 유지됩니다.

- MaxRequestWorkers : 최대 동시 접속자 수

                                      서버가 처리할 수 있는 최대 요청 수를 결정하는 설정으로, 이 값을 증가시키면 동시에 처리할 수 있는 요청 수가 증가합니다.

- MaxConnectionsPerChild : Apache 서버에서 한 프로세스가 처리할 수 있는 최대 연결 수 (0 : 무제한)

httpd 설정 문법에 이상여부를 체크해보고 데몬을 재시작하여 적용합니다.

# /usr/local/apache/bin/apachectl -t

Syntax OK

# /usr/local/apache/bin/apachectl restart

[ 에러 ]

아래와 같은 yaml 파일을 작성하여 Pod 를 생성하려고 하였습니다.

# vi app.yaml

Pod 생성 명령시 아래와 같은 에러가 출력되었습니다.

# oc apply -f app.yaml

Warning: would violate PodSecurity "restricted:v1.24": allowPrivilegeEscalation != false (container "app33" must set securityContext.allowPrivilegeEscalation=false), unrestricted capabilities (container "app33" must set securityContext.capabilities.drop=["ALL"]), runAsNonRoot != true (pod or container "app33" must set securityContext.runAsNonRoot=true), seccompProfile (pod or container "app33" must set securityContext.seccompProfile.type to "RuntimeDefault" or "Localhost")

[ 해결 ]

에러 파일에 대한 조치로 아래와 같이 다시 작성하여 Pod 를 정상적으로 생성하였습니다.

* 설명
allowPrivilegeEscalation: 컨테이너가 프로세스의 권한 상승을 허용하지 않도록 설정합니다.
capabilities: 컨테이너가 사용할 수 있는 권한(capabilities)을 제한합니다. 여기에서는 모든 권한을 제한하도록 drop=["ALL"]로 설정합니다.
runAsNonRoot: 컨테이너가 root 권한으로 실행되지 않도록 설정합니다.
seccompProfile: 컨테이너가 사용하는 seccomp 프로필을 설정합니다. 여기에서는 type을 RuntimeDefault로 설정합니다.

# oc apply -f app.yaml

pod/app4 created

리눅스 쉘에서 파일명앞에 - 가 붙어 있어 삭제하기 어려운 경우가 있었습니다.

명령 뒤에 따라오는 옵션으로 판단하고 삭제가 되지 않았던 것인데

알고보면 삭제 방법은 간단합니다.

-로 시작되는 파일 확인

# ls

-test.txt

삭제 실패 명령어들

# rm -test.txt
rm: 부적절한 옵션 -- 't'
Try 'rm ./-test.txt' to remove the file `-test.txt'.
Try 'rm --help' for more information.

# rm \-test.txt
rm: 부적절한 옵션 -- 't'
Try 'rm ./-test.txt' to remove the file `-test.txt'.
Try 'rm --help' for more information.

# rm '-test.txt'
rm: 부적절한 옵션 -- 't'
Try 'rm ./-test.txt' to remove the file `-test.txt'.
Try 'rm --help' for more information.

# rm "-test.txt"
rm: 부적절한 옵션 -- 't'
Try 'rm ./-test.txt' to remove the file `-test.txt'.
Try 'rm --help' for more information.

삭제 성공 명령어

디렉토리를 포함하여 삭제할 파일명을 지정하면 됩니다.

# rm ./-test.txt
rm: remove 일반 빈 파일 `./-test.txt'? y

PDNS 로그를 수집하고자 할때 아래와 같이 설정하면 됩니다.

아래는 PDNS 4.2 에서 테스트 하였습니다.

1. 설정

데몬 구동 파일을 백업하고 수정합니다.

# cp -arp /usr/lib/systemd/system/pdns.service /usr/lib/systemd/system/pdns.service.bak

# vi /usr/lib/systemd/system/pdns.service

PDNS 설정을 추가합니다.

# vi /etc/pdns/pdns.conf

rsyslog 설정을 추가합니다.

서비스 데몬 설정 상 debug level 로 해놓아서 아래 로깅 설정이 중요합니다.

vi /etc/rsyslog.conf

로그 디렉토리를 생성합니다.

# mkdir /var/log/pdns

2. 적용

# systemctl daemon-reload
# systemctl restart pdns
# systemctl restart rsyslog

3. 확인

# cd /var/log/pdns
# ll
합계 145288
drwxr-xr-x  2 root root      4096  3월 29 09:41 .
drwxr-xr-x. 9 root root      4096  3월 29 16:37 ..
-rw-------  1 root root 147126477  3월 30 07:46 pdns.debug
-rw-------  1 root root       998  3월 29 09:30 pdns.err
-rw-------  1 root root      1331  3월 29 09:27 pdns.info
-rw-------  1 root root   1619633  3월 29 09:39 pdns.warn

pdns.debug 파일에 도메인 질의했던 Remote IP 와 Record Type, Domain name 등 정보가 간략히 출력되는데

참고로 packetcache 값은 아래 의미를 가지고 있습니다.

- HIT : 이전에 처리된 DNS 쿼리 결과가 캐시에 저장되어 있고, 현재 처리중인 쿼리와 동일한 결과를 반환할 수 있습니다.

           이 경우, pdns 서버는 저장된 정보를 즉시 반환하므로, 쿼리 처리 시간이 매우 빠릅니다.
- MISS : 이전에 처리된 DNS 쿼리 결과가 캐시에 없으며, 실제 DNS 서버에서 새로운 쿼리를 처리해야 합니다.

              이 경우, pdns 서버는 실제 DNS 서버로부터 결과를 가져와서 반환해야 하므로, 쿼리 처리 시간이 증가할 수 있습니다.

* 참고

도메인 질의가 많은 서버의 경우 로그 파일 사이즈도 방대하게 늘어나기 때문에

아래 URL 참고하여 logrotate 로 로그 파일을 관리 하면 됩니다.

(내용중 PDNS 설정 부분 참조)

https://sysdocu.tistory.com/63

쉘스크립트 파일을 아래 내용으로 작성하고 실행하면 됩니다.

# vi monitor_and_run.sh

* 결과

마지막으로 추가된 행 내용 : 이건 test 입니다.

마지막으로 추가된 행 내용 : lasttest

마지막으로 추가된 행 내용 : test

마지막으로 추가된 행 내용 : test 끝

네임서버 성능을 확인하기 위해 다량의 도메인 질의를 해 볼 수 있습니다.

아래 설치 및 사용 방법을 확인해 주세요.

CentOS 7 기준으로 작성되었습니다.

1. 설치

# cd /usr/local/src

# wget https://www.dns-oarc.net/files/dnsperf/dnsperf-2.3.2.tar.gz
# tar xfvz dnsperf-2.3.2.tar.gz
# cd dnsperf-2.3.2/
# ./configure
# make
# make install

2. 사용

도메인을 질의하기 위해 테스트 또는 유명 도메인과 A 레코드를 질의하기 위해 A 값을 파일로 만듭니다.

# echo "sysdocu.kr A" > list.txt

아래와 같은 형식으로 테스트가 가능합니다.

# dnsperf -s 8.8.8.8 -d list.txt -T 2 -Q 1000 -l 1

* 옵션 설명

- s : 네임서버 IP 또는 도메인 (생략시 127.0.0.1)

- d : 도메인 또는 도메인이 들어있는 파일명

- T : 사용할 스레드 수

- Q : 쿼리량

- l : 질의 지속 시간 (초)

1초에 1000개 쿼리 수행 결과는 아래와 같이 나옵니다.

DNS Performance Testing Tool
Version 2.3.2

[Status] Command line: dnsperf -s 8.8.8.8 -d list.txt -T 2 -Q 1000 -l 1
[Status] Sending queries (to 8.8.8.8)
[Status] Started at: Tue Mar 28 16:16:00 2023
[Status] Stopping after 1.000000 seconds
[Status] Testing complete (time limit)

Statistics:

  Queries sent:         1000
  Queries completed:    1000 (100.00%)
  Queries lost:         0 (0.00%)

  Response codes:       NOERROR 1000 (100.00%)
  Average packet size:  request 28, response 112
  Run time (s):         1.000256
  Queries per second:   999.744066

  Average Latency (s):  0.000880 (min 0.000374, max 0.019629)
  Latency StdDev (s):   0.001580

oc get pods 로 출력되는 Pod 에 Running 상태가 아닌 값이 있을경우 원인을 확인하기 위해 보통 아래 두가지 방법을 사용합니다.

에러 확인

# oc get pods
NAME                         READY   STATUS         RESTARTS   AGE
my-app11-6c7c9dcd7c-z6cww    0/1     ErrImagePull   0          12s

1. oc logs

# oc logs my-app11-6c7c9dcd7c-z6cww
Error from server (BadRequest): container "my-app11" in pod "my-app11-6c7c9dcd7c-z6cww" is waiting to start: trying and failing to pull image

이미지를 가져올 수 없다는 로그가 확인 되었는데, 이미지를 왜 가져올 수 없는지는 아래처럼 자세히 살펴볼 수 있습니다.

2. oc describe

# oc describe pod my-app11-6c7c9dcd7c-z6cww
Name:             my-app11-6c7c9dcd7c-z6cww
Namespace:        deploy
Priority:         0
Service Account:  default
Node:             worker01.az1.sysdocu.kr/115.68.142.104
Start Time:       Fri, 24 Mar 2023 10:30:18 +0900
Labels:           deployment=my-app11
                  pod-template-hash=6c7c9dcd7c
Annotations:      k8s.v1.cni.cncf.io/network-status:
                    [{
                        "name": "openshift-sdn",
                        "interface": "eth0",
                        "ips": [
                            "10.128.2.44"
                        ],
                        "default": true,
                        "dns": {}
                    }]
                  k8s.v1.cni.cncf.io/networks-status:
                    [{
                        "name": "openshift-sdn",
                        "interface": "eth0",
                        "ips": [
                            "10.128.2.44"
                        ],
                        "default": true,
                        "dns": {}
                    }]
                  openshift.io/generated-by: OpenShiftNewApp
                  openshift.io/scc: anyuid
Status:           Pending
IP:               10.128.2.44
IPs:
  IP:           10.128.2.44
Controlled By:  ReplicaSet/my-app11-6c7c9dcd7c
Containers:
  my-app11:
    Container ID:   
    Image:          my-app11:latest
    Image ID:       
    Port:           80/TCP
    Host Port:      0/TCP
    State:          Waiting
      Reason:       ImagePullBackOff
    Ready:          False
    Restart Count:  0
    Environment:    <none>
    Mounts:
      /var/run/secrets/kubernetes.io/serviceaccount from kube-api-access-q4sh6 (ro)
Conditions:
  Type              Status
  Initialized       True 
  Ready             False 
  ContainersReady   False 
  PodScheduled      True 
Volumes:
  kube-api-access-q4sh6:
    Type:                    Projected (a volume that contains injected data from multiple sources)
    TokenExpirationSeconds:  3607
    ConfigMapName:           kube-root-ca.crt
    ConfigMapOptional:       <nil>
    DownwardAPI:             true
    ConfigMapName:           openshift-service-ca.crt
    ConfigMapOptional:       <nil>
QoS Class:                   BestEffort
Node-Selectors:              <none>
Tolerations:                 node.kubernetes.io/not-ready:NoExecute op=Exists for 300s
                             node.kubernetes.io/unreachable:NoExecute op=Exists for 300s
Events:
  Type     Reason          Age                From               Message
  ----     ------          ----               ----               -------
  Normal   Scheduled       16m                default-scheduler  Successfully assigned deploy/my-app11-6c7c9dcd7c-z6cww to worker01.az1.sysdocu.kr
  Normal   AddedInterface  16m                multus             Add eth0 [10.128.2.44/23] from openshift-sdn
  Normal   Pulling         14m (x4 over 16m)  kubelet            Pulling image "my-app11:latest"
  Warning  Failed          14m (x4 over 16m)  kubelet            Failed to pull image "my-app11:latest": rpc error: code = Unknown desc = reading manifest latest in docker.io/library/my-app11: errors:
denied: requested access to the resource is denied
unauthorized: authentication required
  Warning  Failed   14m (x4 over 16m)   kubelet  Error: ErrImagePull
  Warning  Failed   14m (x6 over 16m)   kubelet  Error: ImagePullBackOff
  Normal   BackOff  69s (x63 over 16m)  kubelet  Back-off pulling image "my-app11:latest"

접근 권한 문제로 확인되었습니다.

이경우 secret 을 이용해 사용자 계정 생성 및 권한 부여 등의 작업을 진행하면 됩니다.

이렇게 서비스에 문제가 생기게 될 경우 로그를 확인하는 두개 명령을 사용해 보시기 바랍니다.

GitLab 은 웹 기반의 Git 저장소 관리 및 지속적인 통합, 배포를 제공하는 소프트웨어 개발 플랫폼입니다.

GitLab-CE (Community Edition) 컨테이너 서비스를 배포하기 위해 아래와 같은 절차를 진행합니다.

gitlab-ce 이미지를 다운로드 받습니다.
# docker pull gitlab/gitlab-ce
* docker.io 주소를 빼도 다운로드 됩니다.

다운로드 받은 이미지를 이용하여 어플리케이션을 배포합니다.
# oc new-app docker.io/gitlab/gitlab-ce

Pod 상태 확인을 하면 Running 과 Error 를 반복하다가 최종 CrashLoopBackOff 상태로 종료됩니다.
# oc get pod
NAME                         READY   STATUS             RESTARTS      AGE
gitlab-ce-549cbd9f47-5xcw5   0/1     CrashLoopBackOff   2 (13s ago)   84s

아래와 같은 로그가 확인됩니다.
# oc logs gitlab-ce-549cbd9f47-5xcw5
Thank you for using GitLab Docker Image!
Current version: gitlab-ce=15.10.0-ce.0

Configure GitLab for your system by editing /etc/gitlab/gitlab.rb file
And restart this container to reload settings.
To do it use docker exec:

  docker exec -it gitlab editor /etc/gitlab/gitlab.rb
  docker restart gitlab

For a comprehensive list of configuration options please see the Omnibus GitLab readme
https://gitlab.com/gitlab-org/omnibus-gitlab/blob/master/README.md

If this container fails to start due to permission problems try to fix it by executing:

  docker exec -it gitlab update-permissions
  docker restart gitlab

Cleaning stale PIDs & sockets
cat: /var/opt/gitlab/gitlab-rails/VERSION: No such file or directory
Preparing services...
ln: failed to create symbolic link '/opt/gitlab/service/sshd': Permission denied

현재 프로젝트 (project412) 서비스어카운트에 anyuid 권한이 없기 대문입니다.
아래와 같이 권한을 부여 합니다. (add-scc-to-user)
# oc adm policy add-scc-to-user anyuid system:serviceaccount:project412:default
clusterrole.rbac.authorization.k8s.io/system:openshift:scc:anyuid added: "default"
- project412 : 현재 프로젝트명 (oc project 로 확인 가능)

오류 발생되었던 deployment 와 service 를 삭제하고 Pod 를 재생성 합니다.
# oc delete deployment gitlab-ce
# oc delete service gitlab-ce

# oc new-app docker.io/gitlab/gitlab-ce

상태를 확인해보면 상태값이 올바르게 Running 으로 표시되었습니다.
# oc get pods
NAME                         READY   STATUS    RESTARTS   AGE
gitlab-ce-7cfcc46b75-ltgx4   1/1     Running   0          62s

사용하는 서비스 포트를 확인합니다.
# oc get svc
NAME             TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)                 AGE
gitlab-ce        ClusterIP   172.30.199.183   <none>        22/TCP,80/TCP,443/TCP   2m4s

같은 포트 번호로 라우팅을 생성하여 외부에서 접근 가능하도록 합니다.
# oc expose service gitlab-ce --port 80
route.route.openshift.io/gitlab-ce exposed
# oc get route
NAME             HOST/PORT                                   PATH   SERVICES         PORT    TERMINATION   WILDCARD
gitlab-ce        gitlab-ce-deploy.apps.az1.sysdocu.kr               gitlab-ce        80                    None

출력된 호스트명과 포트를 이용하여 브라우저로 접속하면 서비스가 정상 확인됩니다.
(GitLab Community Edition 로그인 화면)
http://gitlab-ce-deploy.apps.az1.sysdocu.kr

Pod 생성을 위해 주었던 서비스어카운트의 CSS 권한을 제거합니다. (remove-scc-from-user)
# oc adm policy remove-scc-from-user anyuid system:serviceaccount:project412:default
clusterrole.rbac.authorization.k8s.io/system:openshift:scc:anyuid removed: "default"
- project412 : 현재 프로젝트명 (oc project 로 확인 가능)

[상황]
Pod 에 접속시도 할때 해당 메세지가 출력되거나,

# oc rsh mysql-bd544cdb8-m7p6n
Error from server: error dialing backend: remote error: tls: internal error

Pod 의 로그를 보려해도 같은 메세지가 출력됩니다.
# oc logs mysql-bd544cdb8-m7p6n
Error from server: Get "https://115.68.142.105:10250/containerLogs/deploy/mysql-bd544cdb8-m7p6n/mysql": remote error: tls: internal error


[해결]
보류중인 CSR (Certificate Signing Requests) 을 확인하고 Pending 되어 있는것을 확인합니다.
# oc get csr

출력된 이름을 이용하여 보류중인 CSR 을 승인합니다.
# oc adm certificate approve csr-c4zbq
certificatesigningrequest.certificates.k8s.io/csr-c4zbq 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 을 삭제하려면

# oc delete csr <CSR 이름>

모든 CSR 을 한번에 지우려면

# oc delete csr --all