Понимание Kubernetes: Руководство разработчика

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

• Почему kubernetes
• Основные понятия
• Minikube
• Kubernetes объекты
• Узоры и антипаттерны
• Kubernetes в облаке — EKS
• Kubectl
• Microk8s
• Вопросы интервью

Почему? $%^#

Это была моя первая мысль, когда я читал о Kubernetes. Зачем нам такие сложные системы? Простого Java -Jar достаточно, чтобы запустить мой микросервис на сервере Linux! Я пишу хороший код. Я справляюсь со всеми исключениями. Я уверен, что ничто не пройдет. Даже если это не удастся, я могу написать простой сценарий Bash, который заботится о перезапуске моего сервиса. Мой код может позаботиться о горизонтальном масштабировании и отказах. У меня хороший брандмауэр и фреймворки. И все это требует лишь нескольких строк дополнительного кода — упакованного в простую банку, которую я включаю во все свои микросервисы. Почему я должен тратить драгоценные вычисления и время и ресурсы на такие сумасшедшие вещи? Честно говоря, я все еще чувствую то же самое.

Многие системы действительно не нужны Kubernetes. Но некоторые системы делают. Для приложений по масштабе критического предприятия, где время простоя может быть дорогостоящим, нам нужно больше, чем просто внутренняя библиотека — чтобы позаботиться об оркестровании услуг. Мы склонны недооценивать уровень упрочнения и устойчивости, которые нам нужны для таких приложений. И это невозможно или стоит усилий, если мы выберемся из -за переосмысления колеса для каждого применения в мире. Нам нужна система, которая проверяется и затвердевает разработчиками по всему миру. И это Kubernetes.

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

Kubernetes начался как Hedty Multi Node Application. Но его популярность и удобство использования привели к нескольким вариантам, таким как Minikube (для одного ПК) и Microk8s (IoT). Kubernetes не ограничивается приложениями PETA Scale. Он нашел свой путь в различные другие платформы и архитектуры.

Простой поиск в Google покажет нам — «Kubernetes — это портативный, расширяемый инструмент оркестровки с открытым исходным кодом». Это звучит круто — не так ли? Мы только что очистили первый вопрос интервью. Давайте теперь посмотрим на остальных.

Простыми словами

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

Каждый сервер называется Узел Анкет У нас есть Мастер -узлы и Рабочие узлы Анкет Как следует из имен, мастер позаботится об оркестровке, и работник — это то, что действительно справляется с работой. Kubernetes не требует этого различия. У нас могут быть компоненты мастер -узла, работающие на рабочих узлах. Но это хорошая практика, чтобы разделить их.

Очевидно, что Master Node является основным компонентом, и мы не можем полагаться только на один мастер -узел. Нам нужно как минимум два. У нас может быть несколько рабочих узлов, которые несут рабочие нагрузки контейнера. Один узел имеет несколько контейнеров, работающих в Стручки Анкет

Мастер -узел, также называемый Плоскость управления , содержит несколько компонентов, которые заботятся об оркестровке. Узел работника соединяется с мастером и заботится о отдельных стручках через минимальные приложения, работающие на рабочем узле — Кубелет и K-Proxy Анкет У Мастера, с другой стороны, есть сложный набор компонентов, которые обрабатывают оркестровку.

Давайте посмотрим на каждый из этих компонентов в некоторых деталях. Но прежде чем я отбросил имена этих компонентов, имеет смысл подумать о том, как мы будем реализовать приложение, такое как Kubernetes. Какие компоненты мы бы добавили к этому?

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

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

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

И все это должно быть реализовано с экстремальной абстракцией, так что ни один компонент не заблокирован в другой. Давайте теперь посмотрим, как Kubernetes реализует каждый из них.

Стручки

На самом низком уровне у нас есть контейнеры (в основном докер), которые могут запускать наши микросервисы. Если вы читаете это, очевидно, вы знаете, что такое Docker или контейнер, поэтому я не буду слишком глубоко в него. Если нет, то вы можете просто подумать об этом, это хорошо упакованный микросервис, который может работать независимо.

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

Каждый стручок имеет независимый IP -адрес во внутреннем пространстве IP -кластеров. Это позволяет общаться между микросервисами в кластере

обслуживание

