Репозиторий для выполнения домашних заданий курса "Инфраструктурная платформа на основе Kubernetes-2024-08"

Практические занятия:

skyfly535_repo

skyfly535 kubernetes repository

Оглавление:

• HW1 Знакомство с решениями для запуска локального Kubernetes кластера, создание первого pod.

• HW2 Kubernetes controllers. ReplicaSet, Deployment, DaemonSet.

• HW3 Сетевое взаимодействие Pod, сервисы.

• HW4 Volumes, StorageClass, PV, PVC.

• HW5 Настройка сервисных аккаунтов и ограничение прав для них.

• HW6 Шаблонизация манифестов приложения, использование Helm. Установка community Helm charts.

• HW7 Создание собственного CRD.

• HW8 Мониторинг приложения в кластере.

• HW9 Сервисы централизованного логирования для Kubernetes.

• HW10 GitOps и инструменты поставки.

• HW11 Хранилище секретов для приложения. Vault.

HW11 Хранилище секретов для приложения. Vault.

В процессе выполнения ДЗ выполнены следующие мероприятия:

1. Написаны манифесты

Terraform

для установки кластера Kubernetes удовлетворяющего условиям ДЗ в

Yandex Cloud

.

Создан файл

со следующим содержимым:

# Создание Kubernetes-кластера

resource "yandex_kubernetes_cluster" "yc_cluster" {
  name                    = var.cluster_name

  master {
    zonal {
      zone      = var.zone
      subnet_id = var.subnet_id
    }
    version               = var.k8s_version
    public_ip             = true
  }

  network_id              = var.network_id

  service_account_id      = var.service_account_id
  node_service_account_id = var.service_account_id

  release_channel         = "RAPID"
  network_policy_provider = "CALICO"
}

# Создание групп узлов для рабочих нагрузок
resource "yandex_kubernetes_node_group" "workload_node_group" {
  cluster_id  = yandex_kubernetes_cluster.yc_cluster.id

  name        = "${var.cluster_name}-workload"
  version     = var.k8s_version
  count       = var.workload_nodes_count

  instance_template {
    platform_id = "standard-v2"

    network_interface {
      nat                = true
      subnet_ids         = [var.subnet_id]
    }

    resources {
      memory = var.node_memory_size
      cores  = var.node_cpu_count
    }

    boot_disk {
      type = "network-ssd"
      size = var.node_disk_size
    }

    scheduling_policy {
      preemptible = false
    }

    container_runtime {
      type = "containerd"
    }
  }

  scale_policy {
    fixed_scale {
      size = 1
    }
  }
  
  # создана метка для узлов этой группы для управления раскаткой нагрузки
  
  node_labels = {
    worknode = "true"
  }
  
}

---

2. При помощи файла

values.yaml

(чарта

Consul

) сконфигурирована установка компонентов

Consul

в одноименный namespase.

Установка Consul в namespace

с 3 репликами сервера

Создан файл чарта

со следующим содержимым:

Создан файл переменных

со следующим содержимым:

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

1. Обнаружение сервисов: Consul позволяет сервисам регистрироваться и обнаруживать другие сервисы с помощью DNS или HTTP интерфейсов. Это обеспечивает динамическую регистрацию и обнаружение без необходимости жестко задавать IP-адреса.

2. Проверка работоспособности: Он выполняет проверки состояния сервисов, чтобы убедиться в их корректной работе. Если сервис не проходит проверку, Consul может автоматически удалить его из реестра, предотвращая отправку трафика на неисправные сервисы.

3. Хранилище ключ/значение: Consul включает распределенное хранилище ключ/значение, которое можно использовать для хранения конфигурационных данных, флагов функций или любых других динамических параметров, необходимых приложениям во время выполнения.

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

5. Сегментация сервисов: С помощью возможностей сервисной сетки (service mesh), Consul может управлять безопасным взаимодействием между сервисами, предоставляя функции аутентификации и шифрования с использованием mTLS.

В контексте текущего развертывания Kubernetes:

• Бэкенд высокой доступности для Vault: Vault — это инструмент для безопасного хранения и доступа к секретам и конфиденциальным данным. При работе Vault в режиме высокой доступности (HA) требуется хранилище, поддерживающее выбор лидера и репликацию данных. Consul служит таким хранилищем, обеспечивая необходимые функции для поддержания высокой доступности Vault и согласованной репликации данных между узлами.

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

• Динамическая конфигурация: С помощью своего хранилища ключ/значение, Consul позволяет централизованно управлять конфигурационными данными. Приложения могут получать настройки во время выполнения, что позволяет динамически обновлять конфигурации без перезапуска сервисов.

• Масштабируемость и надежность: Распределенная архитектура Consul позволяет ему масштабироваться вместе с вашей инфраструктурой. Его способность работать в нескольких узлах и датацентрах повышает общую надежность и устойчивость вашей системы.

---

3. При помощи файла

values.yaml

(чарта

Vault

) сконфигурирована установка компонентов

Vault

в одноименный namespase.

Установка Vault в namespace

с использованием Consul в режиме HA

Создан файл чарта

со следующим содержимым:

Создан файл переменных

со следующим содержимым:

Данный файл

предназначен для настройки установки HashiCorp Vault с помощью Helm-чарта в Kubernetes. В нем определены параметры для различных компонентов Vault, таких как сервер, агент, инжектор и CSI-провайдер. Ниже подробно описан каждый раздел файла:

---

1. Инжектор (injector):

Описание:

• injector.image.repository: Указывает пользовательский репозиторий Docker-образа для инжектора Vault Kubernetes. В данном случае используется репозиторий

  dockerhub.timeweb.cloud/hashicorp/vault-k8s
  .

• injector.agentImage.repository: Указывает репозиторий Docker-образа для агента Vault, который используется инжектором. Здесь используется образ

  dockerhub.timeweb.cloud/hashicorp/vault
  .

Назначение:

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

---

2. CSI-провайдер (csi):

Описание:

• csi.image.repository: Указывает репозиторий Docker-образа для провайдера Vault CSI. Используется образ
  dockerhub.timeweb.cloud/hashicorp/vault-csi-provider
  .

