Всем привет. Меня зовут Добрый Кот Telegram.

В этой статье расскажем, как развернуть кластер нашим модулем terraform в Yandex Cloud.

От коллектива FR-Solutions и при поддержке @irbgeo Telegram : Продолжаем серию статей о K8S.

Всем привет. Меня зовут Добрый Кот Telegram.

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

Вошли и вышли, приключение на 20 минут)

От коллектива FR-Solutions и при поддержке @irbgeo Telegram : Продолжаем серию статей о K8S.

Заблуждение 1. В сутках 24 часа или 86 400 секунд

Развёртывать микросервисы на сервере — то ещё удовольствие, даже с Kubernetes. К тому же Kubernetes не занимается коммуникациями между сервисами. Для этой задачи мы привлекаем Istio — реализацию service mesh.

В Kubernetes мы развёртываем сервисы в подах, но как поды внутри Kubernetes общаются друг с другом и в чём тут загвоздка? Разберемся в этой статье. 

Появление Docker привело к взрывному росту популярности контейнеров, но с тех пор появились и другие инструменты. К сожалению, разобраться в них может быть совсем непросто. Но мы попробуем! И если вы считаете себя единственным, кто всего этого пока не понимает, не волнуйтесь... Это не так!

Kubernetes произвел настоящую революцию в распределенных вычислениях. Хотя он решает ряд сверхсложных проблем, появляются и новые вызовы. Одна из таких проблем - обеспечение того, чтобы кластеры Kubernetes были спроектированы с учетом доменов отказов. Проектирование с учетом доменов отказов включает в себя такие аспекты, как предоставление инфраструктуры в зонах доступности, обеспечение того, чтобы физические серверы находились на разных стойках, также необходимо убедиться, что поды, поддерживающие ваше приложение, не окажутся в одном и том же физическом воркере Kubernetes.

Для решения последней задачи можно использовать правила совместного или раздельного существования между подами (inter-pod affinity and anti-affinity rules), и в официальной документации Kubernetes они описаны очень хорошо:

“Сходство между подами (inter-pod affinity) и анти-сходство (anti-affinity) позволяет вам ограничивать, на каких узлах может быть запланирован ваш под, основываясь на метках подов, которые уже запущены на узле, а не на основе меток на узлах. Правила имеют вид "этот под должен (или, в случае anti-affinity, не должен) работать на узле X, если на этом X уже работает один или несколько подов, удовлетворяющих правилу Y". Y выражается как LabelSelector с опциональным ассоциированным списком пространств имен; в отличие от узлов, поскольку поды разделены по именам (и поэтому метки на поды также неявно разделены по именам), селектор меток  должен указать, к каким пространствам имен он должен применяться. Концептуально X - это домен топологии, такой как узел, стойка, зона облачного провайдера, регион облачного провайдера и т. д. Вы выражаете его с помощью topologyKey, который является ключом для метки узла, используемой системой для обозначения такого топологического домена; например, см. ключи меток, перечисленные выше в разделе "Интерлюдия: встроенные метки узлов".

Безопасное хранение и передача секретов (токенов, паролей и т.п.) между пользователями и сервисами – это один из вызовов, с которыми сталкиваются разработчики и DevOps инженеры. Традиционные централизованное хранение в менеджерах паролей, например, полностью проблему не решает, а лишь смещает её в сторону управления мастер-паролями, которые, к тому же, становятся «ключами к царству» и компрометация которых может иметь катастрофические последствия. Данную проблему «курицы и яйца» ещё иногда называют проблемой «нулевого секрета» (Secret Zero Problem). В этой заметке я расскажу о попытке решить эту проблему при помощи механизма обёртки ответа (Response Wrapping).

Let's Encrypt — это центр сертификации, который предоставляет бесплатные сертификаты в полностью автоматизированном процессе. Эти сертификаты выдаются по протоколу ACME. За последние два года в Интернете широко использовалась технология Let’s Encrypt — более 50% веб-сертификатов SSL / TLS теперь выдает Let’s Encrypt.

В этом посте описывается, как выдавать сертификаты Let's Encrypt для внутренних серверов.

Kubernetes Nginx Ingress: перенаправление трафика с использованием аннотаций

Перенаправляйте HTTP-трафик или переписывайте URL-адреса с помощью входных аннотаций Kubernetes и Nginx ingress controller. В этой статье объясняется использование аннотаций и их влияние на результирующий файл конфигурации nginx.conf.

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

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

Управление приложениями — сложный аспект Kubernetes. Helm значительно упрощает его, предоставляя единый метод упаковки программного обеспечения, поддерживающий контроль версий. Helm устанавливает пакеты (называются Чартами в Helm) для Kubernetes и управляет ими, как это делают yum и apt.

В этом руководстве мы позволим Helm создать для нас базовый чарт. В этом руководстве предполагается, что у вас есть хотя бы базовое понимание того, что такое Helm. Если вы не знакомы с ним, я предлагаю вам ознакомиться с этим руководством, прежде чем приступить к статье: https://www.alibabacloud.com/help/doc-detail/86511.htm

Советы по созданию операторов уровня продакшена с помощью Kubebuilder.

В этой статье рассматривается простой пример оператора для сценария автоматического создания ServiceAccount и ClusterRoleBinding с помощьюKubebuilder.

Существует множество альтернатив для доступа к модулю извне кластера. Шлюз API - это определенно новинка этой области, и потому выбран темой этой статьи.

Ранее мы описывали несколько способов доступа к модулям Kubernetes. Так, например, доступ к модулю pods можно получить через его IP-адрес, но важно учитывать, что поды по своей сути являются временными. Штатный способ - настроить Service: в этом случае IP-адрес стабилен, а задача Kubernetes - обеспечивать мапироание между Service и соответствующими ей подами. В настоящий момент доступны различные виды сервисов: только внутренние, NodePort, позволяющий открыть доступа извне кластера, и LoadBalancer, который полагается на сторонний компонент - обычно это на облачный провайдер. Не будем забывать и об Ingress, обеспечивающем маршрутизацию.

Ну а API-шлюз, как новинку в этой области, мы оставили на десерт, решив посвятить ему целый пост.

В Kubernetes есть механизм проверки работоспособности, с помощью которого можно узнать, работает контейнер в pod’е или нет. В этой статье поговорим про 3 вида проверок работоспособности kubelet: пробу запуска (startup),пробу работоспособности (liveness) и пробу готовности (readiness).