Стручки имеют отдельные IP -адреса — чтобы стручки могли общаться друг с другом. Но тогда у нас есть проблема. Стручки не являются постоянными. Они могут быть прекращены, масштабированы или могут умереть по разным причинам, которые находятся за пределами нашего контроля. Kubernetes позаботится о том, чтобы заменить их надлежащим образом. Но когда создается новый стручок, он получает еще один IP -адрес. Кроме того, поскольку мы масштабируем горизонтально, мы можем иметь несколько стручков для одного и того же микросервиса.

Если один микросервис вызывает другое, мы не можем сделать это с помощью IP -адресов — это добавит сложность вызывающему абоненту. Звонищий должен будет позаботиться о выявлении текущего IP -адреса POD, и если у нас есть несколько стручков для микросервиса, ему придется позаботиться о выборе одного из них. Это абсурдно!

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

Развертывание

Как мы видели, стручки могут быть заменены, масштабированы, прекращены и созданы на лету. Развертывание может рассматриваться как шаблон, который определяет, как может быть создан новый стручок для данной службы. Он содержит все подробности о изображении Docker, свойствах приложения, количестве реплик, ресурсах, необходимых для POD. Он содержит детали того, как POD должен общаться с внешним миром … и все, что требуется Kubernetes, чтобы создать стручок и обеспечить правильное количество стручков.

Кубелет

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

У этого есть очень мало собственного интеллекта. Я просто позаботился о отчетности и внедрении инструкций. Но он подробно отслеживает состояние узла — ЦП, использование памяти рабочих узлов, а также состояние каждого стручка, работающего на узле. Он заботится о периодически проведении проверки здоровья на каждом стручке, чтобы убедиться, что он активен.

Плоскость управления может дать инструкцию заканчивать заданный стручок или создать новые. Кубелет заботится о выполнении этих инструкций.

Kube Proxy

Некоторые из этих микросервисов могут подвергать внешний API или получить доступ к некоторым внешним API. Это включено kubeproxy. Как следует из названия, оно действует как простой прокси -сервер на узле.

API -сервер

Это фасад кластера Kubernetes для остального мира. Это точка входа для всех вызовов API. Несколько клиентов общаются с этим — пользовательский интерфейс Dashboard, API для автоматизации технологий, инструмент CLI. Он основан на Kurbe-Apiserver Анкет Обратите внимание, что это запись для самого кластера Kubernetes. Общение отдельных стручков — с внешним миром, не проходит через это. Он проходит через кубепрокси на отдельных узлах рабочих.

Планировщик

Планировщик отвечает за планирование стручков на рабочих узлах. Если существующий стручок умирает, нам нужно удалить его и создать новый. Точно так же, если нам нужно масштабировать развертывание, нам нужно создать новые стручки. Такие стручки должны найти новое место в кластере. Они должны быть назначены конкретному узлу работника.

При выборе рабочего узла он должен позаботиться о нескольких факторах. У нас не может быть все стручки развертывания на одном узле. Это побеждает цель наличия кластера нескольких рабочих узлов. Стручки должны быть распределены так, чтобы, если какие -либо рабочие узлы сбои, остальная часть кластера должна продолжить работу. Наряду с этим, необходимо позаботиться о том, чтобы нагрузка одинаково распределена между различными рабочими узлами.

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

Менеджер контроллера

Как следует из названия, это контроллер, управляющий всем кластером. Это отслеживает все, что происходит в кластере. Kubelets сообщают о состоянии каждого стручка для этого менеджера контроллера. Если стручок умирает, статус сообщается контроллеру. При необходимости (возможно, что POD был явно прекращен для масштабирования — в этом случае нет необходимости заменять), контроллер запускает планировщик для создания замены.

и т.д.

Это текущее состояние кластера. (Кластер с точки зрения администратора Kubernetes, а не состояние отдельных микросервисов). ETCD содержит подробную информацию о текущей системе и о том, что она должна быть. Другие компоненты относятся к нему для определения следующего действия.

Это очень полезно в случае аварийного восстановления — в результате чего менеджер контроллеров в новом кластере может просто выбрать ETCD, чтобы воссоздать новый кластер. Но есть предостережение. Kubernetes не заботится о том, чтобы сохранить ETCD на диске. Если мы хотим использовать, если для аварийного восстановления, администратор должен позаботиться об этом.

Вход

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

INGRESS имеет сложный механизм для экспорта конкретного URL -адреса для каждой услуги. Мы можем обеспечить отображение внешнего экспортируемого URL -адреса в то, что ожидается API в рамках службы.

Configmap

Нам всем нравится извлекать константы из кода приложения в файл свойств. Kubernetes предоставляет аккуратную структуру для обработки таких файлов свойств. Фактически, Kubernetes делает это на несколько шагов вперед — позволяя нам настроить файлы конфигурации.

