Навчальні посібники

• 1: Привіт Minikube
• 2: Створення кластера
• 3: Розгортання застосунку
• 4: Вивчення застосунку
• 5: Налаштування
• 6: Stateless-застосунки
• 7: Безпека
• 7.1: Застосування Стандартів безпеки Podʼів на рівні простору імен
• 8: Відкриття доступу до застосунку за межами кластера
• 9: Застосунки зі станом
• 9.1: Приклад: Розгортання WordPress та MySQL з постійними томами
• 10: Масштабування застосунку
• 11: Оновлення застосунку

1 - Привіт Minikube

Цей навчальний посібник показує, як запустити демонстраційний застосунок у Kubernetes за допомогою minikube. Навчальний посібник надає образ контейнера, який за допомогою NGINX повертає у відповідь усі отримані запити.

Цілі

• Розгорнути демонстраційний застосунок у minikube.
• Запустити застосунок.
• Переглянути логи застосунку.

Перш ніж ви розпочнете

Цей навчальний посібник передбачає, що ви вже налаштували minikube. Інструкції щодо встановлення дивіться в Кроці 1 на сторінці minikube start.

Вам також потрібно встановити kubectl. Інструкції щодо встановлення дивіться в розділі Встановлення інструментів.

Створення кластера minikube

minikube start

Перевірка стану кластера minikube

Перевірте стан кластера minikube, щоб переконатися, що всі компоненти працюють.

minikube status

Вивід наведеної вище команди має показувати всі компоненти у стані Running або Configured, як у прикладі виводу нижче:

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

Відкриття інформаційної панелі

Відкрийте інформаційну панель Kubernetes. Це можна зробити двома різними способами:

• Запуск вебоглядача
• Скопіювати та вставити URL

# Запустіть новий термінал та залиште його працювати.
minikube dashboard

<p>Команда <code>dashboard</code> вмикає надбудову інформаційної панелі та відкриває проксі в типовому вебоглядачі. Ви можете створювати в інформаційній панелі ресурси Kubernetes, такі як Deployment і Service.</p>

# Запустіть новий термінал та залиште його працювати.
minikube dashboard --url

Створення Deployment

Pod у Kubernetes — це група з одного або декількох контейнерів, що обʼєднані разом з метою адміністрування і роботи в мережі. У цьому навчальному посібнику Pod має лише один контейнер. Kubernetes Deployment перевіряє стан вашого Podʼа і перезапускає контейнер Podʼа, якщо контейнер перестає працювати. Створювати і масштабувати Podʼи рекомендується за допомогою Deploymentʼів.

1. За допомогою команди kubectl create створіть Deployment, який керуватиме Podʼом. Pod запускає контейнер на основі наданого образу Docker.

   # Запустіть тестовий образ контейнера, який містить вебсервер
   kubectl create deployment hello-node --image=registry.k8s.io/e2e-test-images/agnhost:2.53 -- /agnhost netexec --http-port=8080
   

2. Перегляньте інформацію про Deployment:

   kubectl get deployments
   

   У виводі ви побачите подібну інформацію:

   NAME         READY   UP-TO-DATE   AVAILABLE   AGE
   hello-node   1/1     1            1           1m
   

   (Може знадобитися деякий час, поки Pod стане доступним. Якщо ви бачите «0/1», спробуйте ще раз за кілька секунд.)

3. Перегляньте інформацію про Pod:

   kubectl get pods
   

   У виводі ви побачите подібну інформацію:

   NAME                          READY     STATUS    RESTARTS   AGE
   hello-node-5f76cf6ccf-br9b5   1/1       Running   0          1m
   

4. Перегляньте події кластера:

   kubectl get events
   

5. Перегляньте конфігурацію kubectl:

   kubectl config view
   

6. Перегляньте логи застосунку для контейнера в Podʼі (замініть імʼя Podʼа на те, яке ви отримали з kubectl get pods).

   Примітка

   Замініть hello-node-5f76cf6ccf-br9b5 у команді kubectl logs на імʼя Podʼа з виводу команди kubectl get pods.

   kubectl logs hello-node-5f76cf6ccf-br9b5
   

   У виводі ви побачите подібну інформацію:

   I0911 09:19:26.677397       1 log.go:195] Started HTTP server on port 8080
   I0911 09:19:26.677586       1 log.go:195] Started UDP server on port  8081
   

