Полное руководство kubernetes

Отметьте синее слово «Облачные вычисления CSDN«Подписывайтесь на нас!

Источник / Переводчик | Псевдоархитектор

Автор оригинала | Жером Петаццони

Хотите развернуть контейнерные приложения? Развертывание контейнерных приложений в Kubernetes всегда включает

Развертывание, вот все содержимое этого объекта.

Одна из первых команд Kubernetes, которую мы узнали, была kubectl run. Пользователи с опытом работы с Docker неизбежно будут использовать команду docker run для сравнения с этой командой. Вывод может быть таким: запустить контейнер — это очень просто.

Давайте посмотрим, что произойдет, когда мы запустим простую команду запуска kubectl:

$ kubectl run web --image=nginx
deployment.apps/web created

Что создается в кластере?

$ kubectl get all
NAME                       READY     STATUS    RESTARTS   AGE
pod/web-65899c769f-dhtdx   1/1       Running   0          11s

NAME                 TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)   AGE
service/kubernetes   ClusterIP   10.96.0.1    <none>        443/TCP   46s

NAME                  DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/web   1         1         1            1           11s

NAME                             DESIRED   CURRENT   READY     AGE
replicaset.apps/web-65899c769f   1         1         1         11s

Мы видим не контейнер, а набор неизвестных объектов:

• Deployment：web

• ReplicaSet：web-65899c769f

• Pod：web-65899c769f-dhtdx

Сервис kubernetes здесь можно игнорировать, он уже существует до того, как мы запустим команду.

Я просто хочу контейнер! Почему вы видите три разных объекта?

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

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

Непрерывная интеграция повышает уверенность в коде. Чтобы распространить эту уверенность на процесс выпуска, операции развертывания нуждаются в большей гарантии.

Контейнер и контейнер

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

Например, контейнеры в Pod могут связываться друг с другом через localhost. С точки зрения сети все процессы в этих контейнерах являются локальными.

Но мы никогда не сможем создать независимый контейнер: ближайшая операция может заключаться только в создании Pod, содержащего только один контейнер.

Мы хотим, чтобы Kubernetes создавал NGINX. Полная строка гласит: «Мне нужен Pod, который содержит только один контейнер, и этот контейнер запускает образ nginx».

# pod-nginx.yml
# Create it with:
#    kubectl apply -f pod-nginx.yml
apiVersion: v1
kind: Pod
metadata:
  name: web
spec:
  containers:
    - image: nginx
      name: nginx
      ports:
        - containerPort: 80
          name: http

Есть только один модуль. Что случилось с ReplicaSet и Deployment?

Директивы и декларации

Kubernetes — это декларативная система (в отличие от императивной системы), что означает, что мы не можем отдавать ей команды. Мы не можем сказать: «Запустите этот контейнер». Все, что мы можем сделать, это описать, что нам нужно, а затем подождать, пока Kubernetes синхронизирует ожидаемый контент на основе существующего контента.

Например, мы можем сказать: «Мне нужен синий контейнер высотой 40 футов с желтой дверцей». Kubernetes будет искать этот контейнер для нас. Если он не может его найти, он создаст его; если он уже существует, но Это зеленая красная дверь, и Kubernetes поможет нам ее раскрасить; если уже есть контейнеры, полностью отвечающие требованиям, потому что существующий контент соответствует ожидаемому контенту, Kubernetes ничего не сделает.

Возвращаясь к теме программных контейнеров, мы можем сказать: «Я хочу Pod с именем web, в котором должен быть отдельный контейнер, запускающий образ nginx».

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

Основываясь на этой идее, как масштабировать веб-приложения для удовлетворения рабочих потребностей нескольких контейнеров или модулей?

ReplicaSet упрощает процесс масштабирования Pod

Если у нас есть только один Pod, и мы хотим больше одного и того же Pod, мы можем сделать запрос в Kubernetes: «Нам нужен Pod с именем web2, конкретные требования: …», а затем повторить предыдущую спецификацию Pod. Повторите столько стручков, сколько хотите.

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

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

С помощью ReplicaSet мы можем сказать Kubernetes: «Мне нужен ReplicaSet под названием web, который содержит 3 модуля, и эти модули соответствуют следующим спецификациям: …» Kubernetes подтвердит в соответствии с этой инструкцией, есть ли ровно три модуля, соответствующих спецификациям. Под. Если мы начнем с нуля, эти 3 модуля будут созданы. Если уже есть 3 модуля, ничего не произойдет — наши требования такие же, как статус-кво.

# pod-replicas.yml
apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: web-replicas
  labels:
    app: web
    tier: frontend
spec:
  replicas: 3
  selector:
    matchLabels:
      tier: frontend
  template:
    metadata:
      labels:
        app: web
        tier: frontend
    spec:
      containers:
      - name: nginx
        image: nginx
        ports:
        - containerPort: 80

Масштабируемость и высокая доступность ReplicaSet

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

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

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

Что происходит, когда вы изменяете определение Pod

Изменение определения Pod — не редкость. Например, мы часто хотим заменить образ контейнера новой версией.

Помните: миссия ReplicaSet состоит в том, чтобы «убедиться, что есть N модулей, соответствующих спецификации». Что произойдет, если мы изменим определение — внезапно не останется модулей, соответствующих новой спецификации.

На данный момент мы уже знаем, как работает декларативная система: Kubernetes немедленно создаст N Pod’ов, соответствующих новой спецификации. Старые модули будут существовать постоянно, пока мы не очистим их вручную.

Было бы хорошо, если бы CI / CD можно было использовать для автоматической очистки этих просроченных подов; было бы лучше, если бы новые поды можно было создавать более элегантным способом.

ReplicaSet, управляемый развертыванием

Упомянутая ранее необходимость является обязанностью Развертывания. На первый взгляд, спецификация развертывания очень похожа на ReplicaSet: она содержит спецификацию Pod и количество реплик. (Есть некоторые параметры, о которых мы поговорим позже)

# deployment-nginx.yml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: web
spec:
  selector:
    matchLabels:
      app: nginx
  replicas: 3
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.7.9
        ports:
        - containerPort: 80

Deployment не несет прямой ответственности за создание и удаление модулей. Он делегирует эти задачи одному или нескольким ReplicaSets.

Когда мы создаем развертывание, оно создаст ReplicaSet со своей собственной спецификацией Pod.

При обновлении развертывания и изменении количества реплик обновленное содержимое будет передано в нижележащий ReplicaSet.

При изменении конфигурации

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

Когда мы обновляем спецификацию Pod, Deployment создаст новый ReplicaSet с новой спецификацией Pod. Первоначальное количество экземпляров нового ReplicaSet равно 0. Затем количество экземпляров ReplicaSet будет постепенно увеличиваться, постепенно уменьшая размер другого ReplicaSet.

Представьте, что перед нами находится микшерный пульт.Мы хотим одновременно добавить новый ReplicaSet и старый.

В течение всего процесса запрос отправляется в старый и новый ReplicaSet, и пользователь не почувствует прерывания обслуживания.

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

Поврежденное развертывание и обнаружение готовности

Если мы выпустим ошибочную версию, поскольку Kubernetes продолжит заменять старые модули новыми (ошибочными) версиями, это может привести к поломке всего приложения (Pod by Pod).

Если только мы не используем обнаружение готовности.

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

Kubernetes поддерживает три способа определения готовности:

1. Запустить команду в контейнере;

2. Отправить в контейнер HTTP (S) запрос;

3. Инициируйте TCP-соединение с контейнером.

Kubernetes будет использовать результаты теста, чтобы понять, готовы ли контейнер и его Pod принимать трафик. Когда мы запускаем новую версию, Kubernetes будет ждать, пока новый тест Pod не получит «готовый» результат, прежде чем перейти к следующему шагу.

Если Pod продолжает отказывать из-за проверок готовности, он никогда не сможет перейти в состояние готовности, и Kubernetes не перейдет к следующему шагу. Процесс развертывания остановится, и приложение будет продолжать работать со старой версией, пока мы не решим проблему.

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

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

В любой момент во время или после непрерывного обновления мы можем сказать Kubernetes: «Я передумал, пожалуйста, вернитесь к предыдущей версии этого развертывания». Эта операция изменит статус старого и нового ReplicaSet. Начиная с этого момента, количество экземпляров старой версии ReplicaSet будет увеличено до указанного значения, а количество экземпляров новой версии будет уменьшено.

Вообще говоря, это не ограничивается старым и новым ReplicaSet. В конечном итоге есть ReplicaSet, который считается «последней» версией. Мы можем использовать эту версию в качестве целевого ReplicaSet. Так называемая цель — это то, что мы хотим запустить, и это также версия, которую Kubernetes будет постепенно развивать. При этом может быть любое количество других версий ReplicaSet, соответствующих старой версии.

Например, мы запускаем 10 копий приложения версии 1, а затем начинаем развертывать версию 2. В какой-то момент у нас может быть запущено 7 модулей версии 1 и 3 версии 2. Если мы не хотим ждать полного выпуска версии 2, мы решаем выпустить версию 3. Когда была развернута версия 3, мы хотели вернуться к версии 1. На протяжении всего процесса Kubernetes будет корректировать количество реплик в каждой версии ReplicaSet по мере необходимости.

MaxSurge и MaxUnavailable

Kubernetes не обязательно обновляет один под за раз. Ранее мы упоминали, что Deployment имеет некоторые дополнительные параметры, включая MaxSurge и MaxUnavailable, эти два параметра определяют скорость процесса обновления.

Представьте себе две стратегии в процессе запуска новой версии:

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

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

MaxSurge указывает, сколько дополнительных модулей мы можем иметь во время непрерывного обновления; а MaxUnavailable показывает, сколько модулей мы можем допустить, не предоставляя услуги во время непрерывного обновления. Эти два параметра могут быть количеством модулей или процентом от количества экземпляров развертывания; оба параметра могут быть установлены на 0 (но не одновременно).

Затем посмотрите на общие значения этих двух параметров и их цель.

Значение 0 для параметра MaxUnavailable означает: «Не закрывайте старый модуль, пока новый модуль не будет запущен и не будет готов».

Установка MaxSurge на 100% означает: «запускать все новые модули немедленно», что означает, что у нас достаточно ресурсов, и мы надеемся завершить обновление как можно скорее.

Оценка этих двух параметров составляет 25% .Если мы обновим 100 Pod Deployment, 25 новых Old Pod будут созданы немедленно, а 25 старых Pod будут закрыты одновременно. Каждый раз, когда Pod готов к запуску, вы можете закрыть старый Pod. Каждый раз, когда старый модуль завершает процесс завершения работы (освобождая ресурсы), может быть создан еще один новый модуль.

Время презентации

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

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

Если у вас есть кластер Kubernewtes (подойдет настольная версия одноузлового кластера Minikube или Docker), вы можете запустить следующие команды в разных терминалах, чтобы увидеть, что произойдет:

kubectl get pods -w
kubectl get replicasets -w
kubectl get deployments -w
kubectl get events -w

Затем используйте следующие команды для создания, масштабирования и обновления развертывания:

kubectl run deployment web --image=nginx
kubectl scale deployment web --replicas=10
kubectl set image deployment web nginx=that-image-does-not-exist

Вы увидите, что процесс развертывания остановлен, но доступно 80% емкости приложения.

Если мы запустим kubectl rollout undo deployment web, Kubernetes вернется к старой версии с помощью образа nginx.

Понять селекторы и теги

Как мы уже говорили ранее, задача ReplicaSet — обеспечить наличие N соответствующих Pod’ов. На самом деле это еще не все. Фактически ReplicaSet не заботится о спецификациях Pod, он заботится только о ярлыках.

Другими словами, независимо от того, работает ли Pod nginx, redis или что-то еще, все заботы о том, чтобы у них были правильные метки. В предыдущем примере теги примерно имеют вид run = web и pod-template-hash = xxxyyyzzz.

ReplicaSet содержит элемент селектора, содержимое является логическим выражением, функция аналогична SELECT в SQL, используется для выбора Pod, который соответствует требованиям. ReplicaSet гарантирует, что количество модулей правильное. При необходимости модули будут созданы или удалены, но существующие модули не будут изменены.

Будет предположение: Pod с этими тегами можно создать вручную, но с другими зеркалами (или разными конфигурациями) вы можете обмануть ReplicaSet.

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

Балансировка нагрузки службы

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

kubectl expose deployment web --port=80

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

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

Когда мы редактируем развертывание и запускаем прокрутку, будет создан новый ReplicaSet. Этот ReplicaSet создаст модули, а новый тег Pod будет содержать run = web, поэтому эти модули будут автоматически получать трафик.

Это означает, что во время непрерывного обновления развертыванию не нужно перенастраивать или уведомлять балансировщик нагрузки, поскольку Pod запускается и останавливается. Балансировщик нагрузки автоматически выполняет задачи с помощью селекторов.

Если вас интересует внутренняя история обнаружения готовности: Pod будет добавлен в службу как действительная конечная точка только после того, как все контейнеры-участники пройдут проверку готовности. Другими словами, Pod начнет получать трафик только после того, как будет готов.

Расширенные стратегии развертывания Kubernetes

Есть некоторые вещи, над которыми мы надеемся получить больший контроль после выхода новой версии.

Две хорошо известные популярные технологии — это сине-зеленое развертывание и канареечное развертывание.

Сине-зеленое развертывание в Kubernetes

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

• Мы не хотим смешивать старые и новые запросы, мы надеемся максимально четко перейти со старой версии на новую;

• Мы обновляем несколько компонентов (например, веб-интерфейс и серверную часть API) и не хотим, чтобы новая версия интерфейса соприкасалась со старой версией серверной части;

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

В Kubernetes вы можете создать несколько развертываний для завершения сине-зеленых развертываний и переключать их, управляя полем «Селектор» службы.

Следующая команда создаст два развертывания: синий и зеленый, используя зеркала nginx и httpd соответственно:

kubectl create deployment blue --image=nginx
kubectl create deployment green --image=httpd

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

kubectl create service clusterip web --tcp=80

Затем мы обновляем селектор веб-сервисов: kubectl edit service web. Эта команда получит определение служебного объекта из Kunernetes API и откроет его в текстовом редакторе. Найдите в нем:

selector:
  app: web

Замените паутину синей или зеленой или чем-нибудь еще. Сохранить и выйти. kubectl отправит обновленное определение в Kubernetes API, и теперь веб-служба будет отправлять трафик на конкретное развертывание.

Вы можете использовать веб-команду kubectl get svc, чтобы получить адрес службы, и использовать curl для доступа к ней.

Изменения, которые мы вносим в текстовом редакторе, также можно полностью выполнить с помощью командной строки, например, с помощью команды kubectl patch:

kubectl patch service web -p '{"spec": {"selector": {"app": "green"}}}'

Преимущество сине-зеленого развертывания заключается в том, что переключение трафика завершается почти сразу, а развертывание и откат можно легко выполнить, обновив определение службы.

Полное канареечное развертывание с Kubernetes

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

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

Благодаря метке и механизму селектора Kubernetes эту стратегию можно легко реализовать.

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

Например, установите селектор службы, позвольте ему выбрать модуль со статусом = включен, а затем пометьте конкретный модуль:

kubectl label pod fronted-aabbccdd-xyz status=enabled

Вы также можете поставить сразу несколько тегов:

kubectl label pods -l app=blue,version=v1.5 status=enabled

Удаление тегов также просто:

kubectl label pods -l app=blue,version=v1.4 status-

В заключение

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

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

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

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

Рекомендуемое чтение

• Сборник, наиболее цитируемый с момента публикации в 2017 г. — Большие данные

• Создана отечественная производственная, образовательная и исследовательская база RISC-V. Разделятся ли Intel, Arm и RISC-V на три части?
  

• Контейнеризация небольших веб-сайтов (часть 1)
  

• AbutionGraph: построение центра обработки данных нового поколения на основе графа знаний

• Является ли китайский язык программирования «Mulan» еще одним браузером с «чужой» оболочкой?

• У Ethereum 2.0 светлое будущее!

В первый день нового года отправляйтесь в Ухань!

Видео текст:

[00:00] => Kubernetes позволяет контейнеризировать приложения и упрощает развертывание в
[00:05] => производство. Богдан Стащук научит вас все, что вам нужно знать, чтобы начать
[00:09] => с помощью Kubernetes. Добро пожаловать в Kubernetes Для Начинающих. Kubernetes является стандартом де-факто для
[00:16] => внедрение контейнерных приложений в производство. Kubernetes имеет открытый исходный код
[00:22] => и поэтому он бесплатен для использования. Позвольте мне сначала представиться, прежде чем мы начнем этот курс.
[00:29] => Меня зовут Богдан Стащук, и я использую Докер и Kubernetes несколько лет на практике.
[00:36] => И я внедрил приложения реального мира в производство с использованием Kubernetes. Также,
[00:42] => Я преподаю онлайн и на своих личных сайтах , которые shoe.com Вы могли бы найти все курсы, которые
[00:47] => Я преподаю. Теперь давайте начнем с Kubernetes для начинающих, и я хотел бы начать с
[00:53] => план курса. Итак, что входит в этот курс, мы начнем с разговора о терминологии и
[01:01] => ключевые особенности Kubernetes. И вы узнаете, что такое кластер Kubernetes,
[01:07] => что такое узел и что такое спорт и что Kubernetes, по сути, делает это. Впоследствии,
[01:14] => мы немедленно погрузимся в практику и мы создадим небольшой кластер Kubernetes локально на
[01:20] => наши компьютеры. И впоследствии использовать такой кластер мы будем создавать и масштабировать различные развертывания.
[01:30] => Кроме того, мы создадим пользовательский докер изображение, переместите его в Docker Hub,
[01:35] => а затем создайте развертывание Kubernetes на основе этого специально созданного образа докера.
[01:44] => Помимо этого, мы также будем создавать службы и развертывания в Kubernetes с использованием конфигурации Yamo
[01:51] => файлы. Кроме того, мы будем соединять различные развертывания вместе, потому что это очень распространено
[01:58] => ситуация, когда вам приходится соединять разные приложения вместе по сети.
[02:05] => И Kubernetes, конечно, позволяет это делать. И также, наконец, мы изменим время выполнения контейнера
[02:13] => из докера в CRI o, потому что Kubernetes не привязан к докеру. Он также поддерживает
[02:20] => другие среды выполнения контейнеров, такие как CRI O и контейнер D. И вы могли бы использовать Kubernetes
[02:26] => абсолютно без докера. Одно единственное предварительное условие для этого курса необходимо ваше знакомство с докером,
[02:34] => Я предполагаю, что вы знаете, что такое контейнер Docker и как создавать различные контейнеры.
[02:40] => Хорошо, итак, давайте начнем с этого курса. И я хотел бы начать с определения
[02:45] => Kubernetes — это система оркестровки контейнеров. используя Docker, вы, конечно, могли бы
[02:52] => создайте контейнер на любом компьютере. Но, конечно, если вы хотите создать несколько контейнеров
[02:59] => на разных компьютерах на разных серверах у вас могут возникнуть проблемы. Kubernetes позволяет вам
[03:06] => для создания контейнеров на разных серверы, физические или виртуальные.
[03:11] => И все это делается автоматически без ваше вмешательство. Вы просто скажите Kubernetes, как
[03:17] => много контейнеров, которые вы хотели бы создать основанный на определенном изображении. Кубернетес — это
[03:23] => относительно одно хорошее слово, и оно состоит из 10 разных букв. НО ИТ-специалисты и
[03:29] => разработчики программного обеспечения относительно ленивы люди, и они не любят много печатать.
[03:34] => Вот почему награда за поиск в одиночку обычно сокращается только для трех персонажей. Но как это делается?
[03:41] => Давайте взглянем на это слово. между k и s на самом деле есть восемь разных букв.
[03:48] => Итак, номер восемь, вот почему кредитная премия Kubernetes будет сокращена всего до трех символов,
[03:55] => К восьми с. Таким образом, восемь представляет собой просто количество букв между начальным и конечным залогом
[04:03] => Вот так просто. Зная эту очень простую настройку мы могли бы продолжать. А теперь позвольте мне объяснить вам
[04:10] => о чем заботится Кубра. Таким образом, Kubernetes заботится об автоматическом развертывании контейнеризованного
[04:18] => приложения на разных серверах. И эти серверы могут быть как металлическими, так и физическими
[04:25] => серверы или виртуальные серверы. Опция виртуальных серверов, конечно, более распространена в настоящее время,
[04:31] => и почти никто сейчас не использует голые металлические серверы. Таким образом, Kubernetes позволяет выполнять автоматизированные
[04:38] => развертывания на разных серверах, которые могли бы находиться даже в разных уголках мира.
[04:45] => Помимо этого, Kubernetes также заботится о распределении ресурсов по
[04:50] => эти несколько серверов. И это позволяет вам эффективно использовать свои ресурсы
[04:57] => и избегайте недостаточного или чрезмерного использования ресурсов.
[05:03] => Также Kubernetes заботится об автоматическом масштабирование развернутых приложений в случае
[05:09] => вам нужно, например, увеличить количество контейнеров, которые должны быть созданы на разных
[05:15] => серверы. И все это делается автоматически. Вы просто скажите, когда вы хотите увеличить или уменьшить масштаб. Также,
[05:24] => Kubernetes заботится о мониторинге и проверка работоспособности контейнеров. И в случае
[05:31] => некоторые контейнеры выходят из строя по некоторым причинам Kubernetes может автоматически заменять вышедшие из строя контейнеры
[05:39] => и все это делается без вашего вмешательства. Как Я только что сказал вам, что Kubernetes развертывает контейнерные
[05:46] => приложения и, следовательно, он должен использовать определенную среду выполнения контейнера. И Догра — это просто
[05:54] => один из возможных вариантов Kubernetes в настоящее время, поддержка таких контейнерных сред выполнения Docker,
[06:02] => CRI O и контейнер D, а также среда выполнения контейнера поиска, например, как Docker или cRIO, должны
[06:10] => быть запущенным на каждом из серверов, входящих в кластер Kubernetes.
[06:17] => И главный результат здесь заключается в том, что Kubernetes можно использовать даже без докера вообще.
[06:23] => Он поддерживает другие среды выполнения контейнеров, такие как CRI O и контейнер D. И в конце этого курса,
[06:30] => Я продемонстрирую вам, как изменить время выполнения контейнера и перемещение из докера
[06:35] => например, критиковать О. Итак, теперь давайте начнем с терминологии и архитектуры Kubernetes.
[06:44] => И давайте начнем с того, что порт оба является самым маленьким подразделением в мире Kubernetes в Дакке.
[06:51] => контейнер — наименьшая единица измерения в Kubernetes pod — наименьшая возможная единица измерения и
[06:58] => контейнеры создаются внутри модуля. Так оба атома следуют внутри капсулы,
[07:06] => там могут быть контейнеры, один или даже несколько контейнеров. Кроме того, существуют
[07:12] => общие тома и общие сетевые ресурсы для пример, общий IP-адрес. Это означает, что
[07:21] => все контейнеры внутри одного контейнера общие объемы и общий IP-адрес.
[07:29] => И вы должны иметь это в виду, если хотите создать несколько контейнеров внутри одного и того же
[07:35] => порт. Наиболее распространенный сценарий, конечно, состоит в том, чтобы иметь всего один контейнер на порт. Но иногда
[07:42] => когда контейнеры должны быть скреплены вместе , и они сильно зависят друг от друга, и они
[07:48] => может существовать в одном и том же пространстве имен, возможно для сортировки нескольких контейнеров в одном порту.
[07:56] => Но опять же, один контейнер на порт — наиболее распространенный вариант использования.
[08:04] => Также, пожалуйста, имейте в виду, что каждый порт должен быть расположенный на одном и том же сервере, невозможно
[08:11] => распределите контейнеры с одного порта по разным серверам кластера Kubernetes,
[08:18] => один банк, один сервер. Итак давайте теперь взглянем на этот кластер Kubernetes что это за Kubernetes
[08:27] => кластер состоит из узлов, узел фактически является либо сервером с открытым исходным кодом, либо виртуальным сервером. И
[08:36] => вы могли бы включить несколько серверов saij в Кластер Kubernetes, и они будут расположены в
[08:43] => разные центры обработки данных в разных частях мира. Но обычно узлы, принадлежащие одному и тому же
[08:50] => Кластеры Kubernetes расположены близко друг к другу , чтобы выполнять все задания более эффективно.
[08:58] => Внутри узла есть порты, которые снова являются наименьшей возможной единицей в Kubernetes
[09:06] => и внутри каждого порта есть контейнеры обычно по одному контейнеру на порт
[09:12] => и такие платы сортируются по разным узлам , и все это делается автоматически для вас
[09:20] => Kubernetes выполняет эту работу. Но, конечно, ваша задача состоит в том, чтобы создавать такие узлы и создавать кластеры на основе
[09:29] => на этих узлах. Узлы не будут автоматически Формируйте класс или без вашего вмешательства.
[09:35] => Но после такой начальной настройки все будет автоматизировано и Kubernetes
[09:40] => будет автоматически развертываться как на разных узлы. Но как эти узлы на самом деле взаимодействуют
[09:47] => с Чарльзом или и как они управляются. В кластере Kubernetes был главный узел
[09:56] => а другие узлы в кластере называются рабочими узлы. и главный узел фактически управляет рабочим
[10:03] => узлы. И если задание главных узлов распределять например, загрузка через другие рабочие узлы
[10:12] => и все платы, связанные с вашими приложениями, развернуты на рабочих узлах,
[10:19] => главный узел запускает только системные порты, которые отвечают за фактические
[10:26] => работу кластера Kubernetes в целом, мы могли бы также сказать, что главный узел в
[10:31] => Кластер Kubernetes на самом деле является плоскостью управления, и он не запускает ваши клиентские приложения.
[10:40] => Итак, какие службы на самом деле работают на разных узлы? Давайте взглянем на эту диаграмму.
[10:48] => Существуют такие сервисы, как cubelet, прокси-сервер куба и среда выполнения контейнера, и эти сервисы
[10:56] => присутствует на каждом узле кластера Kubernetes. Вы уже знаете, что такое среда выполнения контейнера
[11:03] => среда выполнения контейнера запускает фактические контейнеры внутри каждого узла, и что существуют такие контейнеры
[11:10] => время выполнения в качестве докера CRI o или контейнера D. Существует также такой сервис, как cubelet. И
[11:19] => такая служба на каждом рабочем узле обменивается данными с помощью службы BI-сервера на главном узле.
[11:28] => Служба Di-сервера является основной точкой связи между различными узлами в мире Kubernetes.
[11:37] => Прокси-сервер куба, который также присутствует на каждом узле, отвечает за сетевую связь
[11:44] => внутри каждого узла и между узлами. Кроме того, существуют и другие услуги, которые присутствуют
[11:53] => на главном узле. И они являются планировщиком, и такая служба отвечает за планирование
[12:00] => и распределение Лорда между разными узлами в классе.
[12:05] => Кроме того, был диспетчер контроллера куба, и эта единственная точка, которая фактически управляет всем в
[12:12] => кластер Kubernetes. И это контролирует на самом деле что происходит на каждом из узлов кластера.
[12:20] => Кроме того, там был менеджер облачных контроллеров. И его работа заключается в взаимодействии с поставщиком облачных услуг
[12:27] => где вы на самом деле запускаете свой кластер Kubernetes, потому что обычно вы не создаете такие кластеры
[12:34] => самостоятельно, используя только свои собственные серверы. Вместо этого вы могли бы очень легко запустить Kubernetes
[12:40] => кластер от одного из облачных провайдеров, который фактически выполняет почти автоматизированные
[12:45] => создание всех узлов и соединений между такими узлами. И для этого у вас есть
[12:52] => чтобы запустить службу диспетчера облачных контроллеров на этом главном узле. Также, например, если вы хотите
[13:00] => создайте развертывание вашего приложения внутри кластера Kubernetes, которое будет открыто
[13:06] => к внешнему миру и разрешать подключения извне, вы также можете создать IP-адрес балансировщика нагрузки
[13:13] => адреса. И эти балансировщики нагрузки. IP-адреса обычно предоставляются конкретными облачными провайдерами.
[13:22] => Также на главном узле есть такой сервис, как etc. И это сервис, который на самом деле хранит
[13:29] => все журналы, относящиеся к работе всего кластера Kubernetes. И такие журналы хранятся там в качестве ключевых
[13:38] => пары значений. Кроме того, существуют другие службы, которые работают на главном узле, например, DNS
[13:46] => служба, которая отвечает за разрешение имен, весь кластер Kubernetes. И, например,
[13:52] => используя службу DNS, вы можете подключиться к определенному развертыванию по имени соответствующего
[13:59] => служба развертывания. И таким образом, вы могли бы соединять различные развертывания с заданием или
[14:06] => это разные сервисы, которые работают на разных узлах кластера Kubernetes. И
[14:13] => основной службой на главном узле является API Sara. И, кстати, с помощью этого сервиса API-сервера,
[14:21] => на самом деле вы могли бы управлять целым кластером Kubernetes. Как это делается? Это делается с помощью
[14:28] => cube CTL или управление кубом. А управление кубом — это отдельная командная строка
[14:37] => инструмент, который позволяет подключаться к определенным Кластер Kubernetes и управляйте им удаленно.
[14:45] => И cube CTL может работать даже на вашем локальном компьютер. И используя такой инструмент cube CTL, вы могли бы
[14:52] => управляйте удаленным кластером Kubernetes. И используя такой инструмент, вы фактически подключаетесь с помощью REST API
[14:59] => к службе сервера API на главном узле. И такое общение происходит по протоколу HTTPS. Между прочим,
[15:08] => другие узлы в кластере, я имею в виду рабочие узлы , взаимодействуют с главным узлом таким же образом.
[15:15] => Это означает, что с помощью такого инструмента cube CTL вы можете управлять любым удаленным кластером Kubernetes.
[15:22] => Это для обзора архитектуры Kubernetes, и теперь вы знаете, что кластер Kubernetes
[15:27] => состоит из узлов, и один из узлов является главным узлом, и он управляет нашими другими узлами,
[15:34] => которые называются рабочими узлами. На каждом узле есть доски, и доски классифицированы
[15:41] => автоматически с помощью Kubernetes. А внутри порта есть контейнеры, обычно просто
[15:47] => единый контейнерный порт. Кроме того, пожалуйста, имейте в виду, что все контейнеры внутри порта
[15:53] => общее пространство имен для этого порта, например тома или сетевой IP-адрес. Кроме того, оба наших самых маленьких подразделения
[16:03] => в Kubernetes, и могут быть созданы порты, которые может быть удален, может быть перемещен с одного узла на
[16:10] => другой. Это происходит автоматически без ваше вмешательство. Но вы должны спроектировать
[16:16] => ваше приложение с учетом этого, оба могут быть удалено в любой момент времени. Кроме того, существуют
[16:24] => различные службы, работающие на разных узлы. Например, служба сервера API является центральной
[16:31] => точка связи между главным узлом и другими рабочими узлами. А также используя такой
[16:38] => сервисное обслуживание, вы действительно могли бы управлять фактическим Кластер Kubernetes с использованием инструмента cube CTL, который имеет
[16:45] => быть установленным, например, на вашем компьютере , если вы выполняете управление со своего компьютера.
[16:51] => Хорошо, я не хочу углубляться в детали Kubernetes, потому что
[16:56] => это очень сложный инструмент. И я хочу вместо этого больше сосредоточиться на практических задачах.
[17:03] => Вот почему сейчас, после такого обзора, мы вместе с вами погрузимся в практику и выполним
[17:10] => различные практические задачи вместе. Например, мы будем создавать развертывания, сервисы, масштабировать
[17:16] => развертывания, создайте пользовательский образ Docker и создайте развертывание на основе этого образа и так далее.
[17:23] => Для того, чтобы выполнять все практические задачи вместе со мной вам придется установить некоторые программы
[17:29] => на вашем компьютере. И теперь, когда мы говорим о необходимое программное обеспечение, и сначала мы должны создать
[17:35] => фактический кластер Kubernetes, где мы будем создавайте различные развертывания. Конечно,
[17:41] => вы можете создать кластер, используя сервисы одного из облачных провайдеров, таких как Amazon Web Services,
[17:47] => или Google Cloud, но вам придется заплатить за такое обслуживание. Если вам нужно бесплатное решение, вы могли бы
[17:54] => создайте класс для локально на вашем компьютере. И для этого существовал такой инструмент, как мини-куб.
[18:01] => И такой инструмент, по сути, создаст всего один узловой кластер. И этот узел будет
[18:06] => быть как рабочим узлом, так и главным узлом. Но для тестовых развертываний и в качестве игровой площадки,
[18:14] => это работает довольно хорошо, и все это бесплатно и будет запущено на вашем локальном компьютере.
[18:21] => Для успешного запуска mini cube у вас есть для использования виртуальной машины или диспетчера контейнеров.
[18:28] => И поддерживаются следующие менеджеры виртуальных машин или контейнеров
[18:33] => VirtualBox, VMware, Docker, Hyper V или parallels. Есть и другие доступные варианты.
[18:43] => Но вы должны использовать один из таких вариантов. Для того, чтобы фактически создать виртуальный узел,
[18:49] => который будет запускать все оба в вашем кластере Kubernetes.
[18:54] => Я предлагаю вам продолжить работу с Hyper V, если вы пользователь Windows. И если вы являетесь пользователем Mac OS,
[19:02] => вы могли бы использовать welchol box, он бесплатный и с открытым исходным кодом, или вы могли бы использовать VMware или
[19:09] => параллели. Кстати, также была возможность запустить mini cube в качестве контейнера внутри докера.
[19:19] => Конечно, если у вас на компьютере уже установлен Docker, вы можете использовать его для того, чтобы
[19:25] => для создания кластера Kubernetes с использованием mini cube и, по сути, он создаст отдельный докер
[19:31] => контейнер и внутри этого контейнера будут созданы все оба. Но я лично не рекомендую
[19:37] => для вас, чтобы продолжить работу с опцией Docker, потому что были некоторые ограничения. Например, я был
[19:42] => не удается изменить среду выполнения контейнера внутри контейнера Docker на CRY или контейнер D.
[19:50] => И поэтому я рекомендую вам использовать другие варианты, которые упомянуты здесь.
[19:55] => Кстати, Hyper V доступен в Windows компьютеры из коробки, и И вы могли бы
[20:00] => используйте его в качестве диспетчера компьютеров Butoh для запуска узла mini cube. Подведем итог с помощью мини-куба,
[20:07] => вы создадите кластер Kubernetes с одним узлом . Но, как я уже упоминал ранее,
[20:12] => вы должны использовать определенный инструмент для управления этот кластер. И этот инструмент называется cube CTL.
[20:20] => Кстати, cube CTL входит в состав mini cube. Но если вы хотите использовать такую включенную версию,
[20:27] => вам придется вводить команды CTL mini cube cube, это неудобно. Поэтому я рекомендую
[20:33] => вы должны установить cube CTL отдельно. И используя отдельная установка, вы сможете, из
[20:39] => курс для управления другими кластерами Kubernetes, которые расположены, например, в Amazon Web Services.
[20:46] => Итак, cube CTL также является одной из программ, которые вы необходимо установить на свой компьютер. Конечно, я буду
[20:53] => объясню вам, как установить mini cube и cube CTL. Кроме этого, мы также сделаем некоторое кодирование
[21:01] => в этом практическом курсе. И для этого у вас есть использовать один из редакторов кода, и я рекомендую
[21:08] => для вас, чтобы установить код Visual Studio, он открыт исходный код и бесплатный для использования. И если вы еще не сделали
[21:15] => установил его, пожалуйста, продолжайте и установите его. Кроме того, он имеет множество различных расширений, и один
[21:21] => одним из них является расширение Kubernetes. И используя такие расширение, которое вы могли бы очень быстро, например, отлично
[21:27] => Файлы конфигурации Yamo для ваших развертываний и служб в Kubernetes. Это все, что ты
[21:34] => необходим для этого курса мини-куб cube CTL и визуальный Студийный код. Теперь давайте начнем с практических
[21:40] => часть. И я надеюсь, что вам понравится этот курс. И мы начнем с установки мини-куба
[21:47] => и кубический CTL. Хорошо, ребята, теперь давайте начнем с практической части курса. И мы будем
[21:53] => начните с установки communication cube вместе с cube CTL. Но сначала я хотел бы попросить вас
[22:00] => перейдите к kubernetes.io . Это основной сайт , посвященный Kubernetes в целом, и на нем есть
[22:08] => вся документация, связанная с настройкой кластеров мини-кубов, созданием развертываний и т.д.
[22:14] => Пожалуйста, нажмите здесь на документацию. И здесь , в левом разделе, перейдите к началу работы.
[22:22] => И здесь вы можете прочитать, как вы могли бы создать среду обучения.
[22:26] => Наряду с этим вы также можете найти информацию как создать производственную среду. Но мы есть
[22:32] => сейчас заинтересован в создании локального кластера Kubernetes. И для этого мы будем использовать мини-куб.
[22:40] => А также мы установим трубный CTL. Вот почему а пожалуйста, нажмите здесь на эту гиперссылку для установки инструментов.
[22:48] => И найдите инструкции по установке cube CTL в разных операционных системах, пожалуйста, выберите
[22:56] => твой. Я выберу Mac OS здесь. И если вы являетесь Пользователь Mac OS, вы могли бы очень легко установить cube
[23:04] => CTL с использованием доморощенного позвольте мне продемонстрировать вам, как чтобы сделать это. Позвольте мне нажать на эту опцию. Запустить
[23:10] => команда установки brew install cube CTL Позвольте мне скопируйте эту команду и откройте терминал, который я использую
[23:17] => элемент на Mac и вставьте эту команду здесь. Давайте идите вперед и установите cube CTL. Пакет надзирателя
[23:30] => и был установлен cube CTL. Позвольте мне проверить версию cube CTL. Для этого я мог бы использовать
[23:37] => в этой версии CTL командного куба есть настольный клиент. Позвольте мне ввести его здесь.
[23:44] => И я вижу, что cube CTL был установлен успешно. И там была клиентская версия
[23:51] => мажор один и минор 22. И вот на самом деле была установлена точная версия.
[23:57] => Хорошо, если вы пользователь Windows, я рекомендую вам установить cube CTL с помощью диспетчера пакетов,
[24:06] => вы можете перейти к установке и настройке cube CTL на Windows и здесь выберите опцию установить в Windows
[24:13] => используя шоколад или совок. Нажмите на эту опцию , и здесь вы найдете инструкции по установке
[24:21] => различные пакеты, использующие диспетчер пакетов chocolaty или установщик командной строки scoop, я рекомендую
[24:27] => вам нужно установить менеджер пакетов chocolatey. Для того , чтобы сделать это, пожалуйста, откройте эту ссылку здесь и найдите
[24:35] => инструкции по установке этого менеджера пакетов для окон. Используя тот же менеджер пакетов, что и вы
[24:42] => также можно было бы очень легко установить mini cube. Так пожалуйста, продолжайте и установите этот менеджер пакетов
[24:48] => а затем следуйте этим инструкциям о том, как чтобы установить cube CTRL в Windows. Используйте только один
[24:56] => выполните эту команду, а затем проверьте, что куб CTL доступен с помощью этой команды. Все в порядке.
[25:04] => После этого я предполагаю, что cube CTL уже доступен на ваших компьютерах.
[25:09] => А теперь давайте продолжим и установим mini cube. Иди вернитесь на страницу «Начало работы» и здесь прокрутите вниз
[25:15] => перейдите в среду обучения и нажмите на гиперссылку установленные инструменты. В этом вы найдете игру
[25:22] => что вам нужно установить cube CTL. Это то, что мы просто сделали это вместе. И если вы прокрутите страницу вниз, вы увидите
[25:29] => найдите варианты, которые вы могли бы использовать для создания локального кластера Kubernetes для обучения и
[25:36] => цели тестирования. В настоящее время существуют такие инструменты , как kind, и они позволяют создавать Kubernetes
[25:43] => кластеризуйте локально на вашем компьютере, но для этого требуется Докер. Также есть мини-куб и куб ADM.
[25:51] => Мы будем использовать мини-куб на протяжении всего этого курса. Вот почему давайте начнем с установки
[25:58] => из мини-куба. Для этого не требуется докер. Но для этого требуется одна из виртуальных машин
[26:05] => менеджерам нравятся параллели Hyper V. Или, если вы хотите, вы также можете использовать Docker, пожалуйста, перейдите к
[26:14] => по этой ссылке мини-куб, вы можете просто ввести мини -куб в строке поиска Google и нажать на
[26:20] => первый результат на выходе. И здесь вы найдете документация о том, как начать работу с mini cube,
[26:28] => пожалуйста, нажмите на эту ссылку, чтобы начать. И здесь вы могли бы прочитать о мини-кубе и
[26:35] => это в основном создаст кластер Kubernetes локально на вашем компьютере.
[26:39] => И он будет содержать только один узел, который будет действовать как главный узел, так и рабочий узел.
[26:46] => И все, что вам нужно для того, чтобы создать такой кластер — это всего лишь запуск мини-куба с одной командой
[26:52] => вот так просто. Но для того, чтобы успешно создайте кластер мини-кубов, вам необходимо установить
[26:59] => один из менеджеров контейнеров или ваших виртуальных машин , таких как Docker, HyperCard, Hyper V parallels и
[27:06] => так далее. Я уже говорил вам, что если вы являетесь пользователем Windows, я рекомендую вам использовать Hyper V
[27:12] => потому что он доступен в Windows из коробки. Если вы являетесь пользователем Mac, я рекомендую вам перейти
[27:19] => впереди либо опция will toolbox, либо parallels , либо VMware Fusion beautiful box для нас бесплатна.
[27:28] => Поэтому, если вы не хотите ничего покупать для Менеджер виртуальных машин, я рекомендую вам перейти
[27:33] => вперед с этим вариантом. Кроме того, внутри контейнера можно создать мини-кубический кластер
[27:41] => Контейнер Docker, и для этого вы можете просто установить Docker. Но я лично не рекомендую
[27:46] => для вас, чтобы продолжить этот вариант, потому что существуют некоторые ограничения при запуске таких
[27:51] => стеклянная дверь внутри контейнера докера. Все прямо здесь, ниже, вы можете узнать, как установить
[27:57] => мини-куб на разных операционных системах Linux, Mac OS и Windows. Если вы являетесь пользователем Windows,
[28:03] => вы могли бы так же, как и в случае cube CTL, использовать choco латте, пожалуйста, выберите этот вариант и введите просто
[28:12] => одна команда choco установите mini cube просто , и вы получите установленный mini cube
[28:17] => на компьютере с Windows, но я использую Mac OS Вот почему я выберу этот вариант и выберу
[28:23] => доморощенный, и для того, чтобы установить mini cube с помощью brew, я мог просто ввести только одну команду brew
[28:29] => установите мини-куб. Позвольте мне пойти дальше и установить это с помощью варева. Давайте вернемся к терминалу и
[28:36] => здесь основана команда brew install mini cube. Давайте подождите немного, пока это не будет установлено. Хорошо, мини-куб
[28:45] => был установлен, и теперь я мог проверить его версию версия мини-куба. Вот была версия в моем случае
[28:53] => и вы также можете ввести команду СПРАВКИ mini cube , чтобы найти список всех доступных команд
[29:00] => в мини-кубе. А если вы прокрутите страницу вверх, то узнаете, как запустить локальный кластер Kubernetes,
[29:07] => получите статус локального кластера Kubernetes, остановите стекло или удалите и откройте панель мониторинга.
[29:15] => Также вы можете приостановить и отключить кластер Kubernetes прямо сейчас давайте создадим настоящий кластер
[29:23] => Я предполагаю, что теперь вы также установили mini cube и cube CTL. Эти инструменты представляют собой два отдельных
[29:30] => инструменты. Вот почему они доступны в виде двух отдельные команды mini cube и cube CTL.
[29:38] => А теперь давайте продолжим и создадим кластер Kubernetes . Для этого, пожалуйста, используйте команду mini cube
[29:45] => начните, но сначала давайте введем статус мини-куба , чтобы проверить текущее состояние кластера
[29:52] => статус мини-куба. Здесь я вижу , что профиль mini cube не найден
[29:56] => вокруг профиля мини-куба эти два профиля , а также лед, чтобы начать кластер,
[30:01] => Я должен запустить команду запуска мини-куба. Вот что мы собираемся сделать это прямо сейчас, давайте создадим кластер
[30:08] => старт мини-кубика. И здесь я хотел бы спросить вы должны запустить кластер мини-кубов с опцией.
[30:16] => И эта опция будет драйвером, и вы должны пишите с двумя тире, это водитель. И здесь
[30:23] => будет знак равенства. И после этого вы должны указать виртуальную машину или диспетчер контейнеров,
[30:29] => который вы бы использовали для создания кластера мини-кубов. Я уже упоминал об этом раньше
[30:35] => если вы являетесь пользователем Windows, я рекомендую вам использовать Hyper V. Поэтому, если вы используете Windows,
[30:41] => просто введите здесь, Hyper V вот так, все в нижнем регистре без тире есть этот знак равенства водителя.
[30:50] => V. Если вы являетесь пользователем Mac OS, вы могли бы пойти вперед с любым из этих вариантов VirtualBox
[30:56] => parallels или VMware Fusion, я буду использовать Виртуальный ящик. Если у вас нет с собой набора инструментов,
[31:03] => пожалуйста, продолжайте и установите его, и вот ваш набор инструментов, и нажмите на первую ссылку здесь.
[31:13] => Ваш набор инструментов свободен. А вот ссылка, по которой вы можете скачать свой набор инструментов. Так что, если ты этого не сделаешь
[31:20] => у вас есть свой набор инструментов, и если вы пользователь Mac OS, пожалуйста, скачайте свой набор инструментов.
[31:27] => Хорошо, я уже установил ваш набор инструментов. Вот почему я просто уточню
[31:32] => это как биография для этого варианта драйвера здесь. Поэтому я наберу Vertol box.
[31:40] => Давайте продолжим и создадим кластер мини-кубов внутри виртуальной машины VirtualBox в моем случае,
[31:46] => создание виртуальной машины toolbox количество процессоров, памяти и диска. Это займет некоторое время
[31:54] => Позвольте мне немного подождать, виртуальная машина была создана. И теперь я вижу сообщение о подготовке Kubernetes
[32:00] => на Докере. И это означает, что по умолчанию мы будет использовать среду выполнения контейнера Docker для
[32:06] => запуск реальных контейнеров внутри кластера Kubernetes. Здесь я вижу шаг создания сертификатов
[32:14] => и клавиши, загружающие плоскость управления. И, наконец, в конце я вижу, что CTL done cube не настроен на
[32:22] => используйте кластер мини-кубов. И это означает, что вы не нужно ничего делать для подключения
[32:28] => от cube CTL до фактического кластера мини-кубов. Это соединение было создано автоматически для вас
[32:34] => во время создания кластера мини-кубов. Кроме того, в моем случае я вижу такое предупреждение,
[32:41] => вы выбрали драйвер панели инструментов, но есть лучшие варианты для повышения производительности
[32:45] => и поддержка рассмотрите возможность использования другого драйвера Гиперкарты parallels или VMware. Теперь давайте на самом деле
[32:52] => проверьте статус этого кластера Kubernetes. И для этого вы можете ввести статус командного мини-куба.
[33:00] => И вы должны понять, что хозяин ироничен cubelet запущен, сервер API запущен и
[33:06] => конфигурация куба настроена. Это нормальное состояние кластера мини-кубов. И теперь мы на самом деле
[33:13] => возможность создавать службы развертывания и так далее внутри этого кластера мини-кубов. Кроме того, я бы
[33:20] => хотел бы упомянуть, что у меня не работает докер прямо сейчас. Я на самом деле установил его на этом
[33:26] => компьютер. Но здесь, на панели значков, я не вижу значка докера, это означает, что теперь Kubernetes включен
[33:33] => мой локальный компьютер не использует фактическую версию или установку на моем компьютере. Но есть Докер
[33:42] => который работает внутри узла мини-куба. И это то, что мы проверим прямо сейчас. Так как вы
[33:50] => уже известно, что каждый узел в кластере Kubernetes — это просто виртуальный или физический сервер. В нашем
[33:56] => в этом случае мы создали виртуальный сервер, и вы можете подключиться к любому серверу с помощью протокола SSH.
[34:04] => И для того, чтобы подключиться через SSH, нам сначала нужно чтобы узнать, какой IP-адрес был назначен
[34:11] => Узел Kubernetes. Мини-куб предоставляет команду для этого. Просто введите IP-адрес mini cube, и вы получите
[34:18] => посмотрите, какой IP-адрес был назначен виртуальному машина, на которой работает наш узел Kubernetes, который
[34:26] => был создан mini cube, в моем случае он был адресом , просто возьмите этот IP-адрес, а затем,
[34:33] => введите SSH Docker это имя пользователя по умолчанию имя пользователя для такого узла такая красивая Сара
[34:42] => и после добавления подпишите баланс мини -кубической заметки, а затем, пожалуйста, нажмите enter
[34:56] => вам будет предъявлен отпечаток пальца, пожалуйста продолжайте и введите здесь в качестве вывода средств такие
[35:02] => отпечаток пальца. После этого вам будет предложено ввести пароль по умолчанию для mini cube. Ваш
[35:09] => эта машина является пользователем постоянного тока, пожалуйста, продолжайте и введите это здесь. Таким образом, имя пользователя темнее, а пароль — DC
[35:18] => был введен пароль пользователя. И теперь я см. приветственное приглашение из мини-куба
[35:23] => Сара. Теперь я нахожусь внутри узла Kubernetes. И первая команда, которую я хотел бы задать
[35:32] => вы должны войти сюда в докер ps. Такая команда перечислит все, что вы запускаете в контейнерах Docker.
[35:39] => А вот и куча разных контейнеров которые были созданы внутри узла Kubernetes.
[35:46] => И еще раз, пожалуйста, напомните, что Docker является средой выполнения контейнера по умолчанию для Kubernetes.
[35:53] => Существуют и другие среды выполнения контейнеров, такие как CRI O и контейнер D. Но здесь мы видим, что там
[36:00] => представляют собой кучу разных контейнеров, которые были созданный докером внутри заметки mini cube.
[36:06] => И, например, здесь я вижу такой контейнер, как сервер cube API, планировщик кубов и так далее.
[36:14] => Напомним, что мы обсуждали с вами различные сервисы, работающие на главных узлах
[36:19] => и рабочие узлы. И эти услуги на самом деле работает внутри контейнеров, как вы видите справа
[36:26] => теперь здесь. Кроме того, существуют такие контейнеры, как поставщик прокси-хранилища cube, или, например,
[36:34] => основной DNS. И опять же, у каждого контейнера есть свое предназначение. Вот как вы могли бы проверить, какой
[36:42] => контейнеры были созданы внутри узла Kubernetes . Но если я введу здесь команду cube CTL, я
[36:49] => появится сообщение об ошибке команда cube CTL не найдена, так как команда cube CTL недоступна внутри
[36:56] => Куб узла Kubernetes cube CTL — это внешний инструмент, который используется для управления кластером Kubernetes
[37:03] => таким образом, давайте теперь выйдем из этого SSH-соединения соединение было закрыто. А теперь давайте воспользуемся кубом
[37:09] => Здесь доступна команда CTL куба роста CTL локально на наших компьютерах, потому что мы установили
[37:16] => cube CTL прежде чем давайте сначала проверим класс на предмет информации cube CTL кластеризует эту информацию, и я получаю следующее
[37:25] => выходная плоскость управления Kubernetes запущена. И здесь я вижу IP-адрес, который мы только что видели после
[37:32] => ввод IP-команды mini cube. В вашем случае, конечно, такой IP-адрес будет другим.
[37:38] => А также я вижу, что основная служба DNS также работает. Это означает, что теперь мы действительно можем
[37:47] => создавать службы развертывания и так далее на нашем Кластер Kubernetes. Но сначала давайте перечислим узлы
[37:54] => которые доступны в нашем кластере Kubernetes. Для этого, пожалуйста, введите команду cube CTL get
[38:01] => узлы. И здесь я вижу только один узел, потому что мини-куб создает кластер с одним узлом, он был
[38:09] => имя такого статуса узла готово. И вот они роли управляющего самолетом и ведущего. Мы это поймем
[38:17] => теперь внутри нашего мини-кубического кластера. Этот сингл узел действует как главный узел, так и рабочий узел и
[38:24] => на рабочем узле Kubernetes создает различные болты, связанные с вашими развертываниями, которые вы развертываете
[38:31] => в кластере Kubernetes. Теперь позвольте мне проверить, какой порты доступны или прямо сейчас в этом кластере.
[38:38] => Для этого давайте введем команду cube CTL получить модули, и теперь я вижу вывод без ресурсов
[38:45] => найдено в пространстве имен по умолчанию. Давайте перечислим все доступные пространства имен
[38:53] => теперь в этом кластере Kubernetes. Для этого, пожалуйста , введите команду cube CTL, чтобы получить такие пробелы в именах.
[39:01] => И я вижу несколько пространств имен, таких как куб по умолчанию пространства имен узла, общедоступного куба и системы кубов
[39:11] => используются в Kubernetes для группировки различные ресурсы и объекты конфигурации.
[39:18] => И если вы введете просто куб CTL получите капсулы, вы будете смотрите только порты, доступные внутри по умолчанию
[39:25] => пространство имен здесь. И, кстати, все порты, которые будет создавать повсюду баллы, будет здорово
[39:32] => в пространстве имен по умолчанию, но мы еще не создали никаких портов до сих пор. Вот почему давайте
[39:39] => попробуйте выяснить, какие порты работают внутри других наших пространств имен, например, cube system. В
[39:47] => чтобы перечислить порты в определенном пространстве имен, вы должны использовать опцию пространства имен. Итак, куб
[39:55] => CTL. Достань капсулы. Вот пространство имен, знак равенства , а здесь введите систему кубов. Давайте пойдем дальше и побежим
[40:02] => эта команда. И теперь здесь, в этом пространстве имен кубическая система, я вижу такие доски, как гордиан
[40:10] => etcd, в котором хранятся все журналы всего кластера Kubernetes, куба, сервера API, контроллера куба, куба,
[40:18] => прокси-сервер, расписание куба и поставщик хранилища. Все эти болты являются системными шариками, которые работают на
[40:25] => эта главная записка. Хорошо, вот как мы могли бы узнать, какие порты работают прямо сейчас в нашем
[40:33] => Кластер Kubernetes. Теперь давайте пойдем дальше и создадим оба вручную. И для этого мы могли бы использовать
[40:40] => команда, аналогичная команде запуска docker. Но с помощью команды docker run вы можете создать
[40:45] => просто один контейнер Docker здесь, или вы могли бы используйте команду cube CTL Run для создания
[40:52] => только один порт. Давайте сделаем этот пробег cube CTL здесь будет назван. Давайте, например, использовать nginx
[41:01] => Изображение докера, доступное в Docker Hub. Для этого давайте введем здесь имя порта Nginx.
[41:07] => А затем давайте добавим опцию image, и ее значение будет Ingenix Ingenix. Здесь
[41:14] => это имя изображения докера, которое будет автоматически извлечено и будет создан новый контейнер
[41:22] => на основе этого изображения и этого контейнера будет будет работать внутри порта Kubernetes.
[41:29] => Давайте пойдем дальше и посмотрим, что произойдет. Куб CTL Iran Ingenix делает это изображение знаком равенства
[41:35] => Ingenix и здесь я вижу выходной порт Ingenix. Здорово. Давайте введем команду cube CTL, чтобы получить банки.
[41:44] => И вот теперь я вижу, что однопортовый nginx еще не готов. И вместо него создали контейнер.
[41:54] => Давайте снова введем ту же команду cube CTL get pods , и теперь я вижу, что эта плата теперь запущена, это
[42:00] => готово, и оно имеет статус запущено. Конечно , для создания такого модуля потребовалось некоторое время, потому что
[42:08] => внутри него был контейнер nginx и докер внутри узла Kubernetes
[42:15] => на самом деле было запрошено извлечь изображение nginx из Концентратор докеров и создайте соответствующий контейнер
[42:23] => на основе поискового изображения Ingenix. Дайте нам знать , узнайте подробности об этом конкретном порту.
[42:30] => по имени Nginx. Это имя мы указали здесь вручную. Для этого, пожалуйста, введите команду cube CTL
[42:38] => опишите порт, и здесь будет название порта, который вы хотели бы описать, чтобы получить подробную информацию о
[42:46] => здесь будет Ingenix. Это имя порта запуска. И есть много разных деталей, связанных с
[42:52] => этот конкретный порт. Позвольте мне прокрутить немного вверх. И здесь я узнаю такую информацию, как пространство имен
[43:01] => этот порт принадлежит и был автоматически назначен пространству имен по умолчанию. Вот почему мы были
[43:08] => смогли увидеть это в списке, когда мы ввели команду cube CTL получить модули, потому что такие списки команд
[43:16] => все они находятся внутри пространства имен по умолчанию. Вот информация об узле, где находится такой конкретный порт
[43:24] => было создано или сохранено, что Kubernetes автоматически распределяет нагрузку по всем узлам рабочие узлы
[43:31] => внутри кластера, и он выбирает конкретный узел для конкретного содержания доски информация о
[43:38] => узел, на котором был создан этот конкретный порт. В нашем кластере с одним узлом, конечно, вы будете
[43:45] => смотрите один и тот же узел каждый раз, когда вы создаете какой-либо порт, и вот IP-адрес такого узла
[43:52] => здесь с указанием времени запуска указаны метки статуса запущено. А вот адрес B, который
[43:58] => был приписан к этому конкретному порту 172 17 03. Но, пожалуйста, знайте, что теперь мы
[44:06] => не сможет подключиться к этому конкретному порт, использующий такой внутренний IP-адрес или порт.
[44:13] => Чтобы иметь возможность подключаться к портам, вы должны создавать сервисы в Kubernetes.
[44:18] => И это то, что мы рассмотрим немного позже. Здесь или ниже вы также можете узнать, какие
[44:24] => контейнеры были созданы внутри этого порта. И здесь был только один контейнер, который был
[44:31] => такого контейнера здесь был длинный идентификатор здесь было изображение который был использован для этого конкретного контейнера.
[44:38] => И это то изображение, которое было указано с помощью опции dash dash Image при создании нового порта.
[44:45] => Здесь был идентификатор изображения, и это идентификатор изображения из концентратора докеров, потому что по умолчанию Kubernetes тянет
[44:52] => все изображения из концентратора докеров. Конечно, можно настроить Kubernetes для извлечения изображений
[44:58] => из других репозиториев. Службы записи, но по умолчанию это Докер-хаб. Хорошо, это рассказы о
[45:06] => этот конкретный порт. И мы узнаем, что этому порту был назначен адрес B, был
[45:13] => контейнер, который был создан внутри этого порта. И вот журналы, связанные с созданием этого
[45:20] => конкретный порт. Вы видите, что этот конкретный порт был успешно назначен на минуту, которую вы отмечаете здесь
[45:27] => было сообщение о том, что движок изображений X из концентратора докеров успешно извлек созданный образ
[45:34] => Контейнерный движок X и запустил контейнер Ingenix. А это значит, что теперь появился контейнер nginx
[45:42] => работает внутри сетевого порта. Опять же, вы можете найти список всех лодок, введя команду
[45:48] => cube CTL получает модули, и здесь была одноплатная плата , доступная прямо сейчас в пространстве имен по умолчанию. Сейчас,
[45:57] => давайте быстро вернемся снова внутрь Узел мини-куба Kubernetes и, наконец, снова,
[46:04] => Контейнеры Docker, и мы обнаружим, что теперь появился еще один контейнер, который был создан
[46:10] => в экспорте двигателя. Поэтому, используя стрелку вверх, я мог бы вернитесь к команде SSH, которую я ввел ранее.
[46:18] => Вот он и снова подключитесь к этому узлу. Входить Пароль пользователя TC. И давайте введем сюда докера
[46:26] => ps. Но теперь давайте отфильтруем вывод по имени ngi NX. И теперь я узнаю, что есть два
[46:36] => разные контейнеры здесь был первый, а вот второй, которые связаны с двигателем X.
[46:45] => Вот название контейнера для тяги, Высоты nginx nginx по умолчанию и так далее.
[46:52] => А также там был еще один контейнер GAE восемь спортивных nginx по умолчанию и так далее.
[46:59] => И этот второй контейнер называется контейнер для патронов. Вот вы видите, что
[47:04] => внутри контейнера , в котором фактически был запущен исполняемый файл, один контейнер был оценен
[47:12] => и если Dogra — это среда выполнения контейнера в Kubernetes, всегда есть такие оба контейнера,
[47:20] => которые создаются для каждого конкретного порта. И такие почтовые контейнеры создаются для того, чтобы
[47:28] => допустим, посмотрите пространство имен определенного порта. И мы уже обсуждали, что все контейнеры внутри
[47:35] => одной и той же платы фактически разделяют пространства имен. И этот контейнер, который на самом деле запущен в нашем nginx
[47:43] => веб-сервер будет остановлен, может быть воссоздан с помощью Кубернетес. Но и то, и другое остается нетронутым. И это
[47:52] => второй контейнер, который называется контейнером boss , необходим для сохранения пространства имен порта.
[47:59] => Хорошо, вот как сейчас выглядят контейнеры. И давайте на самом деле подключимся к этому контейнеру
[48:07] => где мы запускаем службу nginx. В порядке для подключения к контейнеру вы можете использовать любой идентификатор
[48:13] => этот или это имя. Давайте подключимся к контейнеру по этому идентификатору, пожалуйста, выберите это
[48:20] => контейнер примечание: приостановите контейнер. И давайте введем команду Docker Exec. Это удостоверение личности здесь было удостоверением личности
[48:30] => контейнер. И давайте соединим этот контейнер с помощью Исполняемый файл SHA. Теперь я внутри контейнера.
[48:37] => Давайте проверим его имя хоста. Гениальный. На самом деле это название правления. И было присвоено то же имя
[48:46] => к этому контейнеру. И давайте также проверим IP адрес этого контейнера вот такой адрес был 172 17
[48:54] => 03. И это тот IP-адрес, который мы видели в деталях порта. Теперь давайте попробуем
[49:01] => подключитесь к веб-серверу, который работает внутри этого контейнера, в котором мы сейчас находимся, используя
[49:07] => этот IP-адрес. И для этого мы могли бы использовать команду see URL, а здесь основаны на IP-адресе
[49:14] => из этого конкретного контейнера. Как бы то ни было, мы находимся внутри контейнера nginx.
[49:20] => Давайте попробуем установить связь. И вот я вижу Добро пожаловать на страницу nginx, которая была возвращена этим
[49:28] => веб-сервер. Это означает, что веб-сервер nginx запущен и работает. Давайте выйдем из этого контейнера и
[49:37] => сейчас мы все еще находимся внутри узла Kubernetes. Хорошо, но мы подключились к нему по SSH. И теперь
[49:43] => давайте так же выйдем из этой связи. А теперь давайте введем следующую команду cube CTL
[49:50] => получите модули, которые все белые, и с помощью такой опции вы также найдете IP-адрес конкретного
[49:58] => порт в этом выводе — тот же IP-адрес, который мы только что видели внутри контейнера.
[50:06] => Давайте теперь попробуем подключиться к такому адресу P с нашего компьютера, наш компьютер является внешним по отношению к
[50:15] => наш кластер Kubernetes, потому что узел Kubernetes работает внутри виртуальной машины.
[50:20] => И этот IP-адрес был назначен докером к определенному контейнеру внутри узла.
[50:28] => Давайте попробуем подключиться к такому IP-адресу, я мог бы используйте ту же команду CRL. Здесь он доступен
[50:35] => на Mac. Или вы можете просто открыть веб-браузер и подключиться к этому IP-адресу. И ты найдешь
[50:41] => выходит, что вы не сможете подключиться к контейнеру engine X таким образом. Потому что, как я уже сказал
[50:48] => вами ранее, такой IP-адрес является внутренним IP-адресом порта, и вы не можете подключиться к такому
[50:54] => портвейн извне выкатился за пределы классной комнаты. Здорово. Вот как мы создали самую первую доску в
[51:02] => наш кластер Kubernetes. И мы также исследовали хвост коммутатора. И я надеюсь, что теперь это так
[51:09] => вам ясно, что происходит, когда вы создаете доску внутри контейнера port Kubernetes grades.
[51:16] => И для того, чтобы создать контейнер, он должен извлечь изображение из концентратора докеров.
[51:20] => И в нашем примере изображение nginx было извлечено, и на основе этого изображения был создан новый контейнер.
[51:27] => Кроме того, мы зашли внутрь контейнера и убедились , что веб-сервер nginx теперь действительно запущен.
[51:35] => Но мы не можем подключиться к такому порту извне , потому что теперь у него есть только внутренний IP
[51:41] => адрес, который был назначен докером. Но , конечно, создание порта с использованием cube CTL Выполняется
[51:46] => команда не очень удобна, потому что вы не способен масштабироваться. И, например, увеличить
[51:53] => количество портов, был только один порт, который мы создали с помощью команды cube CTL Run.
[51:59] => Вот почему теперь давайте просто удалим созданный порт, для этого есть команда cube CTL Delete.
[52:07] => Далее будет название ресурса, который мы хотели бы удалить и Диспорт, и там будет имя
[52:12] => порта в нашем примере Ingenix, потому что мы указали имя сайта для порта вручную, когда
[52:19] => мы ввели команду запуска cube CTL. Так что давайте идите дальше и удалите порт, купленный Ingenix
[52:27] => удалено, cube CTL получает модули, и в пространстве имен по умолчанию не найдено ресурсов и такого порта
[52:35] => просто исчез. И все тома все пространства имен связанные с этим конкретным портом были удалены.
[52:45] => Здорово. Вы могли заметить, что мы вошли в куб Команда CTL несколько раз и, на мой взгляд,,
[52:52] => такая команда относительно длинная. И мы способны создать псевдоним для такой команды, чтобы сохранить
[52:59] => когда-нибудь в будущем. И мы могли бы использовать псевдоним преобразуйте команду CTL всего в одну букву K.
[53:06] => А затем мы введем такие команды, как K получить порты. Но теперь, если я введу команду поиска,
[53:12] => Я получу команду не найдена ошибка потому что я еще не создал никаких псевдонимов.
[53:18] => В операционных системах, подобных Linux, вы можете очень легко создавать псевдонимы, введя псевдоним команды.
[53:26] => Далее будет псевдоним для команды, затем знак равенства, а после знака равенства в двойных кавычках вы
[53:32] => можете написать команду, которую вы хотели бы использовать под псевдонимом в нашем примере cube CTL, если вы являетесь пользователем Windows
[53:39] => и если вы используете PowerShell, эта команда будет не работать там. Если вы хотите получить аналогичное
[53:47] => мой опыт работы в командной строке, я рекомендую вам установить Git Bash. Для того, чтобы установить
[53:53] => это, пожалуйста, перейдите, чтобы получить SCM-связь и просто скачайте Git. Если get уже установлен на вашем
[54:00] => Компьютер с Windows, у вас уже есть доступ к Git Баш, это еще один терминал. Если у вас нет
[54:07] => Установлен Git пожалуйста, перейдите в раздел Windows здесь и скачайте git для Windows, есть разные
[54:14] => ссылки, чтобы поесть. И после установки, пожалуйста, откройте Терминал Git Bash вместо powershell. Так
[54:22] => У меня уже есть команда псевдонима, доступная в этом терминале на Mac OS. Поэтому я смогу
[54:28] => чтобы создать такой псевдоним, давайте создадим LS Был создан LS, и теперь я могу использовать только короткий
[54:35] => версия команды K получает модули, и теперь я вижу , что в пространстве имен по умолчанию не найдено ресурсов.
[54:42] => С этого момента я буду использовать такую короткую версию команды cube CTL
[54:47] => но, пожалуйста, обратите внимание, что такой псевдоним будет удален только во время этой сессии в терминале. После стольких
[54:54] => компьютера или когда вы открываете другой сеанс терминала. Этот псевдоним исчезнет.
[54:59] => Если вы хотите, я бы хотел создать постоянный псевдоним, конечно, можно сделать,
[55:03] => для выполнения такой задачи вам необходимо отредактировать свой профиль конфигурации оболочки. Но я буду
[55:09] => не делайте этого прямо сейчас, достаточно иметь только временный псевдоним. Здорово. А теперь давайте продолжим. как я
[55:17] => как упоминалось ранее, создавать неудобно отдельные порты внутри кластера Kubernetes,
[55:22] => потому что вы не можете масштабировать и увеличивать количество портов.
[55:27] => Поэтому наиболее распространенный способ создания несколько портов, когда вы сможете
[55:33] => увеличить количество портов, количество степеней, изменить конфигурацию и т.д. Можно с помощью развертывания.
[55:41] => И развертывание будет отвечать за создание фактических портов. Но, пожалуйста, обратите внимание, что все
[55:48] => порты внутри развертывания будут одинаковыми, точно такими же. Но вы могли бы создать несколько
[55:54] => копии одной и той же платы и распределяют нагрузку между разными узлами кластера Kubernetes,
[56:00] => это цель развертывания. Теперь давайте идите вперед и создайте развертывание. И мы будем
[56:06] => используйте то же изображение, которое мы использовали до того, как оно стало изображением nginx. А также впоследствии мы увеличим
[56:14] => количество портов в этом развертывании. И также мы создадим сервис для этого развертывания
[56:20] => для того, чтобы иметь возможность подключаться к нашему развертыванию с внешних устройств. Давайте пойдем дальше и создадим
[56:26] => развертывание размера. И для этого мы будем используйте CTL командного куба, создайте развертывание,
[56:32] => мы уже создали псевдоним для команды cube CTL. Это почему я буду вводить ключ для создания развертывания.
[56:40] => И далее будет указано название развертывания. Давайте назовем его Ingenix. А потом,
[56:46] => давайте также укажем изображение аналогично тому, как мы делали в cube CTL, выполнив команду. И здесь после знака равенства
[56:54] => будет именем образа, который мы хотели бы использовать для этого развертывания. И давайте войдем сюда
[57:00] => Nginx. Чтобы избежать путаницы, давайте изменим название этого развертывания. И давайте
[57:06] => назовите его, например, Ingenix. Такое развертывание , давайте продолжим и создадим это развертывание.
[57:15] => развертывание было создано с помощью ant или команды K приступайте к развертыванию. Он был одинок.,
[57:23] => он готов и обновлен. И давайте войдем в капсулы K get. И теперь я вижу, что единой платы нет
[57:32] => который управляется этим конкретным развертыванием. И такая Доска была создана автоматически
[57:38] => после того, как мы создали такое развертывание. И теперь этот порт управляется этим развертыванием. Там был
[57:48] => на данный момент только один порт. И, конечно же, одноразовое для масштабирования количество портов и
[57:57] => градусы хотели иметь порт, например 235 и так далее. Но сначала, прежде чем сделать это,
[58:02] => давайте подробнее рассмотрим развертывание размера. И для этого давайте введем команду «описать
[58:09] => развертывание. И здесь будет имя о развертывании развертывания nginx.
[58:17] => Вот подробные сведения о созданном развертывании. Давайте прокрутим немного вверх. И вот в самом начале
[58:23] => на выходе я вижу название механизма развертывания X развертывание. Это то имя, которое было дано
[58:30] => для этого развертывания нами здесь было пространство имен, в котором было создано наше развертывание sash пространство имен по умолчанию
[58:38] => ниже вы увидите, что Kubernetes автоматически присвоил все метки этому конкретному развертыванию.
[58:43] => И там была только одна надпись со знаком равенства развертывание движка X. Также есть аннотации,
[58:52] => опять же, автоматически созданная здесь аннотация. И он также был селектором селекторы используются
[58:58] => для того, чтобы соединить платы с чертежами. Потому что в Kubernetes платы и развертывания
[59:04] => на самом деле это отдельные объекты. И мы должны знать, как назначать конкретные доски конкретным
[59:11] => развертывания. И здесь мы видим селектор вверх по знаку равенства развертывания nginx и для определенного порта,
[59:19] => который был автоматически создан и назначен для этого развертывания мы найдем ярлык с
[59:26] => то же значение при развертывании nginx со знаком равенства, мы рассмотрим это буквально через минуту.
[59:32] => Кроме того, там было поле реплики, и здесь вы могли найти информацию о количестве досок,
[59:40] => которые требуются для этого развертывания и фактического количества запущенных портов
[59:47] => здесь был только один порт, одна реплика, которая желательна, одна обновленная, одна общая и одна доступная.
[59:55] => Это значит, что теперь остался один порт который назначен для этого развертывания
[60:01] => Он также был текущим обновлением типа стратегии, которое рассказывает, как выполнять обновления развертываний.
[60:08] => Мы вернемся к этому немного позже в этом курсе. А также ниже вы найдете другие подробности
[60:14] => об этом конкретном развертывании. Здесь вы найдете всю подробную информацию об обоих шаблонах.
[60:21] => И, как я вам только что сказал, вы найдете внутри порта соответствующую метку
[60:26] => развертывание nginx со знаком равенства. И то же самое метка упоминается здесь в селекторе
[60:33] => поле в развертывании. И именно так развертывание подключается к определенным портам.
[60:42] => Кроме того, если вы прокрутите немного вниз, вы найдете фактические события, связанные с этим конкретным развертыванием.
[60:49] => И здесь мы видим набор реплик масштабирования одного события . Но что такое реплика, установленная немного выше вас
[60:57] => посмотрите новое развертывание набора реплик nginx и идентификатор набора реплик. И набор реплик фактически управляет
[61:06] => все шары, связанные с развертыванием. А набор реплик — это набор реплик вашего приложения,
[61:14] => потому что вы могли бы создать 510 100 разных платы в одном и том же развертывании. И все они
[61:20] => включены в набор реплик. И это почему здесь вы видите, что набор реплик этого размера был
[61:27] => масштабирован до одного, и в этом был создан один порт набор реплик. Отлично, вот подробности о
[61:37] => это конкретное развертывание. А теперь давайте устроим взгляните еще раз на список портов, которые получают модули
[61:43] => здесь был только один порт и обратите внимание на его название. Он начинается с имени набора реплик,
[61:50] => который мы только что обсуждали. И так в выводе деталей развертывания,
[61:55] => развертывание nginx и этот хэш, а затем был определенный хэш для этого конкретного порта.
[62:03] => И если в одном и том же порту имеется несколько портов развертывание, принадлежащее к тому же набору реплик,
[62:09] => здесь вы увидите ту же графику, но другую хэши здесь для разных портов. Сейчас,
[62:15] => там будет один порт, который готово, и мы просто перемалываем. Кроме того, мы могли бы
[62:21] => получите подробную информацию об этом конкретном порту, давайте возьмем его название и введем здесь, чтобы описать
[62:29] => доска. А здесь давайте вставим корпоративный хэш. И вот подробная информация об этом конкретном порту.
[62:35] => Давайте прокрутим вверх. Он был одним из доска, которая совпадает с этим именем.
[62:40] => Ему было присвоено пространство имен по умолчанию, такое же, как и при развертывании. Вот узел, где этот конкретный
[62:48] => модуль работает прямо сейчас, вот метки этого конкретного порта. И я вижу такой ярлык, как
[62:54] => до развертывания nginx и хэша шаблона порта. Обратите внимание, что этот хэш равен этому
[63:01] => гашиш. И он совпадает с идентификатором набора реплик . Кроме того, ИГИЛ, которое работало здесь, было IP
[63:08] => адрес правления. И здесь я вижу, что это контролируется определенным набором реплик, набором реплик
[63:15] => развертывание nginx. А вот хэш набора реплик, который управляет этим конкретным портом.
[63:23] => Кроме того, вот подробная информация о контейнерах которые работают внутри порта. И
[63:27] => здесь был идентификатор контейнера и изображение, которое использовалось для создания контейнера в этом конкретном порту.
[63:36] => Кроме того, в конце вы могли бы найти журналы, связанные с портом, как мы обсуждали ранее, успешно
[63:43] => назначенный определенному пулу узлов, изображение nginx и так далее. Так вот, там было развертывание.
[63:50] => И вместо развертывания был набор реплик . И порты не управляются этим развертыванием.
[63:56] => Теперь там был только один порт. Здорово. Теперь давайте попробуем масштабировать это развертывание и увеличить количество
[64:03] => из портов внутри развертывания. Теперь для этого был единственный порт, который мы могли использовать
[64:09] => следуя команде cube CTL. Вкратце, Кей, в нашем случае масштаб, мы хотели бы расширить развертывание.
[64:17] => Давайте прямо здесь развернемся. Название развертывания в нашем случае — Nginx. Это развертывание.
[64:25] => А потом давайте уточним одну из реплик мы хотели бы иметь в этом развертывании право
[64:30] => сейчас. Теперь там будет одна копия. Для того , чтобы указать желаемое количество реплик,
[64:37] => мы могли бы добавить сюда реплики опций, а затем после знак равенства, укажите количество реплик.
[64:44] => Допустим, мы хотим увеличить масштаб до пяти копий. Давайте введем файл здесь. И давайте расширим наше развертывание.
[64:52] => развертывание было масштабировано, и теперь давайте введем команду ворота получают голоса. И я вижу, что есть четыре Новых
[65:00] => контейнеры, которые в настоящее время создаются. Здесь был один порт, второй, третий и четвертый
[65:09] => порт. И этот порт все еще работает. Через мгновение вы должны увидеть, что все пять болтов будут запущены.
[65:16] => Вот они. Мы только что расширили наше развертывание до пяти разных копий. И теперь их пять
[65:25] => разные модули, работающие прямо сейчас внутри нашего Кластер Kubernetes. И заметьте, как это легко,
[65:33] => мы не создавали эти шары вручную, Kubernetes автоматически масштабировал это развертывание для нас.
[65:41] => Обратите внимание, что все эти порты имеют один и тот же префикс, это имя набора реплик, все эти порты
[65:48] => принадлежать. И эти детали разные для разных портов. И снова все оба бегут.
[65:56] => Давайте также прочитаем подробную информацию о тех портах, которые будут включать IP-адреса, давайте добавим здесь,
[66:01] => вариант этот весь белый. И я прослежу, чтобы каждый порт имеет другой IP-адрес здесь или здесь, здесь,
[66:10] => здесь или здесь. И все эти болты были классифицированы только на мини-кубе с одним узлом, потому что снова,
[66:17] => мы здесь просто кластер с одним узлом. Если бы вы управляли несколькими узлами, конечно, многое было бы
[66:25] => распределенный по разным узлам. И вы бы увидели, что полюса были отнесены к разным
[66:32] => узлы. Хорошо, теперь давайте попробуем уменьшить масштаб количество реплик в этом развертывании. от
[66:38] => от пяти до, скажем, трех. Давайте вернемся к этой команде, K, масштабное развертывание развертывания nginx. И
[66:45] => здесь давайте уточним, что я хочу сделать реплики как три таких. развертывание было масштабировано, давайте приступим
[66:51] => доски. И я вижу, что сейчас их всего три платы установлены и запущены, два порта были удалены. Здорово.
[67:01] => Теперь давайте попробуем подключиться к одному из портов. Например, у этого был изъят его IP-адрес.
[67:07] => И до этого мы уже пытались подключиться к одному из портов с нашего локального компьютера, и снова наш
[67:13] => локальный компьютер является внешним по отношению к кластеру Kubernetes, это очень, очень важно. Давайте попробуем
[67:20] => подключитесь к этому IP-адресу CRL и вставьте IP-адрес и подключение не выполнены успешно.
[67:26] => Давайте теперь зайдем внутрь узла мини-куб и попробуем подключиться к этому порту любым из этих портов
[67:33] => изнутри узла. И это будет означать, что мы пытаемся подключиться к порту внутри
[67:39] => скопление. Давайте снова подключимся по SSH к нашему узлу mini cube в качестве sage, Docker, apt и этого IP-адреса. В
[67:52] => в вашем случае этот IP-адрес, конечно, отличается паролем является пользователем постоянного тока. А теперь давайте посмотрим URL-адрес и введем
[68:01] => IP-адрес одного из портов. Любой порт работает здесь. Итак, давайте посмотрим URL, и я смог подключиться
[68:09] => к определенному порту по его IP-адресу. Давайте попробуем подключиться к другому порту с другим IP-адресом.
[68:15] => Например, список y 0.3. Я не уверен, смогу ли я иметь такой запущенный порт. Да, у меня есть. И я тоже
[68:22] => получил ответ от такого порта с таким безграничным напомним, что теперь я нахожусь внутри узла.
[68:29] => И я могу подключаться к портам, которые запуск на этой конкретной заметке с использованием IP-адресов
[68:36] => из этих портов. Давайте выйдем из этого узла. И опять же, давайте перечислим порты вместе с адресом. Так
[68:43] => Я смог подключиться к этому порту и этому порту из узла. Но, конечно, такие IP-адреса
[68:51] => назначаются обоим динамически, когда вы оба созданный. И вам не следует полагаться на IP-адреса
[68:59] => из портов, если вы хотите подключиться к определенному порту. Поэтому неудобно
[69:06] => используйте такие IP-адреса. И вы должны использовать какие-то другие IP-адреса, которыми управляют
[69:13] => Kubernetes и которые позволяют подключаться к любому из портов внутри развертывания.
[69:21] => Позвольте мне показать вам, как это сделать. В Kubernetes. Вы должны создать так называемые сервисы, если хотите
[69:27] => хотите подключиться к определенным развертываниям с помощью конкретные IP-адреса. И есть разные
[69:33] => доступные опции вы могли бы создать так называемые IP-адрес кластера и такой IP-адрес будут созданы
[69:41] => и назначены для конкретного развертывания, и вы будете иметь возможность подключиться к этому конкретному развертыванию
[69:47] => вся внутренняя часть кластера, использующая этот виртуальный ip-адрес. И Kubernetes будет распространять много
[69:55] => через разные порты, которые назначены для конкретного развертывания, но, пожалуйста, знайте, что такие
[70:01] => Адрес API будет всего лишь одним IP-адресом для всего развертывания. И, конечно же, это гораздо больше
[70:08] => удобнее использовать такой адрес API, чем конкретный IP-адреса портов, как мы только что попробовали.
[70:14] => Кроме того, была возможность создать внешний IP-адрес адреса для открытого развертывания во внешнем мире. И
[70:23] => можно предоставить конкретное развертывание IP-адресу узла или использовать балансировщик нагрузки
[70:33] => или получить внутреннюю часть кластера Kubernetes, возможно иметь несколько узлов, и оба могут быть
[70:39] => распределенный по разным узлам. Поэтому наиболее распространенным решением является наличие IP-адреса балансировщика нагрузки
[70:46] => адрес, который будет единственным для всего Кластер Kubernetes для конкретного развертывания.
[70:52] => И вы сможете подключиться к вашему развертывание независимо от того, где оба оцениваются
[70:58] => используя только один внешний IP-адрес. Но такой IP-адреса балансировщика нагрузки обычно назначаются
[71:05] => конкретный облачный провайдер, такой как Amazon Web Services или Google Cloud. И такие задания выполняются
[71:12] => диспетчер облачных контроллеров — это служба, запущенная на главном узле. Давайте теперь попробуем
[71:18] => создайте IP-адрес кластера для нашего развертывания. И мы будем создайте для этой конкретной службы. Так что мы уже
[71:26] => создав развертывание, давайте прочитаем подробную информацию о развертывании размера, хорошо, приступайте к развертыванию.
[71:35] => Кстати, вы могли бы сократить такую длинную дорогу просто для того, чтобы вот так развернуться, развернитесь. И здесь
[71:41] => так называлась наша дислокация. Теперь есть три разных порта, которые уже
[71:46] => в этом развертывании. Давайте теперь создадим службу для этого конкретного развертывания.
[71:52] => И используя сервис, вы могли бы разоблачить определенный порт из развертывания.
[71:58] => Сейчас мы используем три разных порта. И внутри каждого порта был nginx
[72:04] => контейнер. И по умолчанию веб-сервер nginx работает на порту 80. Это означает, что мы должны
[72:11] => предоставьте доступ к внутреннему порту 80 из контейнеров любому другому продукту за пределами развертывания.
[72:20] => И мы могли бы выбрать, например, Порт 8080. Для этого конкретного примера,
[72:25] => чтобы открыть внутренний порт из портов развертывания, вы должны выполнить команду устройства
[72:31] => разоблачение, давайте введем развертывание «разоблачение геев». Здесь будет указано название развертывания, мы бы
[72:39] => хотелось бы создать сервис для развертывания nginx. Здесь было название нашей дислокации. Резюмировать
[72:47] => что мы не упоминаем здесь порты, мы работаем с развертывания. И порты управляются развертываниями.
[72:56] => Итак, давайте представим развертывание механизма развертывания X здесь будет опция порт, давайте укажем порт
[73:03] => который мы хотели бы использовать в качестве внешнего порта для нашего развертывания. И давайте установим его на порт 8080.
[73:11] => А также мы должны добавить сюда целевой порт, если привезенный внутри контейнеров отличается
[73:18] => из этого продукта, который мы указываем прямо сейчас здесь. И в нашем примере прямо сейчас, приведенном внутрь
[73:24] => контейнер выдержан. Вот почему мы должны добавить здесь опция делает этот целевой порт равным знаку 80
[73:33] => Таким образом, мы открываем внутренний порт из контейнеров для внешнего продукта 88. И
[73:40] => мы делаем это для имени героя развертывания. Хорошо, давайте представим развертывание nginx
[73:49] => механизм развертывания службы был раскрыт, и теперь меньше всего услуг для того, чтобы была команда
[73:57] => геи получают услуги. И теперь есть две службы , одна из которых является системной службой по умолчанию. Это
[74:06] => называемый тип Kubernetes — идентификатор кластера, и здесь является IP-адресом кластера. А также здесь мы видим одного
[74:14] => более серьезное развертывание nginx. Он был именем, он был типом IP-адреса кластера, а здесь был IP-адрес кластера.
[74:24] => И этот IP-адрес полностью отличается от IP-адреса, назначенного порту
[74:31] => этот IP-адрес даже из другой сети IP-адреса платы начинаются со 172. И
[74:38] => здесь этот IP-адрес начинается с 10, и это виртуальный IP-адрес, созданный Kubernetes
[74:47] => и это всего лишь один IP-адрес, который может может использоваться для подключения к любому из портов
[74:57] => и такой тип кластерного IP-адреса позволяет вам подключаться к конкретному развертыванию в нашем примере nginx
[75:05] => развертывание только внутри кластера Kubernetes. Например, если в вашем Kubernetes
[75:11] => кластер, было развертывание базы данных, например, была база данных MongoDB или мой SQL
[75:17] => база данных. И поисковая база данных не должна быть доступна и доступна извне.,
[75:23] => вы можете создать кластерную IP-службу для такого развертывания базы данных и других развертываний
[75:30] => внутри вашего кластера Kubernetes мы сможем для подключения к развертыванию базы данных с помощью кластера
[75:37] => ip. Но опять же, развертывание сеанса будет скрыто от внешнего мира. Но, с другой стороны, если вы
[75:44] => создайте любое развертывание веб-службы, и оно должно быть доступным извне, конечно, у вас есть
[75:50] => чтобы открыть его внешнему миру, используя порт узла или балансировщик нагрузки. Это то, что мы попробуем немного позже.
[75:58] => IP-адрес кластера будет доступен только внутри кластера.
[76:03] => Итак, здесь мы видим IP-адрес кластера. Вот оно , а вот приведенное, которое было выставлено
[76:11] => нашим развертыванием. Кроме того, вы можете получить список служб, используя короткую версию этой команды,
[76:19] => просто введите имя, чтобы получить SVC, это сокращенная версия услуг SVC. И результат будет тот же самый. Там
[76:27] => теперь есть две разные службы с этими последними тремя IP-адресами, одна для службы Kubernetes,
[76:34] => и это для службы развертывания nginx. А теперь давайте попробуем подключиться к нашему развертыванию
[76:42] => используя эту услугу. Давайте возьмем этот IP-адрес кластера. И давайте сначала попробуем подключиться к этому кластеру IP
[76:51] => адрес с нашего локального компьютера. Посмотрите URL-адрес и вставьте этот IP-адрес. А после холода давайте
[76:59] => также добавьте порт, который мы выставили. Это внешнее порт для нашего развертывания. Внутренне это будет
[77:06] => прокси-сервер на порт 80 в каждом контейнере. Давайте попробуем работает ли это на нашем локальном компьютере или нет
[77:12] => КРЛ. И я не вижу никакого ответа. Это то, что я тебе только что сказал. IP-адрес кластера недоступен
[77:21] => за пределами кластера Kubernetes. Такое поведение IP-адреса кластера является просто внутренне доступным IP-адресом
[77:29] => адрес, но вы можете получить доступ к IP-адресу кластера с любого узла. И давайте попробуем это сделать. Давайте перейдем к нашему
[77:38] => узел. Позвольте мне вернуться к этой команде, SSH Dogra и IP-адресу пользователя node DC. И давайте
[77:46] => теперь попробуйте подключиться к IP-адресу кластера с узла. И здесь снова давайте укажем порт 8080. И я вижу
[77:54] => результат Добро пожаловать в Ingenix. И этот ответ был предоставлен одним из портов в развертывании.
[78:05] => Конечно, теперь, исходя из этого вывода, я не могу чтобы узнать, какой порт точно мне ответил.
[78:12] => Но этот ответ был предоставлен одним из портов в развертывании.
[78:18] => Я мог бы попробовать еще раз. Снова и снова, и я получаю ответ от портов в развертывании.
[78:24] => Вот как это работает. IP-адрес кластера — это всего лишь один IP, который был оценен как услуга для конкретных
[78:33] => развертывание. И вы могли бы использовать только один IP для подключения к любому из портов
[78:40] => и за кулисами Kubernetes выполняет все проксирование запроса на конкретный выбранный порт и
[78:47] => это сильно балансирует между различными портами в развертывании. Хорошо, давайте закроем эту связь
[78:55] => бесконечное нет также читайте рассказы о конкретной услуге, мы доберемся туда с помощью команды K get SVC
[79:02] => короткая версия для получения услуг, и он был назван о сервисе, который мы создали раньше. Давайте возьмем
[79:09] => это имя и прямо сейчас K опишите услугу и название услуги, которую мы хотели бы получить подробнее
[79:17] => примерно здесь был IP-адрес Глостера, который мы только что использовали для подключения к этой серии. Также там
[79:24] => был внешним рубежом, а здесь был порт таргетт. И есть три разные конечные точки. Те
[79:31] => конечные точки указывают конкретные порты, которые используются для подключения к данному конкретному кластеру
[79:39] => ip. Таким образом, нагрузка будет сбалансирована между этими тремя разными портами. И заметьте, здесь повсюду порт
[79:48] => 80. Он широко предназначен для нашего сервиса, Dysport, ad — порт по умолчанию, на котором запущен сервер Ingenix. Так что
[79:56] => ОБЪЯВЛЕНИЕ и объявление также здесь Вы видите тип IP-адреса кластера услуг, и здесь также присутствует селектор
[80:07] => знак равенства При развертывании. И вот как эта услуга на самом деле подключается к определенным портам.
[80:15] => Все эти порты также имеют особую маркировку развертывание nginx. И этот ярлык был создан
[80:24] => Кубернетес. Автоматически мы не указывали это, потому что мы только что создали развертывание
[80:29] => использование команды развертывания сетки. И мы создал службу с помощью команды expose.
[80:35] => Пространство имен здесь используется по умолчанию, как и для обоих и развертывания, которое называется Nginx. Развертывание.
[80:43] => Хорошо, вот и все для этой службы. И мы раскрыли наше развертывание с использованием кластерного IP-адреса.
[80:50] => А IP-адрес кластера доступен только внутри кластеров Kubernetes. Теперь вы знаете, как
[80:56] => создание порта, как создать развертывание, как масштабировать развертывание и как создать службу
[81:01] => для конкретного развертывания. И мы используем Изображение Ingenix, доступное в Docker Hub.
[81:09] => А теперь пришло время перейти к следующему шаг в нашем плане. И я обещал тебе, что
[81:13] => мы создадим пользовательский образ докера, нажмем на него в Docker Hub, а затем развертывание сетки
[81:20] => основываясь на этом изображении. И это то, что мы будем делай следующее. Но прежде чем сделать это, давайте удалим
[81:26] => существующее обслуживание и развертывание для того, чтобы иметь чистая, скажем так, настройка. Итак, давайте удалим развертывание
[81:32] => развертывание удаления ключа. И здесь будет имя развертывания развертывания nginx.
[81:40] => А также, давайте удалим серию, удалим серию Развертывание Ingenix, подобное этой службе, было удалено
[81:51] => также. Давайте теперь перечислим развертывания, чтобы развернуть их, короткую версию развертываний,
[81:57] => ресурсов не найдено, и давайте перечислим услуги гей получает только одну услугу по умолчанию с
[82:06] => названный Kubernetes. Мы готовы идти. И теперь давайте создадим очень простое приложение Node js.
[82:13] => Они заключаются в том, что мы будем использовать экспресс-веб-сервер упакуйте и создайте наш собственный веб-сервер.
[82:20] => Планируйте этот следующий шаг, следуя правилам мы не будем создавать веб-приложение GS Express и
[82:26] => мы настроим веб-сервер таким образом, чтобы он ответит именем хоста сервера.
[82:33] => Когда мы подключаемся к нему, используя корневой URL-адрес и тому подобное таким образом, мы сможем определить, какой порт
[82:40] => на самом деле отвечает на конкретный запрос. Мы также будем Докер видит такое приложение, используя файл докера
[82:48] => и команда сборки докера. А затем нажмите создать образ докера в Docker Hub. И наконец,
[82:55] => мы создадим развертывание, используя такой специально созданный образ. Вы могли бы найти весь окончательный проект
[83:02] => файлы в репозитории GitHub, вы найдете ссылку на него прямо сейчас здесь. Но я настоятельно рекомендую
[83:08] => вы можете создать такое приложение самостоятельно даже если вы мало что знаете о ногах и экспрессе.
[83:15] => И, конечно же, я рекомендую вам построить ваше пользовательское изображение и нажмите на свой концентратор докеров
[83:20] => счет. Конечно, вы можете использовать изображения , доступные в Моей учетной записи. Они являются публичными,
[83:26] => это зависит от тебя. Так что давайте не будем открывать код Visual Studio. Если у вас его нет, пожалуйста, установите его.
[83:32] => Я открою его. И здесь, в визуальной студии Код, пожалуйста, откройте встроенный терминал, нажмите клавишу
[83:39] => комбинация Ctrl назад, как будто этот терминал был открыт. А теперь давайте создадим папку для
[83:46] => файлы нашего проекта. Я установлю компакт-диск на рабочий стол. И здесь, используя команду создать каталог, я создам
[83:52] => папка gate eight S расшифровывается как Kubernetes. Как вы уже знаете, давайте посмотрим папку 2k eight s и
[84:00] => вы можете открыть любую папку с помощью команды code dot если вы правильно установили код Visual Studio.
[84:07] => Если такая команда недоступна на вашем компьютер, вы могли бы нажать комбинацию клавиш
[84:12] => Команда Shift B или Ctrl Shift B в Windows и здесь введите золото и выберите Показать команду установить
[84:21] => команда gold в пути, а затем вызванная команда будут доступны с любого терминала.
[84:28] => Так что у меня есть эта команда, уже доступная в прошлом. Вот почему я открою папку с Рыцарями
[84:34] => в редакторе кода Visual Studio. Итак called.it откроется в новом окне таким образом.
[84:42] => Теперь эта папка полностью пуста и в ней нет файлов. Позвольте мне снова открыть встроенный терминал здесь.
[84:49] => Он будет открыт в папке Knights. И теперь здесь давайте создадим папку для нашего первого проекта.
[84:56] => И это имя папки будет будь, скажем так, геем. восьмерки,
[85:01] => этот веб-привет, потому что мы создадим очень простое веб-приложение, которое будет просто отвечать
[85:09] => привет от Сары и имя сервера. Такой веселый веб-привет. И вот в этой папке
[85:16] => мы создадим приложение Node js. Давайте послушаем в папке terminal CD для загрузки веб-привета, например
[85:23] => тот. А вот броски мы будем инициализировать узлом приложение js. И для того, чтобы сделать это, вы должны
[85:30] => установите NPM на свой компьютер. Если у вас нет никакого Доступны GS и NPM, пожалуйста, перейдите в раздел «Загрузка без GS».
[85:42] => Вот ссылка, скачайте no Gs и установите no GS с вашего компьютера он будет установлен вместе
[85:49] => с НПМ. Конечно, мы не будем запускать приложение с использованием Node js на наших компьютерах, мы будем
[85:58] => вместо этого запустите приложение внутри контейнера в кластере Kubernetes.
[86:03] => Но для того, чтобы инициализировать проект локально и установить зависимости, вы должны использовать
[86:10] => НПМ. Поэтому, пожалуйста, не устанавливайте никаких GS вместе с НПМ. После этого НПМ должен
[86:16] => становятся доступными на вашем компьютере. Я спрячу эту боль в спине. А теперь позвольте мне поучаствовать в этом.
[86:25] => И я инициализирую этот проект. И вы могли бы добавить сюда опцию dash, которая будет
[86:30] => сохраните все ответы для вас во время инициализации нового проекта node js. Так что NPM в этом, вот почему
[86:38] => Новый проект был инициализирован. И здесь вы должны найти теперь пакет JSON-файла с
[86:44] => такое содержимое, название версии проекта и так далее. А теперь давайте установим пакет под названием Express
[86:52] => и установите Экспресс. Это будет загружено из реестра NPM
[87:01] => пакет был установлен и упакован в JSON файл был обновлен, зависимость не вызывалась
[87:08] => Экспресс. Итак, теперь давайте создадим файл index js в нашей папке Heights web Hello.
[87:17] => Кстати, обратите внимание, что теперь появились узловые модули папка, в которой содержатся все зависимости нашего
[87:22] => проект. Но теперь безопасно просто удалить это папка, нам это больше не нужно, потому что мы будем
[87:29] => не запускайте этот проект локально с помощью узла. Поэтому просто выберите эту папку и удалите.
[87:36] => Хорошо, теперь у нас есть только пакет JSON и запишите в журнал файлы JSON. Здорово. Сейчас
[87:42] => давайте создадим файл и создадим его внутри папки gay eight s web Hello. Итак, новый файл,
[87:48] => и давайте назовем это точкой индекса m j s y m, потому что мы будем использовать синтаксис шести модулей EF, который
[87:58] => доступно в Node js, начиная с версии 13. И если вы хотите использовать инструкции импорта,
[88:05] => вместо инструкций require вы должны называть файлы с расширением MJS. Итак, давайте создадим
[88:12] => индекс файла точка MJS. И здесь я не умру за содержание всего приложения, я просто скопирую
[88:20] => их для того, чтобы сэкономить немного времени. Так что вставляй сюда. Если вам бы хотелось, чтобы вы, конечно, могли написать это очень
[88:27] => крошечное приложение самостоятельно. Поэтому мы импортируем Экспресс из экспресс-посылки. Мы также импортируем масла из
[88:34] => масла масла не встроены в модуль GS. А потом мы создаем экспресс-приложение здесь — порт 3000.
[88:43] => Вы можете указать любой другой порт, если хотите нравиться. И это тот порт, где находится наша экспресс-сеть
[88:49] => сервер будет работать внутри контейнера. Здесь мы добавляем обработчик маршрута для URL-адреса с косой чертой.
[88:57] => Это URL-адрес маршрута. И мы просто отвечаем клиенту текстом «Привет» с их имени хоста.
[89:06] => используя пакет, мы получаем имя хоста сервера. И в ответе от сервера вы
[89:13] => увидите просто текстовое сообщение «Привет» оттуда и название сервера, на котором запущено это приложение.
[89:20] => Итак, отправленные аресты мы отправили клиенту такие сообщение, а также мы регистрируем его на консоли.
[89:27] => И, наконец, мы запускаем Экспресс-веб-сервер Обновление слушайте, и мы начнем с этого порта
[89:34] => 3000 и веб-сервер запустится, мы посмотрим на сообщение консоли веб-сервер прослушивает порт
[89:41] => и там был портвейн. Я не буду погружаться глубже в эти объяснения и синтаксис узла GS, потому что это
[89:48] => не старый курс GS. Но у тебя есть идея. Мы создайте очень простой веб-сервер, который будет отвечать
[89:54] => с таким текстовым сообщением. Итак, давайте сохраним изменения в этом файле. Нажмите CTRL S в Windows или команду S на
[90:02] => Mac нравится, что изменения были сохранены. А теперь давайте закрепите это приложение, и для этого мы будем
[90:10] => создайте файл Dockerfile. Теперь я рекомендую вам установить расширения под названием Docker и Kubernetes.
[90:18] => Так что перейдите в раздел Расширения здесь и войдите в докер здесь. Выберите Dogra и нажмите кнопку Установить. В моем случае,
[90:26] => Расширение Docker уже было установлено. И после этого, пожалуйста, также установите Kubernetes
[90:32] => расширение, найдите его таким образом и тоже установите. В моем случае расширение Kubernetes
[90:38] => был установлен ранее. Так что теперь мы готовы идти. А также для того, чтобы создать реальный образ докера,
[90:46] => вы должны запустить Docker на своем компьютере. Раньше мы не разрешали докеру запускать мини-куб
[90:53] => Кластер Kubernetes. Но теперь нам нужен докер , чтобы создать образ докера. Вот почему
[91:00] => пожалуйста, продолжайте и установите Docker. Если он не установлен на вашем компьютере и/или не загружен докером.
[91:09] => перейдите по этой ссылке и установите Docker desktop, который доступен для Windows
[91:16] => Mac OS. А также вы могли бы установить Докер непосредственно в системах, подобных Linux.
[91:21] => Поэтому, пожалуйста, продолжайте и установите Docker. впоследствии. Пожалуйста, запустите его, я буду запускать его вот так. Я уже
[91:28] => установил его раньше. Теперь здесь я вижу иконку Догра , здесь я вижу информацию об этом.
[91:36] => Я немного подожду. А пока давайте создадим Файл Dockerfile внутри веб-страницы K-s Привет
[91:43] => папка. Потому что мы не создаем никаких отдельных обязательств в корневой папке Heights.
[91:49] => Итак, давайте создадим файл Docker здесь новый файл и назовите его Dockerfile вот так.
[91:57] => Обратите внимание, что код Visual Studio распознает тип этого файла и добавил панель настройки значков. И
[92:04] => здесь, в файле Docker, инструкции по добавлению в реальном времени как мы хотели бы создать пользовательский образ докера.
[92:10] => Я снова возьму содержимое этого файла Docker и вставлю сюда, чтобы сэкономить немного времени. И
[92:17] => существуют следующие инструкции. Мы будем использовать узел Используйте в качестве базового изображения для вашего пользовательского изображения. Здесь
[92:25] => мы устанавливаем рабочий каталог как косую черту. Далее, мы открыть порт 3000. После этого мы поднимемся сюда, чтобы
[92:33] => файлы упаковывают JSON и упаковывают пули в JSON, которые присутствуют здесь. А затем мы запускаем npm
[92:42] => установите, когда мы создадим этот пользовательский образ. И после установки NPM мы копируем все
[92:49] => оставшиеся файлы из этой папки, в которой находится наш файл Docker. В нашем примере это будет просто
[92:55] => индекс одного файла указывает на NGS. И этот файл будет совсем немного в папке приложения внутри изображения.
[93:06] => Если вы не знакомы с этими шагами и не знаете, что означают Rockdoor, экспорт и так далее,
[93:12] => Я настоятельно рекомендую вам найти сбой докера Курс и пройти его, чтобы понять
[93:18] => как работает Docker и как вы можете создавать собственные изображения. Этот курс не является курсом докера.
[93:24] => Итак, мы проходим через все оставшиеся приложения файлы для создания целевой папки вверх. И, наконец, мы
[93:30] => добавьте команду CMD, которая обозначает команду, которая фактически указывает, какая команда будет
[93:37] => будет выполняться, когда будет запущен соответствующий контейнер, основанный на этом пользовательском перестроенном изображении.
[93:44] => И мы хотим запустить команду npm start. Но что произойдет сейчас, если мы войдем в нпм
[93:50] => начните с нашей папки проекта. Давайте попробуем это сделать. Давайте сохраним эти изменения в файле Docker, сохраним.
[93:57] => И давайте снова откроем встроенный терминал. Я я все еще нахожусь в папке «Веб-привет». И
[94:04] => вот в этой папке был индекс как в файле GS. И здесь давайте введем команду npm start.
[94:13] => И то, что я вижу, я вижу отсутствующий запуск сценария. Теперь наше обязательство ничего не позволит
[94:21] => если вы введете команду запуска npm. Для того, чтобы иметь возможность запускать наш веб-сервер, запустите веб-сервер,
[94:27] => нам нужно изменить файл package dot JSON. Давайте сделаем это. Давайте откроем пакет JSON-файла и
[94:35] => здесь вы найдете раздел скрипты, а там был всего лишь один тест сценария по умолчанию. Давайте
[94:43] => на самом деле замените тест на запуск таким образом. И здесь в двойных кавычках введите точку индекса узла MJS.
[94:55] => Итак, теперь будет сценарий запуска
[94:59] => и он, по сути, будет работать с использованием файл узла индексирует оба NGS. И это
[95:06] => фактически запустится наш экспресс-веб-сервер на порту 3000. Это то, что мы здесь обсуждали.
[95:14] => Мы сохранили изменения в пакете в файле JSON. Теперь доступен установленный NPM.
[95:21] => И теперь мы можем создать свой имидж. Если вы хотите создать собственное изображение, вам необходимо использовать
[95:28] => Команда сборки докера. И обычно эта команда вводится в папку, где находится ваш файл Docker
[95:35] => находится. Вот эта папка в нашем примере здесь, и если я перечислю здесь файлы и папки, я
[95:41] => найдет файл Docker. И содержимое файла Docker здесь с работы, каталог разоблачения и так далее, выполните CMD
[95:52] => теперь давайте создадим образ докера. А также мы добавим технологии в этот созданный на заказ образ докера.
[96:00] => И это будет включать все имя пользователя вашей учетной записи в Docker Hub. Если вы этого не сделаете
[96:07] => у вас есть учетная запись Docker Hub, пожалуйста, перейдите в hub docker.com и создайте учетную запись. Я уже
[96:15] => у меня есть учетная запись, и вот мое имя пользователя. Пожалуйста создайте свою учетную запись и выберите свое имя пользователя.
[96:22] => И после этого вы сможете подтолкнуть репозитории в Docker Hub под вашей учетной записью.
[96:29] => И когда вы нажимаете репозитории, вы найдете их здесь, в разделе репозитории. Сейчас,
[96:36] => под моей учетной записью в этом пространстве имен нет репозиториев. Итак, давайте вернемся в Visual Studio
[96:44] => код. И здесь давайте создадим собственное изображение для нашего приложения. Давайте воспользуемся командой Docker build. Следующий
[96:53] => будет путь к файлу Dockerfile. Я буду использовать просто точку , потому что теперь я нахожусь внутри папки, где Docker
[97:00] => файл был создан. Так что Докер строит точку. Следующий, давайте добавим тег к нашему изображению, используя опцию SD,
[97:08] => затем будет указано имя пользователя вашей учетной записи GitHub. В моем случае я напечатаю свой. И после пореза,
[97:16] => Я дам имя хранилищу. Давайте назовем это то же самое, как мы назвали эту папку, гей восемь
[97:25] => это веб делает Привет. Как это. Давайте построим это изображение с помощью команды сборки Docker. Создайте образ
[97:37] => обратите внимание, что в моем случае базовое изображение уже было присутствующие в кэше и другие слои также были
[97:45] => кэшированный. И, наконец, образ был создан. Теперь, если Я ввожу команду, устанавливаю изображения и добавляю grep
[97:54] => и здесь будет сеть К восьми, которую я найду изображение, которое теперь доступно в наших локальных изображениях
[98:02] => хранилище. Здесь было название изображения, которое мы только что построенный. Это последнее, потому что в этой команде
[98:10] => который я только что ввел, я не указал тег, который здесь вы можете указать столбец «после». Но я
[98:16] => построенное изображение с более поздним стеком. Так вот почему технологии здесь самые современные. А вот идентификатор сборки
[98:25] => изображение и размер изображения. Теперь давайте предположим , что это стоило только создания образа для Docker Hub. В
[98:32] => для этого вам необходимо сначала сделать заказ в Docker Hub. Для этого, пожалуйста, введите команду Docker login.
[98:41] => Я уже входил в систему раньше. Вот почему Docker использовал кэшированные учетные данные, и вход в систему прошел успешно.
[98:49] => В вашем случае, если вы впервые войдете в систему Docker , вам будет предложено
[98:54] => введите логин и пароль Docker Hub. Теперь я возможность отправить этот образ сборки в Docker Hub.
[99:02] => Для этого я буду использовать команду docker push и здесь будет название изображения, которое я хотел бы
[99:09] => для отправки в службу хостинга удаленного репозитория. Мистер Сюй Кей, привет из Интернета. Давайте пойдем дальше и подтолкнем его
[99:19] => использование колоды по умолчанию для перемещения различных слоев изображения
[99:27] => это займет некоторое время, потому что имидж Израиля тоже большой. Итак, вы видите ожидание всех этих слоев.
[99:37] => И, наконец, это изображение было перенесено в Docker Hub. Позвольте мне проверить, что оно появилось здесь.
[99:44] => Обновите страницу, и теперь там были ворота восьмое изображение веб-приветствия. Замечательный.
[99:51] => Это изображение, кстати, является публичным и вы также можете использовать его
[99:55] => для ваших развертываний Kubernetes. Изображение готово и готово добавить концентратор докеров. И теперь мы можем
[100:02] => чтобы создать развертывание Kubernetes на основе этого изображение. Давайте сделаем это. Давайте подойдем к здешнему терминалу.
[100:09] => И давайте создадим новое развертывание. Кстати, сейчас развертываний нет, ключ, приступайте к развертыванию.
[100:17] => Никаких развертываний не было, получите услуги SVC, никаких услуг, только один Kubernetes. Оно
[100:24] => является значением по умолчанию. А теперь давайте создадим новое развертывание на основе специально созданного образа.
[100:30] => Для этого давайте сначала используем ту же команду, что и раньше, хорошо, отличное развертывание. Хорошо, отлично
[100:37] => развертывание. Давайте назовем это S. Web. Здравствуйте. И следующим будет вариант изображения. И изображение будет
[100:47] => быть припрятанным в моем кейсе, слэш гей восемь паутина. Здравствуйте, то же имя, что и здесь
[100:57] => когда я помещаю это изображение в докер Концентратор и то же имя, как я вижу здесь.
[101:06] => Итак, вот мое имя пользователя. А вот и название репозитория Docker.
[101:10] => Давайте продолжим и создадим развертывание на основе этого образа. Конечно, если вы выполнили все
[101:18] => делайте шаги самостоятельно и подталкивайте клиента к построению изображение в Docker Hub под вашей учетной записью,
[101:23] => вы можете использовать здесь свое имя пользователя. Так давайте продолжим и создадим новое развертывание.
[101:31] => развертывание было создано с помощью модулей K get. Теперь я вижу , что статус создания контейнера — это статус этого
[101:40] => порт, который был создан для этого развертывания. Давайте проверим еще раз, все еще создавая контейнер,
[101:47] => потому что требуется некоторое время, чтобы извлечь изображение из Докер-хаб. И теперь я вижу, что контейнер запущен.
[101:55] => Прямо здесь находится название контейнера. И вот хэш набора реплик, который был создан
[102:03] => путем развертывания. И здесь был конкретный хэш для этого конкретный порт. Теперь давайте создадим сервис, используя
[102:12] => кластерный IPL. И попробуйте подключиться после этого на наш веб-сервер, который работает с использованием
[102:20] => никакого GS Express. Итак, давайте создадим сервис. Для этого мы представим ключ порта для развертывания.
[102:30] => Здесь будет указано название развертывания гей-восьмерки паутина. Здравствуйте. Далее давайте добавим опцию
[102:37] => и напомним, что наш экспресс-веб-сервер работает в порту 3000. Давайте вернемся к нашему приложению.
[102:44] => Перейдите к файлу index dot NGS. И вот этот порт 3000. И мы могли бы в принципе разоблачить это
[102:52] => к тому же внешнему порту, который будет использоваться для подключения к развертыванию, давайте использовать для
[102:58] => что для этого нам не понадобится всего один толчок опция целевого порта. Вот почему давайте добавим этот порт
[103:05] => знак равенства 3000 вот так. И это создаст кластерный IP-адрес для развертывания на веб-хостинге.
[103:14] => Давайте пойдем дальше и создадим сервис с наименьшим количеством услуг получите SVC.
[103:21] => А вот и недавно созданный сервис. Здесь было название службы, а здесь был IP-адрес кластера,
[103:27] => который был создан Kubernetes. И снова, используя такой IP-адрес, мы сможем подключиться к нашему
[103:35] => развертывание, это означает, что вы можете подключиться к любому из портов, вы не выбираете, какой порт
[103:41] => вы будете подключены к Kubernetes, выполняющему эту работу для тебя. И вот мы видим, что мы открыли порт 3000
[103:49] => открытый порт 3000. Давайте попробуем подключиться к этому кластеру по IP и порту 3000. Позвольте мне подняться сюда, это
[103:57] => IP-адрес кластера и, конечно же, я не смогу подключиться к этому IP-адресу кластера со своего локального компьютера.
[104:05] => Вот почему давайте, как обычно, быстро подключимся к нашему узлу mini cube в качестве докера sage по этому IP-адресу
[104:16] => 50 911. В вашем случае этот IP-адрес отличается. Здесь. Наш пароль — пользователь постоянного тока. И теперь здесь
[104:24] => давайте посмотрим URL-адрес для IP-адреса кластера и порта 3000. Это тот порт, который был открыт при развертывании. Так
[104:34] => давайте продолжим, и я вижу сообщение «привет» от веб-сайта gate eight s «Привет» и полное имя
[104:41] => сервера, на котором фактически запущено приложение Express no GS. И это то послание, которое приходит
[104:51] => с веб-сервера Express здесь. Вот где мы отправляем его обратно клиенту привет от
[104:57] => и назовите имя хоста сеанса. над тем, где выполняется это обязательство. И это означает, что все
[105:04] => работает отлично. Мы создали развертывание основываясь на специально созданном изображении, которое мы
[105:12] => перенесен в Докер-хаб. И вот результат этого и мы видим ответ от приложения веб-сервера.
[105:20] => Замечательный. Кстати, если вы введете команду CRL таким образом, вы будете автоматически перемещены в
[105:26] => новое приглашение, и вы останетесь на этой линии. Если вы хотите перейти к новой строке, вы можете ввести
[105:32] => URL, затем добавьте точку с запятой и добавьте сюда , действуйте так. И теперь вы будете переведены на новую линию
[105:40] => здесь, в аут. Замечательный. Теперь мы получили ответ с того же порта. Здесь мы видим то же имя хоста,
[105:47] => как мы видели здесь. А теперь давайте оставим это окно открытым здесь. И давайте увеличим количество опросов
[105:56] => в нашем развертывании. Давайте расширим наше развертывание. Я открою новую вкладку в приложении «Товар»,
[106:04] => вы можете открыть новое окно терминала, если вы используете Windows, я буду использовать комбинацию клавиш, команду
[106:09] => T для того, чтобы открыть здесь новую вкладку. И здесь, в новой вкладке. Если я введу ключ, я скажу команду с ошибкой
[106:14] => не найден, так как псевдоним работает только на этой вкладке. Вот почему давайте еще раз создадим псевдоним, псевдоним к
[106:22] => куб со знаком равенства CTL. Кстати, вы могли бы опустить двойные кавычки здесь, если команда состоит только из
[106:29] => одно-единственное слово. Так что позвольте мне убрать эти двойные цели как это. Псевдоним был создан. А теперь давайте веселиться
[106:36] => достань капсулы. И здесь я вижу то же название доски, которое я видел здесь в ответе из Интернета
[106:44] => сервер. Давайте узнаем масштаб этого развертывания. Резюмировать. Название нашего развертывания — Heights web Hello.
[106:54] => Вот название развертывания. И теперь это в настоящее время имеет только один модуль. давайте масштабируем его
[107:01] => Развертывание в масштабе K. Паутина высот. Здравствуйте. И я хотел бы расширить развертывание до
[107:09] => скажем, четыре копии. Давайте продолжим, развертывание было масштабировано. Давайте теперь возьмем капсулы
[107:16] => К получить капсулы. Сейчас есть четыре порта, один все еще был создан. Давайте проверим еще раз. И теперь все
[107:25] => работают четыре порта. Все они принадлежат к одному и тому же развертыванию Knights web Hello. И каждый порт
[107:32] => конечно, имеет свой собственный уникальный IP-адрес. Давайте подробнее поговорим о портах, гигабитных портах, dash или white.
[107:41] => И здесь я вижу разные IP-адреса каждого порта. И, конечно же, они отличаются от кластера
[107:48] => IP, который был создан для определенной услуги. Со списком услуг получите SVC. И здесь, как и раньше,
[107:57] => мы видим кластерный IP-адрес, службу веб-приветствия 4k восемь секунд. И каждый из этих болтов теперь доступен через этот
[108:08] => IP-адрес кластера и Kubernetes будут решать, какой порт для выбора для каждого конкретного запроса.
[108:17] => Давайте теперь вернемся к этому шагу, где мы находимся внутри узла Kubernetes
[108:22] => и попробуйте снова подключиться к этому IP-адресу кластера и этому порту. Давайте очистим терминал здесь
[108:30] => и посмотрите URL-адрес. Теперь я вижу ответ от этого порта с таким именем. Если я повторю команду, это ответ
[108:37] => из другого порта. Давайте повторим команду еще раз, еще раз и так далее. Теперь я это вижу,
[108:45] => нагрузка сбалансирована по разным портам. Потому что здесь я вижу ответы от разных портов.
[108:53] => Здесь в ответах фигурируют разные имена. Разные опросы обслуживают разные запросы. И
[109:01] => вот разные названия опросов. Вот как действует распределение Господа в действии.
[109:08] => И теперь с помощью поиска пользовательски создайте докер изображение, мы смогли это доказать. Хорошо,
[109:14] => давайте продолжим. А теперь давайте изменим тип службы, которую мы создаем для нашего развертывания, потому что
[109:21] => теперь появился IP-адрес кластера, который доступен только изнутри кластера. Давайте пойдем сюда и
[109:29] => давайте удалим текущую службу K eight s web Здравствуйте. Просто взять его название было понятно.
[109:37] => и antigay удалить SVC означает сервис и основанное на названии сервиса, который мы хотели бы удалить
[109:44] => сервис был удален get SVC такого не было службы больше нет. И если бы я попытался подключиться
[109:52] => снова при развертывании с использованием IP-адреса кластера, который мы использовали раньше, я обязательно получу ошибку. Так что я вижу
[109:59] => Нет ответа. Здорово. Давайте теперь создадим сервис снова. Но теперь мы установим его тип на порт узла.
[110:09] => Давайте используем команду отправки K, развернем развертывание, Хайтс, привет. И здесь будет тип,
[110:20] => который будет установлен на порт узла. В Порт узла обозначения регистра в паскале. И давайте
[110:27] => добавьте сюда опцию порта, и он будет установлен на 3000. Тот же порт, который мы использовали раньше, это то, что
[110:34] => порт, где на самом деле курсируют наши контейнеры. нет приложения GS. Давайте пойдем дальше и создадим такой
[110:42] => была открыта услуга развертывания порта узла типа Давайте перечислим услуги, которые получают SVC. И теперь там был
[110:50] => снова сервис с именем gate s web Здравствуйте, его тип теперь это порт для заметок. Здесь снова был кластерный IP, и
[111:00] => порт. Но здесь я вижу порт, который был указан здесь с помощью опции порта. А также после колонки, которую я вижу
[111:08] => случайно созданный порт 32,142. И теперь я могу для подключения к развертыванию с использованием IP-адреса узла,
[111:23] => Я мог бы получить IP-адрес узла, введя мини-куб IPL, у нас есть только краткое описание одного узла. И там был
[111:30] => в моем случае это немного. И я мог бы воспользоваться этим IP-адресом на этом порту. И я подключусь к одному из портов
[111:40] => в этом развертывании. Давайте сделаем это. Позвольте мне возьмите этот IP-адрес, перейдите, например, в веб-браузер.
[111:48] => Поскольку теперь я смогу подключиться к развертыванию со своего компьютера, позвольте мне вставить это
[111:53] => IP и после столбца я добавлю этот порт таким образом. Так что в моем случае строка подключения находится здесь.
[112:03] => Итак, здесь был адрес точки доступа, это IP-адрес узла, а здесь был случайно сгенерированный порт,
[112:09] => который был создан самим Kubernetes, когда мы созданный сервис для нашего развертывания. Пойдем
[112:16] => вперед и попытайтесь подключиться. И я вижу ответ от одного из портов. Давайте освежимся. И я
[112:24] => смотрите ответ из другого отчета с RS или именем, обновите еще раз, и я увижу ответ с другого порта
[112:30] => здесь. Вот как мы можем подключиться к нашему развертывание с использованием службы портов узлов. Кроме того, это
[112:38] => более простой способ получить URL-адрес для подключения к этому развертыванию с помощью команды службы mini cube
[112:46] => мини-кубический сервис. И здесь введите название сервиса, в нашем случае, gay eight s web Привет.
[112:56] => Давайте войдем, и новая вкладка в веб-браузере откроется автоматически. И обратите внимание на URL-адрес здесь такой же, как
[113:03] => Я просто использовал предыдущий IP-адрес узла и порта который был автоматически сгенерирован Kubernetes.
[113:10] => Это тип порта узла службы.
[113:14] => Также здесь вы можете увидеть этот фактический URL-адрес при входе в веб-сайт службы mini cube. Привет,
[113:21] => там был настоящий URL-адрес. И если вы хотите получить только URL, вы могли бы добавить сюда опцию, которая делает этот URL
[113:29] => и вы увидите только URL-адрес, и вы могли бы возьмите его и разместите в любом месте, где захотите.
[113:36] => Так что это тип службы порта узла. И это предоставляет развертывание в порту узла.
[113:44] => И вот в моем примере был этот конкретный порт, в вашем случае этот продукт будет совершенно другим.
[113:51] => И еще один вариант, который я хотел бы вам показать с точки зрения создания сервиса
[113:56] => является балансировщиком нагрузки. Давайте создадим нагрузку сервис балансировщика и для этого бросает
[114:02] => длина удалить существующий сервисный шлюз удалить SVC веб-привет от сервисных ворот. Услуга была удалена
[114:12] => gate gift — такой услуги больше не было. И давайте создадим сервис типа балансировщик нагрузки.
[114:20] => Ворота раскрывают развертывание. Привет из сети ворот. Здесь давайте добавим тип протокола балансировки нагрузки Pascal Case
[114:32] => Еще раз повторите, и давайте добавим опцию по умолчанию, и ее значение будет равно 3000. То же, что и раньше.
[114:39] => Давайте создадим такой сервис Сервис был создан get SVC. Теперь я вижу, что есть сервис типа load
[114:48] => балансир. Здесь был IP-адрес кластера, но внешний IP-адрес здесь находится на рассмотрении. И вы увидите здесь ожидающий
[114:56] => если вы используете mini cube, но когда вы развертываете свои приложения где-то в облаке с помощью одного из
[115:03] => облачные провайдеры, такие как Amazon, Google Cloud и т. Д. Здесь вы увидите IP-адрес балансировщика нагрузки
[115:10] => назначается автоматически. Но в нашем случае использование mini cube аналогично поведению порта note.
[115:19] => И здесь мы все равно сможем подключиться к нашему развертывание с использованием IP-адреса узла. И если
[115:26] => Я вхожу сейчас в мини-куб, сервис, веб-портал ворот Привет, Я увижу соединение, которое установлено с IP-адресом
[115:36] => узла. И вот появилась игра, которую случайно принес который был сгенерирован здесь. Там был этот случайный
[115:42] => порт. Хорошо, давайте продолжим. И давайте сохраним эту службу и это развертывание на месте. Резюмируйте это
[115:48] => у нас здесь есть единый сервис, который мы создали до того, как он стал веб-приветом и типом
[115:55] => теперь это балансировщик нагрузки. И есть один-единственный ворота развертывания будут развернуты. И это имя —
[116:02] => Хайтс, привет. И теперь в этом развертывании нам доступны четыре разных порта.
[116:09] => Мы могли бы прочитать подробности об этом развертывании Кей, опиши развертывание, походку, привет. И
[116:18] => вот подробная информация об этом развертывании. Кстати, в конце здесь я вижу журналы, связанные с масштабированием
[116:24] => из набора реплик изначально количество реплик составляло единицу, а позже мы масштабировали его до
[116:30] => четыре. Если вы хотите, вы можете попробовать масштабировать его на любой другой номер, если вы хотите это сделать.
[116:36] => Выше я вижу, что у этого развертывания есть имя гей, как веб-привет. пространство имен — это метки по умолчанию
[116:42] => реплики селектора аннотаций, необходимые для обновления , доступны для. А теперь давайте попробуем сформировать.
[116:51] => Давайте попробуем обновить версию образа в нашем развертывании. Обратите внимание здесь, что тип стратегии
[117:00] => это постоянное обновление. Что это значит? Когда вы выпускаете новую версию своего приложения,
[117:07] => конечно, вы хотите запустить эту новую версию в производство плавно, без каких-либо перерывов в
[117:14] => обслуживание. И Kubernetes позволяет это из коробки. И это очень просто. И эта стратегия
[117:21] => тип скользящего обновления означает, что новые порты будут быть созданным с новым изображением, в то время как предыдущие порты
[117:31] => будет все еще работать. Таким образом, оба будут заменены один за другим. И, наконец, через некоторое время, или и то, и другое
[117:40] => будет работать в вашем обновленном изображении. И теперь давайте попробуем это в действии. Мы немного обновим
[117:48] => наше приложение и создание нового образа с Технология НАСА, например, вторая версия точка 0.0.
[117:55] => И после этого мы изменим изображение в нашем развертывание и посмотрите, что произойдет, как Kubernetes
[118:03] => будет выпущено это обновление. Так что давайте продолжим и сделаем это. Кстати, мне это не нужно
[118:11] => шаг второй, где я создал SSH-соединение с узлом. Поэтому позвольте мне выйти из этой связи
[118:19] => и на самом деле завершите этот шаг, и я буду держите открытой только одну вкладку. Так что давайте вернемся к
[118:26] => Код Visual Studio. А вот содержимое файла index dot MJS. И у нас уже есть образ
[118:34] => доступно для этой версии приложения где сервер отвечает нам таким сильным.
[118:41] => Теперь давайте изменим этот пример, например, давайте добавим сюда вторую версию этики, подобную этой.
[118:49] => И давайте узнаем, создайте новое изображение с новым тегом, отправьте его в Docker Hub, а затем измените
[118:56] => изображение в нашем развертывании. Давайте сохраним изменения в этом файле, откроем и улучшим терминал. И давайте
[119:02] => создайте изображение и назначьте другой тег для еды. Сейчас изображение имеет только один тег, оно является последним. Так что давайте
[119:10] => создайте новый докер изображений, создайте dot dusty tech, мистер Чу, добавьте свое имя, если вы хотите продвинуть это
[119:21] => версию изображения для вашей учетной записи Docker Hub. Итак, положите сахар в основу, и здесь будет название
[119:27] => изображение гей-восьмерок в Интернете Привет. И после затишья. Я добавлю тег, например, две точки 0.0 вот так.
[119:37] => Давайте создадим изображение сайта, резюмирующее это Я изменил файл index dot NGS и
[119:44] => Я обновил эту строку, чтобы она строилась новый образ. Давайте пойдем дальше и построим его
[119:52] => построение экспортирующего изображения слоев было построено и теперь давайте перенесем его в Docker Hub. Я скопирую это
[120:01] => имя, включая технологию. И вот теперь я вхожу в docker push. И новая версия моего приложения
[120:08] => будет передан с использованием отдельной технологии для изображения веб-приветствия той же высоты. Так что поехали
[120:15] => вперед и толкай, толкай, я вижу, что некоторые слои уже существуют, и только один слой был перенесен на
[120:25] => изображение было успешно отправлено, позвольте мне убедиться в этом, перейдите в мою учетную запись Docker Hub.
[120:37] => он все еще видит только одно изображение здесь. Обратите внимание, позвольте мне нажать на него.
[120:43] => И здесь я должен найти, чтобы обложить налогом последняя версия и сделайте точку 0.0. Теперь давайте
[120:49] => разверните эту новую версию этого образа. И для этого мы будем использовать следующую команду.
[120:56] => Давайте подойдем к здешнему терминалу. И давайте установим новый образ для набора ключей развертывания
[121:02] => изображение. Мы создаем новый имидж для конкретного развертывание следующим будет имя развертывания
[121:10] => высоты развертывания Веб-Привет. А потом нам нужно выбрать порты, в которых мы хотели бы
[121:17] => установите новое изображение. Здесь мы прибудем к воротам восемь секунд веб-привета. И после знака равенства мы будем
[121:26] => укажите новое изображение. В моем случае это просто веб-сайт для детей-геев с косой чертой, привет, вторая колонка, точка 0.0.
[121:37] => Это новая технология, которая была назначена нами до того, как мы отправьте новую версию изображения в Docker Hub.
[121:46] => После ввода этой команды изображение будет будет начато изменение и развертывание обновления.
[121:53] => Будьте готовы ввести команду следовать после этого статус развертывания 1k высота развертывания веб-привет,
[122:02] => вы могли бы подготовить эту команду где-нибудь в текстовом редакторе, а затем быстро выполнить ее.
[122:08] => После этой команды я попытаюсь ввести ее вручную. Давайте продолжим и изменим изображение изображение обновлено
[122:16] => статус ключевого развертывания развертывание gay eight s web Здравствуйте, ожидание завершения развертывания разрешено.
[122:27] => И теперь я вижу, что развертывание успешно развернуто . И до того, как я увидел такие сообщения, как три из
[122:36] => из четырех новых реплик были обновлены, одна старая реплики ожидают завершения и так далее.
[122:43] => Наконец, все предыдущие реплики были завершены, и были развернуты новые реплики. Давайте хотя бы узнаем
[122:52] => боты-геи получают яйца. И теперь я вижу , что есть четыре порта. И обратите внимание на возраст этих портов
[123:01] => от 30 до 40 секунд, это означает, что предыдущий порты были полностью закрыты, а новые порты были
[123:10] => созданный. И теперь во всех этих четырех болтах мы запускаем новую версию нашего приложения.
[123:17] => И мы могли бы очень легко проверить это, получив доступ к нашему развертыванию с помощью сервиса, и все еще было
[123:24] => тип службы get SVC — это балансировщик нагрузки. И он был кластером IP, который сюда был доставлен. И с помощью
[123:33] => ввод команды в службу мини-кубов, Кей с Уэбб Здравствуйте, я мог бы открыть соединение с одним из запущенных
[123:40] => порты. Итак, давайте продолжим, и на самом деле было открыто , и теперь я вижу ответ, который включает версию
[123:48] => два. Вот как работают неправильные обновления, вы могли бы обновите страницу здесь, затем вы должны увидеть ответ
[123:55] => с другого сервера. Например, вот этот. И опять же, здесь я вижу вторую версию, это означает, что
[124:02] => наша новая версия приложения была успешно развернут на всех лодках в развертывании.
[124:09] => Замечательный. Вот где происходят обновления, и это как вы могли бы проверить статус текущего обновления
[124:14] => введя статус развертывания команды K. Этот, если вы хотите, вы могли бы создать один
[124:23] => для вашего изображения отправьте его в Docker Hub и подтвердите как снова работает развертывание. Или, если вы хотите, вы могли бы
[124:30] => откат к предыдущей версии. Кстати, мы могли бы быстро попробовать это вместе. Давайте отправимся в
[124:36] => эту команду и здесь я сниму колоду и это будет означать, что я хотел бы использовать только это
[124:43] => колода и давайте снова проверим, как будет изменено изображение. И мы действительно возвращаемся
[124:48] => к предыдущей версии нашего приложения. Давайте изменим изображение, давайте улучшим или разрешим статус
[124:59] => наша новая реплика по умолчанию была обновлена, ожидая для развертывания или разрешено завершить. И наконец,
[125:04] => развертывание успешно развернуто. И снова, Я увижу четыре совершенно новых порта, получу модули,
[125:13] => вот был возраст этих четырех портов. Давайте снова подключимся к нашему развертыванию,
[125:19] => сервис mini cube использует его как веб-привет. И я снова смотрите привет с сервера без второй версии.
[125:27] => Вот где происходят обновления. Замечательный. А теперь давайте попробуем сложить. Теперь у нас есть четыре болта
[125:34] => вставай и беги. Но что произойдет, если я просто удалю один из портов вручную?
[125:39] => Давайте попробуем это сделать. Давайте возьмем, к примеру, это название порта, обратите внимание на H этих четырех портов,
[125:47] => и введите ключ удалить порт и вставьте имя любого порта, который вам нравится. И после этой команды,
[125:56] => давайте снова возьмем капсулы. И я увижу этот новый порт будет создан автоматически созданный контейнер.
[126:06] => Потому что мы сказали Kubernetes, что желаемый количество портов в развертывании равно четырем.
[126:13] => Вот почему он старается сделать все возможное, чтобы создать желаемое количество копий, его специфических
[126:21] => развертывание. И теперь я увижу, что есть снова четыре порта, запущены и работают. И возраст
[126:27] => этот порт занимает 33 секунды. Хорошо, мы попробуем это сделать текущие обновления. А также мы попытались удалить один
[126:35] => из одного порта. И не позволяй мне демонстрировать тебе вы знаете, как использовать панель управления Kubernetes. Если ты
[126:41] => используя куб сообщества, это очень просто, всего одна команда. Но если вы используете Kubernetes
[126:47] => в вашем собственном помещении или где-то в облаке это может быть немного сложнее, потому что вам нужно
[126:53] => для обеспечения безопасного веб-доступа к панели мониторинга. Но здесь опять же есть только панель управления мини-кубом с одной командой.
[127:03] => Таким образом, давайте включим этот широкий бездельничающий прокси-сервер, проверяющий ад прокси-сервера.
[127:11] => И эта широкая веб-страница будет открыта здесь. И, как вы видели здесь, нет запроса на имя пользователя и
[127:20] => пароль. Эта панель мониторинга была просто запущена таким образом, потому что мы используем mini cube. И вот ты здесь
[127:27] => мог бы ознакомиться с подробностями о вашем кластере Kubernetes. Например, вы могли бы перейти к развертываниям,
[127:34] => и вы найдете здесь одно развертывание , обратите внимание, позвольте мне немного уменьшить размер таким образом.
[127:40] => Итак, вот метаданные для этого развертывания. Есть ярлыки. Текущее обновление стратегии,
[127:48] => это то, что мы наблюдали. Оба статуса доступны для обновления. Есть условия
[127:56] => новый набор реплик, здесь был идентификатор набора реплик , который был создан этим развертыванием.
[128:02] => Вы можете нажать на эту гиперссылку и прочитать подробную информацию о конкретном наборе реплик. Обратите внимание, что
[128:09] => развертывание набора реплик и порты всех принадлежат одному и тому же пространству имен по умолчанию,
[128:14] => но, конечно, вы могли бы назначить развертывания в разных пользовательских пространствах имен
[128:20] => метки для этой реплики устанавливают статус порта для запуска по желанию, и вот ссылки на
[128:27] => все лодки, принадлежащие этому конкретному набор реплик. Также внизу была служба
[128:34] => который был создан для этого набора реплик для данного типа развертывания, здесь является балансировщиком нагрузки.
[128:42] => И если вы нажмете на определенный порт, вы сможете ознакомьтесь с подробностями о конкретном порту
[128:47] => вот имя пространства имен портов, когда порт был создан. Вот информация о
[128:53] => узел, на котором был создан этот шлюп, имеет статус запущенного IP-адреса порта. Под тобой
[128:59] => можно также найти подробную информацию о наборе реплик который фактически контролирует этот конкретный порт.
[129:06] => И обратите внимание, что метка для этого порта находится здесь до восьми с веб-Привет. И тот же ярлык
[129:14] => находится здесь, управляемый набором реплик , и здесь была метка в наборе реплик.
[129:22] => Также ниже вы можете найти подробную информацию о события, произошедшие в этом конкретном порту.
[129:28] => Например, вот шаг вытягивания изображение веб-привет мистера Сюй Кана.
[129:35] => А вот предложения о контейнерах которые не работают внутри порта.
[129:40] => Внутри каждого порта не было только одного контейнера. Кстати, если я перейду к наборам реплик,
[129:47] => Я найду на самом деле два разных набора реплик которые были созданы для разных изображений для этого
[129:54] => изображение и для этого изображения. И теперь в этом набор реплик имеет нулевую точку, потому что мы
[130:01] => откат от этого изображения к этому изображению с Последний тег, вот почему сейчас здесь я вижу четыре порта,
[130:08] => а здесь — ноль портов. Хорошо, этот графический пользовательский интерфейс, вы можете нажать на другое меню
[130:16] => элементы и наблюдайте, к каким, например, узлам принадлежат в классную комнату. Теперь там был один мини-куб
[130:22] => записка. И если вы нажмете на него, вы сможете прочитать подробную информацию об этом конкретном узле. Это было
[130:30] => Панель управления Kubernetes. И вы могли бы использовать его для того, чтобы наблюдать за состоянием Kubernetes
[130:35] => развертывания и службы и так далее. Позвольте мне закрыть его. А теперь давайте продолжим, и левый Ctrl C в
[130:42] => для того, чтобы прервать этот процесс здесь. И теперь mini cube больше не будет доступен.
[130:49] => Теперь, важное замечание, мы только что использовали императивный подход к созданию развертываний и
[130:56] => услуги. И мы создаем развертывания и службы, используя различные команды CTL куба.
[131:04] => Но обычно это не так, как создаются развертывания и службы.
[131:08] => И в большинстве случаев используется декларативный подход . И в декларативном подходе,
[131:14] => вам необходимо создать файлы конфигурации Yamo, в которых описываются все детали развертывания
[131:21] => и услуги. А затем примените эти файлы конфигурации с использованием cube CTL. Применить команду.
[131:28] => И это фактически декларативный подход к созданию различных ресурсов и объектов в
[131:34] => Кубернетес. И это то, что мы сделаем прямо сейчас. Давайте теперь удалим как развертывание, так и службу, которые
[131:41] => мы создавали раньше. И для этого вы можете выполнить команду псевдонима, cube CTL, удалить развертывание,
[131:48] => а затем удалите сервис. Но была также короткая версия удаления всех ресурсов
[131:53] => в пространстве имен по умолчанию, и оно должно удалить все с помощью опции, там есть все такое
[132:02] => все ресурсы будут удалены, вы увидите , что оба были удалены, сервис был удален,
[132:09] => и развертывание также было удалено. Давайте возьмем капсулы. Оба они все еще находятся в стадии завершения.
[132:17] => Давайте проверим еще раз. Все еще оставалось немного подождать. А теперь нет никаких ресурсов
[132:24] => найдено в пространстве имен по умолчанию. Все порты были закрыты, давайте подключим службы к SVC.
[132:32] => И теперь существовал только один системный сервис по умолчанию Kubernetes. И, конечно же, нет никаких
[132:38] => развертывания развертываются, ресурсы не найдены. Теперь давайте создадим файл конфигурации Yamo
[132:47] => для развертывания. А для серьезных героев мы будем создайте два отдельных файла конфигурации. Давайте
[132:53] => перейдите к коду Visual Studio. А вот, позвольте мне , кстати, уточнить высоту и по терминалу на данный момент.
[132:59] => И позволь мне закрыть эти старые окна. И теперь здесь, давайте свернем эту папку gay eight s web Привет,
[133:08] => потому что эта папка была посвящена нашему веб-приложению Node js Express.
[133:14] => И теперь здесь, в корне буквы К, восемь с папка здесь, давайте создадим следующие файлы
[133:20] => развертывание обоих Ямо. А также давайте создадим файловая служба dot Yamo. Как это. Итак, два файла
[133:30] => развертывание Yamo и точка обслуживания Yamo. Давайте добавим поле в файл dot Yamo развертывания.
[133:38] => Если вы установили расширение Kubernetes здесь, в ПРОТИВ кода, то, что я просил тебя сделать, прежде чем ты смог
[133:45] => создавайте такие файлы конфигурации очень быстро. Позволь я тебе покажу. Так что введите здесь просто развертывание
[133:53] => и вы увидите предложение Kubernetes развертывание, которое мы выбрали, и вы
[133:59] => увидит этот файл конфигурации Yamo будет создан автоматически для вас.
[134:05] => И вы увидите, что все элементы моего приложения будут выделены, и вы можете просто ввести
[134:13] => имя развертывания, которое вы хотели бы установить, и оставили имя таким же, как мы
[134:20] => до. Но теперь мы используем конфигурационный файл Yamo. Итак, К восьмому веб-привету. Как это.
[134:28] => имя развертывания было задано здесь как фактическое имя для этого развертывания. Он был диверсионным агентом slash v1.
[134:39] => Здесь был селектор со схемой спичечной этикетки. И с помощью этой схемы соответствия этикеток мы указываем, какие
[134:46] => поляки будут управляться этим развертыванием. И ниже был вложенный шаблон и этот шаблон
[134:55] => описывает на самом деле порт, но здесь вам не нужно Чтобы указать вид шаблона таким образом, потому что
[135:05] => этот вложенный шаблон для шаблона развертывания является всегда покупал. Следовательно, ток здесь не
[135:11] => необходимый. Далее, для портов, принадлежащих этому развертыванию, здесь мы устанавливаем метки. И этикетка здесь есть
[135:21] => то же самое, что и метка здесь, в селекторе совпадающих меток. Так что эта этикетка и эта этикетка здесь совпадают. И следующий
[135:30] => в спецификации мы указываем, какие контейнеры мы хотим для создания в этом порту. И там был только один
[135:39] => контейнер с таким изображением имени должен быть заполнен, теперь мы заменим этот заполнитель изображения на
[135:46] => реальный образ. А также ниже вы могли бы указать какие порты вы хотели бы открыть в конкретных
[135:54] => контейнер. А ниже, в разделе порты, вы можете указать список контейнерных портов,
[136:00] => который будет открыт на IP-адресе порта. Так давайте теперь рассмотрим детали в этом разделе спецификации.
[136:08] => изображение будет основано на веб-сайте Ashok slash K eight Здравствуйте. И то и другое здесь будет содержаться в
[136:19] => 3000. Как это. Также обратите внимание, что VS код Расширение Kubernetes добавило раздел ресурсов здесь.
[136:28] => И в этом разделе был пропущен лимит, в котором указаны ограничения памяти и процессора для каждой платы,
[136:36] => который будет создан в результате этого развертывания. И здесь будет ограничен объем памяти и объем процессора
[136:43] => ресурсы. 500 м означает половину ядра процессора. Если вы хотите изменить 500 на 250, например, 1/4 от
[136:54] => ядро процессора, давайте оставим все как есть. И это все для данной спецификации развертывания.
[137:01] => Давайте сохраним изменения в этом файле. А теперь позвольте мне на самом деле показать, как найти документацию о том, как
[137:09] => создайте определенные файлы конфигурации Yamo. Пойдем в веб-браузер, и здесь давайте перейдем к kubernetes.io .
[137:17] => И перейдите сюда, к документации. И здесь или уходи для ссылки. И здесь выберите API Kubernetes.
[137:26] => А в API Kubernetes вы можете выбрать , например, ресурсы рабочей нагрузки. И вы
[137:32] => найдете подробности, как описать, например порты, или создайте шаблон порта, или создайте реплику
[137:40] => набор, мы просто создаем развертывание. Поэтому давайте нажмите на раздел развертывания здесь. И ты будешь
[137:47] => узнайте подробности о том, как создать конфигурацию Yamo файлы. Если вы хотите создать развертывание,
[137:54] => для перенаправления должно быть установлено значение apps slash v1. И ниже вы найдете другие ключи, которые должны быть
[138:01] => присутствует в файле конфигурации развертывания. Для пример, клиент должен быть настроен на развертывание. Затем
[138:08] => там был раздел метаданных статус спецификации статус, кстати , заполняется Kubernetes автоматически,
[138:16] => и он будет добавлен после того, как вы создадите развертывание на основе определенного файла конфигурации. И если я
[138:23] => вернитесь к файлу конфигурации здесь, я найду такие ключи, как метаданные типа версии API и спецификация,
[138:31] => те же ключи, которые описаны здесь Версия API метаданные вида и спецификации. И если вы хотите получить
[138:38] => подробную информацию о спецификации развертывания вы можете нажать здесь, и вы найдете это внутри спецификации,
[138:45] => вы должны указать шаблон селектора реплики, стратегия означают радиосекунды и так далее.
[138:52] => И если я взгляну на это здесь, я буду узнайте, что внутри спецификации в этом примере,
[138:59] => здесь есть селектор, селектор шаблонов и шаблон, и оба они обязательны.
[139:07] => Если вы нажмете на шаблон, вы прочтете подробную информацию об обеих спецификациях шаблона. Давайте щелкнем
[139:13] => на нем. И здесь вы обнаружите, что внутри спецификация шаблона доски, вы должны указать метаданные
[139:21] => и спец. мы только что купили спец. И это то, что мы добавили здесь в раздел шаблона, метаданные и
[139:29] => спецификация для модуля. Давайте нажмем на спецификацию pod и прочитаем подробную информацию о контейнерах спецификации pod
[139:37] => требуется, и вы можете добавить несколько контейнеров в спецификацию pod, если хотите это сделать.
[139:44] => И здесь, в этой спецификации, у нас есть контейнеры вот оно, давайте нажмем на контейнер здесь.
[139:51] => И в этой спецификации контейнера вы найдете имя, которое требуется. Вот почему мы устанавливаем имя как
[139:58] => все это также вы должны установить изображение для определенного контейнера. Здесь с ресурсами изображения и портами находятся
[140:07] => также описано здесь, на этой странице рекомендаций. Итак, здесь мы поддерживаем раздел. Также,
[140:14] => вы можете установить, например, переменные среды для конкретного контейнера. Я настоятельно рекомендую
[140:20] => вам ознакомиться с документацией, а также с все доступные варианты, и я только что продемонстрировал
[140:26] => вам, как вы могли бы покопаться в документации и выяснить, как чувствовать различные разделы
[140:33] => файл конфигурации. Хорошо, мы закончили с созданием файла конфигурации для развертывания.
[140:40] => Итак, в настоящее время здесь идет развертывание. И давайте теперь применим этот конфигурационный файл, используя декларативный
[140:47] => подход, создающий такой файл на месте, вам больше не потребуется вводить команду
[140:52] => cube CTL создает развертывание, вам просто нужно ввести команду cube CTL применить. Давайте сделаем это.
[140:59] => Давайте откроем встроенный терминал здесь. И теперь Я все еще внутри сети врат восемь с Привет
[141:05] => папка. Позвольте мне выйти из этой папки, где находится этот файл развертывания Yamo. Давайте по крайней мере напишем
[141:13] => здесь. Итак, вот файл конфигурации развертывания Yamo . И здесь давайте введем команду cube CTL.
[141:21] => Примените это F означает файл, и здесь будет именем развертывания файла.
[141:28] => Точка Ямо. Просто, так как был применен файл Det и создано развертывание
[141:36] => был сгенерирован. Кстати, здесь у меня нет псевдоним с соответствующим псевдонимом, псевдонимом K, cube CTL.
[141:43] => Все в порядке, приступайте к развертыванию. И теперь там войны К восьмому развертыванию веб-привета.
[141:52] => И в этом развертывании был один порт. порты. Вот этот порт, который запущен и работает.
[142:00] => Верно. Но то, как мы могли бы теперь масштабировать это развертывание и увеличивать количество копий, было легко
[142:08] => путем изменения этого файла спецификации. Но как мы могли бы увеличить количество своих копий.
[142:16] => Здесь на данный момент мы не видим никаких цифр. Давайте попробуем выяснить это с помощью документации.
[142:22] => Я предполагаю, что я не знаю, как это изменить. Так давайте перейдем к рабочей загрузке ресурсов, проверим развертывание
[142:31] => и прокрутите страницу вниз здесь. Итак, вид метаданных статуса спецификации , здесь нет вариантов. Давайте нажмем на развертывание
[142:40] => спекуляция. Здесь мы выберем или шаблонируем количество реплик желаемых портов. И это тот самый вариант
[142:48] => который вам необходимо использовать, если вы хотите изменить количество реплик по умолчанию номер один,
[142:55] => о, здесь был номер один по умолчанию для любого другого номер. И вы должны добавить реплику Skee
[143:02] => в спецификации развертывания. Итак, давайте перейдем к спецификации развертывания. Итак, вот мы и пришли. И здесь,
[143:09] => давайте добавим реплики новых сделок. И его ценность подойдет, скажем, номер пять. Если я вернусь,
[143:16] => Я мог бы прочитать, что его значение равно целому числу 32. Так вы не нужно писать здесь такой файл. Верно.
[143:24] => В качестве числа у нас есть сохранение изменений. И давайте снова применим этот файл конфигурации развертывания Yamo,
[143:32] => используя тот же CTL командного куба, примените этот Ямо развертывания F. Давайте продолжим
[143:39] => настроено, получите капсулы. И теперь я вижу, что четыре создаются новые контейнеры. И теперь
[143:49] => в моем развертывании есть пять различных порты, четыре из них уже находятся
[143:56] => знаю пятерых в округе. Вот как мы смогли очень легко модифицировать
[144:03] => наше развертывание просто путем изменения файла конфигурации развертывания Yamo.
[144:09] => Но, конечно, сейчас нет услуг, которые можно получить. давайте создадим новый сервис, используя аналогичный подход.
[144:17] => Давайте спрячем их у терминала. А теперь давайте перейдем к файлу конфигурации service dot Yamo.
[144:22] => И здесь я также позволю ускорить процесс создания конфигурации сервиса
[144:27] => служба файлов и типов и расширение Kubernetes предложит нам этот вариант. И эта спецификация будет
[144:34] => автоматически оцениваться. Клиент — это сервис API версия — это кость, здесь она отличается от версии API
[144:42] => имя метаданных вида развертывания задает имя для этой службы. Давайте введем имя веб-шлюза привет
[144:51] => а также герой давайте изменим селектор и выберите все, что будет до восьми Золотых ворот
[144:57] => веб-привет, а также. Кстати, если вы наведете курсор мыши на любую из клавиш в этом файле конфигурации,
[145:03] => вы можете найти гиперссылки на документацию для каждого конкретного ключа, например, URL-адрес имени ключа
[145:10] => здесь. Или, если вы наведете курсор мыши на вид, вы могли бы также найдите здесь гиперссылки для отвлечения внимания для вида
[145:18] => метаданных, например. Хорошо, что осталось вот в этой серии модификация порта
[145:26] => раздел. Здесь я вижу этот порт и целевой порт были ли наши авто заселены. Прежде чем мы используем
[145:34] => открыт фактически тот же порт 3000, который является портом, на котором работает наш веб-сервер Express.
[145:40] => И теперь мы могли бы попробовать другой порт открыть порт 3000, который является целевым портом для порта, скажем
[145:49] => 3030, вот так. И это означает, что целевой порт 3000 будет открыт
[145:55] => к внешнему органу управления портом. Также обратите внимание, что в этой спецификации не было
[146:01] => введите для этой услуги. И давайте скажем, что мы хотим создать службу балансировки нагрузки.
[146:08] => Для этого давайте перейдем к документации. Давайте найдем документация для обслуживания здесь. Kubernetes, API,
[146:16] => сервисные ресурсы, сервис. И вот давайте нажмите на спецификацию услуги. Здесь мы выберем
[146:25] => Отчеты. А также ниже вы можете найти тип типа службы, либо IP-адрес кластера, который используется по умолчанию,
[146:34] => или внешнее имя, или порт узла, или балансировщик нагрузки. Давайте установим тип для балансировщика нагрузки. Давай вернемся
[146:42] => в наш конфигурационный файл. И здесь проверяют, давайте установим тип для балансировщика нагрузки таким образом.
[146:51] => Вот и все для этой спецификации сервиса. Давайте сохраним изменения в этом файле. И давайте применим это
[146:58] => используя ту же команду, что и до cube CTL. Применить тире F означает файл, а здесь — служебная точка типа
[147:06] => Ямо. Я все еще внутри врат восемь секунд папка. Итак, давайте применим служебный файл Yamo
[147:14] => применяемые GAE получают SVC. И теперь я вижу, что был создан новый сервис с типом балансировщик нагрузки.
[147:23] => И теперь точно так же, как и раньше, я мог открыть соединение с нашим развертыванием
[147:27] => с помощью службы командной строки mini cube K-s Web. Здравствуйте, давайте продолжим, и страница откроется.
[147:39] => Обновление и хороший ответ с другого порта. Оно означает, что теперь все работает по-прежнему, есть
[147:46] => не было никакого обслуживания и развертывания. И мы создали все, использующее декларативный подход, использующий
[147:53] => файлы конфигурации. Он был зачислен на службу и вот файл для развертывания. Мы могли бы также очень
[148:00] => легко удалить развертывание и сервис, которые мы просто создан с помощью всего одной команды. Давай сделаем это, иди
[148:07] => к терминалу и здесь введите клавишу удалить этот f здесь будет указано имя первого файла развертывания
[148:16] => Ямо. И здесь давайте еще раз добавим опцию dash f и тип услуги, которую предоставляет Yamo. Давайте продолжим
[148:23] => и удалите как развертывание, так и службу. Мы будем проверьте нормально, получите SVC без обслуживания, приступайте к развертыванию
[148:34] => и никакого развертывания. Здорово. Теперь давайте сделаем следующее. Давайте попробуем создать два развертывания. И давайте
[148:43] => соедините их друг с другом. Потому что это очень распространенная задача, когда вы хотите соединить разные
[148:48] => обязательства вместе, например, подключить интерфейс к серверной части или подключить серверную часть к базе данных
[148:54] => обслуживание и так далее. Поэтому сейчас мы сделаем далее позвольте мне нарисовать картинку. Так же, как
[149:01] => прежде чем мы создадим веб-развертывание и развернем их наше веб-приложение no GS Express. И здесь
[149:10] => позвольте мне напечатать вот так. А также мы создадим еще одно развертывание и назовем его Ingenix.
[149:23] => Это развертывание Ingenix будет запускать базовый образ nginx без каких-либо изменений
[149:31] => и это развертывание nginx будет иметь соответствующие сервис с IP-адресом кластера. Так что позвольте мне нарисовать ей
[149:39] => линия и здесь будет в Глостере IBM будет начните с IP-адреса кластера capital C вот так. И
[149:49] => эти два развертывания, конечно же, распределены в кластере Kubernetes. И это развертывание
[149:56] => также будут выставлены, но у каждой службы будет тип балансировщика нагрузки, это означает, что мы будем
[150:02] => возможность подключения к любому из внешних устройств с помощью нагрузки IP-адрес балансировщиков здесь с помощью балансировщика нагрузки.
[150:11] => Теперь внутри веб-приложения мы создадим две конечные точки, первой будет маршрут и точка,
[150:18] => то же, что и раньше, которое вернется просто привет с веб-сервера. И еще один
[150:24] => конечной точкой здесь будет, скажем, Ingenix. И когда будет произведено подключение к nginx,
[150:30] => мы подключимся к сервису nginx с помощью IP-адреса кластера. Или вы увидите, что с помощью имени сервиса nginx
[150:42] => как это. Таким образом, из одного развертывания мы подключимся к другому развертыванию
[150:47] => и получить ответ от одного из портов который будет запущен в приложении nginx.
[150:56] => И после этого мы вернем результат клиенту с содержимым, которое мы получили
[151:02] => от инженера и экспорта. Так вот в чем план. И таким образом, мы действительно соединимся
[151:08] => к различным развертываниям, веб-развертыванию и развертывание nginx. Давайте начнем с этого.
[151:15] => Вы находитесь внутри папки «Рыцари». Позвольте мне закройте эти файлы на данный момент. Давайте создадим
[151:21] => копия этой папки K eight s web Hello, которая содержит все файлы, связанные с нашим Weber Express
[151:29] => приложение. Давайте скопируем эту папку и вставим сюда. И давайте переименуем его, просто нажмите на это
[151:36] => имя, нажмите enter и введите новое имя K восемь s паутина для такого изобретения. Далее, давайте оставим Докера
[151:46] => файл без изменений, у Киры Коултер есть этот файл Docker в этой папке, так что никаких изменений здесь нет,
[151:54] => но мы немного изменим файл index dot MGS. И я возьму измененный файл отсюда. Позвольте мне
[152:04] => скопируйте его и вставьте сюда. Итак, вот содержимое файла index dot MGS для этого второго приложения.
[152:13] => Здесь все еще есть URL-адрес маршрута вперед слэш, мы все еще отличный экспресс-продавец в Интернете.
[152:21] => Но мы добавим сюда еще одну конечную точку Ingenix. И его обработчик маршрута теперь является асинхронной функцией, потому что теперь мы
[152:30] => будет подключаться к другому серверу, имитирующему связь между различными развертываниями.
[152:36] => И обратите внимание, что URL здесь просто http двоеточие косая черта косая черта Nginx.
[152:43] => И мы создадим сервис под названием Гениальный. Для второго развертывания nginx.
[152:50] => И из этого развертывания мы сможем подключиться к другому развертыванию
[152:56] => используя только название соответствующей службы. Вот так просто. Конечно, можно
[153:03] => подключайтесь, используя либо кластерный IP, либо некластерный IP-адрес динамический, имя службы статическое. Так что
[153:11] => мы подключимся к одному из серверов nginx , используя имя службы nginx. И здесь мы используем
[153:20] => выборка, которую мы импортируем из пакета node fetch, кстати, в данный момент мы ее установим
[153:26] => в этом приложении также. Итак, мы ждем ответа от сервера engine X. А потом,
[153:34] => мы берем тело из текста вызова ответа метод и просто верните клиенту это тело
[153:44] => по сути, то, что будет делать эта конечная точка, это будет просто прокси-запрос к серверу nginx и
[153:51] => верните результат ответа от Ingenix клиенту. Вот так просто. И здесь мы импортируем и получаем
[154:00] => следовательно, из выборки узла мы должны установить такую внешнюю зависимость. И для этого давайте откроем
[154:06] => вверх по другому терминалу и здесь убедитесь, что вы видите глубоко в этой папке, переходите из Интернета в Nginx.
[154:15] => Веб для Nginx. И здесь давайте войдем в узел установки npm и получим установочный пакет
[154:26] => Веб для Nginx. И здесь давайте введем npm install Node fetch, и вы увидите, что этот пакет файл JSON будет изменен.пакет nstalling
[154:32] => Итак, теперь вот две зависимости Express и node была установлена зависимость выборки. И снова обратите внимание,
[154:39] => эта папка модулей узла появилась здесь, но нам это здесь не нужно. Давайте просто удалим его
[154:46] => потому что внутри образа, который мы будем строить прямо сейчас у нас есть инструкция по запуску установки npm.
[154:54] => Вот он. Вот почему все необходимые зависимости будет установлен внутри докера. изображение. Все
[155:01] => ладно, теперь мы готовы идти. Кстати, это приложение также включено в финальный проект
[155:07] => файлы, которые вы могли бы клонировать с моего GitHub хранилище. Итак, перейдем с интернета на Nginx. И здесь
[155:13] => был файл MJS с индексом dot. А теперь давайте снова создадим образ докера, но он будет в вашем докере
[155:20] => изображение из этого приложения. А теперь давайте строить он использует ту же команду, что и до сборки Docker.
[155:28] => Итак, давайте перечислим файлы и папки, здесь было файл докера. Файл Docker не был изменен,
[155:34] => это то же самое, что и для предыдущего приложения. И теперь давайте создадим Docker image Docker build dot.
[155:40] => И давайте добавим тег, мистер Ашок, косую черту, и назовем его gay eight s web two Ingenix. То же имя, что и
[155:50] => для этой папки. И давайте сохраним пометку как последнюю. Вам не нужно добавлять сюда такой тег. В
[155:57] => в этом случае он будет добавлен автоматически. Так давайте построим такой образ образ строится
[156:05] => обратите внимание, что был создан образ команды установки npm. И теперь давайте перенесем его в Docker Hub. Дай мне схватить
[156:11] => это имя. толчок докера. И здесь будет имя изображения, которое я хочу отправить в Docker Hub
[156:20] => нажатие на некоторые слои будет повторно использовано из нашего изображение. И, наконец, изображение было сдвинуто, и теперь мы
[156:30] => возможность использовать его при развертывании Kubernetes. Отлично, давайте спрячем терминал и не меньше
[156:36] => следующий. Теперь я хотел бы продемонстрировать вы, как вы могли бы объединить развертывание Yamo и
[156:42] => файлы конфигурации сервиса Yamo только в одном файле. Давайте закроем эти файлы. И давайте создадим новый
[156:51] => файл и давайте назовем его K eight s web to nginx точка Ямо. Как это. Теперь в этом файле конфигурации,
[157:02] => мы объединим инструкции по созданию развертывания и сервиса. Давайте сначала пойдем
[157:08] => для обслуживания дот Ямо. Возьмите содержимое этого файла и вставьте сюда, в веб-сайт gates, в nginx Yamo.
[157:17] => После этого, пожалуйста, добавьте три тире ровно три и переходите к следующей строке.
[157:23] => Теперь давайте перейдем к файлу Yamo для развертывания, возьмем все его содержимое и вставим сюда под этими
[157:32] => три тире. И теперь, просто по одному, у нас есть спецификация, как для обслуживания, так и для развертывания.
[157:41] => Теперь давайте изменим развертывание, потому что мы бы хотели бы использовать наш другой образ, и здесь мы
[157:46] => будем использовать наше другое имя. Кстати, мы могли бы выберите это имя здесь, затем щелкните правой кнопкой мыши
[157:54] => и выберите Изменить все вхождения. И давайте назовем службу и развертывание «веселой восьмеркой».
[158:02] => сеть для Ingenix. Как это. Давайте сохраним тип для этой службы в качестве балансировщика нагрузки
[158:10] => порт здесь может быть изменен , например, на другой, давайте установим его на все три таким образом. И
[158:17] => здесь, в спецификации развертывания, давайте уменьшим количество реплик, скажем
[158:23] => три. А также давайте изменим спецификацию для контейнеров. И образ, который мы хотели бы
[158:31] => использовать прямо сейчас будет K eight s web для движка X он был заменен, когда я изменил Knights web
[158:39] => Привет, имя. Таким образом, он был правильным образом, который мы просто нажал на Docker Hub, и это изображение, которое мы бы
[158:46] => хотелось бы использовать для этого конкретного развертывания. И контейнерный порт останется неизменным в этом году
[158:54] => Хорошо, вот и все для спецификации развертывания и обслуживания нового приложения.
[159:01] => А теперь давайте создадим спецификацию для NJ MCs развертывание и обслуживание, потому что мы будем развертывать сейчас
[159:10] => два разных приложения. Тот, который будет основываться на нашем пользовательском изображении и втором,
[159:16] => который основан на официальном изображении докера под названием Nginx. Давайте просто скопируем этот файл и вставим сюда.
[159:23] => И давайте назовем этот файл nginx dot Yamo. И теперь в этом файле nginx точка Yamo. Давайте изменим
[159:32] => имена. Еще раз выберите это и измените все вхождения. И давайте назовем его просто Ingenix.
[159:40] => Пожалуйста, введите точно так, как я только что сделал. Именно Ingenix потому что это название для сервиса, который мы будем использовать
[159:49] => внутри нашего развертывания внутри наших контейнеров на которых работает веб-сервер Express no GS.
[159:56] => Мы подключимся к этому развертыванию с помощью Название службы Ingenix. Вот почему это имя очень
[160:04] => здесь это важно. Теперь мы решили использовать кластер Тип IP-службы для этого второго развертывания.
[160:13] => Вот почему давайте удалим балансировщик нагрузки типов из здесь. По умолчанию будет назначен IP-адрес кластера
[160:19] => здесь. И давайте изменим раздел порты здесь, давайте удалим целевой порт и сохраним только порт и установим его
[160:28] => до восьми. Это порт по умолчанию, на котором Ingenix будет запускать веб-сервер. Также в разделе развертывание,
[160:37] => мы должны изменить изображение. И теперь это будет будьте просто Ingenix без вашего имени пользователя,
[160:43] => потому что мы хотели бы использовать nginx по умолчанию изображение. Давайте сохраним здесь ограничения на ресурсы,
[160:51] => и давайте изменим здесь контейнерный порт, чтобы добавить вот так. Таким образом, количество реплик будет для
[160:59] => экземпляр пять вместо трех. Давайте сохраним изменения здесь и здесь подведем итог тому, что мы здесь сделали,
[161:06] => мы создадим новый сервис под названием Nginx. И имя здесь важно для нашей настройки.
[161:14] => Вот раздел порта с одним ключевым портом. И это означает, что внешний порт A будет
[161:20] => быть сопоставлен с внутренним портом 80. Это порт где веб-сервер nginx запускается по умолчанию.
[161:28] => И тип услуги здесь — IP-адрес кластера, это означает, что такой услуги не будет
[161:34] => доступно за пределами кластера Kubernetes. И здесь, в этом развертывании, мы используем
[161:41] => официальное изображение докера под названием Nginx. Здесь спецификация для портовых контейнеров
[161:48] => а контейнерный порт установлен на восемь. Это оно. Поэтому мы создали две конфигурации Yamo
[161:55] => файлы nginx точка Yamo и K восемь s веб два Ingenix, который использует специально созданное изображение.
[162:05] => Вот это название изображения. А теперь давайте применим оба файла конфигурации, этот и этот.
[162:12] => Давайте подойдем к терминалу и проверим это сейчас у нас нет никаких развертываний для развертывания.
[162:20] => На данный момент никаких развертываний и никаких сервисов. И теперь давайте развернем все, используя только один
[162:27] => команда. Теперь я все еще нахожусь внутри К восемь веб-страниц в папку «движок X». Пойдем
[162:34] => на один уровень выше, где наша конфигурация Yamo файлы находятся. Вот они,
[162:42] => этот и этот. И давайте применим их. Хорошо, примените это f, здесь будет первый файл.
[162:52] => Вот его название. И мы могли бы также применить еще один файл, этот F Ingenix Yamo.
[162:59] => Как это. Давайте пойдем дальше и создадим оба развертывания и обе службы.
[163:07] => Служба создана, развертывание создано , служба создана и развертывание создано.
[163:12] => Давайте проверим развертывание и приступим к развертыванию. В настоящее время существует два развертывания: это и это.
[163:19] => Частично они уже получают SVC. Давайте почитаем информацию об услугах.
[163:26] => Есть два сервиса, которые были созданы в этом который имеет балансировщик нагрузки типа и nginx, который имеет
[163:35] => введите IP-адрес кластера, который мы будем подключать из этой сети к развертыванию nginx для развертывания nginx
[163:44] => используя это имя для службы. Или мы могли бы также используйте кластерный IP-адрес для подключения
[163:51] => от одного развертывания к другому. Но кластер IP-адрес является динамическим. Это имя службы является статическим.
[163:59] => Так что давайте также проверим доски, чтобы получить капсулы. Некоторые опросы уже проводятся, а один все еще находится на рассмотрении.
[164:08] => И теперь мы можем протестировать нашу настройку и попытаться подключиться из веб-приложения из веб-развертывания
[164:17] => к развертыванию nginx. Давайте откроем соединение к развертыванию нашего веб-сервиса, потому что мы
[164:24] => здесь используется тип балансировщика нагрузки для этой службы.
[164:28] => И мы могли бы использовать этот порт здесь в качестве IP-адреса узла Kubernetes. Повторите это по порядку
[164:35] => чтобы быстро получить URL-адрес для конкретного развертывания с помощью mini cube, вы можете ввести команду mini cube
[164:43] => сервис и здесь будет название сервиса Heights web two Ingenix.
[164:54] => Страница веб-браузера была открыта, и мы получили ответ от одного из портов, который принадлежит, похоже,
[165:00] => Поддерживает развертывание web для nginx. А вот название соответствующего набора реплик.
[165:09] => Хорошо, мы только что запустили подключение к корневому URL-адресу. Давайте быстро вернемся к нашему приложению. Позвольте мне
[165:16] => спрячьте этот терминал здесь. И давайте перейдем к этому новому приложению и откроем index dot m. Файл JS.
[165:23] => И напомним, что здесь у нас есть две конечные точки корневая конечная точка и конечная точка nginx с косой чертой,
[165:30] => который, по сути, отправит запрос в nginx URL-адрес, этот и верните обратно клиенту
[165:38] => ответ прокси-сервера с другого сервера. Этот сервер является внешним по отношению к этому серверу, где мы
[165:46] => используете это веб-приложение. Мы просто получил этот поток с сервера,
[165:52] => давайте не будем пытаться подключиться к конечной точке Ingenix. Давайте вернемся в ваш браузер и добавим сюда
[166:00] => разрежьте Nginx. Нажмите Enter. И то, что у меня есть, у меня есть Добро пожаловать в Nginx. Это означает, что ответ от
[166:12] => сервер nginx успешно прошел прокси-сервер внутри сервера, который принадлежит нашему веб-развертыванию.
[166:23] => И мы смогли таким образом подключиться от одного развертывания к другому развертыванию
[166:30] => по названию другой службы. Итак, nginx, вот название другой службы, как мы указали здесь.
[166:39] => И у такой службы нет IP-адреса кластера, получите SVC. Итак, вот IP-адрес кластера для службы nginx.
[166:52] => И мы смогли подключиться к другому развертыванию по названию услуги. Вот как вы могли бы очень
[167:01] => легко соединяйте различные развертывания вместе. И такое разрешение имени службы на IP
[167:07] => адресация выполняется внутренней службой Kubernetes, которая называется DNS.
[167:13] => И мы действительно могли бы быстро это проверить. Давайте перейдем к терминалу, например, здесь.
[167:18] => И подытожим, что на неделе все равно появится список портов для получения модулей. И теперь мы могли бы взять
[167:25] => любой из модулей и выполняйте любые команды внутри запущенного контейнера внутри модуля.
[167:32] => Использование cube CTL. Команда Exec, эта команда очень похоже на команду Docker exec. Давайте сейчас
[167:39] => возьмите имя любого порта, который принадлежит k s развертывание из Интернета в nginx. Позвольте мне скопировать это имя в
[167:47] => названия ваших дел будут совершенно другими. И позвольте мне очистить наш терминал здесь и ввести K exec
[167:54] => здесь будет указано название порта. Далее будут два тире. А потом давайте наберем NS lookup
[168:02] => в Януксе. Вот так, давайте нажмем Ввод. И У меня есть иностранные корреспонденты. Что это значит?
[168:10] => Используя эту команду? Мы попытались решить Имя Нью-Джерси вытекает изнутри контейнера
[168:18] => который относится к спорту и такой резолюции был успешным. И этот IP-адрес, который я получил
[168:27] => с DNS-сервера, когда я сделал запрос и как поиск Ingenix. Но откуда берется этот IP-адрес?
[168:37] => С правильным геем познакомься. И вот я получаю такое вид. И обратите внимание, что этот IP-адрес тот же самый
[168:46] => как этот. И это то, что я тебе сказал. Сейчас Kubernetes может разрешить имя службы
[168:56] => к соответствующему IP-адресу кластера. И вот что мы видим здесь. И мы выполнили резолюцию
[169:04] => внутри порта, который принадлежит нашему развертывание и другие наши услуги. И, конечно же,,
[169:12] => Я мог бы выполнить аналогичную команду в одном из портов, например, я мог бы ввести здесь,
[169:19] => мы добираемся туда, искажаем все это и здесь набираем http Гениальный. И это действительно подключится к Nginx.
[169:31] => Сара, затем извлеченная из него веб-страница маршрута. Давайте попробуем это сделать.
[169:37] => И я успешно получил ответ от одного из портов Ingenix. А вот и веб-страница nginx.
[169:46] => Хорошо, вот как различные развертывания могли бы будьте очень легко связаны друг с другом.
[169:52] => Давайте вернемся к коду Visual Studio и удалим все, что у нас есть до сих пор. Если ты
[169:57] => хотите погрузиться глубже и изучить подробности о эти развертывания, конечно, вы могли бы это сделать,
[170:03] => теперь вы могли бы разрешить это, например, мини-куб приборная панель, вы могли бы копнуть глубже, перейти к другому
[170:10] => порты и исследуйте, что происходит внутри них, и так далее. У вас есть все необходимые знания для этого.
[170:17] => Хорошо, теперь давайте удалим оба развертывания и обе службы. Удалите это
[170:25] => Ingenix точка Ямо и тире ф гей это с веб для nginx точка Ямо. Давайте продолжим,
[170:34] => обе службы и развертывания были удалены, и они будут развернуты. Никаких ресурсов не найдено, чтобы получить, как мы видим
[170:45] => только одна услуга. Я думаю, вы согласились бы с мне это развертывание с использованием файлов конфигурации Yamo
[170:52] => это гораздо приятнее и быстрее, чем развертывание с использованием отдельных команд CTL куба.
[171:00] => Мы закончили с основной практической частью этого курс. И еще один шаг влево. И я хотел бы
[171:06] => продемонстрирую вам, как изменить среду выполнения контейнера который в настоящее время темнее в нашем Kubernetes
[171:12] => например, кластер в другой контейнер вовремя, cRIO или контейнер D и для изменения
[171:21] => среда выполнения контейнера нам нужно удалить текущую настройку мини-куба и создать новую. Но давайте
[171:29] => идите к здешнему терминалу. И давайте введем команду статуса мини-куба. Теперь он работает cubelet — это
[171:37] => запуск службы барьера запущен. Давайте не будем останавливаться, мини-куб, мини-куб, перестань останавливать узел, мини-куб
[171:48] => один узел был остановлен, и теперь давайте удалим текущий настроенный мини-куб удаляет
[171:56] => маленький мини-кубик в виртуальной коробке в моем случае я удалены все следы кластера мини-кубов. Теперь
[172:03] => давайте создадим Глостер заново. Мини-куб начать я снова буду использовать опцию драйвера и его
[172:11] => значением в моем случае будет виртуальная коробка. Если вы являетесь Пользователь Windows, вы должны ввести здесь Hyper V так же, как
[172:18] => для предыдущего запуска мини-куба. Но, пожалуйста, обратите внимание , что опция Docker, по крайней мере, для меня не сработала,
[172:27] => Я не смог запустить контейнеры CRI o внутри контейнера Docker. Так что по какой-то причине этого не произошло
[172:34] => работа. Поэтому я использую VirtualBox, и они не рекомендую вам использовать сейчас. Водитель-докер.
[172:41] => Так что в моем случае драйвер — это VirtualBox. И следующий Я добавлю опцию. Вот этот контейнер
[172:48] => это время выполнения и это значение будут CRI это еще один вариант — контейнер D.
[172:58] => Вы можете попробовать и то, и другое, если хотите это сделать. Так что я буду войдите сюда, КРИо, вот так. И давайте создадим
[173:06] => мини-кубический кластер снова с нуля . Но теперь время выполнения контейнера установлено
[173:12] => to CRI o давайте начнем с контрольной плоскости узел мини-куб в классе снова мини-куб
[173:20] => создание настоящих кукольных книг. Это займет некоторое время теперь я вижу шаг подготовки Kubernetes на CRI oh
[173:31] => и наконец это было сделано. Давайте теперь проверим статус статуса мини-куба.
[173:39] => Введите Ctrl, хост Блейна запущен, все работает так же, как и раньше. Но теперь время выполнения контейнера
[173:45] => внутри узла находится CRI O. Давайте проверим это. Давайте подключимся по SSH к IP-адресу миникуба и введем
[173:55] => здесь бросает мини-куб IBM SSH Docker на 192 168 59. Один автоматический Да, пользователь постоянного тока. Теперь я нахожусь внутри
[174:09] => узел мини-куба. А теперь давайте войдем в docker ps. И то, что я вижу, я вижу, не может подключиться к докеру.
[174:18] => И это указывает на то, что Docker не работает внутри этого узла, потому что мы используем
[174:25] => вместо этого используйте среду выполнения контейнера. Но как проверить, есть ли криоконтейнеры.
[174:32] => Было легко использовать следующую команду sudo CRI CTL PS и вот куча разных
[174:40] => контейнеры, которые работают как прокси-сервер do основной поставщик хранилища DNS и так далее. Теперь
[174:49] => давайте попробуем еще раз развернуть оба приложения веб -приложение и приложение nginx и создать
[174:55] => обе услуги и посмотрите, как это происходит. Давайте вернитесь к результатам. К кодексу. И здесь,
[175:02] => давайте выполним ту же задачу, что и раньше. Просто примените ворота конфигурации, применили это F и
[175:09] => примените оба файла конфигурации Yamo. Что ж, давайте продолжайте создавать развертывания и создавать службы
[175:18] => ворота разворачиваются. Еще не готов, но существует два варианта развертывания. Еще раз,
[175:26] => опять же, не готовы, давайте получим информацию о услуги. Есть две услуги, такие же, как и раньше,
[175:34] => гейт, достань капсулы. Некоторые из сообщений вместо создания контейнера
[175:41] => одна расширяющаяся любовь проверяет игру. Некоторые уже бегут.
[175:49] => Как получить развертывание для AWS для развертывания — это радио Ingenix еще не готов. Давайте проверим еще раз.
[175:58] => Теперь nginx частично готов. И теперь все эти контейнеры были созданы с помощью криоконтейнера
[176:06] => время выполнения. Давайте введем сервис mini cube и название сервиса, чтобы проверить, является ли
[176:14] => все работает, как и раньше. Итак, вот ответ одного из опросов. И давайте добавим сюда косую черту
[176:22] => Гениальный. И так же, как и раньше, это работает. Сейчас мы смогли просмотреть ответ от
[176:29] => развертывание движка X. Замечательный. Мы просто изменил среду выполнения контейнера.
[176:35] => И теперь он настроен на CRI о, давайте вернемся к этому SSH-соединению, где мы подключились к
[176:42] => узел. И вот давайте войдем снова. Sudo CRI CTL пс. И давайте, например, возьмем за название,
[176:51] => Рыцари паутины два изобретения. И теперь я вижу три разных контейнера, которые принадлежат этому
[177:00] => развертывание. И теперь они прибывают с помощью CRI. О. Хорошо, давайте не будем отключаться от этого сервера.
[177:10] => Хорошо, ребята, вот и все для этого курса Kubernetes для начинающих. Вы могли бы, конечно, сохранить свой
[177:16] => мини-кубический кластер работает. Вы могли бы создать другие развертывания, вы могли бы создавать другие образы Docker.
[177:22] => Другими словами, играйте с Kubernetes так, как вам хочется , и знакомьтесь со всеми инструментами Kubernetes, которые
[177:29] => мы обсуждали это в этом курсе. Я надеюсь, вам это понравится конечно, и я надеюсь, что вам понравилось проводить время с
[177:36] => мне. Если да, то вы можете найти меня в социальных сетях сети все ссылки вы найдете здесь, на экране
[177:42] => и я буду более чем рад встретиться с вами в других видео и желаю вам всего наилучшего. Пока-пока

