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

Введение

В этом руководстве показано, как выполнять команды в подах Kubernetes при запуске. Вы узнаете, как настраивать команды запуска с использованием полей command и args, выполнять несколько команд и обрабатывать сбои при запуске. Мы будем использовать Minikube для создания локальной среды Kubernetes, где вы сможете практиковать эти концепции на практике.

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

Настройка среды Kubernetes

На этом этапе мы подготовим нашу среду, запустив Minikube и изучив основные концепции Kubernetes, необходимые для этого практического занятия (LabEx).

Что такое Kubernetes?

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

Запуск Minikube

Minikube - это инструмент, который позволяет запускать Kubernetes локально. Давайте запустим его:

minikube start --driver=docker

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

Вы должны увидеть вывод, похожий на следующий:

😄  minikube v1.30.1 on Ubuntu 22.04
✨  Using the docker driver based on user configuration
📌  Using Docker driver with root privileges
👍  Starting control plane node minikube in cluster minikube
🚜  Pulling base image ...
🔥  Creating docker container (CPUs=2, Memory=2200MB) ...
🐳  Preparing Kubernetes v1.27.4 on Docker 24.0.4 ...
    ▪ Generating certificates and keys ...
    ▪ Booting up control plane ...
    ▪ Configuring RBAC rules ...
🔎  Verifying Kubernetes components...
🌟  Enabled addons: default-storageclass, storage-provisioner
💡  kubectl not found. If you need it, try: 'minikube kubectl -- get pods -A'
🏄  Done! kubectl is now configured to use "minikube" cluster and "default" namespace by default

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

Давайте убедимся, что все работает правильно, проверив статус нашего кластера Minikube:

minikube status

Вы должны увидеть вывод, указывающий, что Minikube запущен:

minikube
type: Control Plane
host: Running
kubelet: Running
apiserver: Running
kubeconfig: Configured

Теперь проверим, что kubectl (командная утилита Kubernetes) правильно настроена:

kubectl get nodes

Вы должны увидеть один узел (ваш экземпляр Minikube) с пометкой Ready:

NAME       STATUS   ROLES           AGE     VERSION
minikube   Ready    control-plane   2m15s   v1.27.4

Понимание концепции подов Kubernetes

Под (Pod) - это базовая единица выполнения приложения Kubernetes. Каждый под представляет собой запущенный процесс в кластере и объединяет один или несколько контейнеров. Поды по своей природе временные, то есть их можно создавать, уничтожать и воссоздавать по мере необходимости.

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

Перейдем в каталог, где находятся эти файлы:

cd ~/project/kubernetes-examples
ls -la

Вы должны увидеть следующие файлы:

total 20
drwxr-xr-x 2 labex labex 4096 Sep 21 10:00 .
drwxr-xr-x 3 labex labex 4096 Sep 21 10:00 ..
-rw-r--r-- 1 labex labex  193 Sep 21 10:00 basic-pod.yaml
-rw-r--r-- 1 labex labex  254 Sep 21 10:00 liveness-probe-pod.yaml
-rw-r--r-- 1 labex labex  312 Sep 21 10:00 multi-command-pod.yaml
-rw-r--r-- 1 labex labex  263 Sep 21 10:00 startup-command-pod.yaml

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

Создание первого пода с базовыми командами запуска

На этом этапе мы создадим наш первый под (Pod) Kubernetes и узнаем, как он выполняет команды при запуске. Мы рассмотрим поле command, которое определяет, что должен запустить контейнер при старте.

Исследование базовой конфигурации пода

Сначала изучим конфигурацию базового пода. Откройте файл basic-pod.yaml с помощью редактора nano:

nano basic-pod.yaml

Вы увидите файл YAML со следующим содержимым:

apiVersion: v1
kind: Pod
metadata:
  name: basic-pod
spec:
  containers:
    - name: ubuntu
      image: ubuntu:20.04
      command: ["/bin/bash", "-c", "echo 'Pod is running' && sleep 3600"]

В этой конфигурации определены:

Под с именем basic-pod
Один контейнер с именем ubuntu, использующий образ ubuntu:20.04
Команда запуска, которая выводит сообщение и затем засыпает на 3600 секунд (1 час)

Поле command указывает исполняемый файл, который будет запущен при старте контейнера. В данном случае мы запускаем оболочку /bin/bash с флагом -c, который позволяет передать строку команд для выполнения.

Нажмите Ctrl+X, чтобы выйти из редактора nano.