Створення Service

Типово Pod доступний лише за внутрішньою IP-адресою в межах кластера Kubernetes. Для того, щоб контейнер hello-node став доступний за межами віртуальної мережі Kubernetes, Pod необхідно відкрити як Service Kubernetes.

1. Відкрийте Pod для публічного доступу з інтернету за допомогою команди kubectl expose:

   kubectl expose deployment hello-node --type=LoadBalancer --port=8080
   

   Прапорець --type=LoadBalancer вказує, що ви хочете відкрити доступ до Service за межами кластера.

   Код застосунку в тестовому образі прослуховує лише TCP-порт 8080. Якби ви використали kubectl expose, щоб відкрити інший порт, клієнти не змогли б підʼєднатися до цього іншого порту.

2. Перегляньте інформацію про створений вами Service:

   kubectl get services
   

   У виводі ви побачите подібну інформацію:

   NAME         TYPE           CLUSTER-IP      EXTERNAL-IP   PORT(S)          AGE
   hello-node   LoadBalancer   10.108.144.78   <pending>     8080:30369/TCP   21s
   kubernetes   ClusterIP      10.96.0.1       <none>        443/TCP          23m
   

   Для хмарних провайдерів, що підтримують балансувальники навантаження, для доступу до Service буде надано зовнішню IP-адресу. У minikube тип LoadBalancer робить Service доступним через команду minikube service.

3. Виконайте наступну команду:

   minikube service hello-node
   

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

Увімкнення надбудов

Інструмент minikube містить набір вбудованих надбудов, які можна увімкнути, вимкнути і відкрити в локальному середовищі Kubernetes.

1. Перегляньте перелік наразі підтримуваних надбудов:

   minikube addons list
   

   У виводі ви побачите подібну інформацію:

   addon-manager: enabled
   dashboard: enabled
   default-storageclass: enabled
   efk: disabled
   freshpod: disabled
   gvisor: disabled
   helm-tiller: disabled
   ingress: disabled
   ingress-dns: disabled
   logviewer: disabled
   metrics-server: disabled
   nvidia-driver-installer: disabled
   nvidia-gpu-device-plugin: disabled
   registry: disabled
   registry-creds: disabled
   storage-provisioner: enabled
   storage-provisioner-gluster: disabled
   

2. Увімкніть надбудову, наприклад metrics-server:

   minikube addons enable metrics-server
   

   У виводі ви побачите подібну інформацію:

   The 'metrics-server' addon is enabled
   

3. Перегляньте Pod і Service, які ви створили, встановивши цю надбудову:

   kubectl get pod,svc -n kube-system
   

   У виводі ви побачите подібну інформацію:

   NAME                                        READY     STATUS    RESTARTS   AGE
   pod/coredns-5644d7b6d9-mh9ll                1/1       Running   0          34m
   pod/coredns-5644d7b6d9-pqd2t                1/1       Running   0          34m
   pod/metrics-server-67fb648c5                1/1       Running   0          26s
   pod/etcd-minikube                           1/1       Running   0          34m
   pod/influxdb-grafana-b29w8                  2/2       Running   0          26s
   pod/kube-addon-manager-minikube             1/1       Running   0          34m
   pod/kube-apiserver-minikube                 1/1       Running   0          34m
   pod/kube-controller-manager-minikube        1/1       Running   0          34m
   pod/kube-proxy-rnlps                        1/1       Running   0          34m
   pod/kube-scheduler-minikube                 1/1       Running   0          34m
   pod/storage-provisioner                     1/1       Running   0          34m
   
   NAME                           TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)             AGE
   service/metrics-server         ClusterIP   10.96.241.45    <none>        80/TCP              26s
   service/kube-dns               ClusterIP   10.96.0.10      <none>        53/UDP,53/TCP       34m
   service/monitoring-grafana     NodePort    10.99.24.54     <none>        80:30002/TCP        26s
   service/monitoring-influxdb    ClusterIP   10.111.169.94   <none>        8083/TCP,8086/TCP   26s
   

