Apigee Hybrid가 생성 또는 출시 상태에서 멈추는 문제 해결

ApigeeApigee Hybrid 문서입니다.
이 주제에 해당하는 Apigee Edge 문서가 없습니다.

이 문서에서는 Apigee Hybrid 구성요소가 creating 또는 releasing 상태에서 중단된 경우 이 구성요소를 재설정하는 방법을 설명합니다.

다음 명령어를 실행하여 Apigee Hybrid 설치 기본 구성요소를 나열합니다.

kubectl get crd | grep apigee
apigeeorganization (apigeeorganizations.apigee.cloud.google.com)
apigeeenvironment (apigeeenvironments.apigee.cloud.google.com)
apigeedatastore (apigeedatastores.apigee.cloud.google.com)
apigeetelemetries (apigeetelemetries.apigee.cloud.google.com)
apigeeredis (apigeeredis.apigee.cloud.google.com)

다음 명령어를 실행하여 현재 상태를 표시합니다.

kubectl get apigeedatastore -n NAMESPACE

완전히 작동하면 각 구성요소가 running 상태가 됩니다. 예를 들면 다음과 같습니다.

NAME      STATE     AGE
default   running   5d6h

성공적으로 설치되지 않으면 구성요소가 creating(또는 releasing) 상태에서 중단될 수 있습니다. 예를 들면 다음과 같습니다.

NAME      STATE     AGE
default   creating   5d6h

문제 파악

문제 원인을 식별하려면 먼저 각 구성요소를 설명합니다. 구성요소는 다음과 같이 구성됩니다.

ApigeeOrganization 커스텀 리소스는 다음 계층 구조로 나타낼 수 있습니다.

ApigeeOrganization/HASHED_VALUE
├─ApigeeDeployment/apigee-connect-agent-HASHED_VALUE
│ ├─HorizontalPodAutoscaler/apigee-connect-agent-HASHED_VALUE-VER-xxxx
│ ├─PodDisruptionBudget/apigee-connect-agent-HASHED_VALUE
│ ├─ReplicaSet/apigee-connect-agent-HASHED_VALUE-VER-xxxx
│ │ └─Pod/apigee-connect-agent-HASHED_VALUE-VER-xxxx
├─ApigeeDeployment/apigee-mart-HASHED_VALUE
│ ├─HorizontalPodAutoscaler/apigee-mart-HASHED_VALUE-VER-xxxx
│ ├─PodDisruptionBudget/apigee-mart-HASHED_VALUE
│ ├─ReplicaSet/apigee-mart-HASHED_VALUE-VER-xxxx
│ │ └─Pod/apigee-mart-HASHED_VALUE-VER-xxxx
├─ApigeeDeployment/apigee-watcher-HASHED_VALUE
│ ├─HorizontalPodAutoscaler/apigee-watcher-HASHED_VALUE-VER-xxxx
│ ├─PodDisruptionBudget/apigee-watcher-HASHED_VALUE
│ ├─ReplicaSet/apigee-watcher-HASHED_VALUE-VER-xxxx
│ │ └─Pod/apigee-watcher-HASHED_VALUE-VER-xxxx

ApigeeEnvironment 커스텀 리소스는 다음 계층 구조로 나타낼 수 있습니다.

ApigeeEnvironment/HASHED_VALUE
├─ApigeeDeployment/apigee-runtime-HASHED_VALUE
│ ├─HorizontalPodAutoscaler/apigee-runtime-HASHED_VALUE-VER-xxxx
│ ├─PodDisruptionBudget/apigee-runtime-HASHED_VALUE
│ ├─ReplicaSet/apigee-runtime-HASHED_VALUE-VER-xxxx
│ │ └─Pod/apigee-runtime-HASHED_VALUE-VER-xxxx
├─ApigeeDeployment/apigee-synchronizer-HASHED_VALUE
│ ├─HorizontalPodAutoscaler/apigee-synchronizer-HASHED_VALUE-VER-xxxx
│ ├─PodDisruptionBudget/apigee-synchronizer-HASHED_VALUE
│ ├─ReplicaSet/apigee-synchronizer-HASHED_VALUE-VER-xxxx
│ │ └─Pod/apigee-synchronizer-HASHED_VALUE-VER-xxxx
├─ApigeeDeployment/apigee-udca-HASHED_VALUE
│ ├─HorizontalPodAutoscaler/apigee-udca-HASHED_VALUE-VER-xxxx
│ ├─PodDisruptionBudget/apigee-udca-HASHED_VALUE
│ ├─ReplicaSet/apigee-udca-HASHED_VALUE-VER-xxxx
│ │ └─Pod/apigee-udca-HASHED_VALUE-VER-xxxx