Назначение:

Vault CSI-провайдер позволяет Kubernetes использовать секреты из Vault в качестве томов через интерфейс Container Storage Interface (CSI). Это дает возможность приложениям монтировать секреты как файлы или тома, обеспечивая более гибкое и безопасное управление конфиденциальными данными.

---

3. Агент (agent):

Описание:

• agent.image.repository: Указывает репозиторий Docker-образа для агента Vault. Образ берется из
  dockerhub.timeweb.cloud/hashicorp/vault
  .

Назначение:

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

---

4. Сервер (server):

Описание:

• server.image.repository: Указывает репозиторий Docker-образа для сервера Vault. Используется образ

  dockerhub.timeweb.cloud/hashicorp/vault
  .

• ha.enabled: Включает режим высокой доступности (High Availability) для Vault. Значение

  true
  означает, что HA-режим активирован.

• ha.replicas: Указывает количество реплик сервера Vault в HA-режиме. Здесь установлено 3 реплики для обеспечения отказоустойчивости и распределения нагрузки.

• ha.config: Содержит встроенную конфигурацию сервера Vault. Вот что входит в эту конфигурацию:

  • ui = true: Активирует веб-интерфейс Vault, позволяя администраторам управлять секретами через браузер.

  • listener "tcp" { ... }: Настраивает сетевой слушатель Vault.

    • tls_disable = 1: Отключает TLS-шифрование. Это означает, что соединения будут нешифрованными. Важно: В производственной среде TLS должен быть включен для обеспечения безопасности.
    • address = "[::]:8200": Указывает, что Vault будет слушать на порту 8200 на всех сетевых интерфейсах (IPv4 и IPv6).

  • storage "consul" { ... }: Настраивает Consul в качестве бэкенда хранения для Vault.

    • path = "vault": Указывает путь в Consul, где Vault будет хранить свои данные.
    • address = "consul-server.consul:8500": Указывает адрес Consul-сервера. В данном случае это сервис
      consul-server
      в namespace
      consul
      на порту 8500.

  • service_registration "kubernetes" {}: Включает регистрацию сервиса Vault в Kubernetes. Это позволяет Vault взаимодействовать с Kubernetes API для обнаружения сервисов и упрощения интеграции.

Назначение:

Этот раздел настраивает серверную часть Vault для работы в режиме высокой доступности с использованием Consul в качестве хранилища данных. Это обеспечивает надежное и устойчивое к сбоям хранение секретов и состояния кластера Vault.

---

Дополнительные пояснения:

• Пользовательские репозитории образов:

  Все образы Docker берутся из частного реестра

  dockerhub.timeweb.cloud/hashicorp/
  . Это может быть необходимо для ускорения загрузки образов, соответствия политикам безопасности компании или использования проверенных версий образов.

• Отключение TLS:

  В конфигурации слушателя TLS отключен (

  tls_disable = 1
  ). Это упрощает начальную настройку и тестирование, но не рекомендуется для производственной среды из-за рисков безопасности. В реальных условиях следует настроить TLS для шифрования трафика между клиентами и сервером Vault.

• Использование Consul в качестве бэкенда хранения:

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

• Регистрация сервиса в Kubernetes:

  Секция

  service_registration "kubernetes" {}
  позволяет Vault автоматически регистрировать себя в Kubernetes. Это упрощает процессы обслуживания и обновления, а также позволяет другим сервисам в кластере находить Vault через стандартные механизмы Kubernetes.

---

Итоговое назначение файла

values.yaml

:

• Устанавливает Vault в режиме высокой доступности с 3 репликами.
• Настраивает использование Consul в качестве бэкенда хранения для обеспечения отказоустойчивости и согласованности данных.
• Конфигурирует инжектор и агент Vault для автоматического внедрения секретов в приложения Kubernetes.
• Включает веб-интерфейс Vault для удобства управления.
• Использует пользовательские образы Docker из частного реестра.

---

Этот файл

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

---

4. Создан файл

./skyfly535_repo/kubernetes-vault/external-secrets-operator/helmfile.yaml

для установка компонентов (чарта

external-secrets

)

external-secrets

в namespase

Vault

.

— это, по сути,

контроллер Kubernetes

, который управляет секретами, хранящимися за пределами кластера, например, в

HashiCorp Vault

или облачной системе управления секретами, такой как AWS Secrets Manager. Когда модулю требуется доступ к определённому секрету, внешний оператор секретов извлекает его из внешней системы и делает доступным для модуля в качестве секрета Kubernetes.

External Secret Operator работает, создавая три

: ClusterSecretStore, SecretStore и ExternalSecret.

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

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

---

5. Создан файл

./skyfly535_repo/kubernetes-vault/sa.yaml

для создания

serviceAccount

с именем

vault-auth

и

ClusterRoleBinding

для него с ролью

system:auth-delegator

в namespase

Vault

.

6. Создан файл

./skyfly535_repo/kubernetes-vault/otus-policy.hcl

для применитя политики

otus-policy

секретов

/otus/cred

с

capabilities = [“read”, “list”]

.

path "/otus/data/cred" {
  capabilities = ["read","list"]
}

path "/otus/metadata/cred" {
    capabilities = ["read", "list"]
}

path "auth/token/renew-self" {
    capabilities = ["update"]
}

7. Создан манифест

./skyfly535_repo/kubernetes-vault/secretStore.yaml

в namespace

vault

, сконфигурированный для доступа к

KV секретам Vault

с использованием ранее созданной роли

otus

и сервис аккаунта

vault-auth

.

8. Создан манифест

./skyfly535_repo/kubernetes-vault/externalSecret.yaml

удовлетваряющий параметрам ДЗ.

● ns – vaultж;

● SecretStore – созданный на прошлом шаге;

● Target.name = otus-cred;

● Получает значения KV секрета /otus/cred из vault и отображает их в два ключа – username и password соответственно.

9. Написан скрипт

install.sh

для автоматического развертывания требуемой инфраструктуры.