• Урок 1.
  00:03:44

  Why Use Docker?

• Урок 2.
  00:02:54

  What is Docker?

• Урок 3.
  00:01:58

  Docker for Mac/Windows

• Урок 4.
  00:04:46

  Installing Docker on MacOS

• Урок 5.
  00:02:04

  Installing Docker for Windows Professional with HyperV

• Урок 6.
  00:00:41

  More Windows Professional Setup with HyperV

• Урок 7.
  00:01:10

  One Last Piece of Windows Professional Setup with HyperV

• Урок 8.
  00:05:04

  Using the Docker Client

• Урок 9.
  00:08:31

  But Really…What’s a Container?

• Урок 10.
  00:02:45

  How’s Docker Running on Your Computer?

• Урок 11.
  00:01:55

  Docker Run in Detail

• Урок 12.
  00:05:13

  Overriding Default Commands

• Урок 13.
  00:04:10

  Listing Running Containers

• Урок 14.
  00:05:17

  Container Lifecycle

• Урок 15.
  00:03:44

  Restarting Stopped Containers

• Урок 16.
  00:01:40

  Removing Stopped Containers

• Урок 17.
  00:02:34

  Retrieving Log Outputs

• Урок 18.
  00:05:22

  Stopping Containers

• Урок 19.
  00:04:17

  Multi-Command Containers

