我有一个多容器应用程序：app + sidecar。两个容器都应该一直处于活动状态，但 sidecar 并不是那么重要。
Sidecar 依赖于外部资源，如果该资源不可用 - Sidecar 就会崩溃。它会导致整个吊舱瘫痪。 Kubernetes 尝试重新创建 pod，但失败了，因为 sidecar 现在无法启动。
但从我的业务逻辑角度来看，sidecar 崩溃是绝对正常的。拥有那个边车很好，但不是强制性的。
我不希望 sidecar 在崩溃时带走主应用程序。
实现这一目标的最佳 Kubernetes 原生方式是什么？
是否有可能告诉 kubernetes 将 sidecar 的故障忽略为“误报”事件，这绝对没问题？
我在 Pod 规范中找不到任何控制该行为的内容。
My yaml:
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
name: myapp
spec:
strategy:
type: RollingUpdate
rollingUpdate:
maxSurge: 1
maxUnavailable: 0
template:
metadata:
labels:
app: myapp
spec:
volumes:
- name: logs-dir
emptyDir: {}
containers:
- name: myapp
image: ${IMAGE}
ports:
- containerPort: 9009
volumeMounts:
- name: logs-dir
mountPath: /usr/src/app/logs
resources:
limits:
cpu: "1"
memory: "512Mi"
readinessProbe:
initialDelaySeconds: 60
failureThreshold: 8
timeoutSeconds: 1
periodSeconds: 8
httpGet:
scheme: HTTP
path: /myapp/v1/admin-service/git-info
port: 9009
- name: graylog-sidecar
image: digiapulssi/graylog-sidecar:latest
volumeMounts:
- name: logs-dir
mountPath: /log
env:
- name: GS_TAGS
value: "[\"myapp\"]"
- name: GS_NODE_ID
value: "nodeid"
- name: GS_SERVER_URL
value: "${GRAYLOG_URL}"
- name: GS_LIST_LOG_FILES
value: "[\"/ctwf\"]"
- name: GS_UPDATE_INTERVAL
value: "10"
resources:
limits:
memory: "128Mi"
cpu: "0.1"
Warning:被标记为“正确”的答案似乎不起作用。
将 Liveness Probe 添加到应用程序容器并将重新启动策略设置为“从不”，将导致 Pod 停止并从未重新启动过在 sidecar 容器已停止并且应用程序容器的 Liveness Probe 失败的情况下。这是一个问题，因为您确实希望重新启动应用程序容器。
该问题应按如下方式解决：
- 在启动命令中调整 sidecar 容器，以在应用程序进程失败时保持主进程运行。这可以通过额外的脚本来完成，例如通过附加
| tail -f /dev/null到启动命令。
- 将 Liveness Probe 添加到应用程序容器通常是一个好主意。但请记住，它只能保护您免受应用程序进程在应用程序未处于正确状态的情况下持续运行的情况的影响。它肯定不会覆盖 restartPolicy：
livenessProbe：指示容器是否正在运行。如果活性探测失败，kubelet 将终止容器，并且容器将遵循其重新启动策略。如果容器不提供活性探测，则默认状态为成功。容器探针 https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/#container-probes
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
