Kubernetes: kubectl apply не обновляет модули при использовании тега "latest"

Question

Я использую kubectl apply для обновления моих модулей Kubernetes:

kubectl apply -f /my-app/service.yaml
kubectl apply -f /my-app/deployment.yaml

Ниже мой сервис.yaml:

apiVersion: v1
kind: Service
metadata:
  name: my-app
  labels:
    run: my-app
spec:
  type: NodePort
  selector:
    run: my-app 
  ports:
  - protocol: TCP
    port: 9000
    nodePort: 30769

Ниже мой развертывание. Yaml:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:  
  selector:
    matchLabels:
      run: my-app
  replicas: 2
  template:
    metadata:
      labels:
        run: my-app
    spec:
      containers:
      - name: my-app
        image: dockerhubaccount/my-app-img:latest
        ports:
        - containerPort: 9000
          protocol: TCP
      imagePullSecrets:
      - name: my-app-img-credentials
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 25%
      maxSurge: 25%

Это отлично работает в первый раз, но при последующих запусках мои модули не обновляются.

Я прочитал предложенный обходной путь на https://github.com/kubernetes/kubernetes/issues/33664, который:

kubectl patch deployment my-app -p "{\"spec\":{\"template\":{\"metadata\":{\"labels\":{\"date\":\"`date +'%s'`\"}}}}}"

Мне удалось выполнить указанную выше команду, но она не решила проблему для меня.

Я знаю, что могу запускать обновления модуля, вручную изменяя тег изображения с «последнего»к другому тегу, но я хочу убедиться, что получаю последнее изображение, не проверяя Docker Hub.

Любая помощь будет принята с благодарностью.

Answer 1

Здесь есть две вещи, которые касаются проблемы:

1. . Рекомендуется использовать kubectl apply впервые при создании ресурса, а затем рекомендуется использовать kubectl replace илиkubectl edit или kubectl patch команды, которые впоследствии вызывают kubectl apply.

2. После создания службы с использованием kubectl apply или kubetcl create вы не можете заменить эту службу yamlфайл.Другими словами, сервис генерирует случайный IP , который не может быть исправленным или замененным .Единственная возможность воссоздать службу - это удалить службу и воссоздать ее с тем же именем.

ПРИМЕЧАНИЕ: Когда я попытался заменить службу с помощьюКоманда kubectl apply, когда я пытался создать решение для резервного копирования и восстановления, выявила следующую ошибку.

kubectl apply -f replace-service.yaml -n restore-proj
The Service "test-q12" is invalid: spec.clusterIP: Invalid value: "10.102.x.x": provided IP is already allocated.

Answer 2

Если в спецификации развертывания ничего не изменится, модули не будут обновлены для вас.Это одна из многих причин, по которой не рекомендуется использовать :latest, так как другой ответ более подробно описан.Контроллер Deployment очень прост и в значительной степени просто делает DeepEquals(old.Spec.Template, new.Spec.Template), поэтому вам нужно внести некоторые изменения, например, при вызове PATCH, установив метку с текущей датой-временем.

Answer 3

Оказывается, я неправильно понял команду обхода, которую я дал по ссылке.

Я думал, что это была однократная команда, которая настроила мое развертывание для обработки всех будущих команд kubectl apply как триггера для обновления моих модулей..

На самом деле мне просто нужно было запускать команду каждый раз, когда я хотел обновить свои модули:

kubectl patch deployment my-app -p "{\"spec\":{\"template\":{\"metadata\":{\"labels\":{\"date\":\"`date +'%s'`\"}}}}}"

Большое спасибо всем, кто помог!

Answer 4

Вам не хватает imagePullPolicy в вашем развертывании.Попробуйте это:

containers:
- name: my-app
  image: dockerhubaccount/my-app-img:latest
  imagePullPolicy: Always

Политика по умолчанию - ifNotPresent, поэтому ваша учетная запись не обновляется.

Я включу две заметки по ссылке:

Примечание: Следует избегать использования тега :latest при развертывании контейнеров в производстве, поскольку сложнее отслеживать, какая версия образа запущена, и сложнее правильно выполнить откат *.1018 *

Примечание: Семантика кэширования основного поставщика изображений делает даже imagePullPolicy: Always эффективным.Например, в Docker, если изображение уже существует, попытка извлечения выполняется быстро, поскольку все слои изображения кэшируются и загрузка изображения не требуется