Kubernetes блог

Одной из самых больших проблем при разработке собственных облачных приложений сегодня является ускорение числа ваших развертываний. Используя микросервисный подход, разработчики уже работают и разрабатывают полностью модульные приложения, которые позволяют нескольким группам одновременно писать и развертывать изменения в приложении. Более короткие и частые развертывания предлагают следующие преимущества: Сокращение времени выхода на рынок. Клиенты могут воспользоваться функциями быстрее. Отзывы клиентов быстрее возвращаются в группу разработчиков продукта, а это означает, что группа может быстрее перебирать функции и исправлять проблемы. Более высокий моральный дух разработчика с большим количеством функций в продакшн среде. Но с более частыми релизами шансы негативно повлиять на надежность приложений или качество обслуживания клиентов также могут возрасти. Вот почему для операций и команд DevOps важно разрабатывать процессы и управлять стратегиями развертывания, которые миними...

Модель Kubernetes для соединения контейнеров Теперь, когда у вас есть постоянно работающее, реплицируемое приложение, вы можете открыть его в сети. Прежде чем обсуждать подход Kubernetes к созданию сетей, стоит сравнить его с "обычным" способом работы сетей с Docker. По умолчанию Docker использует частную сеть, поэтому контейнеры могут общаться с другими контейнерами, только если они находятся на одной машине. Чтобы контейнеры Docker могли обмениваться данными между узлами, на собственном IP-адресе машины должны быть выделены порты, которые затем перенаправляются или передаются в контейнеры. Это, очевидно, означает, что контейнеры должны либо координировать, какие порты они используют очень осторожно, либо порты должны распределяться динамически. Координировать порты между несколькими разработчиками очень сложно в масштабе, и пользователи подвергаются проблемам уровня кластера вне их контроля. Kubernetes предполагает, что Pod'ы могут общаться с другими Pod'ами, нез...

В этом посте представлен обзор поддержки DNS в Kubernetes . Kubernetes DNS планирует Pod и сервис DNS в кластере и настраивает kubelet'ы для указания отдельным контейнерам использовать IP-адрес сервиса DNS для разрешения имен DNS. Какие объекты получают DNS-имена? Каждому сервису, определенному в кластере (включая сам DNS-сервер), присваивается имя DNS. По умолчанию в список поиска DNS клиентского Pod'а будет входить собственное пространство имен Pod'а и домен кластера по умолчанию. Это лучше всего иллюстрируется примером: Предположим, что сервис называется foo в пространстве имен Kubernetes bar. Pod, работающий в пространстве имен bar, может найти этот сервис, просто выполнив DNS-запрос для foo. Pod, работающий в пространстве имен quux, может найти этот сервис, выполнив DNS-запрос для foo.bar. В следующих разделах подробно описаны поддерживаемые типы записей и поддерживаемый макет (layout). Любой другой макет (layout), имена или запросы, которые работают, считаются де...

В данном посте описаны некоторые особенности, использованные в реализации виртуального IP для сервисов. Избегать коллизий Одна из основных философий Kubernetes - то, что вы не должны подвергаться ситуациям, которые могут привести к тому, что ваши действия потерпят неудачу не по вашей вине. Для дизайна ресурса Сервис это означает не заставлять вас выбирать свой собственный номер порта, если этот выбор может вступить в конфликт с выбором другого. Это ошибка изоляции. Чтобы позволить вам выбрать номер порта для ваших Сервисов, мы должны убедиться, что никакие два Сервиса не могут конфликтовать. Kubernetes делает это, выделяя каждому сервису свой IP-адрес. Чтобы гарантировать, что каждый сервис получает уникальный IP-адрес, внутренний распределитель автоматически обновляет глобальную карту размещения в etcd перед созданием каждого сервиса. Объект карты должен существовать в реестре, чтобы сервисы могли получать назначения IP-адресов, в противном случае создание завершится неудачно с со...

Для некоторых частей вашего приложения (например, фронтендов) вы можете захотеть предоставить Сервису внешний IP-адрес, который находится за пределами вашего кластера. Kubernetes ServiceTypes (типы сервисов) позволяют вам указать, какой тип сервиса вы хотите. По умолчанию используется ClusterIP. Значения Type (типа) сервиса и их поведение: ClusterIP : Предоставляет Сервису внутренний IP-адрес кластера. Выбор этого значения делает Сервис доступным только из кластера. Это ServiceType (тип сервиса) по умолчанию. NodePort : Предоставляет Сервис для каждого IP-адреса узла по статическому порту (NodePort). Сервис ClusterIP, к которой направляется сервис NodePort, создается автоматически. Вы сможете связаться с NodePort сервисом из-за пределов кластера, запросив <NodeIP>:<NodePort>. LoadBalancer : предоставляет сервис извне, используя балансировщик нагрузки облачного провайдера. Службы NodePort и ClusterIP, к которым создаются внешние маршруты балансировки нагрузки, создают...