10. Произведена проверка развернутой инфраструктуры.

10.1 Получаем список ExternalSecret:

10.2 Смотрим подробности о ExternalSecret

:

10.3 Получаем YAML-спецификацию ExternalSecret

:

10.4 Проверяем статус синхронизации:

10.5 Смотрим созданный Secret

:

10.6 Декодируем значения Secret (если необходимо):

---

Хранилище секретов otus/ с Secret Engine KV и секретом otus/cred

Метод аутентификации Kubernetes

---

HW10 GitOps и инструменты поставки.

В процессе выполнения ДЗ выполнены следующие мероприятия:

1. Написаны манифесты

Terraform

для установки кластера Kubernetes удовлетворяющего условиям ДЗ в

Yandex Cloud

.

# Создание Kubernetes-кластера

resource "yandex_kubernetes_cluster" "yc_cluster" {
  name                    = var.cluster_name

  master {
    zonal {
      zone      = var.zone
      subnet_id = var.subnet_id
    }
    version               = var.k8s_version
    public_ip             = true
  }

  network_id              = var.network_id

  service_account_id      = var.service_account_id
  node_service_account_id = var.service_account_id

  release_channel         = "RAPID"
  network_policy_provider = "CALICO"
}

# Создание групп узлов для рабочих нагрузок
resource "yandex_kubernetes_node_group" "workload_node_group" {
  cluster_id  = yandex_kubernetes_cluster.yc_cluster.id

  name        = "${var.cluster_name}-workload"
  version     = var.k8s_version
  count       = var.workload_nodes_count

  instance_template {
    platform_id = "standard-v2"

    network_interface {
      nat                = true
      subnet_ids         = [var.subnet_id]
    }

    resources {
      memory = var.node_memory_size
      cores  = var.node_cpu_count
    }

    boot_disk {
      type = "network-ssd"
      size = var.node_disk_size
    }

    scheduling_policy {
      preemptible = false
    }

    container_runtime {
      type = "containerd"
    }
  }

  scale_policy {
    fixed_scale {
      size = 1
    }
  }
  
  # создана метка для узлов этой группы для управления раскаткой нагрузки
  
  node_labels = {
    homework = "true"
  }

  
}

# Создание групп узлов для инфраструктуры
resource "yandex_kubernetes_node_group" "infra_node_group" {
  cluster_id  = yandex_kubernetes_cluster.yc_cluster.id

  name        = "${var.cluster_name}-infra"
  version     = var.k8s_version
  count       = var.infra_nodes_count

  instance_template {
    platform_id = "standard-v2"

    network_interface {
      nat                = true
      subnet_ids         = [var.subnet_id]
    }

    resources {
      memory = var.node_memory_size
      cores  = var.node_cpu_count
    }

    boot_disk {
      type = "network-ssd"
      size = var.node_disk_size
    }

    scheduling_policy {
      preemptible = false
    }

    container_runtime {
      type = "containerd"
    }
  }

  scale_policy {
    fixed_scale {
      size = 1
    }
  }

  # создана метка для узлов этой группы для управления раскаткой нагрузки

  node_labels = {
    node-role = "infra"
  }

  # добавлен taint, запрещающий на нее планирование подов с посторонней нагрузкой

  node_taints = [
    "node-role=infra:NoSchedule"
  ]
 

}

---

2. При помощи файла

values.yaml

(чарта

Argocd

) сконфигурирована установка компонентов argoCD исключительно на infra-ноды (добавлены соответствующие

toleration

для обхода

taint

, а также

nodeSelector

и

nodeAffinity

).

Файл

3. Создан манифест

appproject.yaml

для развертывания в Argocd

project

с именем

Otus

.

Файл

---

4. Создан манифест

kubernetes-network.yaml

для развертывания в Argocd тестового приложения

kubernetes-network

описанного в репозитории

https://github.com/Kuber-2024-08OTUS/skyfly535_repo.git

.

Файл

---

5. Создан манифест

kubernetes-templating.yaml

для развертывания в Argocd. тестового приложения

kubernetes-templating.yaml

описанного в репозитории

https://github.com/Kuber-2024-08OTUS/skyfly535_repo.git

.

Файл

---

5. Написан скрипт

install.sh

для автоматического развертывания требуемой инфраструктуры.

Файл

---

После завершения работы скрипта полезно воспользоваться "выхлопом" установки чарта

---

6. Произведена проверка развернутой инфраструктуры.

• 6.1 Вся нагрузка
  Argocd
  развернута на инфраструктурной ноде, а нагрузка приложений на ноде для рабочей нагрузки.

---

• 6.2 Смотрим через
  Argocd
  на визуализацию запущенного тестового приложения
  kubernetes-network
  .

Стучимся в приложение

---

• 6.3 Смотрим через
  Argocd
  на визуализацию запущенного тестового приложения
  kubernetes-templating
  .

Стучимся в приложение

---

HW9 Сервисы централизованного логирования для Kubernetes.

В процессе выполнения ДЗ выполнены следующие мероприятия:

1. Проверена работ ранее подготовленного интерфейса командной строки Yandex Cloud.

2. Нагуглен и адаптирован скрипт, разворачивающий инфраструктуру удовлетворяющую условиям ДЗ.

3. Произведена проверка развернутой инфраструктуры.

• 3.1 Вся нагрузка развернута (за исключением одного poda promatil) на инфраструктурной ноде.

• 3.2 Созданы необходимые
  S3
  бакеты.

• 3.3 Проверена визуализаця информации логирования в Grafana.

Пользуемся "выхлопом"

наблюдаем следующую картину

HW8 Мониторинг приложения в кластере.

В процессе выполнения ДЗ выполнены следующие мероприятия:

1. Установлен

Prometheus Operator

через Helm-чарт.

1.1 Добавка репозитория и обновление его:

1.2 Установка Prometheus Operator:

2. Создан манифест

CM-Nginx.yaml (ConfigMap)

, который содержит необходимую

конфигурацию NGINX

для дальнейшего монтирования

Deployment

.

3. Создан

Deployment

