Kubernetes 연산자 문제 해결하기

배포된 리소스의 상태 가져오기

Kubernetes Operator와 함께 배포된 리소스의 상태를 찾으려면 다음 명령 중 하나를 호출합니다.

• Ops Manager 리소스 배포의 경우:

  kubectl get <resource-name> -n <metadata.namespace> -o yaml

  • status.applicationDatabase.phase 필드에는 Application Database 리소스 배포 상태가 표시됩니다.

  • status.backup.phase는 백업 디먼 리소스 배포 상태를 표시합니다.

  • status.opsManager.phase 필드는 Ops Manager 리소스 배포 상태를 표시합니다.

  참고

  Cloud Manager 또는 Ops Manager 컨트롤러는 다음 설정에 정의된 데이터베이스 리소스를 감시합니다.

  • spec.backup.opLogStores

  • spec.backup.s3Stores

  • spec.backup.blockStores

• MongoDB 리소스 배포용:

  kubectl get mdb <resource-name> -n <metadata.namespace> -o yaml

  status.phase 필드는 MongoDB 리소스 배포 상태를 표시합니다.

다음 키-값 쌍은 리소스 배포 상태를 설명합니다.

kubectl get mdb my-replica-set -n developer -o yaml

status:
    lastTransition: "2019-01-30T10:51:40Z"
    link: http://ec2-3-84-128-187.compute-1.amazonaws.com:9080/v2/5c503a8a1b90141cbdc60a77
    members: 1
    phase: Running
    version: 4.2.2-ent

status:
  lastTransition: 2019-02-01T13:00:24Z
  link: http://ec2-34-204-36-217.compute-1.amazonaws.com:9080/v2/5c51c040d6853d1f50a51678
  members: 1
  message: 'Failed to create/update replica set in Ops Manager: Status: 400 (Bad Request),
    Detail: Something went wrong validating your Automation Config. Sorry!'
  phase: Failed
  version: 4.2.2-ent

로그 검토

문제를 디버그하고 클러스터 활동을 모니터링하는 데 도움이 되도록 충분한 양의 로그를 보관하고 검토합니다. 권장 로깅 아키텍처를 사용하여 Pod가 삭제된 후에도 Pod 로그를 유지합니다.

{ "logType": "<log-type>", "contents": "<log line from a log file>" }

kubectl logs -f deployment/mongodb-enterprise-operator -n <metadata.namespace>

kubectl get pods -n <metadata.namespace>

kubectl logs <podName> -n <metadata.namespace>

kubectl logs myrs-0 -n <metadata.namespace>

kubectl logs -c mongodb-enterprise-database replica-set-0 | jq -r 'select(.logType == "mongodb-audit") | .contents'

{{{ "atype":"startup","ts":{"$date":"2023-08-30T20:43:54.649+00:00"},"uuid":{"$binary":"oDcPEY69R1yiUtpMupaXOQ==","$type":"04"},"local":{"isSystemUser":true},"remote":{"isSystemUser":true},"users":[],"roles":[],"param":{"options":{"auditLog":{"destination":"file","format":"JSON","path":"/var/log/mongodb-mms-automation/mongodb-audit.log"},"config":"/data/automation-mongod.conf","net":{"bindIp":"0.0.0.0","port":27017,"tls":{"mode":"disabled"}},"processManagement":{"fork":true},"replication":{"replSetName":"replica-set"},"storage":{"dbPath":"/data","engine":"wiredTiger"},"systemLog":{"destination":"file","path":"/var/log/mongodb-mms-automation/mongodb.log"}}},"result":0}
{"atype":"startup","ts":{"$date":"2023-08-30T20:44:05.466+00:00"},"uuid":{"$binary":"OUbUWC1DQM6k/Ih4hKZq4g==","$type":"04"},"local":{"isSystemUser":true},"remote":{"isSystemUser":true},"users":[],"roles":[],"param":{"options":{"auditLog":{"destination":"file","format":"JSON","path":"/var/log/mongodb-mms-automation/mongodb-audit.log"},"config":"/data/automation-mongod.conf","net":{"bindIp":"0.0.0.0","port":27017,"tls":{"mode":"disabled"}},"processManagement":{"fork":true},"replication":{"replSetName":"replica-set"},"storage":{"dbPath":"/data","engine":"wiredTiger"},"systemLog":{"destination":"file","path":"/var/log/mongodb-mms-automation/mongodb.log"}}},"result":0}}}