Файлы свойств представлены в двух наборах. Конфигурационные карты и воспроизведение. Карта конфигурации можно считать шаблоном файлов свойств. Фактические ценности поступают из пьес. Как правило, у нас есть одна конфигурационная карта для каждой службы, с несколькими пьесами — чтобы позаботиться о нескольких средах и версиях. Таким образом, мы можем иметь один и тот же код приложения, относящиеся к различным файлам свойств, которые генерируются во время развертывания.

Секрет

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

Объем

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

Он работает через класс хранения (SC), постоянный объем (PV) и постоянный объемный претензии (PVC). SC, как следует из названия, является специфической для класса хранения. Это может быть EBS AWS или локальный диск или удаленный сервер в помещении. Эта конфигурация определена и ограничена SC — администратором.

Разработчики настраивают развертывание вместе с претензией на этот постоянный том. Этот ПВХ претендует на объем хранения из запрошенного класса хранения. Kubernetes позаботится о распределении этого в форме PV — когда начинается новый стручок.

Пространство имен

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

У Kubernetes слишком много сущностей. И важно гарантировать, что имена этих сущностей не сталкиваются. Мы не можем иметь консенсусную доску, выделяющую имена каждому разработчику по требованию. Это было бы безумно. Гораздо лучше разделить предприятие на более мелкие приложения — с пространством имен для каждого. Это изолирует команды и предотвращает путаницу.

Пространство имен не является мерой безопасности. Но это просто упрощает дисциплину.

Шлем

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

Как можно себе представить, у нас есть поток файлов YAML. Каждое микросервис там имеет по крайней мере дюжину этих файлов YAML, иногда несколько десятков. Это, естественно, сложная задача для любого администратора. Это расстраивает, когда у нас есть аналогичное развертывание для большинства услуг через предприятие, и у нас есть некоторые услуги, которые имеют аналогичное развертывание по всему миру (например, стек лося)

Helm предоставляет простое решение для этого — в форме диаграмм Helm — которые могут систематически организовать различные файлы YAML в диаграммы Helm.

Мы можем думать о Minikube как о меньшей игрушечной версии Kubernetes — которую мы можем установить на нашей локальной машине. Это полезно для проверки наших развертываний, а также очень полезно для обучения и совершенствования наших навыков.

Давайте начнем с установки Minikube. У меня есть искренняя просьба на данный момент. У меня нет ничего (все) против Microsoft. Windows (не) отличная операционная система. Если вы серьезно относитесь к DevOps, лучше вырасти из этого. Переключитесь на Ubuntu. Или вы можете просто создать небольшой экземпляр EC2 для обучения. (Не забудьте прекратить EC2, как только вы закончите).

Установить

$ curl -LO https://storage.googleapis.com/minikube/releases/latest/minikube-linux-amd64
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 65.2M  100 65.2M    0     0   149M      0 --:--:-- --:--:-- --:--:--  148M

$ sudo install minikube-linux-amd64 /usr/local/bin/minikube

Это быстро. Minikube теперь развернут на Ubuntu.

Начинать

Теперь мы идем вперед и начинаем кластер. Это одинаково просто.

$ minikube start
* minikube v1.23.0 on Ubuntu 20.04
* Automatically selected the docker driver. Other choices: none, ssh

* Starting control plane node minikube in cluster minikube
* Pulling base image ...
* Downloading Kubernetes v1.22.1 preload ...
    > preloaded-images-k8s-v12-v1...: 515.04 MiB / 515.04 MiB  100.00% 138.61 M
    > gcr.io/k8s-minikube/kicbase: 355.82 MiB / 355.82 MiB  100.00% 51.85 MiB p
* Creating docker container (CPUs=2, Memory=1949MB) ...
* Preparing Kubernetes v1.22.1 on Docker 20.10.8 ...
  - Generating certificates and keys ...
  - Booting up control plane ...
  - Configuring RBAC rules ...
* Verifying Kubernetes components...
  - Using image gcr.io/k8s-minikube/storage-provisioner:v5
* Enabled addons: default-storageclass, storage-provisioner
* kubectl not found. If you need it, try: 'minikube kubectl -- get pods -A'
* Done! kubectl is now configured to use "minikube" cluster and "default" namespace by default

Там! Minikube Cluster встал и готов.

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

Мы также можем изменить выделенную конфигурацию памяти напрямую

$ minikube config set memory 16384
! These changes will take effect upon a minikube delete and then a minikube start

