mirror of
https://github.com/go-admin-team/go-admin.git
synced 2026-09-22 18:37:43 +00:00
zhangwenjian
adcdd2edcd
The comment on replicas gave one obstacle to raising it, the shared log volume, which reads as the only one. Someone who moves the log path off that volume would conclude the way is clear. The scheduler in app/jobs is the second, and it is the one that does not announce itself. Its handle on a job lives in sys_job.entry_id, one column shared by every process, and startup zeroes the whole column before writing its own ids. A second pod therefore erases the first pod's, and both pods run the full enabled list. Stopping a job from the UI then removes an entry from whichever process is asked, by an id that belongs to another one, and answers 200. See #915.
119 lines
4.2 KiB
YAML
119 lines
4.2 KiB
YAML
---
|
|
apiVersion: v1
|
|
kind: Service
|
|
metadata:
|
|
name: go-admin
|
|
labels:
|
|
app: go-admin
|
|
service: go-admin
|
|
spec:
|
|
ports:
|
|
- port: 8000
|
|
name: http
|
|
protocol: TCP
|
|
selector:
|
|
app: go-admin
|
|
---
|
|
apiVersion: apps/v1
|
|
kind: Deployment
|
|
metadata:
|
|
name: go-admin-v1
|
|
labels:
|
|
app: go-admin
|
|
version: v1
|
|
spec:
|
|
# One replica, and the drain window below buys nothing at one replica: there
|
|
# is nowhere to send the traffic this pod stops taking. Raising it needs two
|
|
# changes that are not this number:
|
|
#
|
|
# The volume below is shared by every replica, and the log path in
|
|
# settings.yml lives on it, so a second pod would append to the same
|
|
# rotating file.
|
|
#
|
|
# The job scheduler is per process while its handle on a job is one shared
|
|
# column. Startup runs `UPDATE sys_job SET entry_id = 0 WHERE entry_id > 0`
|
|
# across the whole table (app/jobs/jobbase.go), so a second pod erases the
|
|
# first pod's ids and writes its own, and every pod registers the whole
|
|
# enabled list in its own scheduler. Neither symptom logs anything: an
|
|
# enabled job fires once per pod, and stopping one from the UI removes an
|
|
# entry from the wrong process and still answers 200. See #915.
|
|
replicas: 1
|
|
selector:
|
|
matchLabels:
|
|
app: go-admin
|
|
version: v1
|
|
template:
|
|
metadata:
|
|
labels:
|
|
app: go-admin
|
|
version: v1
|
|
spec:
|
|
containers:
|
|
- name: go-admin
|
|
image: registry.cn-shanghai.aliyuncs.com/go-admin-team/go-admin
|
|
imagePullPolicy: IfNotPresent
|
|
ports:
|
|
- containerPort: 8000
|
|
# Readiness answers "send me requests". It fails while the database or
|
|
# the cache is unreachable, so this pod stays out of the Service until
|
|
# the datastore settings.yml names is really there - which is a change
|
|
# from having no probe at all, where a pod with an unreachable database
|
|
# was still sent traffic.
|
|
#
|
|
# timeoutSeconds is 3 rather than the default 1 because the handler
|
|
# allows its checks 2 seconds (readyTimeout in
|
|
# app/other/router/monitor.go). At the default, a database that answers
|
|
# in 1.2s is recorded as a failed check while the handler is returning
|
|
# 200.
|
|
readinessProbe:
|
|
httpGet:
|
|
path: /api/v1/ready
|
|
port: 8000
|
|
periodSeconds: 5
|
|
timeoutSeconds: 3
|
|
failureThreshold: 3
|
|
# Liveness answers "restart me", which is a different question: a
|
|
# process whose database is unreachable does not want restarting, so
|
|
# this points at /health, which is a bare 200. Both probes skip the
|
|
# rate limiter - see exemptProbes in cmd/api/server.go - because a
|
|
# liveness probe that collects 429s under load gets the container
|
|
# restarted at the moment the deployment can least afford to lose it.
|
|
#
|
|
# initialDelaySeconds covers the migrations, which run before the
|
|
# listener opens.
|
|
livenessProbe:
|
|
httpGet:
|
|
path: /api/v1/health
|
|
port: 8000
|
|
initialDelaySeconds: 15
|
|
periodSeconds: 10
|
|
failureThreshold: 3
|
|
volumeMounts:
|
|
- name: go-admin
|
|
mountPath: /temp
|
|
- name: go-admin
|
|
mountPath: /static
|
|
- name: go-admin-config
|
|
mountPath: /config/
|
|
readOnly: true
|
|
# SIGKILL arrives when this is up, so it has to be longer than what the
|
|
# process spends shutting down: extend.shutdown's drain + server +
|
|
# cleanup, which settings.yml ships as 0 + 5 + 3. Raise drain here and
|
|
# this number has to follow, or the cleanup callbacks are cut off
|
|
# part-way through - checksilent's shutdown-budget-overruns-grace check
|
|
# is what notices.
|
|
#
|
|
# No preStop hook on purpose. A sleep there would be spent before the
|
|
# process is told anything, so BeginDraining never runs and /ready
|
|
# answers 200 for the whole of it - and it would be added to the budget
|
|
# above rather than replacing any of it.
|
|
terminationGracePeriodSeconds: 30
|
|
volumes:
|
|
- name: go-admin
|
|
persistentVolumeClaim:
|
|
claimName: go-admin
|
|
- name: go-admin-config
|
|
configMap:
|
|
name: settings-admin
|
|
---
|