• Урок 20.
  00:02:54

  Executing Commands in Running Containers

• Урок 21.
  00:04:36

  The Purpose of the IT Flag

• Урок 22.
  00:04:07

  Getting a Command Prompt in a Container

• Урок 23.
  00:02:14

  Starting with a Shell

• Урок 24.
  00:03:10

  Container Isolation

• Урок 25.
  00:02:37

  Creating Docker Images

• Урок 26.
  00:04:52

  Building a Dockerfile

• Урок 27.
  00:02:42

  Dockerfile Teardown

• Урок 28.
  00:05:41

  What’s a Base Image?

• Урок 29.
  00:11:10

  The Build Process in Detail

• Урок 30.
  00:03:25

  A Brief Recap

• Урок 31.
  00:07:03

  Rebuilds with Cache

• Урок 32.
  00:04:27

  Tagging an Image

• Урок 33.
  00:05:01

  Manual Image Generation with Docker Commit

• Урок 34.
  00:02:36

  Project Outline

• Урок 35.
  00:05:04

  Node Server Setup

• Урок 36.
  00:05:13

  A Few Planned Errors

• Урок 37.
  00:07:51

  Base Image Issues

• Урок 38.
  00:03:19

  A Few Missing Files

• Урок 39.
  00:04:51

  Copying Build Files

