GKE에서 Cloud Endpoints 문제해결

OpenAPI | gRPC

이 문서에서는 Google Kubernetes Engine(GKE) 및 Kubernetes에서 Endpoints 배포 문제를 해결하는 방법에 대해 설명합니다.

`kubectl create -f gke.yaml`에 오류 발생

Failed in kubectl create -f gke.yaml 오류 메시지가 표시되면 다음 단계를 따릅니다.

gcloud를 승인합니다.

gcloud auth login
gcloud auth application-default login

클러스터를 만듭니다. 다음 gcloud 명령어를 사용하거나 Google Cloud 콘솔을 사용하여 클러스터를 만들 수 있습니다.
```
gcloud container clusters create CLUSTER_NAME
```
CLUSTER_NAME을 클러스터 이름으로 바꿉니다.
클러스터의 사용자 인증 정보를 가져와서 kubectl에 제공합니다.
```
gcloud container clusters get-credentials CLUSTER_NAME
```

Endpoints 측정항목 및 로그가 표시되지 않음

API에 요청을 전송할 수 있지만 Google Cloud 콘솔의 Endpoints > 서비스 페이지에 측정항목이나 로그가 표시되지 않으면 다음 단계를 수행합니다.

모든 필수 서비스가 사용 설정되어 있는지 확인합니다.
모든 필요한 권한이 부여되었는지 확인합니다.

Extensible Service Proxy에서 로그에 액세스

문제 진단을 위해 Extensible Service Proxy(ESP) 로그에 액세스해야 하는 경우 다음과 같이 kubectl을 사용하세요.

pod 이름을 가져옵니다.

kubectl get pod

NAME                       READY     STATUS    RESTARTS   AGE
esp-echo-174578890-x09gl   2/2       Running   2          21s

pod 이름은 esp-echo-174578890-x09gl이며 컨테이너 두 개(esp와 echo)가 있습니다.

pod의 로그를 보려면 kubectl logs를 사용합니다.
```
kubectl logs POD_NAME -c CONTAINER_NAME
```
여기에서 POD_NAME과 CONTAINER_NAME은 이전 단계의 kubectl get pod 명령어에서 반환된 값입니다. 예를 들면 다음과 같습니다.
```
  kubectl logs esp-echo-174578890-x09gl -c esp
```

서비스 이름 확인

Fetching service config failed 오류 메시지가 표시되면 배포 매니페스트 파일(deployment.yaml 파일)의 --service 필드에 지정한 서비스 이름이 gRPC API 구성 YAML 파일(api_config.yaml 파일)에 지정한 name 속성의 호스트 이름과 일치하는지 확인하세요.

deployment.yaml 파일에 이름이 잘못된 경우 다음을 수행합니다.

deployment.yaml 파일을 열고 ESP 컨테이너에 구성된 섹션으로 이동합니다. 예를 들면 다음과 같습니다.
```
containers:
- name: esp
  image: gcr.io/endpoints-release/endpoints-runtime:1
  args: [
    "--http_port=8081",
    "--backend=127.0.0.1:8080",
    "--service=SERVICE_NAME",
    "--rollout_strategy=managed"
  ]
  
```
api_config.yaml 파일의 name 속성에 지정된 호스트 이름과 일치하도록 SERVICE_NAME을 변경하고 deployment.yaml 파일을 저장합니다.
Kubernetes 서비스를 시작합니다.
```
  kubectl create -f deployment.yaml
```

api_config.yaml 파일에 이름이 잘못된 경우 다음을 수행합니다.

Endpoints에서 사용하도록 구성된 서비스 이름을 가져옵니다.
서비스를 삭제합니다.
```
gcloud endpoints services delete SERVICE_NAME
```
SERVICE_NAME을 이전 단계의 이름으로 바꿉니다. 서비스가 Google Cloud에서 삭제되는 데 30일이 걸립니다. 이 기간 동안에는 이 서비스 이름을 다시 사용할 수 없습니다.
api_config.yaml 파일을 열고 name 속성의 호스트 이름을 수정한 후 파일을 저장합니다.
업데이트된 서비스 구성을 배포합니다.
```
gcloud endpoints services deploy api_descriptor.pb api_config.yaml api_config_http.yaml
```
서비스 구성이 성공적으로 배포될 때까지 기다립니다.
Kubernetes 서비스를 시작합니다.
```
  kubectl create -f deployment.yaml
```

구성 파일 검사

ssh를 통해 kubectl을 사용하여 pod에 연결합니다.
```
kubectl exec -ti -c CONTAINER_NAME POD_NAME bash
```
CONTAINER_NAME을 컨테이너 이름으로 바꾸고 POD_NAME을 pod 이름으로 바꿉니다.
etc/nginx/endpoints/ 디렉터리에서 다음 구성 파일에 오류가 있는지 확인합니다.
- nginx.conf - ESP 지시문이 있는 nginx 구성 파일
- service.jso - 서비스 구성 파일

Endpoints 상태 페이지에 액세스

ESP 시작 시 rollout_strategy를 managed로 설정한 경우 ESP 인스턴스가 사용 중인 구성 ID는 Endpoints 상태 페이지에서 확인할 수 있습니다.

Endpoints 상태 페이지에 액세스하는 방법은 다음과 같습니다.

ssh를 통해 kubectl을 사용하여 pod에 연결합니다.
```
kubectl exec -ti -c CONTAINER_NAME POD_NAME bash
```
CONTAINER_NAME을 컨테이너 이름으로 바꾸고 POD_NAME을 pod 이름으로 바꿉니다.
curl를 설치합니다.

다음을 입력합니다.

  curl http://localhost:8090/endpoints_status

다음과 비슷한 내용이 표시됩니다.

"serviceConfigRollouts": {
    "rolloutId": "2017-08-09r27",
    "percentages": {
         "2017-08-09r26": "100"
    }
}

rolloutId 값은 ESP가 사용 중인 서비스 구성 ID입니다. ESP가 Endpoints와 동일한 구성을 사용하는지 확인하려면 서비스 이름 및 구성 ID 가져오기를 참조하세요.