spec:
   additionalMongodConfig:
      auditLog:
         destination: file
            format: JSON
            path: /var/log/mongodb-mms-automation/mongodb-audit.log

유효성 검사 Webhook의 메시지 확인

Kubernetes Operator는 유효성 검사 웹후크를 사용하여 사용자가 잘못된 리소스 정의를 적용하는 것을 방지합니다. 웹후크는 유효하지 않은 요청을 거부합니다.

웹훅용 ClusterRole 및 ClusterRoleBinding은 설치 중에 적용하는 기본 구성 파일에 포함되어 있습니다. 역할 및 바인딩을 만들려면 클러스터 관리자 권한이 있어야 합니다.

잘못된 리소스 정의를 생성하면 웹후크는 오류를 설명하는 다음과 유사한 메시지를 셸에 반환합니다.

error when creating "my-ops-manager.yaml":
admission webhook "ompolicy.mongodb.com" denied the request:
shardPodSpec field is not configurable for application databases as
it is for sharded clusters and appdb replica sets

Kubernetes Operator는 각 리소스를 조정할 때 해당 리소스의 유효성도 검사합니다. Kubernetes Operator는 리소스를 생성하거나 업데이트하는 데 유효성 검사 웹 후크를 필요로 하지 않습니다.

유효성 검사 웹후크를 생략하거나, 기본 구성에서 웹후크의 역할과 바인딩을 제거하거나 구성을 실행할 권한이 충분하지 않은 경우 이는 심각한 오류가 아니므로 Kubernetes Operator가 경고를 표시합니다. Kubernetes Operator에 심각한 오류가 발생하면 리소스를 Failed로 표시합니다.

MongoDB 리소스 사양 모두 보기

제공된 네임스페이스에서 MongoDB 리소스 사양을 모두 보려면 다음을 수행합니다.

kubectl get mdb -n <metadata.namespace>

kubectl get mdb dublin -n <metadata.namespace> -o yaml

apiVersion: mongodb.com/v1
kind: MongoDB
metadata:
  annotations:
    kubectl.kubernetes.io/last-applied-configuration: |
      {"apiVersion":"mongodb.com/v1","kind":"MongoDB","metadata":{"annotations":{},"name":"dublin","namespace":"mongodb"},"spec":{"credentials":"credentials","persistent":false,"podSpec":{"memory":"1Gi"},"project":"my-om-config","type":"Standalone","version":"4.0.0-ent"}}
  clusterDomain: ""
  creationTimestamp: 2018-09-12T17:15:32Z
  generation: 1
  name: dublin
  namespace: mongodb
  resourceVersion: "337269"
  selfLink: /apis/mongodb.com/v1/namespaces/mongodb/mongodbstandalones/dublin
  uid: 7442095b-b6af-11e8-87df-0800271b001d
spec:
  credentials: my-credentials
  type: Standalone
  persistent: false
  project: my-om-config
  version: 4.2.2-ent

배포에 실패한 StatefulSet 복원하기

StatefulSet 파드가 배포 중에 오류가 발생하면 Pending 상태가 표시되며 중단될 수 있습니다.

Pending 오류를 해결하기 위해 구성을 변경하고 적용하더라도 Pods는 자동으로 종료되지 않습니다.

StatefulSet를 정상 상태로 되돌리려면 Pending 상태의 MongoDB 리소스에 구성 변경 사항을 적용한 다음 해당 pods를 삭제하세요.

kubectl get pods
my-replica-set-0     1/1 Running 2 2h
my-replica-set-1     1/1 Running 2 2h
my-replica-set-2     0/1 Pending 0 2h