Создание пода

Создадим этот под в нашем кластере Kubernetes:

kubectl apply -f basic-pod.yaml

Вы должны увидеть вывод, похожий на следующий:

pod/basic-pod created

Проверка статуса пода

Теперь проверим, работает ли наш под корректно:

kubectl get pods

Вы должны увидеть вывод, похожий на следующий:

NAME        READY   STATUS    RESTARTS   AGE
basic-pod   1/1     Running   0          30s

Это означает, что наш под успешно запущен. 1/1 в столбце READY означает, что один ожидаемый контейнер запущен.

Просмотр журналов пода

Чтобы увидеть вывод нашей команды запуска, мы можем проверить журналы пода:

kubectl logs basic-pod

Вы должны увидеть:

Pod is running

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

Исследование работающего контейнера

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

kubectl exec -it basic-pod -- /bin/bash

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

ps aux

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

USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root         1  0.0  0.0   4112  3372 ?        Ss   10:05   0:00 /bin/bash -c echo 'Pod is running' && sleep 3600
root         7  0.0  0.0   4112  3536 pts/0    Ss   10:06   0:00 /bin/bash
root        14  0.0  0.0   5900  2928 pts/0    R+   10:06   0:00 ps aux
root        15  0.0  0.0   2512   580 ?        S    10:06   0:00 sleep 3600

Процесс с PID 1 - это наша команда запуска, а команда sleep 3600 запущена как отдельный процесс.

Выйдите из оболочки контейнера, введя:

exit

Понимание жизненного цикла пода

При создании пода он проходит через несколько фаз:

Pending (В ожидании): Под был принят Kubernetes, но еще не запущен.
Running (Запущен): Под запущен со всеми контейнерами.
Succeeded (Успешно завершен): Все контейнеры в поде успешно завершили работу.
Failed (Завершен с ошибкой): Все контейнеры завершили работу, и по крайней мере один контейнер завершился с ошибкой.
Unknown (Неизвестно): Состояние пода не может быть определено.

Наш под находится в состоянии Running, так как наш основной процесс (sleep 3600) все еще работает. Когда этот процесс завершится или будет остановлен, под перейдет в состояние Succeeded или Failed, в зависимости от кода выхода.

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

Использование полей command и args для настройки запуска

На этом этапе мы узнаем, как использовать поля command и args совместно для настройки более сложного поведения при запуске подов (Pods) в Kubernetes.

Понимание полей command и args

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

command: Определяет исполняемый файл, который нужно запустить (аналогично ENTRYPOINT в Docker).
args: Определяет аргументы, которые нужно передать команде (аналогично CMD в Docker).

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

Исследование пода с командой запуска

Рассмотрим файл startup-command-pod.yaml:

nano startup-command-pod.yaml

Вы увидите следующую конфигурацию:

apiVersion: v1
kind: Pod
metadata:
  name: startup-command-pod
spec:
  containers:
    - name: ubuntu
      image: ubuntu:20.04
      command: ["/bin/bash"]
      args:
        ["-c", "echo 'Custom startup message' > /tmp/startup.txt && sleep 3600"]

В этой конфигурации:

Поле command указывает, что мы хотим запустить /bin/bash.
Поле args предоставляет аргументы, которые нужно передать bash: -c и строку с нашими командами.

Разделение команды и аргументов делает конфигурацию более читаемой и поддерживаемой.

Нажмите Ctrl+X, чтобы выйти из редактора nano.

Создание пода с командой запуска

Создадим этот под:

kubectl apply -f startup-command-pod.yaml

Вы должны увидеть:

pod/startup-command-pod created

Проверка статуса пода

Убедимся, что под запущен:

kubectl get pods startup-command-pod

Вы должны увидеть:

NAME                  READY   STATUS    RESTARTS   AGE
startup-command-pod   1/1     Running   0          30s

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

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

kubectl exec startup-command-pod -- cat /tmp/startup.txt

Вы должны увидеть:

Custom startup message

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

Понимание различий между command и args

Важно понять взаимосвязь между полями command и args:

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

Посмотрим, что произойдет, если мы изменим конфигурацию нашего пода. Создайте новый файл с именем modified-command-pod.yaml:

nano modified-command-pod.yaml

Добавьте следующее содержимое:

apiVersion: v1
kind: Pod
metadata:
  name: modified-command-pod
spec:
  containers:
    - name: ubuntu
      image: ubuntu:20.04
      command: ["/bin/echo"]
      args: ["This message is printed by echo"]