Kubectl

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

$ minikube kubectl -- get po -A

NAMESPACE     NAME                               READY   STATUS    RESTARTS        AGE
kube-system   coredns-78fcd69978-wf5wx           1/1     Running   0               3m57s
kube-system   etcd-minikube                      1/1     Running   0               4m8s
kube-system   kube-apiserver-minikube            1/1     Running   0               4m11s
kube-system   kube-controller-manager-minikube   1/1     Running   0               4m8s
kube-system   kube-proxy-l8j4q                   1/1     Running   0               3m57s
kube-system   kube-scheduler-minikube            1/1     Running   0               4m11s
kube-system   storage-provisioner                1/1     Running   1 (3m25s ago)   4m6s

(Minikube может принести для нас правильную версию Kubectl. Для этого мы используем команду Minikube Kubectl. Это также установит Kubectl — если он еще не установлен. )

Как мы обсуждали в части 2/10, это стручки, соответствующие плоскости контроллера.

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

Уборка

Наконец, мы можем очистить материал, прежде чем мы уйдем. Мы можем остановить кластер

$ minikube stop
* Stopping node "minikube"  ...
* Powering off "minikube" via SSH ...
* 1 nodes stopped.
ubuntu@ip-172-31-1-122:~$

А затем удалите все это.

$ minikube delete --all
* Deleting "minikube" in docker ...
* Removing /home/ubuntu/.minikube/machines/minikube ...
* Removed all traces of the "minikube" cluster.
* Successfully deleted all profiles

Любые объекты в кластере Kubernetes — это простой YAML. Мы описываем объект Kubernetes через такие файлы YAML, а затем он предпринимает каждую попытку выполнить эту спецификацию. Будучи супер универсальным инструментом, мы можем ожидать, что он будет иметь очень сложную конфигурацию — и это так.

Но это намного проще, что это могло бы быть. Конфигурация интуитивно разбивается на компоненты, которые намного проще в управлении. Если мы можем понять эту структуру и значение каждого компонента, конфигурация в целом не должна быть вообще затруднена.

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

Постоянный объем

Развертывания базы данных требуют постоянного тома, который может удерживать данные за пределами жизни POD. Такой постоянный том должен быть настроен с использованием YAML, аналогичного этому. Значение отдельных полей довольно интуитивно понятно.

Эта конфигурация определяет постоянный объем, основанный на локальном классе ручного хранения. Он выделяет большую часть 20 ГБ и выделяет

kind: PersistentVolume
apiVersion: v1
metadata:
  name: mysql-pv-volume
  labels:
    type: local
spec:
  storageClassName: manual
  capacity:
    storage: 20Gi
  accessModes:
    - ReadWriteOnce
  hostPath:
    path: "/mnt/data"

Постоянный объемный претензия

Постоянный объем предлагается кластером Kubernetes. Развертывание претендует на одно для себя, используя претензию на постоянный объем. Ниже приведен образец YAML для ПВХ

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: mysql-pv-claim
spec:
  storageClassName: manual
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 20Gi

обслуживание

Определение сервиса довольно простое.

apiVersion: v1
kind: Service
metadata:
  name: mysql
spec:
  ports:
  - port: 3306
  selector:
    app: mysql
  clusterIP: None

Развертывание

Это обеспечивает шаблон для генерации отдельных стручков, а также конкретные детали конфигурации. Это относится к PV, PVC, а также к секретам для создания стручка из указанных контейнеров.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: mysql
spec:
  selector:
    matchLabels:
      app: mysql
  strategy:
    type: Recreate
  template:
    metadata:
      labels:
        app: mysql
    spec:
      containers:
      - image: mysql:5.6
        name: mysql
        env:
          # Use secret in real usage
        - name: MYSQL_ROOT_PASSWORD
          value: password
        ports:
        - containerPort: 3306
          name: mysql
        volumeMounts:
        - name: mysql-persistent-storage
          mountPath: /var/lib/mysql
      volumes:
      - name: mysql-persistent-storage
        persistentVolumeClaim:
          claimName: mysql-pv-claim

Kubernetes Pattern — обширная тема. Слишком обширно, чтобы быть рассмотренным в этом маленьком блоге. Я могу направить замечательную книгу, которая дает очень хорошие детали по этой теме. https://github.com/solegaonkar/kubernetespatterns

Это обеспечивает сложное понимание различных моделей, включая