для nginx с необходимыми настройками для

Prometheus Exporter

.

Реализован вариант включения экспортера при помощи

.

4. Создан

Service

Deployment-а для экспонирования метрик.

b. Service (

):

---

5. Создан

ServiceMonitor

для сбора метрик.

ServiceMonitor (

)

---

**Применяем манифесты **

---

Проверяем

---

HW7 Создание собственного CRD.

В процессе выполнения ДЗ выполнены следующие мероприятия:

1. Создан манифест объекта

CustomResourceDefinition

удовлетворяющий требованиям ДЗ.

1.1 CustomResourceDefinition (CRD) для MySQL

---

1.2 ServiceAccount, ClusterRole и ClusterRoleBinding

• ServiceAccount

• ClusterRole с полным доступом

• ClusterRoleBinding

---

1.3 Deployment для оператора

---

1.4 Кастомный ресурс типа MySQL

---

Пояснение:

• CRD: Определяет новый кастомный ресурс
  MySQL
  с обязательными строковыми атрибутами:
  image
  ,
  database
  ,
  password
  и
  storage_size
  .
• ServiceAccount, ClusterRole, ClusterRoleBinding: Настраивает сервисный аккаунт
  mysql-operator
  с полным доступом к API.
• Deployment: Развертывает оператор, используя указанный образ и сервисный аккаунт.
• Кастомный ресурс: Экземпляр
  MySQL
  , которым будет управлять оператор.

Применяем манифесты и проверяем работу оператора

Проверку проводим в

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

• Проверка создания CRD

• Проверяем, что Deployment оператора работает

• Проверка кастомного ресурса

• Проверка созданных оператором Deployment, Service, PV и PVC

• Удаление кастомного ресурса и проверка очистки

2. Изменен манифест

ClusterRole

, для описания в нем минимального набора прав доступа необходимых для нашего CRD.

Обновленный манифест ClusterRole с минимальным набором прав доступа:

Пояснение:

2.1 Управление ресурсом CRD (

):

• apiGroups:
  otus.homework
• resources:
  mysqls
  ,
  mysqls/status
• verbs:
  get
  ,
  list
  ,
  watch
  ,
  create
  ,
  update
  ,
  patch
  ,
  delete

Это позволяет оператору управлять своими кастомными ресурсами

, включая их создание, обновление и удаление.

2.2 Создание и управление Deployment:

• apiGroups:
  apps
• resources:
  deployments
  ,
  deployments/status
• verbs:
  get
  ,
  list
  ,
  watch
  ,
  create
  ,
  update
  ,
  patch
  ,
  delete

Оператор создает Deployment для запуска экземпляра MySQL, поэтому ему необходимы эти права.

2.3 Создание и управление Service и PersistentVolumeClaim (PVC):

• apiGroups:
  ""
  (core API group)
• resources:
  services
  ,
  persistentvolumeclaims
  ,
  pods
  ,
  events
  ,
  pods/status
  ,
  persistentvolumes
• verbs:
  get
  ,
  list
  ,
  watch
  ,
  create
  ,
  update
  ,
  patch
  ,
  delete

Проверяем

Смотрим лог пода кастомного ресурса

3. Создан свой оператор, который реализовывать функционал удовлетворяющий условиям ДЗ.

• При создании объекта
  MySQL
  оператор будет создавать:
  • Deployment с указанным образом MySQL.
  • Service типа
    ClusterIP
    .
  • PersistentVolume (PV) и PersistentVolumeClaim (PVC) с заданным размером и
    StorageClass
    .
• При удалении объекта
  MySQL
  оператор будет удалять созданные ресурсы.

---

Установка Operator SDK

1. Установка
   Go
   (необходим для Operator SDK):

2. Установка
   Operator SDK
   :

3. Проверка установки:

---

Инициализация проекта оператора

1. Создаем директорию для проекта и переходим в нее:

2. Инициализируем новый
   Ansible-оператор
   :

---

Создание API и CRD

1. Создайте API для ресурса
   MySQL
   :

Это создаст структуру каталогов и файлов для вашего CRD и соответствующих Ansible-ролей.

2. Обновлен CRD с необходимыми полями и валидацией. Файл
   config/crd/bases/mysql.otus.homework_mysqls.yaml
   .

---

Разработка Ansible-ролей

1. Переходим в директорию роли:

2. Редактируем файл

   tasks/main.yml
   , чтобы описать логику создания и удаления ресурсов.

   Создание файла

   tasks/main.yml
   :

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

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

модуль с

state: absent

. Однако в данном случае, поскольку мы используем

state: present

, нам нужно убедиться, что удаление ресурсов происходит автоматически.

Добавляем файл

:

Создание файла

(Чтобы упростить доступ к данным из metadata и spec, явно определяем переменные

meta

и

spec

в файле watches.yaml):

Обновляем права доступа (RBAC)

1. Обновите файл
   config/rbac/role.yaml
   с минимально необходимыми правами:

---

Построение и развертывание оператора

1. Собираем контейнерный образ оператора:

   Обновляем файл

   Makefile
   , указав репозиторий:

Строим образ:

2. Разверните оператор в кластер (сервис
   k8s
   от
   YC
   ):

Образ в моей репе Docker Hub

skyfly534/mysql-operator:01.10.6

---

Создание экземпляра MySQL

1. Создан файл

   config/samples/otus.homework_v1_mysql.yaml
   :

2. Применяем манифест:

---

Проверяем

Можно настроить оператор для работы в кластерном режиме, изменив настройки в

.

---

HW6 Шаблонизация манифестов приложения, использование Helm. Установка community Helm charts.

В процессе выполнения ДЗ выполнены следующие мероприятия:

1. Создана структура-заготовка для нового

Helm chart

, используется команда

helm create

.

Эта команда автоматически создаёт базовую структуру файлов и папок, необходимых для Helm chart.

Helm создаст папку с именем

(или другим именем, указанным вами) и заполнит её следующей структурой:

homework-app-chart/
  Chart.yaml          # Основной файл с метаданными чарта (название, версия и т.д.)
  values.yaml         # Файл с дефолтными значениями параметров для шаблонов
  charts/             # Папка для зависимостей чарта (других Helm charts)
  templates/          # Папка для всех Kubernetes манифестов в виде шаблонов (deployment.yaml, service.yaml и т.д.)
  .helmignore         # Файл, указывающий, какие файлы игнорировать при создании архива чарта

Описание файлов:

• Chart.yaml: Содержит метаданные чарта, такие как имя, версия, описание и т.д.
• values.yaml: Содержит значения по умолчанию, которые можно переопределить при установке чарта.
• templates/: Содержит файлы шаблонов Kubernetes-ресурсов (например, Deployment, Service, ConfigMap и другие).
• charts/: Эта директория используется для указания зависимостей, то есть других чартов, от которых зависит текущий чарт.
• .helmignore: Содержит список файлов и директорий, которые должны быть исключены из пакета чарта при его сборке.

Добавлены недостающие файлы

---

2. Параметризованны манифесты из предыдущих ДЗ. Создан файл

values.yaml

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

Чарт включает параметризацию ключевых значений, возможность включения/отключения проб, включает сообщение после установки, а также зависимость от

Redis

из community-чартов.

Chart.yaml

---

values.yaml

---

3. Произведено дальнейшее описание чарта удовлетворяющее требованиям ДЗ.

templates/_helpers.tpl

Это шаблонный файл Helm, который используется для

объектов Kubernetes (таких как Deployment, Service и т.д.) и других важных идентификаторов при установке чарта. Он позволяет гибко настраивать названия приложений и их версий, чтобы избежать конфликтов с уже существующими ресурсами, обеспечивая уникальность, предсказуемость и консистентность.

---

templates/NOTES.txt

Назначение файла

templates/NOTES.txt

в Helm

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

Описание файл

NOTES.txt

:

1. Вывод полезной информации после деплоя: После успешного развертывания приложения в Kubernetes, Helm выводит содержимое файла

   NOTES.txt
   в консоль. Это может быть инструкция о том, как получить доступ к приложению, проверка его состояния или дальнейшие шаги для его настройки.

2. Гибкость для вывода динамической информации: Так как Helm поддерживает шаблоны, можно выводить динамическую информацию, зависящую от значений в

   values.yaml
   . Например, URL для доступа к приложению через Ingress, который зависит от включённого или отключённого Ingress и настроенных хостов.

3. Улучшение пользовательского опыта: Этот файл позволяет улучшить взаимодействие с пользователем, предоставив информацию, которую пользователь обычно ищет после развертывания (например, URL для доступа, порты, статус и т.д.).

---

Основные функции:

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

Если у вас есть дополнительные вопросы или необходимо более детальное объяснение какого-либо аспекта, дайте знать!

1. Приложение успешно развернуто!

Вы можете получить к нему доступ по следующему URL:

{{- if and .Values.ingress.enabled .Values.ingress.hosts }}
{{ range .Values.ingress.hosts }}
  http{{ if $.Values.ingress.tls }}s{{ end }}://{{ .host }}{{ (index .paths 0).path }}
{{- end }}
{{- else }}
  ПРИМЕЧАНИЕ: Ingress отключен или не настроены хосты.
{{- end }}

---

Пояснение

• Параметризация: Все основные параметры, такие как имена объектов, имена контейнеров, образы, хосты, порты, количество реплик, сообщение для index.html и nodeSelector заданы как переменные в шаблонах. Вы можете настроить их через

  values.yaml
  или переопределить их, используя параметры
  --set
  при установке релиза.

• Репозиторий и тег образа: Репозиторий и тег образа заданы отдельными параметрами (

  image.repository
  и
  image.tag
  в
  values.yaml
  ).

• Включение/Отключение проб: Можно включить или отключить readiness и liveness пробы, используя флаги

  readinessProbe.enabled
  и
  livenessProbe.enabled
  в
  values.yaml
  .

• Сообщение после установки: После установки релиза выводится сообщение, отображающее адрес, по которому можно обратиться к сервису. Это обрабатывается шаблоном

  NOTES.txt
  .

• Зависимость: Чарт включает зависимость от Redis, которая указана в

  Chart.yaml
  и может быть включена или отключена через
  values.yaml
  .

---

Обновление зависимостей

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

Проверка

Устанавливаем чарт с именем релиза

:

Переопределяем параметры, используя

, переопределим колличество реплик:

---

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

---

4. Установлены 2 релиза

kafka

из

bitnami helm-чарта

c следующими параметрами при помощи

helmfile

:

1.1 Установлен в namespace

1.2 Должно быть развернуто

брокеров

1.3 Должна быть установлена kafka версии

1.4 Для клиентских и межброкерных взаимодействий должен использоваться протокол

---

2.1 Установлен в namespace

2.2 Должно быть развернут

брокер

2.3 Должна быть установлена

доступная версия kafka

2.4 Для клиентских и межброкерных взаимодействий должен использоваться протокол

,

авторизация

для подключений к кластеру

отключена

Для развертывания и возможности дальнейшее кастомизирование или включение конфигураций для конкретной среды, создан

с сыkками на отдельные файлы переменных

values-prod.yaml

и

values-dev.yaml

.

За основу файлов

и

values-dev.yaml

взяты кастомные values файлы соответствующих версий Helm чартов и кастомизированны.

Для окружения prod:

1.1 Должно быть развернуто

брокеров

1.2 Должна быть установлена kafka версии

1.3 Для клиентских и межброкерных взаимодействий должен использоваться протокол

Для окружения dev:

2.1 Должно быть развернут

брокер

2.3 Должна быть установлена

доступная версия kafka

2.4 Для клиентских и межброкерных взаимодействий должен использоваться протокол

,

авторизация

для подключений к кластеру

отключена

---

Запускаем:

---

Проверяем

HW5 Настройка сервисных аккаунтов и ограничение прав для них.

В процессе выполнения ДЗ выполнены следующие мероприятия:

1. Создан

ServiceAccount

с именем

monitoring

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

homework

