Серия вебинаров: пристальный взгляд на Кубернетес

Вступление

Kubernetes - инструмент оркестрации контейнеров с открытым исходным кодом для управления контейнеризованными приложениями. В previous учебник в этой серии вы настроили Kubernetes на DigitalOcean. Теперь, когда кластер запущен и работает, вы можете развертывать приложения в контейнерах.

В этом руководстве вы узнаете, как эти примитивы работают вместе, когда вы развертываете Pod в Kubernetes, представляете его как сервис и масштабируете его через контроллер репликации.

Предпосылки

Чтобы завершить этот урок, вы должны сначала завершить предыдущий урок этой серии, Getting Started with Kubernetes.

Шаг 1 - Понимание примитивов Kubernetes

Kubernetes предоставляет API, который клиенты используют для создания, масштабирования и завершения приложений. Каждая операция нацелена на один или несколько объектов, которыми управляет Kubernetes. Эти объекты образуют основные строительные блоки Кубернетеса. Они являются примитивами, с помощью которых вы управляете контейнерными приложениями.

Ниже приводится краткое описание ключевых объектов API Kubernetes:

* Кластеры *: пул вычислительных ресурсов, хранилища и сетевых ресурсов.
* Узлы *: хост-машины, работающие в кластере.
* Пространства имен *: логические разделы кластера.
* Pods *: Единицы развертывания.
* Метки * и * Селекторы *: пары ключ-значение для идентификации и обнаружения службы.
* Услуги *: сбор контейнеров, принадлежащих одному приложению.
* Реплика Set *: Обеспечивает доступность и масштабируемость.
* Развертывание *: управление жизненным циклом приложения.

Давайте посмотрим на это более подробно.

Nodes, которые запускают кластер Kubernetes, также рассматриваются как объекты. Они могут управляться как любые другие объекты API Kubernetes. Чтобы включить логическое разделение приложений, Kubernetes поддерживает создание Namespaces. Например, организация может логически разделить кластер Kubernetes для запуска среды разработки, тестирования, подготовки и производства. Каждую среду можно поместить в выделенное пространство имен, которое управляется независимо. Kubernetes предоставляет свой API через узел Master.

Хотя Kubernetes запускает контейнеры Docker, эти контейнеры не могут быть развернуты напрямую. Вместо этого приложения должны быть упакованы в формате, понятном Kubernetes. Этот формат позволяет Kubernetes эффективно управлять контейнерными приложениями. Эти приложения могут содержать один или несколько контейнеров, которые должны работать вместе.

Фундаментальная единица упаковки и развертывания в Kubernetes называется Pod. Каждый Pod может содержать один или несколько контейнеров, которыми нужно управлять вместе. Например, контейнер веб-сервера (Nginx) и контейнер кеша (Redis) могут быть упакованы вместе как Pod. Kubernetes рассматривает все контейнеры, которые принадлежат Pod, как логическую единицу. Каждый раз, когда создается новый Pod, он приводит к созданию всех контейнеров, объявленных в определении Pod. Все контейнеры в модуле имеют общий контекст, такой как IP-адрес, имя хоста и хранилище. Они связываются друг с другом через межпроцессное взаимодействие (IPC), а не через удаленные вызовы или API REST.

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

Стручки в Kubernetes выставляются через Services. Каждый Сервис объявляется как внутренняя или внешняя конечная точка вместе с информацией о порте и протоколе. Внутренние потребители, в том числе другие модули, и внешние потребители, такие как клиенты API, полагаются на службы Kubernetes для базового взаимодействия. Сервисы поддерживают протоколы TCP и UDP.

Каждый объект в Kubernetes, такой как Pod или Сервис, связан с дополнительными метаданными, называемыми Labels и Selectors. Метки - это пары ключ / значение, прикрепленные к объекту Kubernetes. Эти метки однозначно идентифицируют один или несколько объектов API. Селекторы связывают один объект Kubernetes с другим. Например, селектор, определенный в сервисе, помогает Kubernetes найти все блоки с меткой, соответствующей значению селектора. Эта связь позволяет динамическое обнаружение объектов. Новые объекты, созданные во время выполнения с одинаковыми метками, будут немедленно обнаружены и связаны с соответствующими селекторами. Этот механизм обнаружения услуг обеспечивает эффективную динамическую настройку, например операции масштабирования и масштабирования.

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

Объект Deployment представляет собой комбинацию модулей и наборов реплик. Этот примитив приносит PaaS-подобные возможности в приложения Kubernetes. Это позволяет выполнять непрерывное обновление существующего развертывания с минимальным временем простоя. Развертывания также включают шаблоны, такие как развертывание канареек и сине-зеленые развертывания. Они обрабатывают основные части управления жизненным циклом приложений (ALM) контейнерных приложений.