• Основополагающие закономерности
• Поведенческие закономерности
• Структурные закономерности
• Шаблоны конфигурации
• Продвинутые шаблоны

Мощные инструменты могут быть катастровыми, если не использовать правильно. То же самое происходит с Kubernetes. Просто использование Kubernetes в приложении не делает его идеальной эластичной системой. Мы должны знать, как его использовать. Давайте посмотрим на некоторые анти -шаблоны, которые делают нашу жизнь несчастной.

Последний тег

Некоторые разработчики любят быть на грани. Они несут то же самое в развертывании. Когда мы создаем контейнеры Docker, мы должны предоставить дискретный номер версии в DockerFile. Иначе мы никогда не знаем, когда какое -то обновление однажды может убить наш кластер.

Конфигурация внутри контейнера

Я совершил эту ошибку, так что я это очень хорошо знаю. Разработчики старого класса чувствуют себя довольными, когда они вытаскивают константы в файл constants.java. Это очень хорошая практика. Но недостаточно. Каждая конфигурация должна быть выведена в файл свойств, а затем в конфигурацию. Все, что связано с окружающей средой, должно быть втянуто дальше в пьесу.

Чрезмерное использование функций Kubernetes

Kubernetes хорош для оркестровки контейнеров. Давайте ограничим это там. Избегайте использования его функций или в зависимости от его функций для бизнес -логики. Бизнес -логика должна быть ограничена кодом нашего приложения — в контейнере.

Использование Kubectl Edit/Patch

Это отличные функции, которые можно использовать в лаборатории. Они не должны использоваться в реальном приложении. Любое развертывание должно пройти правильный процесс обновления развертывания. Myml — иначе очень легко потерять контроль над тем, что развертывается, и мы понятия не имеем, что работает, а что нет.

Отсутствует пределы памяти/процессора

Очень важно указать ограничения памяти/процессора в наших развертываниях. Что мы локализуем неудачи. Мы должны хорошо понять требования нашего приложения, и это может помочь нам указать эти ограничения. Если один сервис выходит из пути, она не должна препятствовать остальной части приложения.

Чрезмерное использование Kubernetes

Kubernetes — отличный инструмент для какой -то цели. Это не единое решение для всех проблем на Земле. Некоторые услуги должны жить за пределами Kubernetes, и мы не должны пытаться подтолкнуть их в кластер. Например, базы данных имеют право жить вне кластера.

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

Кроме того, высокая производительность и устойчивость не могут быть в предпосылке. Так что имеет смысл поднять один из готовых кластеров Kubernetes в облаке. И что может быть лучше, чем AWS — Elastic Kubernetes Service.

Эк

Кластер Amazon ECS — это региональная группировка одного или нескольких экземпляров контейнеров, на которых вы можете запустить запросы на задачи. Каждая учетная запись получает кластер по умолчанию в первый раз, когда вы используете сервис Amazon ECS. Кластеры могут содержать более одного типа экземпляра Amazon EC2.

Чтобы начать, перейдите на страницу EKS на консоли AWS. Затем нажмите «Создать кластер»

Далее мы просто предоставляем основные детали для создания нового кластера.

Обратите внимание, что роль должна быть создана в IAM. Это просто основная роль с необходимой политикой для кластера EKS.

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

Все, что нам нужно сделать сейчас, это настроить отдельные развертывания на EKS. Отдых управляется для нас. Azure, GCP и Digital Ocean имеют очень похожие варианты для управляемого хостинга Kubernetes.

Как мы видели ранее, Kubectl — это простой интерфейс командной строки для кластера Kubernetes. Это просто, но очень мощно.

Команды Kubectl

Kubernetes поставляется с простой интерфейсом командной строки — Kubectl. Это очень мощно, и мы можем сделать почти все с кластером.

Синтаксис Kubectl прост.

kubectl    

Действие может быть получено, описать, создавать, удалять, редактировать, применить, Exec .. Целью может быть стручка, развертывание, обслуживание, контейнер, …

Получить

Мы можем использовать Kubectl, чтобы получить список узлов, стручков и т. Д. Это просто получает список и показывает в Stdout.

kubectl get nodes

kubectl get pod

kubectl get services

kubectl get deployment

kubectl get replicaset

Редактировать

Это очень обескуражено. Но если это необходимо, мы можем напрямую отредактировать развертывание YAML на кластере. Но это не рекомендуется. Если мы сделаем это, мы скоро вступим в несоответствие, когда мы не знаем, что развернуто. Лучше всего обновить файл YAML в элементе управления версией, а затем нажать его на кластер.