• Урок 40.
  00:07:27

  Container Port Mapping

• Урок 41.
  00:07:53

  Specifying a Working Directory

• Урок 42.
  00:04:17

  Unnecessary Rebuilds

• Урок 43.
  00:04:59

  Minimizing Cache Busting and Rebuilds

• Урок 44.
  00:03:58

  App Overview

• Урок 45.
  00:06:44

  App Server Starter Code

• Урок 46.
  00:03:13

  Assembling a Dockerfile

• Урок 47.
  00:05:33

  Introducing Docker Compose

• Урок 48.
  00:06:03

  Docker Compose Files

• Урок 49.
  00:05:01

  Networking with Docker Compose

• Урок 50.
  00:04:39

  Docker Compose Commands

• Урок 51.
  00:02:35

  Stopping Docker Compose Containers

• Урок 52.
  00:02:54

  Container Maintenance with Compose

• Урок 53.
  00:09:22

  Automatic Container Restarts

• Урок 54.
  00:02:22

  Container Status with Docker Compose

• Урок 55.
  00:01:29

  Development Workflow

• Урок 56.
  00:06:33

  Flow Specifics

• Урок 57.
  00:01:51

  Docker’s Purpose

• Урок 58.
  00:03:26

  Project Generation

• Урок 59.
  00:01:45

  More on Project Generation

