Победу кубернетес обсуждали год, полтора назад. С тех пор никаких новых конкурентов не появилось.
Идеальный разработчик — это не тот, кто заявляет — у меня на ноуте все работает, а на сервере пусть админы чинят.
А человек, который понимает как использовать преимущества и обходить ограничения:
— контейнеров
— оркестратора контейнеров
— требований безопасности
— и т.д. и т.п.
Разработчик, который хочет просто кодить алгоритмы — не самый востребованный специалист на рынке труда.
Нет. в k8s докеру вообще запрещено что-то с iptables делать. Так что в этом плане ничего не изменится.
iptables создают kube-proxy и CNI plugin
Уменшить их количество можно переключив kube-proxy на режим ipvs
или выбрать CNI plugin типа cilum, который использует eBPF — но тут надо понимать что вы делаете, а не бездумно следовать советам из интернета
Обновляют. Регулярно. Все проблемы возникают не в самом процессе обновления, а когда к новому кластеру обращаются устаревшими методами.
На работу продакшена, который был задеплоен в кластере обычно это не влияет.
Хотя в этот раз с exec probe получилось не очень хорошо )
Вы не совсем правы. Тут скорее о том, что попытка сделать похожий cli совершенно другому инструменту привела к сложностям в понимании назначения и освоении
Нет необходимости, ресурсов или желания самостоятельно управлять своими кластерами — выбирайте любое менеджед решение от крупного поставщика. GKE, EKS, AKS.
Есть и много.
Как минимум кубспрей умеет не только в докер, но и containerd и crio, причем сам ставит, а не требует готовый.
Плюс более удобный подход к запуску контрол-плейна.
kubectl get pod -n kube-system покажет api, cm, scheduler… и логи их так же можно посмотреть. Плюс у кублетов можно динамические конфиги использовать.
ну и там еще много всего, но это уже относится к косякам rke, типа хранения приватного ключа от корневого сертификата кластера в конфигмапе.
в kubeadm народ заморачивался, писал специальный код, который генерил секреты с TTL 1 час, клал в эти секреты сертификаты, дополнительно их шифровал… и все это для того, чтобы передать серты на второй и третий мастера при HA-сетапе…
а в rke ребята простые…
Про хостнейм я не понял про какой таск вы говорите. Если вот про этот из роли bootstrap-os, то это не команда, а модуль ансибль.
- name: Assign inventory name to unconfigured hostnames (non-CoreOS, non-Flatcar, Suse and ClearLinux)
hostname:
name: "{{ inventory_hostname }}"
when:
- override_system_hostname
- ansible_os_family not in ['Suse', 'Flatcar Container Linux by Kinvolk', 'ClearLinux'] and not is_fedora_coreos
По поводу etcd_ionice. Тут да, мой косяк, не уследил за тем, что в контейнерах etcd v3.4.x выпилили бинариник ionice, и я уже убрал эту опцию из своего форка и готовлю PR в основной кубспрей.
Насчет целевой аудитории — Вы как-то резковато обратились только к граничным случаям:
— для поиграться
— и для реально здоровых в хотя бы 100 узлов…
А как же остальные 90% реальных пользователей кубернетес? У которых кластера от 5 до 20 узлов, и нет денег на специалистов, готовых не только написать IaC сценарий для развертывания кластера, но и регулярно изучать, что новенького появилось в кубе, что изменилось, а что и удалили. И согласно всем этим изменениям поддерживать свой сценарий в актуальном состоянии.
Речь о самом простом способе поднять production-ready кластер. Чтобы человек сразу привыкал к хорошему, а не решал вопросы по «расширяемости»…
Про митоген… Помню эту статью на хабре. Там автор предлагал на каждый чих писать свои модули под ансибль. В итоге вместо описания сценариев на ямле, процесс создания IaC превращался в программирование на питоне. и я предполагаю, что его проблемы были как раз между митогеном и его модулями…
Это я к тому, что запуск кубспрея с митогеном я отлаживал и добавлял. И из всего, что пришлось переделывать — это таски с настройкой coreos-like дистров (использовался модуль raw, чтобы питон туда поставить) и пара тасков с хитрыми delegate_to: внутри циклов с include:
«докер» == «среда контейнеризации» — для краткости речи
latency и iops — это уже к СХД вопросы, а не к манифестам кубернетес.
hostPath категорически рекомендую запрещать в PSP для простых приложений.
Вместо него использовать тома типа LocalVolume
По скорости то же обращение к локальному диску узла, как и hostPath, вот только с без возможности безконтрольного доступа к любому каталогу на узле
Стоит добавить, что есть две аннотации, одна cert-manager.io/cluster-issuer: letsencrypt для clusterIssuer, который умеет запрашивать сертификаты для всех объектов в кластере, и вторая cert-manager.io/issuer: letsencrypt для issuer, который только в своем namespace работает.
Ситуация, когда поставили cert-manager, создали ClusterIssuer, а в аннотации написали просто issuer и ничего не работает — очень часто бывают
пиши в форме 09.03.01
В переводе - 'связано с ограничением записи кэша файловой системы ext4'
В оригинале - 'was attributed to ext4 file system’s write barrier cache commits.'
write barrier хорошо гуглится: https://www.kernel.org/doc/Documentation/filesystems/ext4.tx
Для отключения надо добавить опцию монтирования
calico — достаточно просто и универсально. Выбирай в остальных случаях
cillium — обменять +200 к сложности на +1% к скорости. Явно не для новичка выбор
Идеальный разработчик — это не тот, кто заявляет — у меня на ноуте все работает, а на сервере пусть админы чинят.
А человек, который понимает как использовать преимущества и обходить ограничения:
— контейнеров
— оркестратора контейнеров
— требований безопасности
— и т.д. и т.п.
Разработчик, который хочет просто кодить алгоритмы — не самый востребованный специалист на рынке труда.
iptables создают kube-proxy и CNI plugin
Уменшить их количество можно переключив kube-proxy на режим ipvs
или выбрать CNI plugin типа cilum, который использует eBPF — но тут надо понимать что вы делаете, а не бездумно следовать советам из интернета
На работу продакшена, который был задеплоен в кластере обычно это не влияет.
Хотя в этот раз с exec probe получилось не очень хорошо )
Как минимум кубспрей умеет не только в докер, но и containerd и crio, причем сам ставит, а не требует готовый.
Плюс более удобный подход к запуску контрол-плейна.
kubectl get pod -n kube-system покажет api, cm, scheduler… и логи их так же можно посмотреть. Плюс у кублетов можно динамические конфиги использовать.
ну и там еще много всего, но это уже относится к косякам rke, типа хранения приватного ключа от корневого сертификата кластера в конфигмапе.
в kubeadm народ заморачивался, писал специальный код, который генерил секреты с TTL 1 час, клал в эти секреты сертификаты, дополнительно их шифровал… и все это для того, чтобы передать серты на второй и третий мастера при HA-сетапе…
а в rke ребята простые…
По поводу etcd_ionice. Тут да, мой косяк, не уследил за тем, что в контейнерах etcd v3.4.x выпилили бинариник ionice, и я уже убрал эту опцию из своего форка и готовлю PR в основной кубспрей.
Насчет целевой аудитории — Вы как-то резковато обратились только к граничным случаям:
— для поиграться
— и для реально здоровых в хотя бы 100 узлов…
А как же остальные 90% реальных пользователей кубернетес? У которых кластера от 5 до 20 узлов, и нет денег на специалистов, готовых не только написать IaC сценарий для развертывания кластера, но и регулярно изучать, что новенького появилось в кубе, что изменилось, а что и удалили. И согласно всем этим изменениям поддерживать свой сценарий в актуальном состоянии.
Лично я думаю, что версия 3.0 будет не совместима с 2.X ;)
Человек, который знает про cri-o и containerd и чем они отличаются от докера — сложно назвать новичком.
Речь о самом простом способе поднять production-ready кластер. Чтобы человек сразу привыкал к хорошему, а не решал вопросы по «расширяемости»…
Про митоген… Помню эту статью на хабре. Там автор предлагал на каждый чих писать свои модули под ансибль. В итоге вместо описания сценариев на ямле, процесс создания IaC превращался в программирование на питоне. и я предполагаю, что его проблемы были как раз между митогеном и его модулями…
Это я к тому, что запуск кубспрея с митогеном я отлаживал и добавлял. И из всего, что пришлось переделывать — это таски с настройкой coreos-like дистров (использовался модуль raw, чтобы питон туда поставить) и пара тасков с хитрыми delegate_to: внутри циклов с include:
«докер» == «среда контейнеризации» — для краткости речи
hostPath категорически рекомендую запрещать в PSP для простых приложений.
Вместо него использовать тома типа LocalVolume
По скорости то же обращение к локальному диску узла, как и hostPath, вот только с без возможности безконтрольного доступа к любому каталогу на узле
упоминать версии 2.1 и 2.4 — как то странно в 2020 году…
Про митоген ни слова ;)
Ну и общее впечатление — хотите использовать ансибль — изучите питон, напишите свой модуль, и через ансибль передайте в него параметры.
cert-manager.io/cluster-issuer: letsencryptдля clusterIssuer, который умеет запрашивать сертификаты для всех объектов в кластере, и втораяcert-manager.io/issuer: letsencryptдля issuer, который только в своем namespace работает.Ситуация, когда поставили cert-manager, создали ClusterIssuer, а в аннотации написали просто issuer и ничего не работает — очень часто бывают
Часть вебинаров планируем выложить на ютуб
PS: А фича классная. Полностью согласен, что стоит о ней рассказывать при любом удобном случае… ;)