4. Перевірте вивід metrics-server:

   kubectl top pods
   

   У виводі ви побачите подібну інформацію:

   NAME                         CPU(cores)   MEMORY(bytes)
   hello-node-ccf4b9788-4jn97   1m           6Mi
   

   Якщо ви бачите таке повідомлення, зачекайте і спробуйте ще раз:

   error: Metrics API not available
   

5. Вимкніть metrics-server:

   minikube addons disable metrics-server
   

   У виводі ви побачите подібну інформацію:

   metrics-server was successfully disabled
   

Очищення

Тепер ви можете видалити ресурси, які створили у вашому кластері:

kubectl delete service hello-node
kubectl delete deployment hello-node

Зупиніть кластер Minikube

minikube stop

За бажанням видаліть ВМ з Minikube:

# Необовʼязково
minikube delete

Якщо ви хочете знову використовувати minikube, щоб дізнатися більше про Kubernetes, видаляти його не потрібно.

Підсумки

На цій сторінці розглянуто основні аспекти створення та запуску кластера minikube. Тепер ви готові розгортати застосунки.

Що далі

• Навчальний посібник про те, як розгорнути свій перший застосунок у Kubernetes за допомогою kubectl.
• Дізнайтеся більше про обʼєкти Deployment.
• Дізнайтеся більше про розгортання застосунків.
• Дізнайтеся більше про обʼєкти Service.

2 - Створення кластера

Дізнайтесь про кластери Kubernetes та створіть простий кластер за допомогою Minikube.

3 - Розгортання застосунку

4 - Вивчення застосунку

5 - Налаштування

6 - Stateless-застосунки

7 - Безпека

Безпека є важливою темою для більшості організацій і людей, які запускають кластери Kubernetes. Базовий список перевірки безпеки можна знайти в іншому місці документації Kubernetes.

Щоб дізнатися, як розгортати аспекти безпеки Kubernetes і керувати ними, ви можете пройти посібники з цього розділу.

7.1 - Застосування Стандартів безпеки Podʼів на рівні простору імен

Pod Security Admission — це контролер допуску, який застосовує Стандарти безпеки Podʼів під час створення Podʼів. Ця можливість загальнодоступна (GA) з v1.25. У цьому посібнику ви примусово застосуєте Стандарт безпеки Podʼів baseline, по одному простору імен за раз.

Ви також можете застосувати Стандарти безпеки Podʼів одразу до кількох просторів імен на рівні кластера. Інструкції див. у розділі Застосування Стандартів безпеки Podʼів на рівні кластера.

Перш ніж ви розпочнете

Встановіть на свою робочу станцію:

• kind
• kubectl

Створення кластера

1. Створіть кластер kind так:

   kind create cluster --name psa-ns-level
   

   Вивід буде подібний до цього:

   Creating cluster "psa-ns-level" ...
    ✓ Ensuring node image (kindest/node:v1.37.0) 🖼
    ✓ Preparing nodes 📦
    ✓ Writing configuration 📜
    ✓ Starting control-plane 🕹️
    ✓ Installing CNI 🔌
    ✓ Installing StorageClass 💾
   Set kubectl context to "kind-psa-ns-level"
   You can now use your cluster with:
   
   kubectl cluster-info --context kind-psa-ns-level
   
   Not sure what to do next? 😅  Check out https://kind.sigs.k8s.io/docs/user/quick-start/
   

2. Встановіть контекст kubectl для нового кластера:

   kubectl cluster-info --context kind-psa-ns-level
   

   Вивід буде подібний до цього:

   Kubernetes control plane is running at https://127.0.0.1:50996
   CoreDNS is running at https://127.0.0.1:50996/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy
   
   To further debug and diagnose cluster problems, use 'kubectl cluster-info dump'.
   

Створення простору імен

Створіть новий простір імен з назвою example:

kubectl create ns example

Вивід буде подібний до цього:

namespace/example created

Увімкнення перевірки Стандартів безпеки Podʼів для цього простору імен

1. Увімкніть Стандарти безпеки Podʼів у цьому просторі імен за допомогою міток, які підтримує вбудований Pod Security Admission. На цьому кроці ви налаштуєте перевірку, яка попереджатиме про Podʼи, що не відповідають останній версії стандарту безпеки Podʼів baseline.

   kubectl label --overwrite ns example \
      pod-security.kubernetes.io/warn=baseline \
      pod-security.kubernetes.io/warn-version=latest
   