и предоставлен доступ к эндпоинту

/metrics

кластера.

a. Создан ServiceAccount:

b. Создан ClusterRole для доступа к

:

c. Привязан ClusterRole к ServiceAccount

:

---

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

---

2. Измен манифест Deployment, чтобы поды запускались под

ServiceAccount

monitoring

.

Применяем конфигурацию:

Проверяем метаданные ресурса

---

3. Создан

ServiceAccount

с именем

cd

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

homework

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

admin

в рамках этого пространства имен.

a. Создан ServiceAccount:

b. Привязан ClusterRole

к ServiceAccount

cd

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

homework

:

---

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

Для проверки используем команду

, чтобы получить подробную информацию о конкретной привязке ролей для

RoleBinding

:

---

4. Сгенерирован kubeconfig для ServiceAccount cd. Сгенерирован токен со сроком действия 1 день и сохранен в файл token.

a. Получена информацию о кластере:

b. Сгенерирован токен для ServiceAccount

со сроком действия 1 день и сохранён его в файл

token

:

c. Создан файл kubeconfig:

Устанавливаем переменную окружения

, чтобы команды kubectl автоматически использовали

kubeconfig файл

---

Проверяем:

---

5. Модифицирован Deployment так, чтобы при запуске пода происходило обращение к эндпоинту

/metrics

кластера, результат сохранялся в файл

metrics.html

, и этот файл можно было получить по адресу

/metrics.html

.

Модификация Deployment для обращения к

и предоставления

metrics.html

Обновляем раздел

в вашем Deployment:

• Устанавливаем
  curl
  в контейнере (при необходимости).
• Обращаемся к эндпоинту
  /metrics
  , используя токен и сертификат ServiceAccount.
• Сохраняем ответ в
  metrics.html
  и скопируем его в HTML-директорию
  NGINX
  .

Обновленный манифест Deployment:

---

Пояснение

• Использование ServiceAccount:
  • Поле
    serviceAccountName: monitoring
    гарантирует, что поды запускаются под
    ServiceAccount
    monitoring
    .
• Доступ к эндпоинту
  /metrics
  :
  • Установка
    curl
    с помощью
    apk add --no-cache curl
    .
  • Использование
    curl
    с токеном и сертификатом ServiceAccount для безопасного доступа к эндпоинту
    /metrics
    :

  • Сохранение ответа в
    /usr/share/nginx/html/metrics.html
    , чтобы он был доступен по адресу
    http://homework.otus/metrics
    .

Добавляем

Ingress

чтобы обслужить путь

/metrics

, переписывая его на /metrics.html

---

Проверяем:

HW4 Volumes, StorageClass, PV, PVC.

В процессе выполнения ДЗ выполнены следующие мероприятия:

1. Создан манифест
   pvc.yaml
   , описывающий
   PersistentVolumeClaim
   , запрашивающий хранилище с
   storageClass
   по-умолчанию.

Этот

(PVC) предназначен для запроса динамического или статического хранилища в кластере Kubernetes. Вот его описание:

Пояснение:

• spec:
  • storageClassName:
    my-storage-class
    — Указывает на
    StorageClass
    , который будет использоваться для предоставления запрашиваемого хранилища. В этом случае PVC пытается использовать хранилище, созданное с помощью
    StorageClass
    с именем
    my-storage-class
    .
  • accessModes:
    • ReadWriteOnce
      — Указывает, что PVC будет доступен для чтения и записи только одним узлом одновременно.
  • resources:
    • requests:
      • storage:
        1Gi
        — Запрос на объем хранилища, который требуется. В данном случае запрашивается 1 гигабайт постоянного хранилища.

Дальнейшие действия:

• PVC будет ждать, пока
  PersistentVolume
  (PV), соответствующий этим запросам, не будет доступен. Если используется динамическое выделение,
  StorageClass
  сработает и создаст PV автоматически.
• После создания и связывания PV с этим PVC, он будет доступен для подов в пространстве имен
  homework
  для использования в качестве постоянного хранилища.

2. Создан манифест
   cm.yaml
   для объекта типа
   configMap
   , описывающий произвольный набор пар ключ-значение.

Пояснение:

Этот

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

В нашем случае

используется как

файл

и монтируется в под как

volume

,а значение будет доступно как файл.

3. В манифесте
   deployment.yaml
   изменена спецификация
   volume
   с типа
   emptyDir
   , который монтируется в init и основной контейнер, на
   pvc
   , созданный в предыдущем пункте. Добавлено монтирование ранее созданного
   configMap
   как
   volume
   к основному контейнеру пода в директорию
   /homework/conf
   .

Пояснение:

1. Замена
   emptyDir
   на
   PersistentVolumeClaim
   : Теперь volume
   homework-volume
   использует PVC с именем
   my-pvc
   .
2. Добавлен ConfigMap: Создан новый volume
   config-volume
   , который монтируется в папку
   /homework/conf
   .

Это позволит поду использовать постоянное хранилище и иметь доступ к данным из ConfigMap.

В данном случае содержимое

проброшенно в каталог

/usr/share/nginx/html/index.html

и отобразится в браузере, при обращении по адресу

http://homework.otus/homepage

. Файл хранящийся в

persistentVolumeClaim

и подмонтированный в каталог пода

/homework/pvc

будет доступен и после пересоздания Deployment, и после выкатки новой версии.

4. Создан манифест
   storageClass.yaml
   описывающий объект типа
   storageClass
   с provisioner https://k8s.io/minikube-hostpath и
   reclaimPolicy Retain
   .

Этот

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

StorageClass

:

Пояснение:

• provisioner:
  k8s.io/minikube-hostpath
  — Имя провиженера, который отвечает за создание томов хранения. В данном случае используется провиженер
  minikube-hostpath
  , который поддерживается Minikube для создания томов с использованием хранилища на узлах Minikube.
• reclaimPolicy:
  Retain
  — Политика возврата, определяющая, что происходит с томом после удаления
  PersistentVolumeClaim
  (PVC):
  • Retain
    — После удаления PVC том не удаляется автоматически, а сохраняется, чтобы данные могли быть восстановлены или использованы снова.
  • Другие варианты —
    Delete
    (том удаляется) и
    Recycle
    (том очищается и возвращается в пул доступных томов).