루트 구성요소를 설명하여 문제를 판별합니다. 예를 들면 다음과 같습니다.

kubectl describe apigeeorganization -n NAMESPACE COMPONENT_NAME

구성요소의 Staterunning인지 확인합니다.

      Replicas:
        Available:  1
        Ready:      1
        Total:      1
        Updated:    1
      State:        running
  State:            running
Events:             <none>

이 수준에서 로깅되는 이벤트가 없으면 apigeedeployments 다음에 ReplicaSet를 사용하여 프로세스를 반복합니다. 예를 들면 다음과 같습니다.

kubectl get apigeedeployment -n NAMESPACE AD_NAME>

apigeedeploymentsReplicaSet에 오류가 표시되지 않으면 준비되지 않은 포드에 초점을 맞춥니다.

kubectl get pods -n NAMESPACE
NAME                                                              READY   STATUS
apigee-cassandra-default-0                                        1/1     Running
apigee-connect-agent-apigee-b56a362-150rc2-42gax-dbrrn            1/1     Running
apigee-logger-apigee-telemetry-s48kb                              1/1     Running
apigee-mart-apigee-b56a362-150rc2-bcizm-7jv6w                     0/2     Running
apigee-runtime-apigee-test-0d59273-150rc2-a5mov-dfb29             0/1     Running

이 예시에서는 martruntime이 준비되지 않았습니다. 포드 로그를 검사하여 오류를 확인합니다.

kubectl logs -n NAMESPACE POD_NAME

구성요소 삭제

이러한 구성요소에서 실수가 발생하면 구성요소를 삭제하고 해당 구성요소에 apigeectl을 적용하기만 하면 됩니다. 예를 들어 환경을 삭제하려면 다음을 실행하세요.

kubectl delete -n apigee apigeeenv HASHED_ENV_NAME

필요한 수정을 수행한 후 환경을 만들어야 합니다.

apigeectl apply -f overrides.yaml –env=$ENV

컨트롤러 검사

포드에 명확한 오류 메시지가 없지만 구성요소가 running 상태로 전환되지 않으면 apigee-controller에서 오류 메시지를 검사합니다. apigee-controllerapigee-system 네임스페이스에서 실행됩니다.

kubectl logs -n apigee-system $(k get pods -n apigee-system | sed -n '2p' | awk '{print $1}') | grep -i error

그러면 사용자가 컨트롤러에서 요청을 처리할 수 없는 이유를 확인할 수 있습니다(create/delete/update 등).

Apigee Datastore

Apache Cassandra는 StatefulSet로 구현됩니다. 각 Cassandra 인스턴스에는 다음이 포함됩니다.

ApigeeDatastore/default
├─Certificate/apigee-cassandra-default
│ └─CertificateRequest/apigee-cassandra-default-wnd7s
├─Secret/config-cassandra-default
├─Service/apigee-cassandra-default
│ ├─EndpointSlice/apigee-cassandra-default-7m9kx
│ └─EndpointSlice/apigee-cassandra-default-gzqpr
└─StatefulSet/apigee-cassandra-default
  ├─ControllerRevision/apigee-cassandra-default-6976b77bd
  ├─ControllerRevision/apigee-cassandra-default-7fc76588cb
  └─Pod/apigee-cassandra-default-0
  

이 예시에서는 하나의 포드를 보여줍니다. 그러나 일반적인 프로덕션 설치에는 3개 이상의 포드가 포함됩니다.

Cassandra 상태가 creating 또는 releasing이면 상태를 재설정해야 합니다. Cassandra 비밀번호 변경과 같은 특정 문제와 네트워킹과 관련되지 않는 문제에서 구성요소 삭제를 요구할 수도 있습니다. 이러한 경우 인스턴스(즉, kubectl delete apigeedatastore -n NAMESPACE default)를 삭제할 수 없습니다. --force 또는 --grace-period=0를 사용해도 도움이 되지 않습니다.