Сохраните файл и выйдите, нажав Ctrl+X, затем Y и Enter.

Теперь создадим этот под:

kubectl apply -f modified-command-pod.yaml

Вы должны увидеть:

pod/modified-command-pod created

Проверьте логи, чтобы увидеть, что произошло:

kubectl logs modified-command-pod

Вы должны увидеть:

This message is printed by echo

Обратите внимание, как под выполнил команду /bin/echo с нашим указанным аргументом, а затем завершил работу, так как echo завершает выполнение после вывода своего результата.

Проверьте статус пода:

kubectl get pods modified-command-pod

Вы должны увидеть что-то вроде этого:

NAME                   READY   STATUS      RESTARTS   AGE
modified-command-pod   0/1     Completed   0          45s

Статус Completed означает, что под успешно завершил работу и вышел.

Теперь вы знаете, как использовать поля command и args совместно для настройки поведения при запуске подов в Kubernetes.

Выполнение нескольких команд и обработка ошибок запуска

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

Выполнение нескольких команд

Часто при запуске контейнера нужно выполнить несколько команд. В Kubernetes есть несколько способов сделать это:

Сцеплять команды с использованием операторов оболочки (&&, ; и т.д.).
Использовать файл скрипта.
Использовать init-контейнер.

Рассмотрим первый метод, изучив файл multi-command-pod.yaml:

nano multi-command-pod.yaml

Вы увидите:

apiVersion: v1
kind: Pod
metadata:
  name: multi-command-pod
spec:
  containers:
    - name: ubuntu
      image: ubuntu:20.04
      command: ["/bin/bash", "-c"]
      args:
        [
          "echo 'First command' > /tmp/first.txt && echo 'Second command' > /tmp/second.txt && sleep 3600"
        ]

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

Нажмите Ctrl+X, чтобы выйти из редактора.

Создадим этот под:

kubectl apply -f multi-command-pod.yaml

Вы должны увидеть:

pod/multi-command-pod created

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

kubectl exec multi-command-pod -- cat /tmp/first.txt

Вы должны увидеть:

First command

А для второго файла:

kubectl exec multi-command-pod -- cat /tmp/second.txt

Вы должны увидеть:

Second command

Обработка ошибок запуска с помощью проверок здоровья

Kubernetes предоставляет механизмы для обнаружения и обработки ошибок запуска:

Liveness Probes (Проверки жизнеспособности): Проверяют, запущен ли контейнер; если нет, Kubernetes перезапустит его.
Readiness Probes (Проверки готовности): Проверяют, готов ли контейнер принимать трафик.
Startup Probes (Проверки запуска): Проверяют, запустилась ли приложение; полезно для контейнеров с долгим запуском.

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

nano liveness-probe-pod.yaml

Вы увидите:

apiVersion: v1
kind: Pod
metadata:
  name: liveness-probe-pod
spec:
  containers:
    - name: ubuntu
      image: ubuntu:20.04
      command: ["/bin/bash", "-c"]
      args: ["touch /tmp/healthy && sleep 3600"]
      livenessProbe:
        exec:
          command: ["cat", "/tmp/healthy"]
        initialDelaySeconds: 5
        periodSeconds: 5

В этой конфигурации:

Контейнер создает файл /tmp/healthy при запуске.
Проверка жизнеспособности проверяет наличие этого файла каждые 5 секунд.
Если файл отсутствует, Kubernetes считает контейнер неработоспособным и перезапускает его.

Нажмите Ctrl+X, чтобы выйти из редактора.

Создадим этот под:

kubectl apply -f liveness-probe-pod.yaml

Вы должны увидеть:

pod/liveness-probe-pod created

Проверьте, что под запущен:

kubectl get pods liveness-probe-pod

Вы должны увидеть:

NAME                 READY   STATUS    RESTARTS   AGE
liveness-probe-pod   1/1     Running   0          30s

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

kubectl exec liveness-probe-pod -- rm /tmp/healthy

Подождите около 10 секунд, затем снова проверьте статус пода:

kubectl get pods liveness-probe-pod

Вы должны увидеть, что контейнер был перезапущен:

NAME                 READY   STATUS    RESTARTS   AGE
liveness-probe-pod   1/1     Running   1          60s

Число перезапусков (RESTARTS) увеличилось до 1, что означает, что Kubernetes обнаружил неработоспособное состояние и перезапустил контейнер.