• volumeBindingMode:
  Immediate
  — Указывает, когда
  PersistentVolume
  (PV) должен быть привязан к
  PersistentVolumeClaim
  (PVC):
  • Immediate
    — Привязка PV к PVC происходит сразу после создания PVC.
  • Альтернативный вариант —
    WaitForFirstConsumer
    , где привязка PV откладывается до тех пор, пока под, использующий PVC, не будет запланирован на узел.

Проверка

Применяем новые манифесты и обновляем Deployment

смотрим

Удаляем развертывание

Коментим секцию с

в манифесте

deployment

и создаем заново

Проверяем наличие файла в примонтированном

HW3 Сетевое взаимодействие Pod, сервисы.

В процессе выполнения ДЗ выполнены следующие мероприятия:

1. В манифестах из предыдущего ДЗ в
   service.yaml
   поменян тип
   type: LoadBalancer
   на
   type: ClusterIP
   .

2. В кластер установлен
   ingress-контроллер nginx
   .

Так как для выполнения ДЗ используется

достаточно проверить состояние

addon ingress

и при необходимости задействовать его

3. Написан манифест
   ingress.yaml
   удовлетворяющий требованиям ДЗ.

Пояснение:

1. Аннотация
   nginx.ingress.kubernetes.io/rewrite-target: /index.html
   указывает на то, что все запросы, удовлетворяющие правилам, должны быть переписаны на путь
   /index.html
   .
2. Путь
   /homepage
   в Ingress-ресурсе указывает, что все запросы, приходящие по этому URL, должны быть направлены на тот же сервис (
   my-service
   ), но при этом фактический путь изменится на
   /index.html
   .

Применяем:

проверяем состояние:

добавляем строку

с этим IP в файл

/etc/hosts

на хостовой машине:

проверяем:

НЕ забываем включить

:

HW2 Kubernetes controllers. ReplicaSet, Deployment, DaemonSet.

В процессе выполнения ДЗ выполнены следующие мероприятия:

1. Манифест для
   namespace
   с именем
   homework
   взят из ДЗ №1 ./kubernetes-intro/namespace.yaml.

1.

namespace.yaml

2. Создан манифеста ./kubernetes-controllers/pod.yaml, описывающий поднимаемый
   deployment
   и удовлетворяющий требованиям ДЗ.

2.

deployment.yaml

Пояснение:

Deployment:

• replicas: 3: Создаются
  3
  экземпляра подов.
• readinessProbe: Проба проверяет наличие файла
  /homework/index.html
  в контейнере.
• strategy: Стратегия
  RollingUpdate
  настроена так, что во время обновления не более одного пода может быть недоступен (
  maxUnavailable: 1
  ).

Задание с *

• nodeSelector: Указывает, что поды могут запускаться только на
  нодах
  с меткой
  homework=true
  .

Проверка

Производим развертывание и видим, что поды в состоянии

$ kubectl get pods -n homework
NAME                                   READY   STATUS    RESTARTS   AGE
homework-deployment-64cbbd86f8-2wv6v   0/1     Pending   0          41s
homework-deployment-64cbbd86f8-b4bfz   0/1     Pending   0          41s
homework-deployment-64cbbd86f8-tfdsp   0/1     Pending   0          41s

Это означает, что Kubernetes не может назначить их на ноды кластера без метки

.

Исправляем

$ kubectl label node minikube homework=true
node/minikube labeled

Проверяем

$ kubectl get pods -n homework
NAME                                   READY   STATUS    RESTARTS   AGE
homework-deployment-64cbbd86f8-2wv6v   1/1     Running   0          2m57s
homework-deployment-64cbbd86f8-b4bfz   0/1     Running   0          2m57s
homework-deployment-64cbbd86f8-tfdsp   0/1     Running   0          2m57s

$ kubectl get pods -n homework
NAME                                   READY   STATUS    RESTARTS   AGE
homework-deployment-64cbbd86f8-2wv6v   1/1     Running   0          2m58s
homework-deployment-64cbbd86f8-b4bfz   0/1     Running   0          2m58s
homework-deployment-64cbbd86f8-tfdsp   0/1     Running   0          2m58s

$ kubectl get pods -n homework
NAME                                   READY   STATUS    RESTARTS   AGE
homework-deployment-64cbbd86f8-2wv6v   1/1     Running   0          3m23s
homework-deployment-64cbbd86f8-b4bfz   1/1     Running   0          3m23s
homework-deployment-64cbbd86f8-tfdsp   1/1     Running   0          3m23s

Вывод тот же, что и в первом ДЗ

Меняем выводимый текст

в

deployment.yaml

выполняем

$ kubectl apply -f ./
deployment.apps/homework-deployment configured
namespace/homework unchanged
service/homework-service unchanged

и проверяем как выполняется

$ kubectl get pods -n homework
NAME                                   READY   STATUS     RESTARTS   AGE
homework-deployment-6449cb7fc6-p5r6d   0/1     Init:0/1   0          2s
homework-deployment-6449cb7fc6-v9b6q   0/1     Init:0/1   0          2s
homework-deployment-7c6dd4d867-bzp8v   1/1     Running    0          3m40s
homework-deployment-7c6dd4d867-nfw28   1/1     Running    0          3m40s

$ kubectl get pods -n homework
NAME                                   READY   STATUS     RESTARTS   AGE
homework-deployment-6449cb7fc6-p5r6d   0/1     Running    0          8s
homework-deployment-6449cb7fc6-v9b6q   0/1     Init:0/1   0          8s
homework-deployment-7c6dd4d867-bzp8v   1/1     Running    0          3m46s
homework-deployment-7c6dd4d867-nfw28   1/1     Running    0          3m46s