Многопортовые Сервисы Для некоторых сервисов вам нужно предоставить более одного порта. Kubernetes позволяет настроить несколько определений портов для объекта Service. При использовании нескольких портов для Сервиса вы должны указать все имена портов, чтобы они были однозначными. Например: apiVersion: v1 kind: Service metadata: name: my-service spec: selector: app: MyApp ports: - name: http protocol: TCP port: 80 targetPort: 9376 - name: https protocol: TCP port: 443 targetPort: 9377 Примечание: Как и в случае с именами Kubernetes, имена портов должны содержать только строчные буквенно-цифровые символы и - (дефисы). Имена портов также должны начинаться и заканчиваться буквенно-цифровым символом. Например, имена 123-abc и web действительны, а 123_abc и -web - нет. Выбирая свой собственный IP-адрес Вы можете указать свой собственный IP-адрес кластера как часть запроса на создание Сервиса. Для этого установите поле .spec.cl...

Каждый узел в кластере Kubernetes запускает kube-proxy. kube-proxy отвечает за реализацию формы виртуального IP для Сервисов типа, отличного от ExternalName. Почему бы не использовать циклический DNS (round-robin DNS)? Время от времени возникает вопрос, почему Kubernetes использует прокси для пересылки входящего трафика на бэкенды. А как насчет других подходов? Например, можно ли настроить записи DNS, которые имеют несколько значений A (или AAAA для IPv6), и полагаться на разрешение имен циклическим перебором (round-robin)? Существует несколько причин использования прокси для Сервисов: Существует долгая история реализаций DNS, не учитывающих TTL записей и кэширующих результаты поиска имен после того, как они истекли. Некоторые приложения выполняют поиск DNS только один раз и кэшируют результаты на неопределенный срок. Даже если приложения и библиотеки выполнили правильное переразрешение, низкие или нулевые значения TTL в записях DNS могут вызвать высокую нагрузку на DNS, которой...

Сервис (Service) - это абстрактный способ представить приложение, работающее на множестве Pod'ов, как сетевой сервис. С Kubernetes вам не нужно изменять свое приложение, чтобы использовать незнакомый механизм обнаружения сервисов. Kubernetes предоставляет Pod'у свои собственные IP-адреса и одно DNS-имя для набора Pod'ов и может распределять нагрузку между ними. Причины появления сервисов Pod'ы Kubernetes смертны. Они рождаются, а когда они умирают, они не воскресают. Если вы используете Deployment для запуска своего приложения, он может динамически создавать и уничтожать Pod'ы. Каждый Pod получает свой собственный IP-адрес, однако в Deployment набор Pod'ов, работающих в один момент времени, может отличаться от набора Pod'ов, запускающих это приложение через мгновение. Это приводит к проблеме: если некоторый набор Pod'ов (назовем их "бэкэндами") предоставляет функциональные возможности другим Pod'ам (назовем их "фронтендами")...

Cron Job создает Job'ы по расписанию. Один объект CronJob похож на одну строку файла crontab (таблицы cron). Он запускает работу периодически по заданному расписанию, написанному в формате Cron. Примечание. Все расписание CronJob: время основано на часовом поясе мастера, в котором запущено задание. Ограничения Cron Job Cron Job создает объект Job примерно один раз за время выполнения своего расписания. "Примерно", потому что есть определенные обстоятельства, когда могут быть созданы два Job, или Job не может быть создан. Поэтому Job'ы должны быть идемпотентными. Если для startDeadlineSeconds задано большое значение или не задано значение (по умолчанию), а для параметра concurrencyPolicy задано значение Allow, Job'ы всегда будут запускаться хотя бы один раз. Для каждого CronJob Контроллер CronJob проверяет, сколько расписаний он пропустил за время с его последнего запланированного времени до настоящего времени. Если пропущено более 100 расписаний, Job не зап...

Написание спецификации Job Как и во всех других конфигурациях Kubernetes, для работы требуются поля apiVersion, kind и metadata. Job также нуждается в разделе .spec. Pod шаблон .spec.template является единственным обязательным полем .spec. .spec.template является шаблоном pod. У него точно такая же схема, что и у pod, за исключением того, что он вложенный и не имеет apiVersion или kind. В дополнение к полям, обязательным для Pod, в шаблоне Pod в Job должны быть указаны соответствующие метки и соответствующая политика перезапуска. Разрешается только RestartPolicy, равное Never или OnFailure. Pod селектор Поле .spec.selector является необязательным. Почти во всех случаях вы не должны указывать это. Параллельные Job Существует три основных типа заданий, подходящих для выполнения Job: Непараллельные Job Обычно запускается только один Pod, если он не вышел из строя. Job завершается, как только его Pod успешно завершается. Параллельные Job с фиксированным количеством зав...