Убедимся, что файл проверки здоровья снова существует (он должен был быть пересоздан командой запуска при перезапуске контейнера):

kubectl exec liveness-probe-pod -- ls -la /tmp/healthy

Вы должны увидеть, что файл снова существует:

-rw-r--r-- 1 root root 0 Sep 21 10:30 /tmp/healthy

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

Создание пользовательского скрипта запуска

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

nano script-pod.yaml

Добавьте следующее содержимое:

apiVersion: v1
kind: Pod
metadata:
  name: script-pod
spec:
  containers:
    - name: ubuntu
      image: ubuntu:20.04
      command: ["/bin/bash", "-c"]
      args:
        - |
          cat > /tmp/startup.sh << 'EOF'
          #!/bin/bash
          echo "Script started at $(date)" > /tmp/script-log.txt
          echo "Creating configuration files..." >> /tmp/script-log.txt
          mkdir -p /tmp/config
          echo "app_name=MyApp" > /tmp/config/app.conf
          echo "version=1.0" >> /tmp/config/app.conf
          echo "Script completed successfully" >> /tmp/script-log.txt
          EOF
          chmod +x /tmp/startup.sh
          /tmp/startup.sh
          sleep 3600

В этой конфигурации:

Создается скрипт запуска в контейнере.
Скрипт делается исполняемым.
Скрипт запускается.
Контейнер остается запущенным с помощью команды sleep.

Сохраните и выйдите, нажав Ctrl+X, затем Y и Enter.

Создадим этот под:

kubectl apply -f script-pod.yaml

Вы должны увидеть:

pod/script-pod created

Подождите немного, пока под запустится, затем проверьте его статус:

kubectl get pods script-pod

Вы должны увидеть:

NAME         READY   STATUS    RESTARTS   AGE
script-pod   1/1     Running   0          30s

Теперь проверим вывод нашего скрипта:

kubectl exec script-pod -- cat /tmp/script-log.txt

Вы должны увидеть что-то вроде этого:

Script started at Tue Sep 21 10:35:42 UTC 2023
Creating configuration files...
Script completed successfully

И убедимся, что файл конфигурации был создан:

kubectl exec script-pod -- cat /tmp/config/app.conf

Вы должны увидеть:

app_name=MyApp
version=1.0

Это показывает, как использовать сложные скрипты запуска для инициализации контейнеров в Kubernetes.

Лучшие практики и реальные применения

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

Лучшие практики для команд запуска

При настройке команд запуска для подов Kubernetes учитывайте следующие рекомендации:

Сделайте команды запуска идемпотентными: Команды должны быть безопасными для многократного выполнения без возникновения проблем.
Используйте проверки здоровья: Реализуйте проверки жизнеспособности (liveness) и готовности (readiness), чтобы убедиться, что запуск прошел успешно.
Грамотно обрабатывайте ошибки: Включите обработку ошибок в скриптах запуска.
Разделяйте задачи: Используйте init-контейнеры для инициализационных задач, отдельных от основного приложения.
Ограничьте время запуска: Сделайте инициализацию быстрой, чтобы сократить время развертывания.
Используйте переменные окружения: Сделайте команды запуска настраиваемыми с помощью переменных окружения.
Логируйте процесс запуска: Выводите четкие логи для устранения неполадок.

Использование init-контейнеров для задач запуска

Init-контейнеры запускаются перед основными контейнерами приложения и идеально подходят для задач настройки. Создадим под с init-контейнером:

nano init-container-pod.yaml

Добавьте следующее содержимое:

apiVersion: v1
kind: Pod
metadata:
  name: init-container-pod
spec:
  initContainers:
    - name: init-config
      image: ubuntu:20.04
      command: ["/bin/bash", "-c"]
      args:
        - |
          echo "Initializing configuration..."
          mkdir -p /work-dir/config
          echo "database_url=mysql://user:password@db:3306/mydb" > /work-dir/config/db.conf
          echo "api_key=1234567890" > /work-dir/config/api.conf
          echo "Initialization complete"
      volumeMounts:
        - name: shared-volume
          mountPath: /work-dir
  containers:
    - name: app
      image: ubuntu:20.04
      command: ["/bin/bash", "-c"]
      args:
        - |
          echo "Application starting..."
          echo "Reading configuration:"
          cat /work-dir/config/db.conf
          cat /work-dir/config/api.conf
          echo "Application running..."
          sleep 3600
      volumeMounts:
        - name: shared-volume
          mountPath: /work-dir
  volumes:
    - name: shared-volume
      emptyDir: {}

