我遇到了一个问题与图像groundnuty/k8s-wait-for.项目在github和repo在dockerhub.
我很确定这个错误是在命令参数中,因为init容器失败,并返回Init:CrashLoopBackOff。
**关于镜像:**该镜像用于init容器,需要推迟pod部署。镜像中的脚本等待pod或job完成,完成后让主容器和所有副本开始部署。
在我的例子中,它应该等待一个名为{{ .Release.Name }}-os-server-migration-{{ .Release.Revision }}
的作业完成,在它检测到它完成后,它应该让主容器启动。
根据我的理解,作业名为{{ .Release.Name }}-os-server-migration-{{ .Release.Revision }}
,部署.yml中init容器的第二个命令参数需要相同,这样init容器才能依赖于命名的作业。对于这种方法,还有其他意见或经验吗?
有模板附加。
部署。YML:
apiVersion: apps/v1
kind: Deployment
metadata:
name: {{ .Release.Name }}-os-{{ .Release.Revision }}
namespace: {{ .Values.namespace }}
labels:
app: {{ .Values.fullname }}
spec:
replicas: {{ .Values.replicaCount }}
selector:
matchLabels:
app: {{ .Values.fullname }}
template:
metadata:
labels:
app: {{ .Values.fullname }}
spec:
{{- with .Values.imagePullSecrets }}
imagePullSecrets:
{{- toYaml . | nindent 8 }}
{{- end }}
containers:
- name: {{ .Chart.Name }}
image: "{{ .Values.image.repository }}:{{ .Values.image.tag }}"
imagePullPolicy: {{ .Values.image.pullPolicy }}
ports:
- name: http
containerPort: 8080
resources:
{{- toYaml .Values.resources | nindent 12 }}
initContainers:
- name: "{{ .Chart.Name }}-init"
image: "groundnuty/k8s-wait-for:v1.3"
imagePullPolicy: "{{ .Values.init.pullPolicy }}"
args:
- "job"
- "{{ .Release.Name }}-os-server-migration-{{ .Release.Revision }}"
字符串
职位YML:
apiVersion: batch/v1
kind: Job
metadata:
name: {{ .Release.Name }}-os-server-migration-{{ .Release.Revision }}
namespace: {{ .Values.migration.namespace }}
spec:
backoffLimit: {{ .Values.migration.backoffLimit }}
template:
spec:
{{- with .Values.migration.imagePullSecrets }}
imagePullSecrets:
{{- toYaml . | nindent 8 }}
{{- end }}
containers:
- name: {{ .Values.migration.fullname }}
image: "{{ .Values.migration.image.repository }}:{{ .Values.migration.image.tag }}"
imagePullPolicy: {{ .Values.migration.image.pullPolicy }}
command:
- sh
- /app/migration-entrypoint.sh
restartPolicy: {{ .Values.migration.restartPolicy }}
型
日志:
Normal Scheduled 46s default-scheduler Successfully assigned development/octopus-dev-release-os-1-68cb9549c8-7jggh to minikube
Normal Pulled 41s kubelet Successfully pulled image "groundnuty/k8s-wait-for:v1.3" in 4.277517553s
Normal Pulled 36s kubelet Successfully pulled image "groundnuty/k8s-wait-for:v1.3" in 3.083126925s
Normal Pulling 20s (x3 over 45s) kubelet Pulling image "groundnuty/k8s-wait-for:v1.3"
Normal Created 18s (x3 over 41s) kubelet Created container os-init
Normal Started 18s (x3 over 40s) kubelet Started container os-init
Normal Pulled 18s kubelet Successfully pulled image "groundnuty/k8s-wait-for:v1.3" in 1.827195139s
Warning BackOff 4s (x4 over 33s) kubelet Back-off restarting failed container
型
kubectl get all -n development
NAME READY STATUS RESTARTS AGE
pod/octopus-dev-release-os-1-68cb9549c8-7jggh 0/1 Init:CrashLoopBackOff 2 44s
pod/octopus-dev-release-os-1-68cb9549c8-9qbdv 0/1 Init:CrashLoopBackOff 2 44s
pod/octopus-dev-release-os-1-68cb9549c8-c8h5k 0/1 Init:Error 2 44s
pod/octopus-dev-release-os-migration-1-9wq76 0/1 Completed 0 44s
......
......
NAME COMPLETIONS DURATION AGE
job.batch/octopus-dev-release-os-migration-1 1/1 26s 44s
型
2条答案
按热度按时间ttcibm8c1#
对于任何面临同样问题的人,我将解释我的解决方案。
问题是deployment.yaml中的容器没有使用Kube API的权限。因此,groundnuty/k8s-wait-for:v1.3 container无法检查作业**{{ .Release.Name }}-os-server-migration-{{ .Release.Revision }}**是否完成。这就是init container立即失败并出现CrashLoopError的原因。
在添加服务帐户、角色和角色绑定之后,一切都运行得很好,groundnuty/k8s-wait-for:v1.3成功地等待作业(迁移)完成,以便让主容器运行。
下面是解决该问题的服务帐户、角色和角色绑定的代码示例。
萨.亚姆
字符串
role.yaml
型
角色绑定.yaml
型
7kqas0il2#
我有这个确切的问题。原来问题是与pod缺乏权限执行
kubectl get
查询。参考。我之所以添加这个答案,是因为它在没有任何
.yaml
文件的情况下解决了问题。故障排除
通过进入Pod ->单击“打开”->选择init container来检查init container日志。
x1c 0d1x的数据
或者你可以使用
kubectl logs <pod-name> -c <container-name> -n <namespace>
来获取容器日志。在这种情况下,日志如下所示:Error from server (Forbidden): jobs.batch "test-app-release-test-app-cli-1" is forbidden: User "system:serviceaccount:local:default" cannot get resource "jobs" in API group "batch" in the namespace "local"
个这意味着pod缺少执行
kubectl get
查询的权限。参考。修复方法是创建一个具有读取作业权限的角色,并将该角色绑定到服务帐户。服务帐户在日志中显示为:
local:default
。服务帐户的格式为<namespace>:<serviceaccount>
。溶液
创建角色
字符串
创建RoleBinding
这解决了问题!
完整源代码
如果你愿意,可以查看完整的here源代码。
deployment.yaml
文件有init容器部分。