2. Ви можете налаштувати кілька перевірок стандартів безпеки Podʼів для будь-якого простору імен за допомогою міток. Ця команда застосовуватиме (enforce) Стандарт безпеки Podʼів baseline, а для Стандартів безпеки Podʼів restricted за останньою версією (стандартне значення) виконуватиме warn і audit

   kubectl label --overwrite ns example \
     pod-security.kubernetes.io/enforce=baseline \
     pod-security.kubernetes.io/enforce-version=latest \
     pod-security.kubernetes.io/warn=restricted \
     pod-security.kubernetes.io/warn-version=latest \
     pod-security.kubernetes.io/audit=restricted \
     pod-security.kubernetes.io/audit-version=latest
   

Перевірка примусового застосування Стандарту безпеки Podʼів

1. Створіть Pod рівня baseline у просторі імен example:

   kubectl apply -n example -f https://k8s.io/examples/security/example-baseline-pod.yaml
   

   Pod запускається успішно; вивід містить попередження. Наприклад:

   Warning: would violate PodSecurity "restricted:latest": allowPrivilegeEscalation != false (container "nginx" must set securityContext.allowPrivilegeEscalation=false), unrestricted capabilities (container "nginx" must set securityContext.capabilities.drop=["ALL"]), runAsNonRoot != true (pod or container "nginx" must set securityContext.runAsNonRoot=true), seccompProfile (pod or container "nginx" must set securityContext.seccompProfile.type to "RuntimeDefault" or "Localhost")
   pod/nginx created
   

2. Створіть Pod рівня baseline у просторі імен default:

   kubectl apply -n default -f https://k8s.io/examples/security/example-baseline-pod.yaml
   

   Вивід буде подібний до такого:

   pod/nginx created
   

Налаштування примусового застосування Стандартів безпеки Podʼів і попереджень застосовано лише до простору імен example. Ви могли б створити такий самий Pod у просторі імен default без жодних попереджень.

Очищення

Тепер видаліть кластер, який ви створили вище, виконавши цю команду:

kind delete cluster --name psa-ns-level

Що далі

• Виконайте скрипт оболонки, щоб виконати всі попередні кроки за один раз:

  1. Створіть кластер kind.
  2. Створіть новий простір імен.
  3. Застосуйте Стандарт безпеки Podʼів baseline у режимі enforce, водночас застосувавши Стандарт безпеки Podʼів restricted у режимах warn і audit.
  4. Створіть новий Pod, до якого застосовано такі стандарти безпеки Podʼів

• Pod Security Admission

• Стандарти безпеки Podʼів

• Застосування Стандартів безпеки Podʼів на рівні кластера

8 - Відкриття доступу до застосунку за межами кластера

9 - Застосунки зі станом

9.1 - Приклад: Розгортання WordPress та MySQL з постійними томами

У цьому посібнику ви дізнаєтеся, як розгорнути сайт WordPress та базу даних MySQL за допомогою Minikube. Обидва застосунки використовують PersistentVolumes та PersistentVolumeClaims для зберігання даних.

PersistentVolume (PV) — це частина сховища в кластері, яку вручну надав адміністратор або динамічно надав Kubernetes за допомогою StorageClass. PersistentVolumeClaim (PVC) — це запит користувача на сховище, який може бути задоволений за допомогою PV. PersistentVolume і PersistentVolumeClaim не залежать від життєвого циклу Podʼів і зберігають дані під час перезапуску, перепланування та навіть видалення Podʼів.

Цілі

• Створення PersistentVolumeClaim і PersistentVolume
• Створення kustomization.yaml з
  • генератором Secret
  • конфігураціями ресурсів MySQL
  • конфігураціями ресурсів WordPress
• Застосування теки kustomization за допомогою kubectl apply -k ./
• Очищення

Перш ніж ви розпочнете

Вам треба мати кластер Kubernetes, а також інструмент командного рядка kubectl має бути налаштований для роботи з вашим кластером. Рекомендується виконувати ці настанови у кластері, що має щонайменше два вузли, які не виконують роль вузлів управління. Якщо у вас немає кластера, ви можете створити його, за допомогою minikube або використовувати одну з цих пісочниць:

• iximiuz Labs
• Killercoda
• KodeKloud

Для перевірки версії введіть kubectl version.

