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

레지스트리 도메인 인증서를 Let's encrypt 에서 발급받고 로그인 시도 하였을때 아래와 같은 에러가 출력되었습니다.

이는 Let's encrypt 발행자가 시스템에서 인증되지 않은 경우에 발생한 문제입니다.

# podman login -u admin -p 12345678 default-route-openshift-image-registry.apps.az1.sysdocu.kr:5000

Error: error authenticating creds for "default-route-openshift-image-registry.apps.az1.sysdocu.kr:5000": error pinging docker registry default-route-openshift-image-registry.apps.az1.sysdocu.kr:5000: Get https://default-route-openshift-image-registry.apps.az1.sysdocu.kr:5000/v2/: x509: certificate signed by unknown authority

이 경우 아래와 같이 인증 과정을 거치면 로그인이 가능해 집니다.

인증서를 다운로드 (추출) 합니다.

# openssl s_client -showcerts -connect default-route-openshift-image-registry.apps.az1.sysdocu.kr:5000 < /dev/null 2> /dev/null | openssl x509 -outform PEM > myregistry.crt

Podman 이 인증서를 참조할 수 있도록 인증서를 복사합니다.

# mkdir -p /etc/docker/certs.d/default-route-openshift-image-registry.apps.az1.sysdocu.kr:5000/

# cp -arp myregistry.crt /etc/docker/certs.d/default-route-openshift-image-registry.apps.az1.sysdocu.kr:5000/ca.crt

로그인을 시도 합니다.

# podman login -u admin -p 12345678 default-route-openshift-image-registry.apps.az1.sysdocu.kr:5000
Login Succeeded!

다음과 같이 삭제하였다면 다시 복원이 가능합니다.

[ 삭제 ]

# oc patch configs.imageregistry.operator.openshift.io cluster -p '{"spec":{"managementState":"Removed"}}' --type='merge'
config.imageregistry.operator.openshift.io/cluster patched

Terminating 상태이므로 시간이 지나 삭제 됩니다.

# oc get pods -n openshift-image-registry
NAME                                              READY   STATUS        RESTARTS        AGE
cluster-image-registry-operator-77bbb4466-c4nwt   1/1     Running       2 (3h22m ago)   4h8m
image-registry-5f94b4bb5b-r89vg                   1/1     Terminating   0               19m
node-ca-2lkrw                                     1/1     Running       0               104m
node-ca-nxlsk                                     1/1     Running       0               3h27m
node-ca-pcbjq                                     1/1     Running       0               3h27m
node-ca-sxm58                                     1/1     Running       0               104m
node-ca-zdx88                                     1/1     Running       0               3h27m

[ 복원 ]

지워진 상태를 확인합니다.

# oc get configs.imageregistry.operator.openshift.io cluster -o jsonpath='{.spec.managementState}'
Removed

상태를 변경합니다.

# oc patch configs.imageregistry.operator.openshift.io cluster -p '{"spec":{"managementState":"Managed"}}' --type='merge'
config.imageregistry.operator.openshift.io/cluster patched

상태를 재확인합니다.

# oc get configs.imageregistry.operator.openshift.io cluster -o jsonpath='{.spec.managementState}'
Managed

상태 변경 명령 직후 Pod 를 확인하면 image-registry 가 Terminating 으로 보이는데, 시간이 조금 더 지나면 Running 상태로 돌아옵니다.

image-registry 가 되살아난 것이 확인되었습니다.

# oc get pod -n openshift-image-registry -l docker-registry=default

NAME                                              READY   STATUS    RESTARTS        AGE
image-registry-6dfb9c8f99-xbzbd                   0/1     Running   0               5s

단, PVC 구성은 변경되지 않았으므로, PVC 구성 변경이 필요한 경우 PVC 및 Image Registry 삭제를 하고 아래 매뉴얼을 참고하여 재구성 합니다.

https://sysdocu.tistory.com/1776