kubectl describe pod my-replica-set-2
<describe output omitted>
Warning FailedScheduling 15s (x3691 over 3h) default-scheduler
0/3 nodes are available: 1 node(s) had taints that the pod
didn't tolerate, 2 Insufficient memory.

vi <my-replica-set>.yaml
kubectl apply -f <my-replica-set>.yaml
kubectl delete pod my-replica-set-2

ConfigMap을 교체하여 변경 사항 반영

kubectl apply 명령을 사용하여 이미 배포된 리소스 ConfigMap 파일을 수정하거나 재배포할 수 없는 경우에는 다음을 실행합니다.

kubectl replace -f <my-config-map>.yaml

이렇게 하면 ConfigMap 리소스 파일이 삭제되고 다시 만들어집니다.

이 명령은 즉각적인 재귀적 변경을 수행하거나 한 번 초기화하면 업데이트할 수 없는 리소스 파일을 업데이트해야 하는 경우에 유용합니다.

Kubernetes 구성 요소 제거

kubectl delete mdb <name> -n <metadata.namespace>

kubectl delete mdb --all -n <metadata.namespace>

Pod 삭제 후 새 Persistent Volume Claim 생성

실수로 MongoDB 복제본 세트 파드 및 해당 영구 볼륨 클레임을 삭제한 경우 Kubernetes Operator는 MongoDB 파드를 다시 예약하지 못하고 다음 오류 메시지를 발행합니다.

scheduler error: pvc not found to schedule the pod

이 오류를 복구하려면 이 복제본 세트 Pod에 해당하는 PVC 객체의 이름(예: data-<replicaset-pod-name>)을 사용하여 수동으로 새 PVC를 생성해야 합니다.

Ops Manager 기능 제어 비활성화

Kubernetes 연산자를 통해 Ops Manager 프로젝트를 관리하는 경우, Kubernetes 연산자는 프로젝트에 EXTERNALLY_MANAGED_LOCK 기능 제어 정책을 배치합니다. 이 정책은 Kubernetes 연산자 구성을 손상시킬 수 있는 Ops Manager 애플리케이션의 특정 기능을 비활성화합니다. 이러한 차단된 기능을 사용해야 하는 경우에는 기능 제어 API를 통해 정책을 제거하고, Ops Manager 애플리케이션에서 변경한 다음, API를 통해 원래 정책으로 복원할 수 있습니다.

1. Ops Manager 프로젝트에 대한 기능 제어 정책을 조회합니다.

   curl --user "{USERNAME}:{APIKEY}" --digest \
        --header "Accept: application/json" \
        --header "Content-Type: application/json" \
        --include \
        --request GET "https://{OPSMANAGER-HOST}:{PORT}/api/public/v1.0/groups/{PROJECT-ID}/controlledFeature?pretty=true"

   API가 반환하는 응답을 저장합니다. Ops Manager 애플리케이션에서 변경한 후에는 이러한 정책을 프로젝트에 다시 추가해야 합니다.

   중요

   다음 샘플 응답에서 강조 표시된 필드와 값에 주목합니다. 기능 제어 정책을 제거하고 추가할 때 이후 단계에서 이와 동일한 필드와 값을 보내야 합니다.

   externalManagementSystem.version 필드는 Kubernetes 연산자 버전에 해당합니다. 이 작업의 뒷부분에서 요청에 정확히 동일한 필드 값을 보내야 합니다.

   응답은 다음과 비슷해야 합니다.

   {
    "created": "2020-02-25T04:09:42Z",
    "externalManagementSystem": {
      "name": "mongodb-enterprise-operator",
      "systemId": null,
      "version": "1.4.2"
    },
    "policies": [
      {
        "disabledParams": [],
        "policy": "EXTERNALLY_MANAGED_LOCK"
      },
      {
        "disabledParams": [],
        "policy": "DISABLE_AUTHENTICATION_MECHANISMS"
      }
    ],
    "updated": "2020-02-25T04:10:12Z"
   }