kubectl edit deployment nginx-depl

Точно так же мы можем напрямую создать новое развертывание в командной строке.

kubectl create deployment nginx-depl --image=nginx

Это правильный способ сделать это.

kubectl apply -f nginx-deployment.yaml

Журналы

Мы можем распечатать журналы работающего капсула.

kubectl logs {pod-name}

Исполнительный

Мы также можем заглянуть в капсул. Просто зайдите в его раковину Linux и посмотрите, как там появляется мир. Это очень полезно для отладки.

kubectl exec -it {pod-name} -- bin/bash

Чит

Коллекция полезных команд Kubectl

Общие команды

Проверьте производительность

Удаление ресурсов

Force & conf -файлы

Капсул

Лейбл и аннотация

Развертывание и масштаб

Квота, ограничения и ресурсы

обслуживание

Секреты

Statefulset

Объемы и объемные претензии

События и метрики

Университет узла

Пространство имен и безопасность

Сеть

Пластырь

Расширения

Компоненты и услуги

Услуги на главных узлах

Услуги на рабочих узлах

Аддоны: стручки и услуги, которые внедряют функции кластера

Инструменты

Больше ресурсов

• https://kubernetes.io/docs/reference/kubectl/cheatsheet/
• https://cheatsheet.dennyzhang.com/

Когда -то было время, когда Kubernetes означал тяжелые вычислительные и большие накладные расходы на серверах Super Power. За прошедшие годы он истощил себя до такой степени, что у нас также есть Kubernetes, а также в устройствах IoT! Попробуем установить его на нашу малиновую пи

Для этого нам нужен настольный компьютер Ubuntu — Windows недостаточно. Поклонники Microsoft, которые не могут бросить использование Windows, могут установить Ubuntu в виртуальные машины. Нам понадобится не менее 2 малиновых писей (чтобы сделать кластер). Я использовал три в этом примере. И, конечно, нам нужен кабель Micro USB, чтобы подключить каждый PI. А также одна карта MicroSD на PI не менее 8 ГБ — прошивая с изображением сервера Ubuntu

Установка Microk8s

Фактический процесс установки не сложно. Мы просто внедряем устройства индивидуально и выполняем эти шаги:

sudo vi /boot/firmware/cmdline.txt

Это имеет сложную командную строку. Мы просто добавляем в это еще несколько вариантов cgroup_enable = память

Полная линия на моем PI выглядит так. Он будет варьироваться в зависимости от версий:

cgroup_enable=memory cgroup_memory=1 net.ifnames=0 dwc_otg.lpm_enable=0 console=ttyAMA0,115200 console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 elevator=deadline rootwait

Далее мы перезагружаем устройство

sudo reboot

Как только он вернется, мы снова включим в него и устанавливаем Microk8s, используя простую команду

sudo snap install microk8s --classic

Это также устанавливает утилиту командной строки — также называется Microk8s. Несколько простых команд, чтобы дать вкус:

# Start the cluster
microk8s.start  

# Inspect status of services
microk8s.inspect

# Stop all Kubernetes services
microk8s.stop

# Enable addons - eg kubedns addon
microk8s.enable dns

# Get status of the cluster
microk8s.kubectl cluster-info

Мастер/работник

Как только у нас установлен Microk8s на каждом из них, мы можем подключить их к кластеру. Мы должны выбрать одного из них в качестве мастера и запустить ниже команду:

sudo microk8s.add-node

Это объявляет текущий мастер, и он предоставит строку подключения, чтобы пригласить другие рабочие узлы. Строка подключения выглядит следующим образом: : /

Далее мы перейдем к каждому (подражательскому) детскому узлу и запускаем эту команду на оболочке

microk8s.join :/

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

microk8s.kubectl get node

Полезность

Можно задаться вопросом, в чем дело в этом? Зачем нам нужны Kubernetes, работающие на устройствах IoT? Но это имеет большой смысл. Намного больше, чем настоящие серверы. Устройства IoT действительно хрупкие, и мы можем быть уверены, что что -то где -то сломается. Если у нас есть критическое приложение для миссии на поле, полезно иметь несколько устройств, покрывающих друг друга — чтобы убедиться, что приложение продолжает работать.

Мы рассмотрели большинство основных понятий. Время освежить некоторые вопросы интервью, чтобы вы были готовы к этой работе!

Что такое kubernetes

