company_banner

Kubernetes 1.21 — неожиданно много изменений…

    Новая эмблема символизирует распределение членов команды выпуска релиза по земному шару  — от UTC-8 до UTC+8 (похоже, ни японцев, ни корейцев в команде нет). Эмблему нарисовал Aravind Sekar, независимый дизайнер из Индии. На мой взгляд, котики были круче.

    Но давайте перейдем к чтению changelog и особенно моему любимому разделу Urgent Upgrade Notes.


    CronJob

    Сообщение в блоге гласит, что CronJob объявлены stable, но далее есть небольшое уточнение  — стабильным объявлена версия API, то есть структура манифеста kind: cronJob, а вот с контроллером, который и отвечает за реализацию логики работы, все намного интереснее.

    В версии 1.20 был добавлен CronJob контроллер версии 2. В новой версии 1.21 его перевели в стадию бета и включили по умолчанию. В версии 1.22 планируется удалить код старого CronJob контроллера. Очень, очень быстрые изменения, обычно не свойственные циклам релизов в Kubernetes.

    Причем в документации все Cronjob limitations, о которых я писал на Хабре, остались без изменений.

    Зачем тогда делали новый контроллер, если все проблемы с кронджобами остались нерешенными? Ответ есть в этой статье  — старый контроллер излишне нагружал API Kubernetes и не успевал создавать Job, если в кластере было больше 1000 Cronjob манифестов. Новая версия контроллера написана согласно последним гайдлайнам и намного быстрее.

    Immutable Secret and ConfigMap

    Добавили возможность создавать защищенные от изменений секреты и конфиг мапы. Видимо, защита от джунов, которые "pushed bad configuration". На мой взгляд, ConfigMap надо деплоить через helm чарты, а секреты хранить в Vault. Там, где есть история изменений, а ваш CI/CD не должен позволять выкатывать нерабочие конфиги на прод.

    IPv4/IPv6 Dual-Stack support

    Поддержка IPv6 теперь включена по умолчанию, единственная тонкость — ваш CNI также должен уметь в Dual-Stack. Calico умеет)

    Graceful Node Shutdown

    Kubelet научился определять ситуацию, когда узел выключается командой shutdown, и теперь посылает подам sigterm. TODO: Протестировать, не завершается ли container runtime быстрее kubelet, и что будет при простом systemctl shutdown kubelet.

    PodSecurityPolicy Deprecation

    Еще одна неоднозначная новость. PSP объявлены устаревшими и запланированы к удалению в версии 1.25. Но при этом PSP Replacement Policy (полиси для замены полиси) находятся в состоянии проекта, а альфа-версию обещают показать только в Kubernetes 1.22. Кратко ознакомиться, что же там проектируется, можно в KEP #2582. Самое странное из того, что там написано, на мой взгляд, — это предложение использовать namespace label, чтобы определять, по каким правилам проверять манифесты подов. Получается, что, выдав кому-либо права на редактирование неймспейса, вы даете ему и простой способ получить права администратора кластера.

    Подождем и посмотрим, что же будет в итоге, а пока нам предлагают плавно переходить на использование стандартных PSP, аналоги которых в виде встроенных профилей будут захардкожены в новый admission plugin PSPv2.

    Или переходить на использование сторонних решений, таких как Open Policy Agent Gatekeeper.

    Urgent Upgrade Notes

    По умолчанию теперь используется cgroupDriver systemd. Не забывайте проверять настройки своего containerd при установке нового кластера или добавлении узлов. Но и это еще не все. В версии 1.22 обещают принудительную смену cgroup driver в kubelet на systemd при обновлении кластера, поэтому пора уже почитать руководство по миграции и начать смену драйвера.

    Много мелких изменений в районе CSI и PV: перестают использоваться старые метки, флаги и метрики. В принципе ничего страшного, скорее всего, надо будет просто обновить используемые CSI драйверы.

    Команды kubeadm kubeconfig user, certs и debug переведены из экспериментальных в постоянные, и теперь их надо указывать без слова alpha.

    Продолжают урезать функционал команды kubectl run. Убрали целый набор ключей для создания service и cronjob, объявили устаревшими ключи для установки реквестов и лимитов, сервисаккаунта и использования hostport. В общем активно заставляют использовать только готовые yaml-манифесты для создания объектов кластера.

    К большому моему сожалению, окончательно убрали поддержку ключа kubectl --export. А как было удобно с помощью этого ключа получать из готового объекта кластера манифест для создания его копии, например, секрет с TLS сертификатом скопировать в другой namespace.

    Всем, кто использует vSphere версии меньшей, чем 67u3, рекомендуют обновиться, время есть до выхода kubernetes 1.24.

    Интересные мелкие новшества

    В NetworkPolicy добавили поле endPort для поддержки диапазонов портов. Радуйтесь, любители запускать Asterisk в кластере.

    В DaemonSets добавили поле MaxSurge, теперь во время обновления демонсета можно указать, чтобы сначала на узле создавался новый под, а после его запуска удалялся старый.

    В команды kubectl exec и portforward добавили keepalive пинги, и теперь промежуточные HTTP-балансировщики не будут обрывать соединение, если в нем нет активности.

    В Job добавили поле suspend и написали про это целую статью в блоге. Вот только я не понял, какой в этом смысл — имитация работы Kafka или Rabbitmq?

    Появилась возможность выбирать неймспейсы по их имени. Просто в манифест неймспейса автоматически добавляют метку kubernetes.io/metadata.name.

    В Service добавили поле InternalTrafficPolicy. Если указать в нем значение Local, трафик будет направляться только на поды, расположенные на том же узле кластера, что и под, отправивший запрос. Пока в альфа-статусе, для использования надо включить featureGate = ServiceInternalTrafficPolicy.

    Наконец-то включили TTL Controller, который позволяет удалять манифесты завершившихся Job.

    В манифест подов добавили аннотацию kubectl.kubernetes.io/default-container, с помощью которой можно указать, в какой контейнер пода делать exec, чьи логи смотреть и тому подобное, если при вызове не указан ключ -c.

    Southbridge
    Обеспечиваем стабильную работу highload-проектов

    Похожие публикации

    Комментарии 10

      +1

      Центр разработки Kubernetes находится в Самарканде
      Спасибо за пост. Как же теперь получать секрет с TLS сертификатом?

        0

        kubectl get secret my-tls-certificate -o yaml и удалять строки с метаданными о статусе?

        0
        Добавили возможность создавать защищенные от изменений секреты и конфиг мапы. Видимо, защита от джунов, которые "pushed bad configuration". На мой взгляд, ConfigMap надо деплоить через helm чарты, а секреты хранить в Vault. Там, где есть история изменений, а ваш CI/CD не должен позволять выкатывать нерабочие конфиги на прод.

        надеюсь, это будет отключаемой функцией — через тот же фиче-гейт...


        Поддержка IPv6 теперь включена по умолчанию, единственная тонкость — ваш CNI также должен уметь в Dual-Stack. Calico умеет)

        cilium, cilium, cilium, cilium… или на худой конец — kube-router

          0
          А есть ли какой нибудь толковый обзор CNI?
          Да и вообще как реализовать работу с сетью в кластере
          А то только начинаю втягиваться и трудно выбрать
            +1

            Очевидно, от задач зависит.
            Например, в облаке — берете то, что есть там. Кто-то хочет ISTIO — и приходится Istio CNI тащить. Кто-то хочет шифрование поверх публичных сетей. У кого-то задача делать очень быструю сеть с минимальными задержками
            Более того — можно комбинировать разные CNI.
            Флант, например, flannel+kube-router используют.
            Мы попробовали cilium+kube-router (ждем, когда BGP затащат в сам cilium).
            А вообще — есть куча различных сравнений: https://itnext.io/benchmark-results-of-kubernetes-network-plugins-cni-over-10gbit-s-network-updated-august-2020-6e1b757b9e49

              0
              istio CNI — это не про сеть в кластере, это костыль, который позволяет istio настроить iptables в контейнере, при включенном PSP.
              0
              flannel с hostgw — просто и быстро. Выбирай когда все узлы кластера в одной локалке и не нужны NetworkPolicy

              calico — достаточно просто и универсально. Выбирай в остальных случаях

              cillium — обменять +200 к сложности на +1% к скорости. Явно не для новичка выбор
                0
                cillium — обменять +200 к сложности на +1% к скорости. Явно не для новичка выбор

                зато там обзервабилити инструменты классные и за ним будущее.


                calico — достаточно просто и универсально. Выбирай в остальных случаях

                тогда уж лучше Kube-router, не? Не слышал ни одного плохого отзыва о нем. Из несомненных плюсов — и NP, и использование стандартных средств линукс (айпитбейлз и пр) для организации сети

                  0
                  Сложность не пугает, можно разобраться, особенно если нет ограничения по времени на внедрение. Меня например интересует поддержка IPv6, а так же наверно шифрование трафика, так как сеть между нодами публичная (хоть и в одном ДЦ). А так же например интересует возможность ограничить CNI в пределах backend сети, что бы он не вмешивался в настройки публичной сети. Ну или я могу сам поднять IPSec между нодами и объединить их, но мне нужно что бы CNI не мешал в данном варианте. По сравнениям, их конечно много и поэтому тяжелее на начальном этапе определить что лучше подойдет. Так же немного пугает время жизни релизов самого кубика, и периодические переезды api (alpha / beta / depricated / ...)

        Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

        Самое читаемое