2. policies 배열을 빈 목록으로 업데이트합니다.

   참고

   externalManagementSystem.version 필드와 같이 externalManagementSystem 객체에 제공하는 값은 1단계의 응답에서 받은 값과 일치해야 합니다.

   curl --user "{USERNAME}:{APIKEY}" --digest \
        --header "Accept: application/json" \
        --header "Content-Type: application/json" \
        --include \
        --request PUT "https://{OPSMANAGER-HOST}:{PORT}/api/public/v1.0/groups/{PROJECT-ID}/controlledFeature?pretty=true" \
        --data
          '{
            "externalManagementSystem": {
              "name": "mongodb-enterprise-operator",
              "systemId": null,
              "version": "1.4.2"
            },
            "policies": []
          }'

   이전에 차단되었던 기능을 이제 Ops Manager 애플리케이션에서 사용할 수 있습니다.

3. Ops Manager 애플리케이션에서 변경을 수행합니다.

4. policies 배열을 원래 기능 제어 정책으로 업데이트합니다.

   참고

   externalManagementSystem.version 필드와 같이 externalManagementSystem 객체에 제공하는 값은 1단계의 응답에서 받은 값과 일치해야 합니다.

   curl --user "{USERNAME}:{APIKEY}" --digest \
        --header "Accept: application/json" \
        --header "Content-Type: application/json" \
        --include \
        --request PUT "https://{OPSMANAGER-HOST}:{PORT}/api/public/v1.0/groups/{PROJECT-ID}/controlledFeature?pretty=true" \
        --data
          '{
            "externalManagementSystem": {
              "name": "mongodb-enterprise-operator",
              "systemId": null,
              "version": "1.4.2"
            },
            "policies": [
              {
                "disabledParams": [],
                "policy": "EXTERNALLY_MANAGED_LOCK"
              },
              {
                "disabledParams": [],
                "policy": "DISABLE_AUTHENTICATION_MECHANISMS"
              }
            ]
          }'

   이제 기능이 다시 차단되어 Ops Manager 애플리케이션을 통해 더 이상 변경할 수 없습니다. 하지만 Kubernetes Operator는 기능을 사용할 수 있는 동안 Ops Manager 애플리케이션에서 변경한 내용을 그대로 유지합니다.

실패한 컨테이너 디버그

Kubernetes가 루프에서 해당 컨테이너를 다시 시작하는 오류로 인해 컨테이너가 실패할 수 있습니다.

파일을 검사하거나 명령을 실행하기 위해 해당 컨테이너와 상호 작용해야 할 수도 있습니다. 이를 위해서는 컨테이너가 다시 시작되는 것을 방지해야 합니다.

1. 원하는 텍스트 편집기에서 복구해야 하는 MongoDB 리소스를 엽니다.

2. 이 리소스에 다음과 유사한 podSpec 컬렉션을 추가합니다.

   podSpec:
     podTemplate:
       spec:
         containers:
         - name: mongodb-enterprise-database
           command: ['sh', '-c', 'echo "Hello!" && sleep 3600' ]

   spec.podSpec.podTemplate.spec의 sleep 명령은 컨테이너에 사용자가 지정한 시간(초) 동안 대기하도록 지시합니다. 이 예제에서는 컨테이너가 1시간 동안 대기합니다.

3. 이 변경 사항을 리소스에 적용합니다.

   kubectl apply -f <resource>.yaml

4. 컨테이너 내부에서 셸을 호출합니다.

   kubectl exec -it <pod-name> bash

TLS 인증서에서 도메인 이름의 정확성 확인

TLS 인증서가 유효하지 않은 경우 MongoDB 복제본 세트 또는 샤드 클러스터가 READY 상태에 도달하지 못할 수 있습니다.

MongoDB 복제본 세트 또는 샤드 클러스터에 대해 TLS를 구성할 때 유효한 인증서를 지정하는지 확인합니다.

각 TLS 인증서에 대해 올바른 도메인 이름을 지정하지 않으면 Kubernetes 연산자 로그에 다음과 유사한 오류 메시지가 포함될 수 있으며, 여기서 foo.svc.local은 클러스터 멤버의 파드에 대해 잘못 지정된 도메인 이름입니다.