Наведений на цій сторінці приклад працює з kubectl версії 1.27 і вище.

Завантажте такі файли конфігурації:

1. mysql-deployment.yaml

2. wordpress-deployment.yaml

Створення PersistentVolumeClaim і PersistentVolume

Кожному з MySQL і Wordpress потрібен PersistentVolume для зберігання даних. Їхні PersistentVolumeClaim буде створено на етапі розгортання.

У багатьох кластерних середовищах встановлено стандартний StorageClass. Якщо StorageClass не вказано в PersistentVolumeClaim, натомість використовується стандартний StorageClass кластера.

Коли створюється PersistentVolumeClaim, PersistentVolume динамічно надається на основі конфігурації StorageClass.

Створення файлу kustomization.yaml

Додавання генератора Secret

Secret — це обʼєкт, який зберігає чутливі дані, такі як паролі або ключі. Починаючи з версії 1.14, kubectl підтримує керування обʼєктами Kubernetes за допомогою файлу kustomization. Ви можете створити Secret за допомогою генераторів у файлі kustomization.yaml.

Додайте генератор Secret у файл kustomization.yaml за допомогою цієї команди. Вам потрібно буде замінити YOUR_PASSWORD на пароль, який ви хочете використовувати.

cat <<EOF >./kustomization.yaml
secretGenerator:
- name: mysql-pass
  literals:
  - password=YOUR_PASSWORD
EOF

Додавання конфігурацій ресурсів для MySQL і WordPress

Наведений нижче маніфест описує одноекземплярний Deployment MySQL. Контейнер MySQL монтує PersistentVolume у /var/lib/mysql. Змінна середовища MYSQL_ROOT_PASSWORD задає пароль бази даних із Secret.

application/wordpress/mysql-deployment.yaml

apiVersion: v1
kind: Service
metadata:
  name: wordpress-mysql
  labels:
    app: wordpress
spec:
  ports:
    - port: 3306
  selector:
    app: wordpress
    tier: mysql
  clusterIP: None
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: mysql-pv-claim
  labels:
    app: wordpress
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 20Gi
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: wordpress-mysql
  labels:
    app: wordpress
spec:
  selector:
    matchLabels:
      app: wordpress
      tier: mysql
  strategy:
    type: Recreate
  template:
    metadata:
      labels:
        app: wordpress
        tier: mysql
    spec:
      containers:
      - image: mysql:8.0
        name: mysql
        env:
        - name: MYSQL_ROOT_PASSWORD
          valueFrom:
            secretKeyRef:
              name: mysql-pass
              key: password
        - name: MYSQL_DATABASE
          value: wordpress
        - name: MYSQL_USER
          value: wordpress
        - name: MYSQL_PASSWORD
          valueFrom:
            secretKeyRef:
              name: mysql-pass
              key: password
        ports:
        - containerPort: 3306
          name: mysql
        volumeMounts:
        - name: mysql-persistent-storage
          mountPath: /var/lib/mysql
      volumes:
      - name: mysql-persistent-storage
        persistentVolumeClaim:
          claimName: mysql-pv-claim

Наведений нижче маніфест описує одноекземплярний Deployment WordPress. Контейнер WordPress монтує PersistentVolume у /var/www/html для файлів даних вебсайту. Змінна середовища WORDPRESS_DB_HOST задає імʼя Service MySQL, визначеного вище, і WordPress звертатиметься до бази даних через цей Service. Змінна середовища WORDPRESS_DB_PASSWORD задає пароль бази даних із Secret, згенерованого kustomize.

application/wordpress/wordpress-deployment.yaml

apiVersion: v1
kind: Service
metadata:
  name: wordpress
  labels:
    app: wordpress
spec:
  ports:
    - port: 80
  selector:
    app: wordpress
    tier: frontend
  type: LoadBalancer
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: wp-pv-claim
  labels:
    app: wordpress
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 20Gi
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: wordpress
  labels:
    app: wordpress