Шаг 2 - перечисление Kubernetes узлов и пространств имен

Предполагая, что вы выполнили следующие шаги, чтобы set up кластер Kubernetes в DigitalOcean, выполните следующие команды, чтобы получить список всех Узлы и доступные пространства имен:

kubectl get nodes

OutputNAME                  STATUS    ROLES     AGE       VERSION
spc3c97hei-master-1   Ready     master    10m       v1.8.7
spc3c97hei-worker-1   Ready     <none>    4m        v1.8.7
spc3c97hei-worker-2   Ready     <none>    4m        v1.8.7

kubectl get namespaces

OutputNAME                STATUS    AGE
default             Active    11m
kube-public         Active    11m
kube-system         Active    11m
stackpoint-system   Active    4m

Если пространство имен не указано, + kubectl + предназначается для пространства имен по умолчанию.

Теперь давайте запустим приложение.

[[step-3–-creating-and-deploying-a-pod]] === Шаг 3 - Создание и развертывание модуля

Объекты Kubernetes объявляются в файлах YAML и передаются в Kubernetes через CLI + kubectl +. Давайте определим Pod и развернем его.

Создайте новый файл YAML с именем + Simple-Pod.yaml +:

nano Simple-Pod.yaml

Добавьте следующий код, который определяет Pod с одним контейнером на основе веб-сервера Nginx. Он выставлен на порт + 80 + по протоколу TCP. Обратите внимание, что определение содержит метки + name + и + env +. Мы будем использовать эти ярлыки для идентификации и настройки конкретных модулей.

Простой Pod.yaml

apiVersion: "v1"
kind: Pod
metadata:
 name: web-pod
 labels:
   name: web
   env: dev
spec:
 containers:
   - name: myweb
     image: nginx
     ports:
       - containerPort: 80
         name: http
         protocol: TCP

Выполните следующую команду, чтобы создать Pod.

kubectl create -f Simple-Pod.yaml

Outputpod "web-pod" created

Давайте проверим создание Pod.

kubectl get pods

OutputNAME      READY     STATUS    RESTARTS   AGE
web-pod   1/1       Running   0          2m

На следующем шаге мы сделаем этот Pod доступным для общественности.

Шаг 4 - Предоставление стручков через сервис

Сервисы предоставляют набор модулей как внутри, так и снаружи. Давайте определим Сервис, который делает плагин Nginx общедоступным. Мы представим Nginx через NodePort, схему, которая делает Pod доступным через произвольный порт, открытый на каждом узле кластера.

Создайте новый файл с именем + Simple-Service.yaml +, содержащий этот код, который определяет сервис для Nginx:

Простой Service.yaml

apiVersion: v1
kind: Service
metadata:
 name: web-svc
 labels:
   name: web
   env: dev
spec:
 selector:
   name: web
 type: NodePort
 ports:
   - port: 80
     name: http
     targetPort: 80
     protocol: TCP

Служба обнаруживает все модули в одном и том же пространстве имен, которые соответствуют метке с + name: web +. Раздел селектора файла YAML явно определяет эту связь.

Мы указываем, что Сервис имеет тип NodePort через объявление типа: NodePort.

Затем используйте его для отправки в кластер.

kubectl create -f Simple-Service.yml

Вы увидите этот вывод, указывающий, что служба была успешно создана:

Outputservice "web-svc" created

Давайте получим порт, на котором доступен Pod.

kubectl get services

OutputNAME         TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)        AGE
kubernetes   ClusterIP   10.3.0.1     <none>        443/TCP        28m
     NodePort    10.3.0.143   <none>        80:32097/TCP   38s

Из этого вывода мы видим, что Сервис доступен через порт + 32097 +. Давайте попробуем подключиться к одному из рабочих узлов.

Используйте консоль DigitalOcean для получения IP-адреса одного из рабочих узлов.

изображение: https: //assets.digitalocean.com/articles/webinar_4_kubernetes_closer_look/kB9HmSK.png [Капли в консоли DigitalOcean, связанные с вашим кластером Kubernetes.]

Используйте команду + curl +, чтобы сделать HTTP-запрос к одному из узлов порта + 31930 +.

curl http://:32097

Вы увидите ответ, содержащий домашнюю страницу Nginx по умолчанию:

Output<!DOCTYPE html>
<html>
 <head>
   <title>Welcome to nginx!</title>
...
    Commercial support is available at
    <a href="http://nginx.com/">nginx.com</a>.</p>
   <p><em>Thank you for using nginx.</em></p>
 </body>
</html>