TLS attempt failed : x509: certificate is valid for foo.svc.local,
not mongo-0-0.mongo-0.mongodb.svc.cluster.local

각 인증서에는 유효한 도메인 이름이 포함되어야 합니다.

각 복제본 세트 또는 샤드 클러스터 멤버의 경우, 해당 멤버의 인증서에 대한 일반 이름(도메인 이름이라고도 함)은 이 클러스터 멤버가 배포된 파드의 FQDN과 일치해야 합니다.

각 인증서의 FQDN 이름에는 pod-name.service-name.namespace.svc.cluster.local 구문이 있습니다. 이 이름은 복제본 세트 또는 샤드 클러스터의 멤버를 호스팅하는 각 Pod마다 다릅니다.

예를 들어, rs-mongos-0-0이라는 이름으로 파드에 배포된 복제본 세트의 멤버의 경우, 기본 mongodb 네임스페이스에 생성된 mongo-0이라는 이름의 Kubernetes 연산자 서비스에서 FQDN은 다음과 같습니다.

rs-mongos-0-0.mongo-0.mongodb.svc.cluster.local

TLS 인증서를 올바르게 구성했는지 확인하려면 다음을 수행합니다.

1. 실행:

   kubectl logs -f <pod_name>

2. Kubernetes 연산자 로그 파일에서 TLS 관련 메시지를 확인합니다.

TLS 인증서 요구 사항에 대한 자세한 내용은 복제본 세트 배포의 TLS-Encrypted Connections 탭 또는 샤드 클러스터 배포의 사전 요구 사항을 참조하세요.

로컬 모드에서 실행할 때 MongoDB 버전 확인

Ops Manager가 로컬 모드에서 실행 중이고 존재하지 않는 버전의 MongoDB를 지정하거나 로컬 모드로 배포된 Ops Manager가 해당 MongoDB 아카이브를 다운로드하지 않은 유효한 버전의 MongoDB를 지정한 경우 MongoDB CustomResource가 Running 상태에 도달하지 못할 수 있습니다.

존재하지 않는 MongoDB 버전을 지정하거나 Ops Manager가 MongoDB 아카이브를 다운로드할 수 없는 유효한 MongoDB 버전을 지정하면, 파드가 READY 상태에 도달할 수 있더라도 Kubernetes 연산자 로그에 다음과 유사한 오류 메시지가 포함됩니다.

Failed to create/update (Ops Manager reconciliation phase):
Status: 400 (Bad Request), Detail:
Invalid config: MongoDB <version> is not available.

이는 MongoDB Agent가 /var/lib/mongodb-mms-automation 디렉토리에 해당 MongoDB 바이너리를 성공적으로 다운로드하지 못했음을 의미할 수 있습니다. MongoDB Agent가 지정된 MongoDB 버전에 대한 MongoDB 바이너리를 성공적으로 다운로드할 수 있는 경우 이 디렉토리에는 mongodb-linux-x86_64-4.4.0 등의 MongoDB 바이너리 폴더가 포함됩니다.

MongoDB 바이너리 폴더가 있는지 확인하려면 다음을 수행하세요.

1. 이 명령에 파드의 이름을 지정합니다.

   kubectl exec --stdin --tty $<pod_name> /bin/sh

2. /var/lib/mongodb-mms-automation 디렉토리에 MongoDB 바이너리 폴더가 있는지 확인합니다.

3. MongoDB 바이너리 폴더를 찾을 수 없는 경우, 배포된 각 Ops Manager 복제본 세트에 대한 Ops Manager 영구 볼륨에 MongoDB 아카이브를 복사하세요.

kubectl 또는 oc를 사용하여 업그레이드하지 못했습니다.

Kubernetes 연산자를 업그레이드할 때 다음과 같은 오류가 발생할 수 있습니다.

Forbidden: updates to statefulset spec for fields other than
'replicas', 'template', and 'updateStrategy' are forbidden

이 오류를 해결하려면 다음을 수행합니다.