В этой конфигурации:

Init-контейнер init-config запускается первым и создает файлы конфигурации.
Оба контейнера используют общий том с именем shared-volume.
Основной контейнер приложения читает конфигурацию, созданную init-контейнером.

Сохраните и выйдите, нажав Ctrl+X, затем Y и Enter.

Создадим этот под:

kubectl apply -f init-container-pod.yaml

Вы должны увидеть:

pod/init-container-pod created

Проверьте статус пода:

kubectl get pods init-container-pod

Вы должны увидеть, что под запущен:

NAME                 READY   STATUS    RESTARTS   AGE
init-container-pod   1/1     Running   0          30s

Теперь проверим логи основного контейнера:

kubectl logs init-container-pod -c app

Вы должны увидеть что-то вроде этого:

Application starting...
Reading configuration:
database_url=mysql://user:password@db:3306/mydb
api_key=1234567890
Application running...

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

Реальный пример: Веб-приложение с проверкой доступности базы данных

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

nano webapp-pod.yaml

Добавьте следующее содержимое:

apiVersion: v1
kind: Pod
metadata:
  name: webapp-pod
spec:
  initContainers:
    - name: wait-for-db
      image: busybox:1.28
      command: ["/bin/sh", "-c"]
      args:
        - |
          echo "Checking for database availability..."
          ## In a real scenario, this would check an actual database
          ## For this example, we'll simulate success after a short delay
          sleep 5
          echo "Database is available"
          touch /tmp/db-ready
      volumeMounts:
        - name: shared-volume
          mountPath: /tmp
  containers:
    - name: webapp
      image: nginx:1.19
      ports:
        - containerPort: 80
      command: ["/bin/sh", "-c"]
      args:
        - |
          if [ -f /tmp/db-ready ]; then
            echo "Database connection verified, starting web application..."
            ## Customize nginx configuration
            echo "<h1>Web Application Started Successfully</h1>" > /usr/share/nginx/html/index.html
            echo "<p>Connected to database</p>" >> /usr/share/nginx/html/index.html
            ## Start nginx
            nginx -g 'daemon off;'
          else
            echo "Error: Database not available"
            exit 1
          fi
      volumeMounts:
        - name: shared-volume
          mountPath: /tmp
      readinessProbe:
        httpGet:
          path: /
          port: 80
        initialDelaySeconds: 5
        periodSeconds: 5
  volumes:
    - name: shared-volume
      emptyDir: {}

В этой конфигурации:

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

Сохраните и выйдите, нажав Ctrl+X, затем Y и Enter.

Создадим этот под:

kubectl apply -f webapp-pod.yaml

Вы должны увидеть:

pod/webapp-pod created

Подождите немного, пока под полностью запустится, затем проверьте его статус:

kubectl get pods webapp-pod

Вы должны увидеть:

NAME         READY   STATUS    RESTARTS   AGE
webapp-pod   1/1     Running   0          30s

Значение 1/1 в столбце READY указывает, что проверка готовности прошла успешно.

Применим перенаправление портов, чтобы получить доступ к веб-приложению:

kubectl port-forward webapp-pod 8080:80 &

Эта команда запускается в фоновом режиме (из-за &). Теперь мы можем получить доступ к веб-приложению с помощью curl:

curl http://localhost:8080

Вы должны увидеть:

<h1>Web Application Started Successfully</h1>
<p>Connected to database</p>

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

Остановите процесс перенаправления портов:

pkill -f "kubectl port-forward"

Очистка ресурсов

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

kubectl delete pod basic-pod startup-command-pod modified-command-pod multi-command-pod liveness-probe-pod script-pod init-container-pod webapp-pod

Вы должны увидеть:

pod "basic-pod" deleted
pod "startup-command-pod" deleted
pod "modified-command-pod" deleted
pod "multi-command-pod" deleted
pod "liveness-probe-pod" deleted
pod "script-pod" deleted
pod "init-container-pod" deleted
pod "webapp-pod" deleted

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

Резюме

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

Настройке среды Kubernetes с использованием Minikube.
Создании и управлении подами с определенными командами запуска.
Использовании полей command и args для настройки поведения контейнеров.
Выполнении нескольких команд с использованием операторов оболочки и скриптов.
Обработке ошибок запуска с помощью проверок здоровья.
Реализации лучших практик с использованием init-контейнеров.
Создании реальных приложений, требующих правильной инициализации.

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

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