$ kubectl get pods -n homework
NAME                                   READY   STATUS     RESTARTS   AGE
homework-deployment-6449cb7fc6-kf762   0/1     Init:0/1   0          4s
homework-deployment-6449cb7fc6-p5r6d   1/1     Running    0          14s
homework-deployment-6449cb7fc6-v9b6q   0/1     Running    0          14s
homework-deployment-7c6dd4d867-bzp8v   1/1     Running    0          3m52s

$ kubectl get pods -n homework
NAME                                   READY   STATUS    RESTARTS   AGE
homework-deployment-6449cb7fc6-kf762   0/1     Running   0          7s
homework-deployment-6449cb7fc6-p5r6d   1/1     Running   0          17s
homework-deployment-6449cb7fc6-v9b6q   0/1     Running   0          17s
homework-deployment-7c6dd4d867-bzp8v   1/1     Running   0          3m55s

$ kubectl get pods -n homework
NAME                                   READY   STATUS        RESTARTS   AGE
homework-deployment-6449cb7fc6-kf762   0/1     Running       0          11s
homework-deployment-6449cb7fc6-p5r6d   1/1     Running       0          21s
homework-deployment-6449cb7fc6-v9b6q   1/1     Running       0          21s
homework-deployment-7c6dd4d867-bzp8v   1/1     Terminating   0          3m59s

$ kubectl get pods -n homework
NAME                                   READY   STATUS    RESTARTS   AGE
homework-deployment-6449cb7fc6-kf762   1/1     Running   0          24s
homework-deployment-6449cb7fc6-p5r6d   1/1     Running   0          34s
homework-deployment-6449cb7fc6-v9b6q   1/1     Running   0          34s

Проверяем работу

удалением у одного из подов файла

/homework/index.html

kubectl exec -it homework-deployment-7c6dd4d867-242mx -n homework -- rm /homework/index.html

видим

$ kubectl get pods -n homework
NAME                                   READY   STATUS    RESTARTS   AGE
homework-deployment-7c6dd4d867-242mx   0/1     Running   0          19h
homework-deployment-7c6dd4d867-pcfw6   1/1     Running   0          19h
homework-deployment-7c6dd4d867-zw8l4   1/1     Running   0          19h

1. Readiness Probe не будет выполнена

У каждого пода настроена

, которая проверяет наличие файла

/homework/index.html

. Если этот файл исчезнет, команда

cat /homework/index.html

, указанная в

readinessProbe

, не сможет найти файл и вернет ошибку.

Это приведет к тому, что

будет считаться неуспешной для этого пода.

2. Потеря статуса "Ready"

Когда

не выполняется, Kubernetes автоматически снимает статус

Ready

с пода, и под перестает считаться готовым к приему трафика. В выводе команды

kubectl get pods

статус пода будет отображаться как

0/1 Ready

.

3. Трафик перестанет направляться на под

Kubernetes использует

для управления тем, какие поды могут принимать трафик. Как только под теряет статус "Ready", сервисы и балансировщики нагрузки Kubernetes (например,

Service

или

Ingress

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

4. Восстановление статуса "Ready"

Если файл

будет восстановлен,

readinessProbe

снова пройдет успешно, и под вновь станет "Ready", после чего на него возобновится направление трафика.

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

HW1 Знакомство с решениями для запуска локального Kubernetes кластера, создание первого pod.

В процессе выполнения ДЗ выполнены следующие мероприятия:

1. Подготовлено локальное окружение для работы с Kubernetes.

• kubectl - главная утилита для работы с Kubernets API (все, что делает kubectl, можно сделать с помощью HTTP-запросов к API k8s)

• minikube - утилита для разворачивания локальной инсталляции Kubernetes

• ~/.kube - каталог, который содержит служебную информацию для kubectl (конфиги, кеши, схемы API);

2. Поднят кластер в
   minikube
   .

Стандартный драйвер для развертывания кластера в minikube docker. В данной конфигурации кластера у меня возникли проблемы с доступом к образам моего аккаунта в

, поэтому кластер был поднят с драйвером

Virtualbox

(с ним проблем не было).

В процессе поднятия кластера автоматически настраивается

.

3. Cоздан манифест
   ./kubernetes-intro/namespace.yaml
   для namespace с именем
   homework
   .

4. Создан манифеста
   ./kubernetes-intro/pod.yaml
   , описывающий поднимаемый Pod и удовлетворяющий требованиям ДЗ.

Пояснение:

1. Namespace: Pod создается в namespace

   homework
   .

2. Init-контейнер:

   • Контейнер
     init-container
     использует образ
     busybox
     и генерирует файл
     index.html
     с текстом "Hello, OTUS! Homework 1", сохраняя его в директорию
     /init
     .

3. Контейнер

   web-server
   :
   • Использует образ
     nginx:alpine
     и поднимает веб-сервер на порту
     8000
     .
   • Файл
     index.html
     копируется в стандартную директорию веб-сервера Nginx
     /usr/share/nginx/html/
     .
   • Жизненный цикл контейнера настроен так, чтобы удалить файл
     index.html
     из директории
     /homework
     при завершении Pod (фаза
     preStop
     ).

4. Общий том:

   • Том
     homework-volume
     является общим для обоих контейнеров. Он монтируется как
     /homework
     в основном контейнере и как
     /init
     в init-контейнере.
   • Том создается как
     emptyDir
     , что означает, что он является пустым и временным.

5. Для отработки сетевого взаимодействия поднятого Pod и для получения доступа к нему через браузер на хостовой системе, написан манифест
   ./kubernetes-intro/service.yaml
   для
   Service
   с типом
   LoadBalancer
   .

Пояснение:

1. Selector:

   • Service
     определяет Pod, который ему необходимо обслуживать при помощи метки
     app: homework-pod
     .

2. Ports:

   • port: 8000
     : Порт, на котором
     Service
     будет доступен для внешних запросов.
   • targetPort: 80
     : Порт внутри Pod, на котором запущен веб-сервер.

Применяем манифест для Service:

После этого получаем IP-адрес, выделенный для Service:

В

тип

LoadBalancer

работает путем перенаправления на

NodePort

, и minikube service автоматически открывает

URL

в

браузере

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

Вывод браузера.