Kubernetes *

Недавно мы создали распределенную систему планирования cron-заданий на основе Kubernetes – захватывающей новой платформы для управления кластером контейнеров. Сейчас Kubernetes занимает лидирующие позиции и предлагает множество интересных решений. Одно из основных его достоинств – то, что инженерам не нужно знать, на каких машинах работают их приложения.
Распределенные системы по-настоящему сложны, и управление их службами – одна из самых больших проблем, с которыми сталкиваются операционные группы. Внедрить новое программное обеспечение в производство и научиться надежно управлять им – задача, к которой стоит относиться серьезно. Чтобы понять, почему обучение работе с Kubernetes важно (и почему это сложно!), мы предлагаем ознакомиться с фантастическим одночасовым переключением, вызванным ошибкой в Kubernetes.

В этой статье объясняется, почему мы решили построить архитектуру на Kubernetes. Мы расскажем, как проходила интеграция Kubernetes в существующую инфраструктуру, приведем подход к построению (и улучшению) доверия надежности кластера Kubernetes, а также рассмотрим абстракции, которые мы реализовали над Kubernetes.

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

Сеть подов в кластере – аккуратный материал, но сам по себе он недостаточен для создания долгосрочных систем, поскольку поды в Kubernetes эфемерны. В качестве конечной точки можно использовать IP-адрес пода, но нет гарантии, что при следующем воссоздании пода адрес останется прежним. Его смена может произойти по любой причине.

192.168.20.10 k8s-m1.me
192.168.20.11 k8s-m2.me
192.168.20.12 k8s-m3.me
192.168.20.13 k8s-s1.me
192.168.20.14 k8s-s2.me

Azure Container Instances (ACI) позволяют запускать контейнеры, не беспокоясь об инфраструктуре. Мы можем дать образ контейнера, и ACI с радостью запустит контейнер и даже обеспечит внешним IP-адресом. Когда ручное вмешательство необходимо только при запуске контейнеров, это называется «беcсерверные контейнеры». ACI отлично подходит для пакетных рабочих нагрузок или долгосрочных контейнеров, где мы не хотим иметь дело с инфраструктурой.

kubectl run --image=nginx --replicas=3

Как начать пользоваться terraform, развернув локально приложение поверх minikube, и потом запустить его поверх kubernetes в cloud.google.com