Самый простой из всех. Кто -то, кто прочитал этот блог до сих пор, конечно, знает это. Но, давайте отметим что-то, что можно легко запомнить: «Kubernetes-это инструмент управления контейнерами с открытым исходным кодом, который выполняет обязанности развертывания контейнеров, масштабирования и снижения контейнеров и балансировки нагрузки. Будучи детищем Google, он предлагает отличное сообщество и великолепно работает со всеми облачными поставщиками. Таким образом, мы можем сказать, что Kubernetes не является платформой контейнеризации, но это решение для управления мультизантером ».

Что такое оркестровка контейнеров

Мы сказали, что Kubernetes заботится о оркестровании контейнеров. Но что именно это в контейнерном оркестровании?

«Рассмотрим сценарий, в котором у вас есть 5-6 микросервисов для приложения. Теперь эти микросервисы помещаются в отдельные контейнеры, но не смогут общаться без оркестровки контейнеров. Таким образом, поскольку оркестровка означает объединение всех инструментов, играющих вместе в гармонии в музыке, аналогично контейнерное оркестровая означает все услуги в отдельных контейнерах, работающих вместе для удовлетворения потребностей одного сервера ».

Что такое Хипстер?

Теперь некоторые серьезные .. Heapster является агрегатором данных, предоставленных Kubelet, работающим на каждом узле. Этот инструмент управления контейнерами поддерживается назначен на кластере Kubernetes и работает как стручок, как и любой другой стручок в кластере. Таким образом, он в основном обнаруживает все узлы в кластере и запрашивает информацию об использовании у узлов Kubernetes в кластере через агент на Machine Kubernetes.

Каковы компоненты архитектуры Kubernetes?

Архитектура Kubernetes имеет в основном 2 компонента — Master Node и Worker Node. Как вы можете видеть на приведенной ниже диаграмме, у мастера и рабочих узлов есть много встроенных компонентов в них. Мастер-узел имеет Kube-Controller-Manager, Kube-Apiserver, Kube-Scheduler и т. Д. В то время как у узла рабочего на каждом узле Kubelet и Kube-Proxy.

Что такое Kube-Proxy

Kube-Proxy может работать на каждом узле и может выполнять простой переадресацию пакетов TCP/UDP через бэкэнд-сервис. Таким образом, в основном это сетевой прокси, который отражает службы, настроенные в API Kubernetes на каждом узле. Таким образом, переменные совместимой среды, связанные с Docker, предоставляют кластерные IPS и порты, которые открываются Proxy.

Что такое сервер Kube API?

Kube-Apiserver следует за масштабной архитектурой и является передней частью панели управления главным узлом. Это раскрывает все API -интерфейсы компонентов Master Node Kubernetes и отвечает за установление связи между Node Kubernetes и главными компонентами Kubernetes.

Что такое планировщик Kube?

Kube-Scheduler отвечает за распространение и управление рабочей нагрузкой на рабочих узлах. Таким образом, он выбирает наиболее подходящий узел для запуска незапланированного POD на основе требований к ресурсам и следит за использованием ресурсов. Это гарантирует, что рабочая нагрузка не запланирована на узлах, которые уже заполнены.

Что такое Kubernetes Controller Manager?

Многочисленные процессы контроллера, работающие на главном узле, но собираются вместе для запуска как единый процесс, который является диспетчера контроллеров Kubernetes. Таким образом, диспетчер контроллеров — это демон, который встраивает контроллеры и делает создание пространства имен и сбор мусора. Он владеет ответственностью и общается с сервером API для управления конечными точками.

Каковы различные типы управляющих контроллерами?

Различные типы диспетчера контроллеров, работающих на главном узле:

• Контроллер узлов: Управляет статусом узла (создание, обновление, удаление)
• Контроллер репликации: поддерживает количество стручков для каждого объекта репликации
• Контроллер токена: создает учетные записи по умолчанию и токены API Access для новых пространств имен
• Контроллер конечных точек: позаботьтесь о объектах конечных точек, таких как стручки и услуги
• Контроллер маршрута: он управляет маршрутами движения в базовой облачной инфраструктуре
• Контроллер громкости: Управляет объемом хранения и взаимодействует с облачным провайдером, чтобы организовать объем

Что такое и т. Д.?

ETCD написан на языке программирования GO и является распределенным хранилищем ключей, используемым для координации распределенной работы. Итак, ETCD сохраняет данные конфигурации кластера Kubernetes, представляя состояние кластера в любой заданный момент времени.

Каковы различные типы услуг в Kubernetes?