spec:
  selector:
    matchLabels:
      app: wordpress
      tier: frontend
  strategy:
    type: Recreate
  template:
    metadata:
      labels:
        app: wordpress
        tier: frontend
    spec:
      containers:
      - image: wordpress:6.2.1-apache
        name: wordpress
        env:
        - name: WORDPRESS_DB_HOST
          value: wordpress-mysql
        - name: WORDPRESS_DB_PASSWORD
          valueFrom:
            secretKeyRef:
              name: mysql-pass
              key: password
        - name: WORDPRESS_DB_USER
          value: wordpress
        ports:
        - containerPort: 80
          name: wordpress
        volumeMounts:
        - name: wordpress-persistent-storage
          mountPath: /var/www/html
      volumes:
      - name: wordpress-persistent-storage
        persistentVolumeClaim:
          claimName: wp-pv-claim

1. Завантажте файл конфігурації Deployment MySQL.

   curl -LO https://k8s.io/examples/application/wordpress/mysql-deployment.yaml
   

2. Завантажте файл конфігурації WordPress.

   curl -LO https://k8s.io/examples/application/wordpress/wordpress-deployment.yaml
   

3. Додайте їх до файлу kustomization.yaml.

   cat <<EOF >>./kustomization.yaml
   resources:
     - mysql-deployment.yaml
     - wordpress-deployment.yaml
   EOF
   

Застосування та перевірка

Файл kustomization.yaml містить всі ресурси для розгортання сайту WordPress та бази даних MySQL. Ви можете застосувати цю теку командою

kubectl apply -k ./

Тепер ви можете перевірити, що всі обʼєкти існують.

1. Перевірте, що Secret існує, виконавши цю команду:

   kubectl get secrets
   

   Відповідь має бути подібною до цієї:

   NAME                    TYPE                                  DATA   AGE
   mysql-pass-c57bb4t7mf   Opaque                                1      9s
   

2. Перевірте, що PersistentVolume було динамічно надано.

   kubectl get pvc
   

   Примітка

   Надання та привʼязка PV можуть тривати кілька хвилин.

   Відповідь має бути подібною до цієї:

   NAME             STATUS    VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS       AGE
   mysql-pv-claim   Bound     pvc-8cbd7b2e-4044-11e9-b2bb-42010a800002   20Gi       RWO            standard           77s
   wp-pv-claim      Bound     pvc-8cd0df54-4044-11e9-b2bb-42010a800002   20Gi       RWO            standard           77s
   

3. Перевірте, що Pod працює, виконавши цю команду:

   kubectl get pods
   

   Примітка

   Може минути кілька хвилин, перш ніж статус Podʼа стане RUNNING.

   Відповідь має бути подібною до цієї:

   NAME                               READY     STATUS    RESTARTS   AGE
   wordpress-mysql-1894417608-x5dzt   1/1       Running   0          40s
   

4. Перевірте, що Service працює, виконавши цю команду:

   kubectl get services wordpress
   

   Відповідь має бути подібною до цієї:

   NAME        TYPE            CLUSTER-IP   EXTERNAL-IP   PORT(S)        AGE
   wordpress   LoadBalancer    10.0.0.89    <pending>     80:32406/TCP   4m
   

   Примітка

   Minikube може відкривати доступ до Service лише через NodePort. EXTERNAL-IP завжди перебуває в стані pending.

5. Виконайте цю команду, щоб отримати IP-адресу Service WordPress:

   minikube service wordpress --url
   

   Відповідь має бути подібною до цієї:

   http://1.2.3.4:32406
   

6. Скопіюйте IP-адресу та відкрийте сторінку в браузері, щоб переглянути свій сайт.

   Ви повинні побачити сторінку налаштування WordPress, схожу на знімок екрана нижче.

   

   Увага

   Не залишайте встановлення WordPress на цій сторінці. Якщо інший користувач її знайде, він може налаштувати вебсайт на вашому екземплярі й використовувати його для поширення шкідливого вмісту.
   
   Або встановіть WordPress, створивши імʼя користувача та пароль, або видаліть свій екземпляр.

Очищення

1. Виконайте цю команду, щоб видалити ваш Secret, Deployment, Service і PersistentVolumeClaim:

   kubectl delete -k ./
   

Що далі

• Дізнайтеся більше про Налагодження запущених Podʼів
• Дізнайтеся більше про Job
• Дізнайтеся більше про Використання перенаправлення портів для доступу до застосунків у кластері
• Дізнайтеся, як отримати доступ до оболонки запущеного контейнера

10 - Масштабування застосунку

11 - Оновлення застосунку