Контейнер запускается в Google Cloud Shell, но не работает на Kubernetes Engine - PullRequest
Новая
       9

Контейнер запускается в Google Cloud Shell, но не работает на Kubernetes Engine

0 голосов
/ 04 июля 2018

Я новичок в использовании Kubernetes, Docker и GCP, извините, если вопрос глупый и (или) очевидный.

Я пытаюсь создать простой сервер gRPC с отображением http (s) на примере Google. Проблема заключается в том, что мой контейнер может быть запущен из облачной оболочки Google без каких-либо жалоб, но после развертывания происходит сбой в Kubernetes Engine.

В облачной консоли Google: 

git clone https://gitlab.com/myrepos/grpc.git
cd grpc
docker build -t gcr.io/project-id/python-grpc-diagnostic-server:v1 .

# Run the container "locally"
docker run --rm -p 8000:8000 gcr.io/mproject-id/python-grpc-diagnostic-server:v1                                    
Server is started
^CServer is stopped

# Pushing the image to Container Registry
gcloud docker -- push gcr.io/project-id/python-grpc-diagnostic-server:v1

# Deployment 
kubectl create -f grpc-diagnostic.yaml

В «диагностическом» контейнере сведений о развертывании находится статус «CrashLoopBackOff», а в журналах появляется следующая ошибка: 

File "/diagnostic/diagnostic_pb2.py", line 17, in <module>
    from google.api import annotations_pb2 as google_dot_api_dot_annotations__pb2
ModuleNotFoundError: No module named 'google.api'

Не могли бы вы дать какое-либо представление о том, почему тот же контейнер запускается в оболочке и не работает на Kubernetes Engine? Спасибо.

requirements.txt 

grpcio
grpcio-tools
pytz
google-auth
googleapis-common-protos

Dockerfile 

FROM gcr.io/google_appengine/python

# Create a virtualenv for dependencies. This isolates these packages from
# system-level packages.
RUN virtualenv -p python3.6 /env

# Setting these environment variables are the same as running
# source /env/bin/activate.
ENV VIRTUAL_ENV -p python3.6 /env
ENV PATH /env/bin:$PATH

ADD . /diagnostic/

WORKDIR /diagnostic
RUN pip install -r requirements.txt

EXPOSE 8000

ENTRYPOINT ["python", "/diagnostic/diagnostic_server.py"]

КПГР-diagnostic.yaml 

apiVersion: v1
kind: Service
metadata:
  name: esp-grpc-diagnostic
spec:
  ports:
  # Port that accepts gRPC and JSON/HTTP2 requests over HTTP.
  - port: 80
    targetPort: 9000 # or 8000?
    protocol: TCP
    name: http2
  selector:
    app: esp-grpc-diagnostic
  type: LoadBalancer
---
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: esp-grpc-diagnostic
spec:
  replicas: 1
  template:
    metadata:
      labels:
        app: esp-grpc-diagnostic
    spec:
      containers:
      - name: esp
        image: gcr.io/endpoints-release/endpoints-runtime:1
        args: [
          "--http2_port=9000",
          "--service=diagnostic.endpoints.project-id.cloud.goog",
          "--rollout_strategy=managed",
          "--backend=grpc://127.0.0.1:8000"
        ]
        ports:
          - containerPort: 9000
      - name: diagnostic
        image: gcr.io/project-id/python-grpc-diagnostic-server:v1
        ports:
          - containerPort: 8000

1 Ответ

0 голосов
/ 11 июля 2018

Это была моя глупая ошибка. Я изменил изображение, но имя изображения было таким же, поэтому кластер продолжал использовать старое неправильное изображение, думая, что ничего не изменилось. Правильный способ повторного развертывания кода - создать образ с новым тегом, например v1.01, и установить новый образ для существующего развертывания, как описано в документации . Я удалил службу и развертывание и заново создал его, но я не удалял кластер, думая, что я начал с нуля.

Правильный путь: 

docker build -t gcr.io/project-id/python-grpc-diagnostic-server:v1.01 . 
gcloud docker -- push gcr.io/project-id/python-grpc-diagnostic-server:v1.01   
kubectl set image deployment/esp-grpc-diagnostic diagnostic=gcr.io/project-id/python-grpc-diagnostic-server:v1.01

Другой способ получения обновленных изображений без изменения имени - это изменение imagePullPolicy, которое по умолчанию установлено на IfNotPresent. подробнее

...