Если спросить опытного многомудрого инженера, что он думает о cert-manager и почему все им пользуются, то спец вздохнёт, доверительно обнимет и устало скажет: «Все им пользуются, потому что нет альтернатив вменяемых. Наши мыши плачут, колются, но продолжают жить с этим кактусом. Почему любим? Потому что работает. Почему не любим? Потому что постоянно выходят новые версии, которые используют новые фичи. И приходится раз за разом обновлять кластер. А старые версии перестают работать, потому что заговор есть и великое таинственное шаманство». Но разработчики уверяют, что с cert-manager 1.0 всё изменится. Поверим?  Cert-manager - «родной» контроллер управления сертификатами Kubernetes. С его помощью можно выпустить сертификаты из различных источников: Let's Encrypt, HashiCorp Vault, Venafi, пары ключей для подписи и самоподписанных. Он также позволяет поддерживать ключи актуальными по времени действия, а также пытается автоматически обновлять сертификаты в заданное до их истечения время. Cert-manager основан на kube-lego, а также использовал некоторые приемы из других схожих проектов, например kube-cert-manager. Версией 1.0 мы ставим знак доверия за три года разработки проекта cert-manager. За это время он значительно развился в функциональности и стабильности, но больше всего - в сообществе. Сегодня мы видим, как многие люди используют его для защиты своих кластеров Kubernetes, а также проводят внедрение в различные части экосистемы. В последних 16 выпусках было исправлено куча ошибок. А то, что надо было сломать - сломано. Несколько заходов по работе с API улучшили его взаимодействие с пользователями. Мы решили 1500 проблем на GitHub с еще большим числом запросов на слияние от 253 участников сообщества. Выпуская 1.0 мы официально заявляем, что cert-manager - зрелый проект. Мы также обещаем поддерживать совместимость нашего API v1. Огромная благодарность всем, кто нам помогал делать cert-manager все эти три года! Пусть версия 1.0 станет первым из многих будущих больших достижений. Выпуск 1.0 - стабильный выпуск с несколькими приоритетными направлениями: v1 API; Команда kubectl cert-manager status, для помощи при анализе проблем; Использование новейших стабильных API Kubernetes; Улучшенное журналирование; Улучшения ACME. Перед обновлением обязательно прочитайте примечания к обновлению. Версия v0.16 работала с API v1beta1. Это добавило некоторые структурные изменения, а также улучшило документацию по полям API. Версия 1.0 опирается на это все с помощью API v1. Этот API является нашим первым стабильным, в то же время мы уже давали гарантии совместимости, но с API v1 мы обещаем поддерживать совместимость на годы вперед. Внесенные изменения (примечание: наши средства для конвертирования позаботятся обо всем для вас): Сертификат: emailSANs теперь называется emailAddresses uriSANs - uris Эти изменения добавляют совместимость с другими SAN (subject alt names, прим. переводчика), а также с Go API. Мы убираем этот термин из нашего API. Если вы используете Kubernetes 1.16+ - конвертирующие webhooks позволят вам одновременно и бесшовно  работать с версиями API v1alpha2, v1alpha3, v1beta1 и v1. С их помощью вы сможете использовать новую версию API без изменения или повторного развертывания ваших старых ресурсов. Мы настоятельно рекомендуем выполнить обновление манифестов до API v1, поскольку предыдущие  версии скоро будут объявлены устаревшими. Пользователи legacy версии cert-manager будут по-прежнему иметь доступ только к v1, шаги по обновлению можно найти здесь. C новыми улучшениями в нашем расширении к kubectl стало проще исследовать проблемы, связанные с невыдачей сертификатов. kubectl cert-manager status теперь выдает намного больше информации о том, что происходит с сертификатами, а также показывает этап выдачи сертификата. После установки расширения вы можете запустить kubectl cert-manager status certificate <имя-сертификата>, что приведет к поиску сертификата с указанным именем и любых связанных ресурсов, например CertificateRequest, Secret, Issuer, а также Order и Challenges в случае использования сертификатов от ACME. Пример отладки еще не готового сертификата: Команда также может помочь узнать подробнее о содержимом сертификата. Пример детализации для сертификата, выданного Letsencrypt: Cert-manager был одним из первых, кто внедрил Kubernetes CRDs. Это, а также наша поддержка версий Kubernetes вплоть до 1.11, привели к тому, что нам надо было поддерживать устаревший apiextensions.k8s.io/v1beta1 для наших CRD, а также admissionregistration.k8s.io/v1beta1 для наших webhooks. Сейчас они устарели и будут удалены в Kubernetes с версии 1.22. С нашей 1.0 мы теперь предлагаем полную поддержку apiextensions.k8s.io/v1 и admissionregistration.k8s.io/v1 для Kubernetes 1.16 (где они были добавлены) и новее. Для пользователей предыдущих версий мы продолжаем предлагать поддержку v1beta1 в нашей legacy версии. В этой версии мы обновили библиотеку для журналирования до klog/v2, используемой в Kubernetes 1.19. Мы также проверяем каждый журнал, который пишем, для назначения ему соответствующего уровня. Мы руководствовались при этом руководством от Kubernetes. Есть пять (по факту - шесть, прим. переводчика) уровней журналирования, начиная с Error (уровень 0), который выводит только важные ошибки, и заканчивая Trace (уровень 5), который поможет узнать точно, что происходит. Этим изменением мы сократили количество журналов, если вым не нужна отладочная информация при работе cert-manager. Совет: по-умолчанию cert-manager работает на уровне 2 (Info), вы можете переопределить это используя global.logLevel в Helm chart. Примечание: просмотр журналов - последнее средство при устранении неполадок. Для дополнительной информации ознакомьтесь с нашим руководством.N.B. редактора: Чтобы подробнее узнать, как это всё работает под капотом у Kubernetes, получить ценные советы у практиков-преподавателей, а также качественную помощь техподдержки, можно принять участие в онлайн-интенсивах Kubernetes База, который пройдёт 28-30 сентября, и Kubernetes Мега, который пройдёт 14–16 октября.  Наиболее частое применение cert-manager возможно связано с выпуском сертификатов от Let's Encrypt используя ACME. Версия 1.0 примечательна использованием отзывов от сообщества для добавления двух небольших, но важных улучшений в наш ACME issuer. Если вы используете сертификаты ACME в больших объемах, вы скорее всего используете одну и ту же учетную запись на нескольких кластерах, так что ваши ограничения по выпуску сертификатов будут касаться их всех. Это уже было возможно в cert-manager при копировании секрета, указанного в privateKeySecretRef. Такой вариант использования был достаточно глючный, поскольку cert-manager пытался быть полезным и радостно создавал новый ключ учетной записи, если его не находил. Поэтому мы и добавили disableAccountKeyGeneration, чтобы защитить вас от такого поведения, если установить этот параметр в true - cert-manager не будет создавать ключ и предупредит вас о том, что ему не был предоставлен ключ учетной записи. 29 сентября Let's Encrypt перейдет на собственный корневой центр сертификации ISRG Root. Сертификаты с перекрестными подписями будут заменены на Identrust. Это изменение не требует правок в настройках cert-manager, все обновленные или новые сертификаты, выпущенные после этой даты, будут использовать новый корневой CA. Let's Encrypt уже подписывает сертификаты с помощью этого CA и предлагает их в качестве «альтернативной цепочки сертификатов» через ACME. В этой версии cert-manager есть возможность задания доступа к этим цепочкам в настройках issuer. В параметре preferredChain можно указать имя используемого CA, с помощью которого будет выдан сертификат. Если будет доступен сертификат CA, соотвествующий запросу, он выдаст вам сертификат. Обратите внимание, что это предпочтительный вариант, если ничего не будет найдено - будет выдан сертификат по-умолчанию. Это даст гарантию того, что вы все равно произведете обновление своего сертификата после удаления альтернативной цепочки на стороне ACME issuer. Уже сегодня можно получать сертификаты, подписанные ISRG Root, так: Если вы предпочитаете оставить цепочку IdenTrust - выставляйте этот параметр в DST Root CA X3: Обратите внимание, что этот корневой центр сертификации скоро устареет, Let's Encrypt будет поддерживать эту цепочку активной до 29 сентября 2021 года. Подниматель пингвинов