Мне трудно понять, что было бы лучше для моей ситуации, и как на самом деле ее реализовать.
В двух словах, проблема заключается в следующем:
- Я ускорение развертывания моих БД (Postgres), BE (Django) и FE (React) с помощью Skaffold
- Приблизительно в 50% случаев BE будет раскручиваться до того, как DB
- Одна из первых вещей, которые Django пытается сделать, - это подключиться к БД
- Он пытается только один раз (по замыслу и не может быть изменен), если он не может, он терпит неудачу, и приложение не работает
- Таким образом, , мне нужно убедиться, что каждый раз, когда я ускоряю развертывание, развертывание БД запускается перед началом развертывания BE
Я наткнулся на готовность, жизнеспособность и пробный запуск . Я прочитал его пару раз, и тесты готовности звучат так, как мне нужно: я не хочу, чтобы развертывание BE начиналось до тех пор, пока развертывание БД не будет готово принимать соединения.
Я полагаю, я не понимаю как это настроить. Это то, что я пробовал, но я все еще сталкиваюсь с случаями, когда один загружается раньше другого.
postgres .yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: postgres-deployment
spec:
replicas: 1
selector:
matchLabels:
component: postgres
template:
metadata:
labels:
component: postgres
spec:
containers:
- name: postgres
image: testappcontainers.azurecr.io/postgres
ports:
- containerPort: 5432
env:
- name: POSTGRES_DB
valueFrom:
secretKeyRef:
name: testapp-secrets
key: PGDATABASE
- name: POSTGRES_USER
valueFrom:
secretKeyRef:
name: testapp-secrets
key: PGUSER
- name: POSTGRES_PASSWORD
valueFrom:
secretKeyRef:
name: testapp-secrets
key: PGPASSWORD
- name: POSTGRES_INITDB_ARGS
value: "-A md5"
volumeMounts:
- name: postgres-storage
mountPath: /var/lib/postgresql/data
subPath: postgres
volumes:
- name: postgres-storage
persistentVolumeClaim:
claimName: postgres-storage
---
apiVersion: v1
kind: Service
metadata:
name: postgres-cluster-ip-service
spec:
type: ClusterIP
selector:
component: postgres
ports:
- port: 1423
targetPort: 5432
api.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: api-deployment
spec:
replicas: 3
selector:
matchLabels:
component: api
template:
metadata:
labels:
component: api
spec:
containers:
- name: api
image: testappcontainers.azurecr.io/testapp-api
ports:
- containerPort: 5000
env:
- name: PGUSER
valueFrom:
secretKeyRef:
name: testapp-secrets
key: PGUSER
- name: PGHOST
value: postgres-cluster-ip-service
- name: PGPORT
value: "1423"
- name: PGDATABASE
valueFrom:
secretKeyRef:
name: testapp-secrets
key: PGDATABASE
- name: PGPASSWORD
valueFrom:
secretKeyRef:
name: testapp-secrets
key: PGPASSWORD
- name: SECRET_KEY
valueFrom:
secretKeyRef:
name: testapp-secrets
key: SECRET_KEY
- name: DEBUG
valueFrom:
secretKeyRef:
name: testapp-secrets
key: DEBUG
readinessProbe:
httpGet:
host: postgres-cluster-ip-service
port: 1423
initialDelaySeconds: 10
periodSeconds: 5
timeoutSeconds: 2
---
apiVersion: v1
kind: Service
metadata:
name: api-cluster-ip-service
spec:
type: ClusterIP
selector:
component: api
ports:
- port: 5000
targetPort: 5000
client.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: client-deployment
spec:
replicas: 3
selector:
matchLabels:
component: client
template:
metadata:
labels:
component: client
spec:
containers:
- name: client
image: testappcontainers.azurecr.io/testapp-client
ports:
- containerPort: 3000
readinessProbe:
httpGet:
path: api-cluster-ip-service
port: 5000
initialDelaySeconds: 10
periodSeconds: 5
timeoutSeconds: 2
---
apiVersion: v1
kind: Service
metadata:
name: client-cluster-ip-service
spec:
type: ClusterIP
selector:
component: client
ports:
- port: 3000
targetPort: 3000
Я не думаю, что ingress.yaml и skaffold.yaml будут полезно, но дайте мне знать, если я должен добавить их.
Так что я здесь не так делаю?
Редактировать:
Итак Я опробовал несколько вещей, основываясь на ответе Дэвида Мейз. Это помогло мне понять, что происходит лучше, но я все еще сталкиваюсь с проблемами, которые я не совсем понимаю, как решить.
Первая проблема заключается в том, что даже при использовании по умолчанию restartPolicy: Always, и даже при Django терпит неудачу, сами стручки не терпят неудачу. Стручки думают, что они совершенно здоровы, хотя Django не удалось.
Вторая проблема состоит в том, что очевидно, что Стручки должны быть осведомлены о статусе Django. Это та часть, которую я не совсем оборачиваю, особенно если зонды проверяют состояние других развертываний или самих себя?
Вчера мое мышление было первым, но сегодня я думаю, что оно второе: Pod должен знать, что содержащаяся в нем программа провалилась. Тем не менее, все, что я пробовал, приводило к отказу зонда, отказу в соединении и т. Д. c.:
# referring to itself
host: /health
port: 5000
host: /healthz
port: 5000
host: /api
port: 5000
host: /
port: 5000
host: /api-cluster-ip-service
port: 5000
host: /api-deployment
port: 5000
# referring to the DB deployment
host: /health
port: 1423 #or 5432
host: /healthz
port: 1423 #or 5432
host: /api
port: 1423 #or 5432
host: /
port: 1423 #or 5432
host: /postgres-cluster-ip-service
port: 1423 #or 5432
host: /postgres-deployment
port: 1423 #or 5432
Так что, очевидно, я неправильно настроил зонд, несмотря на то, что он "супер легкая "реализация (как это описали несколько блогов). Например, маршруты /health и /healthz: они встроены в Kubernetes или их нужно настроить? Перечитывая документы, надеюсь, прояснить это.