• Cluster IP: обнажает службу на кластерном внутреннем IP. Это делает услугу доступной изнутри кластера. Это тип службы по умолчанию
• Узел Узел: Это раскрывает службу на IP -адресе каждого узла в статическом порте. Сервис IP -адреса кластера, к которой будет создана сервис порта узлов, автоматически создается
• Балансировщик нагрузки: Он открывает службу извне, используя облако, предоставленное балансировщиком нагрузки. Сервис, на который будет автоматически создан внешняя балансировщики нагрузки, автоматически создается
• Внешнее имя: это отображает службу с содержимым поля внешнего имени, возвращая запись CNAME с его значением.

Kubernetes Load Balancers

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

Что такое сеть Ingress?

Intress Network — это набор правил, которые действуют как точка входа в кластер Kubernetes. Это позволяет входящие подключения, которые можно настроить, чтобы предоставлять услуги извне через достижимые URL-адреса, загружать трафик баланса или предлагая виртуальное хостинг на основе имени. Таким образом, Ingress — это объект API, который управляет внешним доступом к Сервисам в кластере, обычно от HTTP и является наиболее мощным способом выявления услуг.

ConfigMap VS Secrets

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

Multi Container Pods

• SIDECAR: спецификация POD, которая запускает основной контейнер и вспомогательный контейнер, который выполняет некоторую рабочую работу, но это не обязательно необходимо для работы основного контейнера.
• Адаптер: Контейнер адаптера будет осматривать содержимое файла приложения, делает какую -то реструктуризацию и переформатировать его и записать правильно отформатированный вывод в местоположение.
• Посол: он соединяет контейнеры с внешним миром. Это прокси, который позволяет другим контейнерам подключаться к порту на Localhost.

API Security в Kubernetes

Используйте правильный режим AUTH с API-сервером, RBAC Убедитесь, что весь трафик защищен с помощью TLS Использовать аутентификацию API (меньший кластер может использовать сертификаты, но более крупные мульти-претенденты могут захотеть AD или некоторую аутентификацию AIDC).

Заставьте Kubeless защитить свой API через. Убедитесь, что Kube-Dashboard использует ограничительный монитор политики RBAC Role Monitor RBAC. Удалите по умолчанию Filter Egress Egress в облачный API метаданные APIS-фильтр весь трафик, поступающий в пространство имен Kube-System, кроме DNS.

Политика по умолчанию отказавшейся на все входящие на все пространства имен — это хорошая практика. Вы явно разрешаете развертывание. Используйте политику безопасности POD, чтобы иметь ограничения контейнеров и защитить узлы Keep Kube на последней версии.

Рабочие узлы:

Kubernetes Worker Node — это машина, на которой развертываются рабочие нагрузки. Рабочие нагрузки находятся в форме контейнерных приложений, и из -за этого каждый узел в кластере должен запускать время выполнения контейнера, такое как Docker, чтобы запустить эти рабочие нагрузки. У вас может быть несколько мастеров, нанесенных на карту с несколькими рабочими узлами или одним мастером, имеющим один узел работника. Кроме того, рабочие узлы не сплетничают или делают выборы лидеров или что-либо, что приведет к нечетной квалификации. Роль времени выполнения контейнера состоит в том, чтобы запустить и управлять контейнерами. Kubelet отвечает за запуск состояния каждого узла, и он получает команды и работает от мастера. Это также проверяет здоровье узлов и убедится, что они здоровы. Кубелет также отвечает и за метрические коллекции стручков. Kube-Proxy-это компонент, который управляет подсетью хоста и предоставляет услуги доступными для других компонентов.

Перезагрузить карту конфигурации без перезапуска капсула

Нам нужен способ запустить перезагрузку. Ether выполняйте проверку каждую минуту или имейте конечную точку перезагрузки для API или проекта ConfigMap в качестве тома, может использовать INOTIFO, чтобы знать об изменении. Зависит от того, как ConfigMap потребляется контейнером. Если env vars, то нет. Если монтирование тома, то файл обновляется в контейнере, готовом к употреблению службой, но он должен перезагрузить файл

Контейнер не перезапускается. Если ConfigMap монтируется как том, он обновляется динамически. Если это переменная среды, она остается как старое значение, пока контейнер не будет перезагружен. Мошенничество с томом ConfigMap в POD, прогнозируемый файл периодически обновляется. Не в реальном времени. Затем пусть приложение распознает, изменилось ли диск на конфигурации и перезагрузить

Оригинал: «https://dev.to/solegaonkar/understanding-kubernetes-developer-s-guide-3np»