• Урок 60.
  00:05:10

  Necessary Commands

• Урок 61.
  00:03:43

  Creating the Dev Dockerfile

• Урок 62.
  00:01:30

  Duplicating Dependencies

• Урок 63.
  00:02:51

  Starting the Container

• Урок 64.
  00:06:54

  Docker Volumes

• Урок 65.
  00:04:51

  Bookmarking Volumes

• Урок 66.
  00:04:23

  Shorthand with Docker Compose

• Урок 67.
  00:02:03

  Overriding Dockerfile Selection

• Урок 68.
  00:02:52

  Do We Need Copy?

• Урок 69.
  00:03:39

  Executing Tests

• Урок 70.
  00:04:55

  Live Updating Tests

• Урок 71.
  00:05:46

  Docker Compose for Running Tests

• Урок 72.
  00:08:31

  Shortcomings on Testing

• Урок 73.
  00:03:08

  Need for Nginx

• Урок 74.
  00:06:55

  Multi-Step Docker Builds

• Урок 75.
  00:07:06

  Implementing Multi-Step Builds

• Урок 76.
  00:02:28

  Running Nginx

• Урок 77.
  00:03:05

  Services Overview

• Урок 78.
  00:03:58

  Github Setup

• Урок 79.
  00:04:18

  Travis CI Setup