reset의 목적은 구성요소(apigeedatastore) 상태를 creating 또는 releasing에서 다시 running으로 변경하는 것입니다. 일반적으로 이러한 방식으로 상태를 변경해도 기본 문제는 해결되지 않습니다. 대부분의 경우 재설정한 후에 구성요소를 삭제해야 합니다.

  1. 삭제 시도(성공하지 않을 가능성 높음):

    kubectl delete -n NAMESPACE apigeedatastore default
    

    일반적으로 이 명령은 완료되지 않습니다. Ctrl+C 키를 사용하여 호출을 종료하세요.

  2. 상태를 재설정합니다.

    창 1:

    kubectl proxy
    

    창 2:

    curl -X PATCH -H "Accept: application/json" -H "Content-Type: application/json-patch+json" --data '[{"op": "replace", "path": "/status/nestedState", "value": ""},{"op": "replace", "path": "/status/state", "value": "running"}]' 'http://127.0.0.1:8001/apis/apigee.cloud.google.com/v1alpha1/namespaces/apigee/apigeedatastores/default/status'
    

    파이널라이저 삭제(창 2):

    kubectl edit -n NAMESPACE apigeedatastore default
    

    다음 두 줄을 찾아 삭제합니다.

    finalizers:
    - apigeedatastore.apigee.cloud.google.com
    

일반적인 오류 시나리오

런타임에서 프록시 구성을 사용할 수 없음

이 오류는 두 가지 방식 중 하나로 나타날 수 있습니다.

  • runtimeready 상태가 아닙니다.
  • runtime에 API의 최신 버전이 수신되지 않았습니다.
  1. synchronizer 포드로 시작합니다.

    synchronizer의 로그를 검사합니다. 일반적인 오류는 다음과 같습니다.

    • *.googleapi.com에 대한 네트워크 연결 없음
    • 잘못된 IAM 액세스(서비스 계정을 사용할 수 없거나 동기화 담당자 관리자 권한에서 제공하지 않음)
    • setSyncAuthorization API가 호출되지 않았음
  2. runtime 포드를 검사합니다.

    runtime 포드에서 로그를 검사하면 runtime에서 구성을 로드하지 않은 이유가 표시됩니다. 제어 영역은 대부분의 구성 실수가 데이터 영역으로 이동하지 않도록 합니다. 검증이 불가능하거나 올바르게 구현되지 않은 경우 runtime은 검증을 로드할 수 없습니다.

제어 영역에 '런타임 포드 없음'

  1. synchronizer 포드로 시작합니다.

    synchronizer의 로그를 검사합니다. 일반적인 오류는 다음과 같습니다.

    • *.googleapi.com에 대한 네트워크 연결 없음
    • 잘못된 IAM 액세스(서비스 계정을 사용할 수 없거나 동기화 담당자 관리자 권한에서 제공하지 않음)
    • setSyncAuthorization API가 호출되지 않았습니다. 구성이 데이터 영역에 도달하지 않았을 수도 있습니다.
  2. runtime 포드를 검사합니다.

    runtime 포드에서 로그를 검사하면 runtime이 구성을 로드하지 않은 이유를 확인할 수 있습니다.

  3. watcher 포드를 검사합니다.

    인그레스(라우팅)를 구성하고 프록시 및 인그레스 배포 상태를 제어 영역에 보고하는 watcher 구성요소입니다. 이 로그를 검사하여 watcher에서 상태를 보고하지 않는 이유를 확인합니다. 일반적인 이유는 overrides.yaml 파일의 이름과 환경 이름 또는 환경 그룹 이름의 제어 영역 간의 불일치입니다.

디버그 세션이 제어 영역에 표시되지 않음

  1. synchronizer 포드로 시작합니다.

    synchronizer의 로그를 검사합니다. 일반적인 오류는 다음과 같습니다.

    • *.googleapi.com에 대한 네트워크 연결 없음
    • 잘못된 IAM 액세스(서비스 계정을 사용할 수 없거나 동기화 담당자 관리자 권한에서 제공하지 않음)
    • setSyncAuthorization API가 호출되지 않았습니다.
  2. runtime 포드를 검사합니다.
    runtime 포드에서 로그를 검사하면 runtime이 디버그 로그를 UDCA에 전송하지 않는 이유를 알 수 있습니다.
  3. UDCA 포드를 검사합니다.
    UDCA에서 로그를 검사하면 UDCA가 제어 영역으로 디버그 세션 정보를 전송하지 않는 이유가 표시됩니다.

대용량 캐시 응답을 반환하는 Cassandra

다음 경고 메시지는 Cassandra가 더 큰 페이로드로 읽기 또는 쓰기 요청을 수신하고 있고, 이 경고 기준이 응답 페이로드 크기를 나타내기 위해 더 낮은 값으로 설정되어 있으므로 무시해도 안전하다는 것을 나타냅니다.

Batch for [cache_ahg_gap_prod_hybrid.cache_map_keys_descriptor, cache_ahg_gap_prod_hybrid.cache_map_entry] is of size 79.465KiB, exceeding specified threshold of 50.000KiB by 29.465KiB