Блог

Я использую службы Azure Kubernetes с версией K8S 1.20.9 и выполняю следующее развертывание K8S

Версия 1:

 apiVersion: apps/v1
kind: Deployment
metadata:
  namespace: test
  name: busybox-deployment
  labels:
    app: busybox
spec:
  replicas: 1
  strategy: 
    type: RollingUpdate
  selector:
    matchLabels:
      app: busybox
  template:
    metadata:
      labels:
        app: busybox
    spec:
      containers:
      - name: busybox
        image: busybox
        imagePullPolicy: IfNotPresent
        command: ['sh', '-c', 'echo Container 1 is Running ; sleep 3600']
        env:
          - name: KEY_1
            value: VALUE_1
 

Я развертываю с kubectl apply его помощью и проверяю значение KEY_1 переменной среды — оно правильно установлено VALUE_1 .

Затем я развертываю еще 2 версии (снова через kubectl apply ), где я меняю пару ключ-значение в разделе env следующим образом, эффективно удаляя старую переменную среды и создавая новую:

Версия 2:

         env:
          - name: KEY_2
            value: VALUE_2
 

Версия 3:

         env:
          - name: KEY_3
            value: VALUE_3
 

После каждого развертывания я проверяю переменные среды, и они в порядке — версия 2 содержит KEY_2:VALUE_2 пару, а версия 3 содержит KEY_3:VALUE_3 пару.

Теперь я возвращаюсь к версии 2, вызывая

 kubectl rollout undo deployment ...
 

Это также работает правильно, и теперь у нас есть KEY_2:VALUE_2 пара в качестве переменных среды.

Однако, если я снова разверну версию 3, контейнер и дескриптор развертывания будут иметь как KEY_2:VALUE_2 переменные среды, так и KEY_3:VALUE переменные среды as. Это не соответствует ни одному из развернутых дескрипторов, потому что они всегда содержат только одну переменную среды. Последующие развертывания приводят к тому же поведению, пока я вручную не отредактирую и не удалю ненужное свойство.

Я прочитал некоторые объяснения, подобные этой хорошей статье, где объясняется, что kubectl apply старые свойства будут удалены, а исправление — нет.

Однако этого не происходит при выполнении «отмены». Есть идеи, почему?

Спасибо.

Это известная проблема rollout undo , о которой сообщалось здесь # 94698, здесь # 25236 и здесь # 22512 .

С точки зрения непрофессионала — kubectl неправильно вычисляет различия и объединяет изменения, потому undo что неправильно загружает предыдущую конфигурацию.

Подробнее о том, как K8s вычисляет различия, можно найти в документации.

Обходным путем является обновление вручную последней примененной конфигурации перед повторным применением другого развертывания из файла конфигурации

 kubectl apply set-last-applied -f Deployment_v2.yaml -o yaml