• Урок 80.
  00:07:40

  Travis YML File Configuration

• Урок 81.
  00:04:15

  A Touch More Travis Setup

• Урок 82.
  00:03:31

  Automatic Build Creation

• Урок 83.
  00:04:11

  AWS Elastic Beanstalk

• Урок 84.
  00:02:26

  More on Elastic Beanstalk

• Урок 85.
  00:08:47

  Travis Config for Deployment

• Урок 86.
  00:07:18

  Automated Deployments

• Урок 87.
  00:03:57

  Exposing Ports Through the Dockerfile

• Урок 88.
  00:04:00

  Workflow With Github

• Урок 89.
  00:02:02

  Redeploy on Pull Request Merge

• Урок 90.
  00:02:04

  Deployment Wrapup

• Урок 91.
  00:03:03

  Single Container Deployment Issues

• Урок 92.
  00:04:31

  Application Overview

• Урок 93.
  00:05:12

  Application Architecture

• Урок 94.
  00:11:42

  Worker Process Setup

• Урок 95.
  00:05:20

  Express API Setup

• Урок 96.
  00:07:37

  Connecting to Postgres

• Урок 97.
  00:12:21

  More Express API Setup

• Урок 98.
  00:01:52

  Generating the React App

• Урок 99.
  00:06:32

  Fetching Data in the React App