1. 이전 Kubernetes 연산자 배포를 제거합니다.

   kubectl delete deployment/mongodb-enterprise-operator -n <metadata.namespace>

   참고

   Kubernetes 연산자 배포서버를 제거해도 MongoDB 리소스의 라이프사이클에는 영향을 주지 않습니다.

2. kubectl apply 명령을 반복하여 새 버전의 Kubernetes 연산자로 업그레이드합니다.

Helm Charts를 사용한 업그레이드 실패

Kubernetes 연산자를 업그레이드할 때 다음과 같은 오류가 발생할 수 있습니다.

Error: UPGRADE FAILED: cannot patch "mongodb-enterprise-operator"
with kind Deployment: Deployment.apps "mongodb-enterprise-operator"
is invalid: ... field is immutable

이 오류를 해결하려면 다음을 수행합니다.

1. 이전 Kubernetes 연산자 배포를 제거합니다.

   kubectl delete deployment/mongodb-enterprise-operator -n <metadata.namespace>

   참고

   Kubernetes 연산자 배포서버를 제거해도 MongoDB 리소스의 라이프사이클에는 영향을 주지 않습니다.

2. helm 명령을 반복하여 새 버전의 Kubernetes 연산자로 업그레이드합니다.

업그레이드 후 두 개의 연산자 인스턴스

Kubernetes Operator 버전 1.10 이하에서 버전 1.11 이상으로 업그레이드한 후, Kubernetes 클러스터에 두 개의 Kubernetes Operato 인스턴스가 배포될 수 있습니다.

get pods 명령을 사용하여 Kubernetes 연산자 파드를 확인합니다.

kubectl get pods

응답에 enterprise-operator 및 mongodb-enterprise-operator 파드가 모두 포함된 경우 클러스터에는 두 개의 Kubernetes 연산자 인스턴스가 있습니다.

NAME                                           READY   STATUS    RESTARTS   AGE
enterprise-operator-767884c9b4-ltkln           1/1     Running   0          122m
mongodb-enterprise-operator-6d69686679-9fzs7   1/1     Running   0          68m

enterprise-operator 배포를 안전하게 제거할 수 있습니다. 다음 명령을 실행하여 제거합니다.

kubectl delete deployment/enterprise-operator

손상된 자동화 구성으로 인한 리소스 복구

사용자 지정 리소스가 오랜 시간 동안 Pending 또는 Failed 상태로 유지되는 경우 Kubernetes 연산자는 자동화 구성을 Ops Manager로 푸시하여 MongoDB 리소스를 자동으로 복구합니다. 이렇게 하면 이전에 잘못된 자동화 구성을 푸시하여 StatefulSet가 Pending 상태로 멈춰 MongoDB Agent가 업데이트된 자동화 구성 변경 사항을 푸시할 수 없는 교착 상태를 방지할 수 있습니다.

자동 복구를 구성하려면 mongodb-enterprise.yaml 파일에서 다음 환경 변수를 정의합니다.

• 파드당 MongoDB 리소스에 대한 자동 복구를 활성화 또는 비활성화하려면 MDB_AUTOMATIC_RECOVERY_ENABLE을 사용합니다.

• Kubernetes Operator가 MongoDB 리소스를 자동으로 복구하기 전에 사용자 지정 리소스가 Pending 또는 Failed 상태로 유지될 수 있는 시간(초)으로 MDB_AUTOMATIC_RECOVERY_BACKOFF_TIME_S를 설정합니다.

1
spec:
2
  template:
3
     spec:
4
        serviceAccountName: mongodb-enterprise-operator
5
        containers:
6
          - name: mongodb-enterprise-operator
7
            image: <operatorVersionUrl>
8
            imagePullPolicy: <policyChoice>
9
            env:
10
             - name: MDB_AUTOMATIC_RECOVERY_ENABLE
11
               value: true
12
             - name: MDB_AUTOMATIC_RECOVERY_BACKOFF_TIME_S
13
               value: 1200

환경 변수를 정의하는 방법을 알아보려면 컨테이너의 환경 변수 정의를 참조하세요.