Вы определили Pod и Сервис. Теперь давайте посмотрим на масштабирование с помощью наборов реплик.

Шаг 5 - Масштабирование модулей через набор реплик

Набор реплик гарантирует, что в кластере запущено как минимум минимальное количество модулей. Давайте удалим текущий Pod и заново создадим три Pod через набор реплик.

Сначала удалите существующий Pod.

kubectl delete pod web-pod

Outputpod "web-pod" deleted

Теперь создайте новое объявление набора реплик. Определение набора реплик идентично стручку. Основное отличие состоит в том, что он содержит элемент реплики, который определяет количество модулей, которые необходимо запустить. Как и Pod, он также содержит метки как метаданные, которые помогают в обнаружении сервиса.

Создайте файл + Simple-RS.yml + и добавьте этот код в файл:

Простой RS.yml

apiVersion: apps/v1beta2
kind: ReplicaSet
metadata:
 name: web-rs
 labels:
   name: web
   env: dev
spec:
 replicas: 3
 selector:
   matchLabels:
     name: web
 template:
   metadata:
     labels:
       name: web
       env: dev
   spec:
     containers:
     - name: myweb
       image: nginx
         ports:
           - containerPort: 80
             name: http
             protocol: TCP

Сохраните и закройте файл.

Теперь создайте набор реплик:

kubectl create -f Simple-RS.yml

Outputreplicaset "web-rs" created

Затем проверьте количество стручков:

kubectl get pods

OutputNAME           READY     STATUS    RESTARTS   AGE
web-rs-htb58   1/1       Running   0          38s
web-rs-khtld   1/1       Running   0          38s
web-rs-p5lzg   1/1       Running   0          38s

Когда мы получаем доступ к Сервису через NodePort, запрос будет отправлен одному из модулей, управляемых набором реплик.

Давайте проверим функциональность набора реплик, удалив один из модулей и посмотрев, что произойдет:

kubectl delete pod web-rs-p5lzg

Outputpod "web-rs-p5lzg" deleted

Посмотрите на стручки снова:

kubectl get pods

OutputNAME           READY     STATUS              RESTARTS   AGE
web-rs-htb58   1/1       Running             0          2m
web-rs-khtld   1/1       Running             0          2m

web-rs-p5lzg   1/1       Running             0          2m
web-rs-p5lzg   0/1       Terminating         0          2m

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

Теперь давайте посмотрим на развертывания.

Шаг 6 - Работа с развертываниями

Хотя вы можете развертывать контейнеры как Pod и наборы реплик, Deployments упрощают обновление и исправление вашего приложения. Вы можете обновить модуль на месте с помощью развертывания, чего нельзя сделать с помощью набора реплик. Это позволяет выкатить новую версию приложения с минимальным временем простоя. Они предоставляют PaaS-подобные возможности для управления приложениями.

Удалите существующий набор реплик перед созданием развертывания. Это также удалит связанные блоки:

kubectl delete rs web-rs

Outputreplicaset "web-rs" deleted

Теперь определите новое развертывание. Создайте файл + Simple-Deployment.yaml + и добавьте следующий код:

Простой Deployment.yaml

apiVersion: apps/v1beta2
kind: Deployment
metadata:
 name: web-dep
 labels:
   name: web
   env: dev
spec:
 replicas: 3
 selector:
   matchLabels:
     name: web
 template:
   metadata:
     labels:
       name: web
   spec:
     containers:
     - name: myweb
       image: nginx
       ports:
       - containerPort: 80

Создайте развертывание и проверьте его создание.

kubectl create -f Simple-Deployment.yml

Outputdeployment "web-dep" created

Просмотр развертываний:

kubectl get deployments

OutputNAME      DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
web-dep   3         3         3            3           1m

Поскольку развертывание приводит к созданию модулей, в соответствии с объявлением реплик в файле YAML будет запущено три модуля.

kubectl get pods

OutputNAME                       READY     STATUS    RESTARTS   AGE
web-dep-8594f5c765-5wmrb   1/1       Running   0          2m
web-dep-8594f5c765-6cbsr   1/1       Running   0          2m
web-dep-8594f5c765-sczf8   1/1       Running   0          2m

Сервис, который мы создали ранее, продолжит направлять запросы к Блокам, созданным Развертыванием. Это связано с тем, что метки содержат те же значения, что и исходное определение Pod.

Очистите ресурсы, удалив Развертывание и Сервис.

kubectl delete deployment web-dep

Outputdeployment "web-dep" deleted

kubectl delete service web-svc

Outputservice "web-svc" deleted

Более подробную информацию о развертываниях см. В документации Kubernetes.

Заключение

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

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

TOC