kubernetes K8S groundnuty/k8s-wait-for镜像无法作为init容器启动(带helm)

iyr7buue  于 12个月前  发布在  Kubernetes
关注(0)|答案(2)|浏览(148)

我遇到了一个问题与图像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

ttcibm8c

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成功地等待作业(迁移)完成,以便让主容器运行。
下面是解决该问题的服务帐户、角色和角色绑定的代码示例。

萨.亚姆

apiVersion: v1
kind: ServiceAccount
metadata:
  name: sa-migration
  namespace: development

字符串

role.yaml

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: migration-reader
rules:
  - apiGroups: ["batch","extensions"]
    resources: ["jobs"]
    verbs: ["get","watch","list"]

角色绑定.yaml

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: migration-reader
subjects:
- kind: ServiceAccount
  name: sa-migration
roleRef:
  kind: Role
  name: migration-reader
  apiGroup: rbac.authorization.k8s.io

7kqas0il

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>

溶液

创建角色

kubectl create role job-reader --verb=get --verb=list --verb=watch --resource=jobs --namespace=local

字符串
创建RoleBinding

# This role binding allows "local:default" service account to read jobs in the "local" namespace.
# You need to already have a role named "job-reader" in that namespace.
kubectl create rolebinding read-jobs --role=job-reader --serviceaccount=local:default --namespace=local

这解决了问题!

完整源代码

如果你愿意,可以查看完整的here源代码。deployment.yaml文件有init容器部分。

相关问题