Я настроил (очень) простое развертывание с помощью GKE в кластере GKE Autopilot с последней версией Kubernetes (1.18.15-gke.1501
) и подключил вход (внешний балансировщик нагрузки HTTP(s)), который ссылается на простую службу ClusterIP
.
Всякий раз, когда я обновляю развертывание новым образом, у меня возникает около 5-15 минут простоя, когда балансировщик нагрузки возвращает ошибку 502. Кажется, что плоскость управления создает новый, обновленный модуль, позволяет пройти проверки работоспособности на уровне обслуживания (не проверки балансировки нагрузки, он еще не создает NEG), затем убивает старый модуль, в то же время время установки нового NEG. Затем он не удаляет старый NEG до определенного промежутка времени.
Журналы в модулях показывают, что проверки работоспособности выполняются, но панель инструментов GKE показывает противоречивые результаты для состояния Ingress. Вход будет отображаться нормально, но служба будет 502.
Вещи, которые я пробовал
- Увеличение количества модулей с 1 до 3. Это помогло при некоторых развертываниях, но при каждом другом развертывании это увеличивало количество времени, которое требовалось балансировщику нагрузки для правильного разрешения.
- Попытка установить
maxSurge
на 1 иmaxUnavailable
на 0. Это совсем не уменьшило время простоя. - Добавление
lifecycle.preStop.exec.command: ["sleep", "60"]
в контейнер при развертывании. Это было предложено в документации GKE здесь . - Повторное создание входа, службы, развертываний и кластеров несколько раз.
- Добавление
BackendConfig
к сервису, который добавляет к нему более медленный слив. - Добавление ворот готовности, найденных в документации, которые должны исправить это, но по какой-то причине этого не делают?
Ничто из вышеперечисленного не помогло и не оказало заметного влияния на то, как долго все было не так.
Я действительно, очень смущен тем, почему это не работает. Такое ощущение, что я упускаю что-то действительно очевидное, но это настолько простая конфигурация, что вы думаете, что она... просто сработает?? Кто-нибудь знает, что происходит?
Файлы конфигурации
Конфигурация развертывания:
apiVersion: apps/v1
kind: Deployment
metadata:
name: foundation-deployment
spec:
replicas: 3
strategy:
type: RollingUpdate
rollingUpdate:
maxUnavailable: 0
maxSurge: 1
selector:
matchLabels:
app: foundation-web
template:
metadata:
labels:
app: foundation-web
spec:
readinessGates:
- conditionType: "cloud.google.com/load-balancer-neg-ready"
serviceAccountName: foundation-database-account
containers:
# Run Cloud SQL proxy so we can safely connect to Postgres on localhost.
- name: cloud-sql-proxy
image: gcr.io/cloudsql-docker/gce-proxy:1.17
resources:
requests:
cpu: "250m"
memory: 100Mi
limits:
cpu: "500m"
memory: 100Mi
command:
- "/cloud_sql_proxy"
- "-instances=nine-foundation:us-central1:foundation-staging=tcp:5432"
securityContext:
runAsNonRoot: true
# Main container config
- name: foundation-web
image: gcr.io/project-name/foundation_web:latest
imagePullPolicy: Always
lifecycle:
preStop:
exec:
command: ["sleep", "60"]
env:
# Env variables
resources:
requests:
memory: "500Mi"
cpu: "500m"
limits:
memory: "1000Mi"
cpu: "1"
livenessProbe:
httpGet:
path: /healthz
port: 4000
initialDelaySeconds: 10
periodSeconds: 10
readinessProbe:
httpGet:
path: /healthz
port: 4000
initialDelaySeconds: 10
periodSeconds: 10
ports:
- containerPort: 4000
Конфиг службы:
apiVersion: v1
kind: Service
metadata:
name: foundation-web-service
annotations:
cloud.google.com/neg: '{"ingress": true}'
cloud.google.com/backend-config: '{"ports": {"4000": "foundation-service-config"}}'
spec:
type: ClusterIP
selector:
app: foundation-web
ports:
- port: 4000
targetPort: 4000
БэкэндКонфигурация:
apiVersion: cloud.google.com/v1
kind: BackendConfig
metadata:
name: foundation-service-config
spec:
# sessionAffinity:
# affinityType: "GENERATED_COOKIE"
# affinityCookieTtlSec: 120
connectionDraining:
drainingTimeoutSec: 60
Входная конфигурация:
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
name: foundation-web-ingress
labels:
name: foundation-web-ingress
spec:
backend:
serviceName: foundation-web-service
servicePort: 4000