• Урок 100.
  00:08:30

  Rendering Logic in the App

• Урок 101.
  00:00:27

  Exporting the Fib Class

• Урок 102.
  00:04:37

  Routing in the React App

• Урок 103.
  00:02:40

  Checkpoint Catchup

• Урок 104.
  00:06:42

  Dockerizing a React App — Again!

• Урок 105.
  00:03:48

  Dockerizing Generic Node Apps

• Урок 106.
  00:07:06

  Adding Postgres as a Service

• Урок 107.
  00:06:18

  Docker-compose Config

• Урок 108.
  00:10:21

  Environment Variables with Docker Compose

• Урок 109.
  00:03:43

  The Worker and Client Services

• Урок 110.
  00:09:42

  Nginx Path Routing

• Урок 111.
  00:11:13

  Routing with Nginx

• Урок 112.
  00:05:39

  Building a Custom Nginx Image

• Урок 113.
  00:01:51

  Starting Up Docker Compose

• Урок 114.
  00:03:23

  Troubleshooting Startup Bugs

• Урок 115.
  00:03:52

  Opening Websocket Connections

• Урок 116.
  00:05:40

  Production Multi-Container Deployments

• Урок 117.
  00:06:06

  Production Dockerfiles

• Урок 118.
  00:05:24

  Multiple Nginx Instances

• Урок 119.
  00:04:54

  Altering Nginx’s Listen Port

• Урок 120.
  00:01:12

  Cleaning Up Tests

• Урок 121.
  00:04:09

  Github and Travis CI Setup

• Урок 122.
  00:08:46

  Travis Configuration Setup

• Урок 123.
  00:07:35

  Pushing Images to Docker Hub

• Урок 124.
  00:01:50

  Successful Image Building

• Урок 125.
  00:04:31

  Multi-Container Definition Files

• Урок 126.
  00:03:10

  Finding Docs on Container Definitions

• Урок 127.
  00:05:46

  Adding Container Definitions to DockerRun

• Урок 128.
  00:05:19

  More Container Definitions

• Урок 129.
  00:07:48

  Forming Container Links

• Урок 130.
  00:03:31

  Creating the EB Environment

• Урок 131.
  00:10:45

  Managed Data Service Providers

• Урок 132.
  00:09:22

  Overview of AWS VPC’s and Security Groups

• Урок 133.
  00:06:32

  RDS Database Creation

• Урок 134.
  00:04:12

  ElastiCache Redis Creation

• Урок 135.
  00:04:19

  Creating a Custom Security Group

• Урок 136.
  00:05:00

  Applying Security Groups to Resources

• Урок 137.
  00:07:56

  Setting Environment Variables

• Урок 138.
  00:05:13

  IAM Keys for Deployment

• Урок 139.
  00:03:21

  Travis Deploy Script

• Урок 140.
  00:04:11

  Container Memory Allocations

• Урок 141.
  00:02:57

  Verifying Deployment

• Урок 142.
  00:01:30

  A Quick App Change

• Урок 143.
  00:00:58

  Making Changes

• Урок 144.
  00:05:06

  Cleaning Up AWS Resources

• Урок 145.
  00:08:07

  The Why’s and What’s of Kubernetes

• Урок 146.
  00:05:48

  Kubernetes in Development and Production

• Урок 147.
  00:05:37

  Minikube Setup on MacOS

• Урок 148.
  00:07:38

  Mapping Existing Knowledge

• Урок 149.
  00:06:53

  Adding Configuration Files

• Урок 150.
  00:06:56

  Object Types and API Versions

• Урок 151.
  00:09:20

  Running Containers in Pods

• Урок 152.
  00:13:38

  Service Config Files in Depth

• Урок 153.
  00:10:25

  Connecting to Running Containers

• Урок 154.
  00:13:03

  The Entire Deployment Flow

• Урок 155.
  00:13:37

  Imperative vs Declarative Deployments

• Урок 156.
  00:06:11

  Updating Existing Objects

• Урок 157.
  00:07:05

  Declarative Updates in Action

• Урок 158.
  00:02:56

  Limitations in Config Updates

• Урок 159.
  00:06:04

  Running Containers with Deployments

• Урок 160.
  00:03:19

  Deployment Configuration Files

• Урок 161.
  00:04:24

  Walking Through the Deployment Config

• Урок 162.
  00:06:23

  Applying a Deployment

• Урок 163.
  00:05:20

  Why Use Services?

• Урок 164.
  00:06:32

  Scaling and Changing Deployments

• Урок 165.
  00:03:58

  Updating Deployment Images

• Урок 166.
  00:03:00

  Rebuilding the Client Image

• Урок 167.
  00:12:25

  Triggering Deployment Updates

• Урок 168.
  00:07:25

  Imperatively Updating a Deployment’s Image

• Урок 169.
  00:05:38

  Multiple Docker Installations

• Урок 170.
  00:05:58

  Reconfiguring Docker CLI

• Урок 171.
  00:05:06

  Why Mess with Docker in the Node?

• Урок 172.
  00:05:14

  The Path to Production

• Урок 173.
  00:04:37

  A Quick Checkpoint

• Урок 174.
  00:05:31

  Recreating the Deployment

• Урок 175.
  00:03:42

  NodePort vs ClusterIP Services

• Урок 176.
  00:03:53

  The ClusterIP Config

• Урок 177.
  00:04:19

  Applying Multiple Files with Kubectl

• Урок 178.
  00:06:03

  Express API Deployment Config

• Урок 179.
  00:03:09

  Cluster IP for the Express API

• Урок 180.
  00:06:00

  Combining Config Into Single Files

• Урок 181.
  00:04:37

  The Worker Deployment

• Урок 182.
  00:04:52

  Reapplying a Batch of Config Files

• Урок 183.
  00:07:27

  Creating and Applying Redis Config

• Урок 184.
  00:06:15

  Last Set of Boring Config!

• Урок 185.
  00:07:19

  The Need for Volumes with Databases

• Урок 186.
  00:05:18

  Kubernetes Volumes

• Урок 187.
  00:03:00

  Volumes vs Persistent Volumes

• Урок 188.
  00:09:23

  Persistent Volumes vs Persistent Volume Claims

• Урок 189.
  00:02:58

  Claim Config Files

• Урок 190.
  00:03:32

  Persistent Volume Access Modes

• Урок 191.
  00:07:43

  Where Does Kubernetes Allocate Persistent Volumes?

• Урок 192.
  00:06:10

  Designating a PVC in a Pod Template

• Урок 193.
  00:02:23

  Applying a PVC

• Урок 194.
  00:04:10

  Defining Environment Variables

• Урок 195.
  00:05:45

  Adding Environment Variables to Config

• Урок 196.
  00:09:26

  Creating an Encoded Secret

• Урок 197.
  00:05:54

  Passing Secrets as Environment Variables

• Урок 198.
  00:02:18

  Environment Variables as Strings

• Урок 199.
  00:04:15

  Load Balancer Services

• Урок 200.
  00:03:33

  A Quick Note on Ingresses

• Урок 201.
  00:01:38

  One Other Quick Note!

• Урок 202.
  00:05:18

  Behind the Scenes of Ingress

• Урок 203.
  00:06:39

  More Behind the Scenes of Ingress

• Урок 204.
  00:06:22

  Setting up Ingress Locally with Minikube

• Урок 205.
  00:07:01

  Creating the Ingress Configuration

• Урок 206.
  00:02:51

  Testing Ingress Locally

• Урок 207.
  00:03:29

  The Minikube Dashboard

• Урок 208.
  00:05:50

  The Deployment Process

• Урок 209.
  00:04:54

  Google Cloud vs AWS for Kubernetes

• Урок 210.
  00:04:00

  Creating a Git Repo

• Урок 211.
  00:01:36

  Linking the Github Repo to Travis

• Урок 212.
  00:02:00

  Creating a Google Cloud Project

• Урок 213.
  00:02:12

  Linking a Billing Account

• Урок 214.
  00:01:48

  Kubernetes Engine Init

• Урок 215.
  00:04:48

  Creating a Cluster with Google Cloud

• Урок 216.
  00:04:35

  Kubernetes Dashboard on Google Cloud

• Урок 217.
  00:05:05

  Travis Deployment Overview

• Урок 218.
  00:05:45

  Installing the Google Cloud SDK

• Урок 219.
  00:05:30

  Generating a Service Account

• Урок 220.
  00:09:18

  Running Travis CLI in a Container

• Урок 221.
  00:07:55

  Encrypting a Service Account File

• Урок 222.
  00:04:41

  More Google Cloud CLI Config

• Урок 223.
  00:06:19

  Running Tests with Travis

• Урок 224.
  00:03:50

  Custom Deployment Providers

• Урок 225.
  00:08:34

  Unique Deployment Images

• Урок 226.
  00:07:48

  Unique Tags for Built Images

• Урок 227.
  00:07:52

  Updating the Deployment Script

• Урок 228.
  00:05:35

  Configuring the GCloud CLI on Cloud Console

• Урок 229.
  00:02:25

  Creating a Secret on Google Cloud

• Урок 230.
  00:08:16

  Helm Setup

• Урок 231.
  00:08:22

  Kubernetes Security with RBAC

• Урок 232.
  00:05:09

  Assigning Tiller a Service Account

• Урок 233.
  00:01:57

  Ingress-Nginx with Helm

• Урок 234.
  00:03:49

  The Result of Ingress-Nginx

• Урок 235.
  00:03:31

  Finally — Deployment!

• Урок 236.
  00:00:46

  Did I Really Type That?

• Урок 237.
  00:05:21

  Verifying Deployment

• Урок 238.
  00:04:30

  A Workflow for Changing in Prod

• Урок 239.
  00:01:02

  Merging a PR for Deployment

• Урок 240.
  00:01:38

  That’s It! What’s Next?

• Урок 241.
  00:05:36

  HTTPS Setup Overview

• Урок 242.
  00:02:18

  Domain Purchase

• Урок 243.
  00:03:31

  Domain Name Setup

• Урок 244.
  00:01:58

  Cert Manager Install

• Урок 245.
  00:05:59

  How to Wire Up Cert Manager

• Урок 246.
  00:05:08

  Issuer Config File

• Урок 247.
  00:05:19

  Certificate Config File

• Урок 248.
  00:03:16

  Deploying Changes

• Урок 249.
  00:03:55

  Verifying the Certificate

• Урок 250.
  00:06:50

  Ingress Config for HTTPS

• Урок 251.
  00:02:53

  It Worked!

• Урок 252.
  00:03:55

  Awkward Local Development

• Урок 253.
  00:02:00

  Installing Skaffold

• Урок 254.
  00:06:44

  The Skaffold Config File

• Урок 255.
  00:05:03

  Live Sync Changes

• Урок 256.
  00:05:08

  Automatic Shutdown

• Урок 257.
  00:05:30

  Testing Live Sync with the API Server

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

Зачем нужен Kubernetes

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

Причины популярности Kubernetes:

1. Развертываемые приложения отделены от инфраструктуры для повышения безопасности.
2. Разработка и тестирование работают одинаково на локальном компьютере и в облаке.
3. Контейнеры свободно переносятся между Ubuntu, CoreOS, RHEL и другими системами.
4. Происходит изоляция ресурсов с прогнозированием производительности.

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

Назначение Kubernetes

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

Перечень возможностей:

1. Обнаружение контейнера происходит по имени DNS или IP-адресу.
2. Система самостоятельно балансирует нагрузку и распределяет трафик в сети.
3. Подключение выбранного типа хранилища происходит в автоматическом режиме.
4. Платформа перезапускает отказавшие контейнеры или блокирует к ним доступ.
5. Конфиденциальная информация хранится изолированно от других данных.

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

Основные компоненты архитектуры

Несмотря на удобство и простоту фреймворка Kubernetes, перед его использованием, при разработке или развертывании приложений, необходимо разобраться в архитектуре. Например, понять, как соединяются между собой контейнеры (через интерфейс API), и узнать, почему компоненты разделены на две основные группы – Master Node и Worker Node.

Базовые компоненты:

1. Nodes – виртуальная (физическая) машина, на мощностях которой запущены контейнеры.
2. Pods – базовые модули управления приложениями, состоящие из одного или нескольких контейнеров.
3. Volume – ресурс, позволяющий одновременно запускать несколько контейнеров.
4. Kube-Proxy – комплекс из прокси-сервера и модуля балансировки нагрузки, позволяющий маршрутизировать входящий трафик под конкретный контейнер Pods.
5. Kubelet – транслятор статусов Pods на узле и контроллер корректности работы контейнера и образа в целом.

Перечисленные компоненты устанавливаются автоматически при помощи сторонних инструментов или вручную, по отдельности. Они составляют модуль под названием Master Node, где собраны все управляющие и контролирующие функции. Через API они связываются с контейнерами, считывают их показатели, дают команду на запуск, штатную остановку или принудительное закрытие.

Процесс установки Kubernetes 

При выборе автоматической установки вникать в детали не понадобится, но требуется выделить достаточное количество системных ресурсов, чтобы платформа работала бесперебойно. Например, при небольшом количестве контейнеров и простой взаимосвязи достаточно 1-2 процессорных ядер, 2-4 Гб оперативки и двух виртуальных машин, выполняющих функции Master и Worker Node.

Инсталляция на Ubuntu

Проще всего воспользоваться одной из готовых реализаций – Minikube или Kubespray. Если нужно установить Kubernetes на сервер с операционной системой Ubuntu вручную, понадобятся права суперпользователя. Начнем с установки Docker для узла. Перечень команд для этого выглядит следующим образом:

apt-get update

apt-get install -y docker.io

При необходимости организовать создание контейнеров более новых версий перечень команд будет несколько иным:

apt-get update

apt-get install -y 

apt-transport-https 

ca-certificates 

curl 

software-properties-common

curl -fsSL https://download.docker.com/linux/ubuntu/gpg | apt-key add –

add-apt-repository 

         "deb [arch=amd64] https://download.docker.com/linux/$(. /etc/os-release; echo "$ID") 

         $(lsb_release -cs) 

         stable"

apt-get update

apt-get install -y docker-ce docker-ce-cli containerd.io

Docker для одного узла установлен. Следующий шаг – установка модулей kubeadm (создание и настройка кластеров), kubelet (их запуск на хостах), kubectl (настройка компонентов, входящих в кластер). Для этого вводятся следующие команды:

apt-get update && apt-get install -y apt-transport-https software-properties-common

curl -s https://packages.cloud.google.com/apt/doc/apt-key.gpg | apt-key add -

add-apt-repository "deb http://apt.kubernetes.io/ kubernetes-xenial main"

apt-get update

apt-get install -y kubelet kubeadm kubectl

systemctl enable kubelet && systemctl start kubelet

Инсталляция на CentOS

При установке на операционную систему CentOS любой версии нужно выполнить ряд требований. Так, понадобится минимум 3 машины (1 главный, 2 рабочих узла), которые подключены к общей сети или интернету. Здесь также вся работа проводится в учетной записи sudo или root. Процедура проводится, как и в случае с Ubuntu, через консоль.

Команды для установки Docker:

yum install -y docker

systemctl enable docker && systemctl start docker

Компоненты Kubernetes (kubeadm, kubelet, kubectl) инсталлируются так:

cat <<EOF > /etc/yum.repos.d/kubernetes.repo

[kubernetes]

name=Kubernetes

baseurl=https://packages.cloud.google.com/yum/repos/kubernetes-el7-x86_64

enabled=1

gpgcheck=1

repo_gpgcheck=1

gpgkey=https://packages.cloud.google.com/yum/doc/yum-key.gpg https://packages.cloud.google.com/yum/doc/rpm-package-key.gpg

EOF

setenforce 0

yum install -y kubelet kubeadm kubectl

systemctl enable kubelet && systemctl start kubelet

После ввода команд (при отсутствии ошибок) можно приступать к настройке платформы. Процесс включает инициализацию кластера, создание CNI, добавление узлов Nodes и получение токена для авторизации.

Настройка Kubernetes

Сначала указывается сервер, на который был инсталлирован Kubernetes. Он становится первичным, где будут запускаться остальные операции. Инициализация выполняется при помощи команды:

kubeadm init --pod-network-cidr=10.244.0.0/16

В результате создается адрес виртуальной сети Pods (цифры выбираются по желанию пользователя). По умолчанию используется указанный IP. При правильной обработке команды на дисплее будет отображаться команда для присоединения остальных Nods-кластеров к первичному серверу, чтобы создать в итоге рабочую систему.

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

mkdir -p $HOME/.kube

sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config

sudo chown $(id -u):$(id -g) $HOME/.kube/config

Теперь можно настраивать Container Network Interface (CNI, сетевой интерфейс контейнера). Чтобы избавить себя от рутины ручного ввода команд, рекомендуется установить плагин Flannel или ему подобный (Weave Net, Calico). Первый устанавливается так:

kubectl apply -f https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel.yml

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

Теперь пользователь добавляет Nods в существующий кластер. Для этого требуется подключение к серверу через SSH, установка модулей Docker, Kubelet, Kubeadm (вопрос рассматривался выше). Выполнение команды:

kubeadm join --token <token> <control-plane-host>:<control-plane-port> --discovery-token-ca-cert-hash sha256:<hash>

Остается получить токен авторизации кластера. Если подключение SSH еще не прервано, повторно заходить на сервер не нужно. Токен выдается после ввода команды:

kubeadm token list

По умолчанию он действует 24 часа. Если поставлена задача добавить новый узел по завершении периода, новый создается командой:

kubeadm token create

Вывод выглядит примерно так:

5didvk.d09sbcov8ph2amjw

На этом все. Система готова к эксплуатации. Дальнейшие действия пользователя зависят от стоящих задач и опыта.