Ersetzt kubectl nicht die Umgebungsvariablen?

Ich füge eine Umgebungsvariable zu einer Kubernetes Replikations-Controller-Spezifikation hinzu, aber wenn ich den laufenden RC von der Spezifikation aktualisiere, wird die Umgebungsvariable nicht hinzugefügt. Woher?Ersetzt kubectl nicht die Umgebungsvariablen?

aktualisiere ich die RC entsprechend die folgenden Spezifikation, wo die Umgebungsvariable IRON_PASSWORD seit der letzten Revision hinzugefügt wird, aber die laufende RC nicht entsprechend aktualisiert, kubectl replace -f docker/podspecs/web-controller.yaml:

apiVersion: v1 
kind: ReplicationController 
metadata: 
    name: web 
    labels: 
    app: web 
spec: 
    replicas: 1 
    selector: 
    app: web 
    template: 
    metadata: 
     labels: 
     app: web 
    spec: 
     containers: 
     - name: web 
     image: quay.io/aknuds1/muzhack 
     # Always pull latest version of image 
     imagePullPolicy: Always 
     env: 
     - name: APP_URI 
      value: https://staging.muzhack.com 
     - name: IRON_PASSWORD 
      value: password 
     ports: 
     - name: http-server 
      containerPort: 80 
     imagePullSecrets: 
     - name: quay.io

Nach dem RC Aktualisierung nach die spec bemerken, es sieht aus wie dieser (kubectl get pod web-scpc3 -o yaml), dass IRON_PASSWORD fehlt:

apiVersion: v1 
kind: Pod 
metadata: 
    annotations: 
    kubernetes.io/created-by: | 
     {"kind":"SerializedReference","apiVersion":"v1","reference":{"kind":"ReplicationController","namespace":"default","name":"web","uid":"c1c4185f-0867-11e6-b557-42010af000f7","apiVersion":"v1","resourceVersion":"17714"}} 
    kubernetes.io/limit-ranger: 'LimitRanger plugin set: cpu request for container 
     web' 
    creationTimestamp: 2016-04-22T08:54:00Z 
    generateName: web- 
    labels: 
    app: web 
    name: web-scpc3 
    namespace: default 
    resourceVersion: "17844" 
    selfLink: /api/v1/namespaces/default/pods/web-scpc3 
    uid: c1c5035f-0867-11e6-b557-42010af000f7 
spec: 
    containers: 
    - env: 
    - name: APP_URI 
     value: https://staging.muzhack.com 
    image: quay.io/aknuds1/muzhack 
    imagePullPolicy: Always 
    name: web 
    ports: 
    - containerPort: 80 
     name: http-server 
     protocol: TCP 
    resources: 
     requests: 
     cpu: 100m 
    terminationMessagePath: /dev/termination-log 
    volumeMounts: 
    - mountPath: /var/run/secrets/kubernetes.io/serviceaccount 
     name: default-token-vfutp 
     readOnly: true 
    dnsPolicy: ClusterFirst 
    imagePullSecrets: 
    - name: quay.io 
    nodeName: gke-staging-default-pool-f98acf11-ba7d 
    restartPolicy: Always 
    securityContext: {} 
    serviceAccount: default 
    serviceAccountName: default 
    terminationGracePeriodSeconds: 30 
    volumes: 
    - name: default-token-vfutp 
    secret: 
     secretName: default-token-vfutp 
status: 
    conditions: 
    - lastProbeTime: null 
    lastTransitionTime: 2016-04-22T09:00:49Z 
    message: 'containers with unready status: [web]' 
    reason: ContainersNotReady 
    status: "False" 
    type: Ready 
    containerStatuses: 
    - containerID: docker://dae22acb9f236433389ac0c51b730423ef9159d0c0e12770a322c70201fb7e2a 
    image: quay.io/aknuds1/muzhack 
    imageID: docker://8fef42c3eba5abe59c853e9ba811b3e9f10617a257396f48e564e3206e0e1103 
    lastState: 
     terminated: 
     containerID: docker://dae22acb9f236433389ac0c51b730423ef9159d0c0e12770a322c70201fb7e2a 
     exitCode: 1 
     finishedAt: 2016-04-22T09:00:48Z 
     reason: Error 
     startedAt: 2016-04-22T09:00:46Z 
    name: web 
    ready: false 
    restartCount: 6 
    state: 
     waiting: 
     message: Back-off 5m0s restarting failed container=web pod=web-scpc3_default(c1c5035f-0867-11e6-b557-42010af000f7) 
     reason: CrashLoopBackOff 
    hostIP: 10.132.0.3 
    phase: Running 
    podIP: 10.32.0.3 
    startTime: 2016-04-22T08:54:00Z

Quelle

2016-04-22 aknuds1

das ReplicationController Objekt Ersetzen neu eigentlich nicht die zugrunde liegende Pods, so dass die Pods die Spezifikation von der vorherigen Konfiguration des RC beibehalten, bis sie neu erstellt werden müssen. Wenn Sie den laufenden Pod löschen, wird der neue Pod, der erstellt wird, um ihn zu ersetzen, die neue Umgebungsvariable haben.

Dies ist, was die kubectl rolling update command ist, und ein Teil des Grundes, warum der Deployment Typ zu Kubernetes 1.2 hinzugefügt wurde.

Quelle

2016-04-22 18:19:42

Eigentlich wurde mir heute gesagt, 'kubectl apply' anstelle von' rolling-update' zu verwenden, aber das aktualisiert auch die Umgebungsvariablen von pods nicht. – aknuds1

Woher hast du das gesagt? Apply und Rolling-Update machen sehr unterschiedliche Dinge. –

Im Slack-Kanal. Ich hatte Probleme mit rolling-update, da ich ein fehlgeschlagenes Update nicht rückgängig machen konnte. – aknuds1

Ersetzt kubectl nicht die Umgebungsvariablen?

Antwort

Verwandte Themen