В этой статье мы разберем основные компоненты Kubernetes, с которыми мы, администраторы или пользователи Kubernetes, будем работать большую часть времени.
Вам не придется иметь дело непосредственно с Docker или любой другой контейнерной технологией в Kubernetes. Вы взаимодействуете только с уровнем Kubernetes.
ПРИМЕЧАНИЕ: Главный узел Kubernetes теперь называется Control Plane (плоскость управления).
Под
Pod — это наименьшая возможная единица в Kubernetes, так же как Container — наименьшая единица в Docker. Контейнер создается внутри Pod. Также существуют общие тома и общие сетевые ресурсы, например, IP-адрес.
Каждый раз, когда мы создаем контейнер в Kubernetes, мы фактически создаем нечто под названием Pod, а внутри этого Pod находится наш контейнер.
Поэтому, когда вы думаете о Kubernetes, вы думаете о Pod как о контейнерах, но технически контейнеры находятся внутри Pod, а также вы можете иметь несколько контейнеров внутри этих Pod, но обычно вы имеете один контейнер внутри одного Pod.
Каждый Pod в Kubernetes имеет свой собственный IP-адрес, через который каждый Pod может общаться друг с другом, используя IP-адрес, который является внутренним IP-адресом, а не публичным IP-адресом. Помните, что IP-адрес получает именно узел, а не контейнер.
Вот пример узла, имеющего два Pod:
Также важной концепцией является то, что Pods являются эфемерными, что означает, что они могут очень легко умереть, и когда это произойдет, например, если мы потеряем наш контейнер базы данных из-за сбоя контейнера из-за сбоя приложения внутри или закончились ресурсы узлов или сервера, на котором мы их запускаем, Pods умрет и на его месте будет создан новый, и когда это произойдет, ему будет присвоен новый IP-адрес, что, очевидно, неудобно, если вы общаетесь с базой данных, используя IP-адрес, потому что вам придется настраивать его каждый раз, когда Pod перезапускается, и поэтому используется другой компонент Kubernetes под названием Service.
Сервис
Сервис — это, по сути, статический IP-адрес или постоянный IP-адрес, который может быть прикреплен, скажем, к каждому Pod. Так в примере выше у my-app будет своя служба, а у базы данных будет своя служба, и хорошо то, что жизненный цикл службы и pod не связаны, так что даже если Pods умрет, служба и ее IP-адрес останутся. Поэтому вам больше не придется менять конечную точку.
Итак, теперь вы хотите, чтобы ваше приложение было доступно через браузер, и для этого вам нужно создать внешнюю службу.
Внешняя служба — это служба, которая открывает связь с внешними источниками, но, очевидно, вы не хотите, чтобы ваша база данных была открыта для публичных запросов, и для этого вы должны создать нечто, называемое внутренней службой.
Внутренняя служба — это тип службы, который вы указываете при создании.
Ingress
Поскольку URL внешней службы, http://116.69.103.5:8080, не очень практичен, все, что у вас есть, это протокол http с IP-адресом узла (IP-адрес узла, а не службы) и номером порта службы. Это для тестовых целей, если вы хотите что-то протестировать, но не для конечных продуктов.
В результате, если вы хотите общаться с вашим приложением, используя безопасный протокол и доменное имя, ваш URL обычно должен выглядеть следующим образом: «https://myUrl.com».
Здесь мы используем другой компонент Kubernetes под названием Ingress.
Таким образом, вместо сервиса запрос сначала идет к Ingress, а он выполняет пересылку к сервису.
ConfigMap
Мы знаем, что модули взаимодействуют друг с другом с помощью сервиса, поэтому у нашего приложения будет конечная точка базы данных, скажем, mongo-db-service, которую оно использует для связи с базой данных.
Где вы настраиваете этот URL базы данных или конечную точку?
Обычно это делается в файле свойств приложения или в какой-либо внешней переменной окружения, но обычно это происходит внутри собранного образа приложения.
Например, если конечная точка сервиса, или имя сервиса в данном случае, изменилось на mongo-db, вам придется изменить URL в приложении, что обычно означает пересоздание приложения с новой версией, занесение ее в репозиторий, а затем извлечение нового образа в ваш pod и перезапуск всего.
Это немного утомительно для такого небольшого изменения, как URL базы данных.
Поэтому для этой цели в Kubernetes есть компонент под названием ConfigMap.
ConfigMap — это внешняя конфигурация вашего приложения, поэтому ConfigMap обычно содержит данные конфигурации, такие как URL базы данных или других сервисов, которые вы используете, а в Kubernetes вы просто подключаете его к Pod, чтобы Pod действительно получил данные, которые содержит ConfigMap.
Таким образом, если вы меняете имя сервиса или конечную точку сервиса, вам нужно только отредактировать ConfigMap; вам не нужно создавать новый образ или проходить весь цикл.
Секрет
Имя пользователя и пароль базы данных также могут быть частью внешней конфигурации, которая может меняться в процессе развертывания приложения, но размещение пароля или других учетных данных в ConfigMap в формате обычного текста будет небезопасным, даже если это внешняя конфигурация, поэтому для этих целей в Kubernetes есть другой компонент, называемый Secret.
Secret похож на ConfigMap, но разница в том, что он используется для хранения секретных данных, таких как учетные данные, и хранится в кодированном формате Base64, а не в виде обычного текста. Однако такой формат не делает его автоматически безопасным; секретные элементы должны быть зашифрованы с помощью сторонних инструментов в Kubernetes.
Как и ConfigMap, вы связываете его с вашим Pod, чтобы он мог просматривать и читать данные из Secret.
Вы можете использовать данные из ConfigMap или Secret внутри вашего приложения Pod, например, как переменные среды или даже как файл свойств.
В следующей статье мы рассмотрим концепцию хранения данных в Kubernetes и увидим, как она работает.
Спасибо, что прочитали этот блог; следите за моими новыми блогами.