Основи Kubernetes: Пам’ятка для початківців та досвідчених користувачів

pic

Фото Іана Тейлора на Unsplash

Вступ:

  • Цей блог призначений для початківців, які хочуть зрозуміти Kubernetes, а також для тих, хто готується до складання сертифікаційного іспиту CKA і хоче освіжити свої знання з основних концепцій та команд перед тестуванням своїх навичок. Це не заміна офіційних курсів. Уся надана інформація черпається з KodeKloud Labs та курсу “Prepare for the Certified Kubernetes Administrator Certification with Live Practice Tests Right in Your Browser — CKA” від Mumshad Mannambeth.

1. Основні концепції та огляд

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

Компоненти кластера:

  • Компоненти майстра: kube-apiserver, controller manager, кластер ETCD, kube-scheduler
  • Компоненти робочих вузлів: kubelet, kube-proxy, Container Runtime Engine
  • ETCD: база даних для зберігання ключ-значення, яка зберігає інформацію, таку як вузли, Pods, конфігурації, секрети, акаунти, ролі, зв'язки тощо.

Об'єкти Kubernetes:

У цьому розділі я дам вам найбільш важливі об'єкти, які використовуються в Kubernetes або найпоширеніші, хоча є й багато інших об'єктів, таких як Job, CronJob, DaemonSet… але ці є найбільш використовуваними.

  1. Pods:
  • Найменша одиниця розгортання в Kubernetes.
  • Може містити один або більше контейнерів.
  • Створюється за допомогою YAML визначень або імперативних команд.
  • Загальні команди:
kubectl run  --image= -l :  
kubectl get pods -o wide  
kubectl describe pod   
kubectl edit pod   
kubectl replace -f   
kubectl scale --replicas= pod/

2. ReplicaSets:

  • Забезпечує постійну кількість ідентичних Pods.
  • Використовує мітки для ідентифікації та керування Pods.
  • Загальні команди:
kubectl create -f   
kubectl get replicasets  
kubectl delete replicaset   
kubectl replace -f   
kubectl scale --replicas= replicaset/  
kubectl describe replicaset

3. Deployments:

  • Абстракція вищого рівня, що керує ReplicaSets.
  • Дозволяє здійснювати декларативні оновлення та відкат додатків.
  • Загальні команди:
kubectl create -f   
kubectl get deployments  
kubectl create deployment  --replicas= --image=  
kubectl delete deployment   
kubectl replace -f   
kubectl scale --replicas= deployment/  
kubectl describe deployment   
kubectl rollout status deployment/  
kubectl rollout history deployment/  
kubectl rollout undo deployment/

4. Services:

  • Забезпечує комунікацію всередині кластера або з зовнішніми клієнтами.
  • Типи включають:
    • NodePort
    • ClusterIP
    • LoadBalancer
  • Загальні команди:
kubectl create -f   
kubectl get services  
kubectl expose pod --port= --name   
kubectl describe service   
kubectl delete service   

# Приклад служби NodePort  
---  
apiVersion: v1  
kind: Service  
metadata:  
 name: webapp-service  
 namespace: default  
spec:  
 ports:  
 - nodePort: 30080  
 port: 8080  
 targetPort: 8080  
 selector:  
 name: simple-webapp  
 type: NodePort  
~

**5.
pic

Фото Іана Тейлора на Unsplash

Вступ:

  • Цей блог створений для початківців, які хочуть зрозуміти Kubernetes, а також для тих, хто готується до складання сертифікаційного іспиту CKA і хоче освіжити свої знання з основних концепцій та команд перед тестуванням своїх навичок. Це не заміна офіційних курсів. Уся надана інформація надихнута KodeKloud Labs та курсом “Prepare for the Certified Kubernetes Administrator Certification with Live Practice Tests Right in Your Browser — CKA” від Mumshad Mannambeth.

1. Основні концепції та огляд

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

Компоненти кластера:

  • Компоненти майстра: kube-apiserver, controller manager, кластер ETCD, kube-scheduler
  • Компоненти робочих вузлів: kubelet, kube-proxy, Container Runtime Engine
  • ETCD: база даних зберігання ключ-значення, яка містить інформацію, таку як вузли, Pods, конфігурації, секрети, акаунти, ролі, зв'язки тощо.

Об'єкти Kubernetes:

У цьому розділі я представлю вам найбільш важливі об'єкти, які використовуються в Kubernetes або найпоширеніші. Існує багато інших об'єктів, таких як Job, CronJob, DaemonSet…, але ці є найбільш використовуваними.

  1. Pods:
  • Найменша одиниця розгортання в Kubernetes.
  • Може містити один або більше контейнерів.
  • Створюється за допомогою YAML визначень або імперативних команд.
  • Загальні команди:
kubectl run  --image= -l :  
kubectl get pods -o wide  
kubectl describe pod   
kubectl edit pod   
kubectl replace -f   
kubectl scale --replicas= pod/

2. ReplicaSets:

  • Забезпечують, щоб в будь-який час працювала задана кількість ідентичних Pods.
  • Використовують мітки для ідентифікації та керування Pods.
  • Загальні команди:
kubectl create -f   
kubectl get replicasets  
kubectl delete replicaset   
kubectl replace -f   
kubectl scale --replicas= replicaset/  
kubectl describe replicaset

3. Deployments:

  • Абстракція вищого рівня, яка керує ReplicaSets.
  • Дозволяє здійснювати декларативні оновлення та відкат додатків.
  • Загальні команди:
kubectl create -f   
kubectl get deployments  
kubectl create deployment  --replicas= --image=  
kubectl delete deployment   
kubectl replace -f   
kubectl scale --replicas= deployment/  
kubectl describe deployment   
kubectl rollout status deployment/  
kubectl rollout history deployment/  
kubectl rollout undo deployment/

4. Services:

  • Забезпечують комунікацію всередині кластера або з зовнішніми клієнтами.
  • Типи включають:
    • NodePort
    • ClusterIP
    • LoadBalancer
  • Загальні команди:
kubectl create -f   
kubectl get services  
kubectl expose pod --port= --name   
kubectl describe service   
kubectl delete service   

# Приклад служби NodePort  
---  
apiVersion: v1  
kind: Service  
metadata:  
 name: webapp-service  
 namespace: default  
spec:  
 ports:  
 - nodePort: 30080  
 port: 8080  
 targetPort: 8080  
 selector:  
 name: simple-webapp  
 type: NodePort  
~

5.
**Namespaces:

  • Логічні розділи в кластері для організації та ізоляції ресурсів.
  • Загальні команди:
kubectl create namespace   
kubectl get namespaces  
kubectl get ns --no-headers | wc -l #щоб дізнатися кількість namespaces  
kubectl get  --all-namespaces #отримати всі сервіси в усіх namespaces  
kubectl delete namespace   
#якщо хочете отримати доступ до ресурсу з іншим namespace: db-service.dev.svc.cluster.local

6. ConfigMap:

  • Використовується для зберігання не чутливої конфігураційної інформації у вигляді пар ключ-значення.
  • Загальні команди:
kubectl create configmap  --from-literal=key=value  
kubectl get configmaps  
kubectl describe configmap   
kubectl delete configmap

7. Secret:

  • Використовується для зберігання чутливої інформації, такої як паролі або API ключі, в безпечний спосіб.
  • Загальні команди:
kubectl create secret generic  --from-literal=key=value  
kubectl get secrets  
kubectl describe secret   
kubectl delete secret

8. PersistentVolume (PV):

  • Надає ресурси зберігання в межах кластера.
  • Загальні команди:
kubectl create -f   
kubectl get pv  
kubectl describe pv   
kubectl delete pv

9. PersistentVolumeClaim (PVC):

  • Запитує ресурси зберігання від PersistentVolumes.
  • Загальні команди:
kubectl create -f   
kubectl get pvc  
kubectl describe pvc   
kubectl delete pvc

10. Ingress:

  • Керує зовнішнім доступом HTTP/HTTPS до сервісів в кластері.
  • Може обробляти маршрутизацію, SSL термінацію та балансування навантаження.
  • Загальні команди:
kubectl create -f   
kubectl get ingress  
kubectl describe ingress   
kubectl delete ingress

11. ServiceAccount:

  • Надає ідентичність процесам, що працюють у Pod, для взаємодії з Kubernetes API.
  • Загальні команди:
kubectl create serviceaccount   
kubectl get serviceaccounts  
kubectl describe serviceaccount   
kubectl delete serviceaccount

12. Role:

  • Визначає дозволи в межах конкретного namespace.
  • Загальні команди:
kubectl create role  --verb= --resource=  
kubectl get roles  
kubectl describe role   
kubectl delete role

13. ClusterRole:

  • Визначає дозволи по всьому кластеру.
  • Загальні команди:
kubectl create clusterrole  --verb= --resource=  
kubectl get clusterroles  
kubectl describe clusterrole   
kubectl delete clusterrole

14. RoleBinding:

  • Прив'язує Role до ServiceAccount в межах конкретного namespace.
  • Загальні команди:
kubectl create rolebinding  --role= --serviceaccount=:  
kubectl get rolebindings  
kubectl describe rolebinding   
kubectl delete rolebinding

15. ClusterRoleBinding:

  • Прив'язує ClusterRole до ServiceAccount або користувача по всьому кластеру.
  • Загальні команди:
kubectl create clusterrolebinding  --clusterrole= --serviceaccount=:  
kubectl get clusterrolebindings  
kubectl describe clusterrolebinding   
kubectl delete clusterrolebinding

16. Resource Quota:

  • Обмежує споживання ресурсів (наприклад, CPU, пам'ять) в межах namespaces.
  • Загальні команди:
kubectl create -f   
kubectl get resourcequota  
kubectl describe resourcequota   
kubectl delete resourcequota

Декларативний та імперативний підхід:

  • Імперативний: надає конкретні інструкції.

  • Декларативний: вказує бажаний стан.

  • Використовуйте — dry-run=client -o yaml для тестування.
    Namespaces:

  • Логічні розділи в кластері для організації та ізоляції ресурсів.
  • Загальні команди:
kubectl create namespace   
kubectl get namespaces  
kubectl get ns --no-headers | wc -l #щоб дізнатися кількість namespaces  
kubectl get  --all-namespaces #отримати всі сервіси в усіх namespaces  
kubectl delete namespace   
#якщо хочете отримати доступ до ресурсу з іншим namespace: db-service.dev.svc.cluster.local

6. ConfigMap:

  • Використовується для зберігання не чутливої конфігураційної інформації у вигляді пар ключ-значення.
  • Загальні команди:
kubectl create configmap  --from-literal=key=value  
kubectl get configmaps  
kubectl describe configmap   
kubectl delete configmap

7. Secret:

  • Використовується для зберігання чутливої інформації, такої як паролі або API ключі, в безпечний спосіб.
  • Загальні команди:
kubectl create secret generic  --from-literal=key=value  
kubectl get secrets  
kubectl describe secret   
kubectl delete secret

8. PersistentVolume (PV):

  • Надає ресурси зберігання в межах кластера.
  • Загальні команди:
kubectl create -f   
kubectl get pv  
kubectl describe pv   
kubectl delete pv

9. PersistentVolumeClaim (PVC):

  • Запитує ресурси зберігання від PersistentVolumes.
  • Загальні команди:
kubectl create -f   
kubectl get pvc  
kubectl describe pvc   
kubectl delete pvc

10. Ingress:

  • Керує зовнішнім доступом HTTP/HTTPS до сервісів в кластері.
  • Може обробляти маршрутизацію, SSL термінацію та балансування навантаження.
  • Загальні команди:
kubectl create -f   
kubectl get ingress  
kubectl describe ingress   
kubectl delete ingress

11. ServiceAccount:

  • Надає ідентичність процесам, що працюють у Pod (Pod), для взаємодії з Kubernetes API.
  • Загальні команди:
kubectl create serviceaccount   
kubectl get serviceaccounts  
kubectl describe serviceaccount   
kubectl delete serviceaccount

12. Role:

  • Визначає дозволи в межах конкретного namespace.
  • Загальні команди:
kubectl create role  --verb= --resource=  
kubectl get roles  
kubectl describe role   
kubectl delete role

13. ClusterRole:

  • Визначає дозволи по всьому кластеру.
  • Загальні команди:
kubectl create clusterrole  --verb= --resource=  
kubectl get clusterroles  
kubectl describe clusterrole   
kubectl delete clusterrole

14. RoleBinding:

  • Прив'язує Role до ServiceAccount в межах конкретного namespace.
  • Загальні команди:
kubectl create rolebinding  --role= --serviceaccount=:  
kubectl get rolebindings  
kubectl describe rolebinding   
kubectl delete rolebinding

15. ClusterRoleBinding:

  • Прив'язує ClusterRole до ServiceAccount або користувача по всьому кластеру.
  • Загальні команди:
kubectl create clusterrolebinding  --clusterrole= --serviceaccount=:  
kubectl get clusterrolebindings  
kubectl describe clusterrolebinding   
kubectl delete clusterrolebinding

16. Resource Quota:

  • Обмежує споживання ресурсів (наприклад, CPU, пам'ять) в межах namespaces.
  • Загальні команди:
kubectl create -f   
kubectl get resourcequota  
kubectl describe resourcequota   
kubectl delete resourcequota

Декларативний та імперативний підхід:

  • Імперативний: надає конкретні інструкції.

  • Декларативний: вказує бажаний стан.

  • Використовуйте — dry-run=client -o yaml для тестування.
    Наприклад:

kubectl create deployment elasticsearch — image=registry.k8s.io/fluentd-elasticsearch:1.20 -n kube-system — dry-run=client -o yaml > fluentd.yaml

2. Планування:

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

  1. Мітки та Селектори:

Пари ключ-значення, прикріплені до об'єктів Kubernetes (наприклад, Pods, вузлів або сервісів).

apiVersion: v1  
kind: Pod  
metadata:  
 labels:  
 app: web  
 environment: production  
 matchLables :  
 app: App1  
 function: front-end  
spec:  
 containers:  
 - name: web-app  
 image: nginx

kubectl get pods -l app=web,environment=production  
kubectl get pods --selector env=dev  
kubectl get all --selector env=prod --no-headers | wc -l

2. Тейни та Толерантності:

Тейни (Taints) застосовуються до вузлів для відштовхування конкретних Pods. Толерантності (Tolerations) дозволяють Pods терпимо ставитися до цих тейнів і бути розміщеними на позначених вузлах.

apiVersion: v1  
kind: Pod  
metadata:  
 name: tolerant-pod  
spec:  
 tolerations:  
 - key: "key"  
 operator: "Equal"  
 value: "value"  
 effect: "NoSchedule"  
 containers:  
 - name: app  
 image: nginx

kubectl taint nodes  key=value:NoSchedule  
kubectl describe node kubemaster | grep Taint  
kubectl describe node | grep taint  
kubectl taint node node01 spray=mortein:NoSchedule

3. Селектори Вузлів:

Селектори вузлів дозволяють Pods запускатися лише на вузлах, що відповідають певним міткам, обмежуючи Pods лише до конкретних вузлів.

apiVersion: v1  
kind: Pod  
metadata:  
 name: memory-intensive-pod  
spec:  
 nodeSelector:  
 hardware: high-memory  
 size: Large  
 containers:  
 - name: app  
 image: nginx

kubectl label nodes node1 size=Large
  1. Прив'язка до Вузлів (Node Affinity):

Прив'язка до вузлів (Node Affinity) — це більш розширена версія селекторів вузлів. Вона дозволяє створювати м'які (бажані) та жорсткі (обов'язкові) правила для розміщення Pods на вузлах.

apiVersion: v1  
kind: Pod  
metadata:  
 name: nginx  
spec:  
 affinity:  
 nodeAffinity:  
 requiredDuringSchedulingIgnoredDuringExecution:  
 nodeSelectorTerms:  
 - matchExpressions:  
 - key: size  
 operator: Exists  
 operator: Not in  
 values:  
 - Small   
 containers:  
 - name: nginx  
 image: nginx  
 imagePullPolicy: IfNotPresent
  1. Вимоги до ресурсів:

Вимоги до ресурсів вказують мінімальні та максимальні значення CPU та пам'яті, які необхідні для ефективного виконання Pod.

Кожен вузол має певну кількість ресурсів: CPU та пам'ять (MEM).

Kubernetes використовує "CPU" як абстракційну одиницю. Коли Kubernetes взаємодіє з основним апаратним забезпеченням, він відображає 1 CPU на:

  • Один апаратний гіперпоток на фізичному процесорі (якщо використовуються сервери без віртуалізації).
  • Один віртуальний ядро, якщо використовується віртуалізована платформа (AWS, GCP, Azure).
apiVersion: v1  
kind: Pod  
metadata:  
 name: resource-pod  
spec:  
 containers:  
 - name: app  
 image: nginx  
 resources:  
 requests:  
 memory: "64Mi"  
 cpu: "250m"  
 limits:  
 memory: "128Mi"  
 cpu: "500m"
  1. Статичні Pods:

Статичні Pods керуються безпосередньо kubelet на конкретному вузлі без необхідності API-сервера. Вони визначені у файлі на вузлі і ідеально підходять для критичних компонентів кластера, таких як etcd або kube-apiserver.

apiVersion: v1  
kind: Pod  
metadata:  
 name: static-pod  
spec:  
 containers:  
 - name: app  
 image: nginx
  1. DaemonSet:

DaemonSet у Kubernetes гарантує, що Pod буде запущено на всіх (або деяких) вузлах кластера.
Наприклад:

kubectl create deployment elasticsearch — image=registry.k8s.io/fluentd-elasticsearch:1.20 -n kube-system — dry-run=client -o yaml > fluentd.yaml

2. Планування:

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

  1. Мітки та Селектори:

Пари ключ-значення, прикріплені до об'єктів Kubernetes (наприклад, Pods, вузлів або сервісів).

apiVersion: v1  
kind: Pod  
metadata:  
 labels:  
 app: web  
 environment: production  
 matchLables :  
 app: App1  
 function: front-end  
spec:  
 containers:  
 - name: web-app  
 image: nginx

kubectl get pods -l app=web,environment=production  
kubectl get pods --selector env=dev  
kubectl get all --selector env=prod --no-headers | wc -l

2. Тейни та Толерантності:

Тейни (Taints) застосовуються до вузлів для відштовхування конкретних Pods. Толерантності (Tolerations) дозволяють Pods терпимо ставитися до цих тейнів і бути розміщеними на позначених вузлах.

apiVersion: v1  
kind: Pod  
metadata:  
 name: tolerant-pod  
spec:  
 tolerations:  
 - key: "key"  
 operator: "Equal"  
 value: "value"  
 effect: "NoSchedule"  
 containers:  
 - name: app  
 image: nginx

kubectl taint nodes  key=value:NoSchedule  
kubectl describe node kubemaster | grep Taint  
kubectl describe node | grep taint  
kubectl taint node node01 spray=mortein:NoSchedule

3. Селектори Вузлів:

Селектори вузлів дозволяють Pods запускатися лише на вузлах, що відповідають певним міткам, обмежуючи Pods лише до конкретних вузлів.

apiVersion: v1  
kind: Pod  
metadata:  
 name: memory-intensive-pod  
spec:  
 nodeSelector:  
 hardware: high-memory  
 size: Large  
 containers:  
 - name: app  
 image: nginx

kubectl label nodes node1 size=Large
  1. Прив'язка до Вузлів (Node Affinity):

Прив'язка до вузлів (Node Affinity) — це більш розширена версія селекторів вузлів. Вона дозволяє створювати м'які (бажані) та жорсткі (обов'язкові) правила для розміщення Pods на вузлах.

apiVersion: v1  
kind: Pod  
metadata:  
 name: nginx  
spec:  
 affinity:  
 nodeAffinity:  
 requiredDuringSchedulingIgnoredDuringExecution:  
 nodeSelectorTerms:  
 - matchExpressions:  
 - key: size  
 operator: Exists  
 operator: Not in  
 values:  
 - Small   
 containers:  
 - name: nginx  
 image: nginx  
 imagePullPolicy: IfNotPresent
  1. Вимоги до ресурсів:

Вимоги до ресурсів вказують мінімальні та максимальні значення CPU та пам'яті, які необхідні для ефективного виконання Pod.

Кожен вузол має певну кількість ресурсів: CPU та пам'ять (MEM).

Kubernetes використовує "CPU" як абстракційну одиницю. Коли Kubernetes взаємодіє з основним апаратним забезпеченням, він відображає 1 CPU на:

  • Один апаратний гіперпоток на фізичному процесорі (якщо використовуються сервери без віртуалізації).
  • Один віртуальний ядро, якщо використовується віртуалізована платформа (AWS, GCP, Azure).
apiVersion: v1  
kind: Pod  
metadata:  
 name: resource-pod  
spec:  
 containers:  
 - name: app  
 image: nginx  
 resources:  
 requests:  
 memory: "64Mi"  
 cpu: "250m"  
 limits:  
 memory: "128Mi"  
 cpu: "500m"
  1. Статичні Pods:

Статичні Pods керуються безпосередньо kubelet на конкретному вузлі без необхідності API-сервера. Вони визначені у файлі на вузлі і ідеально підходять для критичних компонентів кластера, таких як etcd або kube-apiserver.

apiVersion: v1  
kind: Pod  
metadata:  
 name: static-pod  
spec:  
 containers:  
 - name: app  
 image: nginx
  1. DaemonSet:

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

apiVersion: apps/v1  
kind: DaemonSet  
metadata:  
 name: fluentd-elasticsearch  
spec:  
 selector:  
 matchLaabels:  
 app: monitoring-agent  
 template:  
 metadata:  
 labels:  
 app: monitoring-agent  
 spec:  
 containers:  
 - name: fluentd-elastic  
 image: monitoring-agent

якщо не хочете, щоб це було на кожному вузлі, використовуйте nodeSelector.

Поради:

  • якщо Pods не працюють і знаходяться в стані "pending", перевірте pod планувальника.
  • додайте nodeName до spec, щоб вручну призначити pod на вузол.
  • щоб отримати всі pods, які мають мітки, використовуйте kubectl get all --selector env=prod,bu=finance,tier=frontend.
  • щоб видалити тейн, додайте — в кінці команди, наприклад, kubectl taint node controlplane node-role.kubernetes.io/controlplane:NoSchedule-.
  • прив'язка до вузлів (Affinity) для розгортання повинна бути під spec.template.spec.

3. Логування та Моніторинг:

Моніторинг компонентів кластера Kubernetes включає перевірку стану та продуктивності критичних частин кластера, таких як контрольна плата (control plane), вузли (nodes) та застосунки (applications).

Сюди входять такі дані, як кількість вузлів у кластері, скільки pods працюють і є здоровими, а також показники продуктивності, такі як CPU, пам'ять (memory), мережа (network), диск (disk IO) тощо.

# створити pod metrics-server  
kubectl apply -f https://github.com/kubernetes-sigs/metrics-server/releases/latest/download/components.yaml   
kubectl top node (показники продуктивності для вузла)  
kubectl top pod (показники продуктивності для pod)  
docker logs -f   
kubectl logs webapp-2 -c   
kubectl get events --sort-by='.metadata.creationTimestamp'

4. Управління життєвим циклом застосунку:

Це процес управління повним життєвим циклом застосунку, розгорнутого на кластері Kubernetes.

  1. Поетапні оновлення, відкат та версії:
kubectl apply -f deployment.yaml (створюється нова ревізія розгортання)  
kubectl set image deployment/ = або kubectl apply  
kubectl rollout status (перевірка стану оновлень)  
kubectl rollout history (перегляд версій оновлень)

У Kubernetes є дві основні стратегії оновлень: RollingUpdate (за замовчуванням) та Recreate.

strategy:  
 type: RollingUpdate

Для розгортання є наступні стратегії:

  1. RollingUpdate: Оновлює pods поступово, забезпечуючи високу доступність під час оновлення.

  2. Recreate: Видаляє всі існуючі pods перед створенням нових.

  3. Змінні середовища (Environment Variables):

Змінні середовища можна визначати в Kubernetes за допомогою простих пар "ключ-значення", ConfigMap або Secrets.

#### Просте значення ключ-значення  


env:  
 - name: APP_COLOR  
 value: pink  


### ConfigMap  

ConfigMaps використовуються для зберігання незахищених даних конфігурації.  

#### Налаштування ConfigMap в застосунку  

apiVersion: v1  
kind: ConfigMap  
metadata:  
 name: app-config  
data:  
 app-config.properties: |  
 database.url=jdbc:mysql://localhost:3306/mydatabase  
 database.username=myuser  
 database.password=mypassword  


kubectl create -f configmap.yaml  
kubectl create configmap webapp-config-map --from-literal=APP_COLOR=darkblue --from-literal=APP_OTHER=disregard  

#### Вставити ConfigMap у pod:  


apiVersion: v1  
kind: Pod  
metadata:  
 name: mypod  
spec:  
 containers:  
 - name: mycontainer  
 image: myimage  
 envFrom:  
 - configMapRef:  
 name: app-config  


### Secrets  

Secrets використовуються для безпечного зберігання чутливих даних.
**Зазвичай використовується для розгортання фонових сервісів, таких як агенти моніторингу, збирачі логів або мережеві утиліти, які повинні працювати на кожному вузлі.**

apiVersion: apps/v1
kind: DaemonSet
metadata:
name: fluentd-elasticsearch
spec:
selector:
matchLaabels:
app: monitoring-agent
template:
metadata:
labels:
app: monitoring-agent
spec:
containers:
- name: fluentd-elastic
image: monitoring-agent
```

якщо не хочете, щоб це було на кожному вузлі, використовуйте nodeSelector.

Поради:

  • якщо pods не працюють і знаходяться в стані "pending", перевірте pod планувальника (scheduler pod).
  • додайте nodeName до spec, щоб вручну призначити pod на вузол.
  • щоб отримати всі pods, які мають мітки, використовуйте kubectl get all --selector env=prod,bu=finance,tier=frontend.
  • щоб видалити тейн, додайте — в кінці команди, наприклад, kubectl taint node controlplane node-role.kubernetes.io/controlplane:NoSchedule-.
  • прив'язка до вузлів (Affinity) для розгортання повинна бути під spec.template.spec.

3. Логування та Моніторинг:

Моніторинг компонентів кластера Kubernetes включає перевірку стану та продуктивності критичних частин кластера, таких як контрольна плата (control plane), вузли (nodes) та застосунки (applications).

Сюди входять такі дані, як кількість вузлів у кластері, скільки pods працюють і є здоровими, а також показники продуктивності, такі як CPU, пам'ять (memory), мережа (network), диск (disk IO) тощо.

# створити pod metrics-server  
kubectl apply -f https://github.com/kubernetes-sigs/metrics-server/releases/latest/download/components.yaml   
kubectl top node (показники продуктивності для вузла)  
kubectl top pod (показники продуктивності для pod)  
docker logs -f   
kubectl logs webapp-2 -c   
kubectl get events --sort-by='.metadata.creationTimestamp'

4. Управління життєвим циклом застосунку:

Це процес управління повним життєвим циклом застосунку, розгорнутого на кластері Kubernetes.

  1. Поетапні оновлення, відкат та версії:
kubectl apply -f deployment.yaml (створюється нова ревізія розгортання)  
kubectl set image deployment/ = або kubectl apply -f (поетапне оновлення)  
kubectl rollout undo deployment/ (відкат)\  
kubectl rollout status (перевірка стану оновлень)  
kubectl rollout history (перегляд версій оновлень)

У Kubernetes є дві основні стратегії оновлень: RollingUpdate (за замовчуванням) та Recreate.

strategy:  
 type: RollingUpdate

Для розгортання є наступні стратегії:

  1. RollingUpdate: Оновлює pods поступово, забезпечуючи високу доступність під час оновлення.

  2. Recreate: Видаляє всі існуючі pods перед створенням нових.

  3. Змінні середовища (Environment Variables):

Змінні середовища можна визначати в Kubernetes за допомогою простих пар "ключ-значення", ConfigMap або Secrets.

#### Просте значення ключ-значення  


env:  
 - name: APP_COLOR  
 value: pink  


### ConfigMap  

ConfigMaps використовуються для зберігання незахищених даних конфігурації.  

#### Налаштування ConfigMap в застосунку  

apiVersion: v1  
kind: ConfigMap  
metadata:  
 name: app-config  
data:  
 app-config.properties: |  
 database.url=jdbc:mysql://localhost:3306/mydatabase  
 database.username=myuser  
 database.password=mypassword  


kubectl create -f configmap.yaml  
kubectl create configmap webapp-config-map --from-literal=APP_COLOR=darkblue --from-literal=APP_OTHER=disregard  

#### Вставити ConfigMap у pod:  


apiVersion: v1  
kind: Pod  
metadata:  
 name: mypod  
spec:  
 containers:  
 - name: mycontainer  
 image: myimage  
 envFrom:  
 - configMapRef:  
 name: app-config  


### Secrets  

Secrets використовуються для безпечного зберігання чутливих даних.
**#### Створення Secret (секрету)**

apiVersion: v1
kind: Secret
metadata:
name: app-secret
data:
DBHost: mysql
DBUser: root
DB_Password: paswrd
```

kubectl create secret generic db-secret --from-literal=DBHost=sql01 --from-literal=DBUser=root --from-literal=DB_Password=password123

Використання Secret у Pod

apiVersion: v1  
kind: Pod  
metadata:  
 labels:  
 name: webapp-pod  
 name: webapp-pod  
 namespace: default  
spec:  
 containers:  
 - image: kodekloud/simple-webapp-mysql  
 imagePullPolicy: Always  
 name: webapp  
 envFrom:  
 - secretRef:  
 name: db-secret

3. Масштабування застосунку:

kubectl scale deployment my-app --replicas=5  

## або у yaml файлі  

spec:  
 replicas: 5

4. Pods з кількома контейнерами

apiVersion: v1  
 kind: Pod  
 metadata:  
 name: myapp  
 labels:  
 name:simple-webapp  
 spec:  
 containers:  
 - name: simple-webapp  
 image: simple-webapp  
 ports:  
 - containerPort: 8080  
 - name: log-agent  
 image: log agent  
~~  

### Init Container

apiVersion: v1
kind: Pod
metadata:
name: myapp-pod
labels:
app: myapp
spec:
containers:
- name: myapp-container
image: busybox:1.28
command: ['sh', '-c', 'echo The app is running! && sleep 3600']
initContainers:
- name: init-myservice
image: busybox:1.28
command: ['sh', '-c', 'until nslookup myservice; do echo waiting for myservice; sleep 2; done;']
- name: init-mydb
image: busybox:1.28
command: ['sh', '-c', 'until nslookup mydb; do echo waiting for mydb; sleep 2; done;']
```

Команди:

apiVersion: v1  
kind: Pod   
metadata:  
 name: ubuntu-sleeper-3  
spec:  
 containers:  
 - name: ubuntu  
 image: ubuntu  
 command:  
 - "sleep"  
 - "1200"  
# або  

apiVersion: v1  
kind: Pod  
metadata:  
 name: command-demo  
 labels:  
 purpose: demonstrate-command  
spec:  
 containers:  
 - name: command-demo-container  
 image: debian  
 command: ["printenv"]  
 args: ["HOSTNAME", "KUBERNETES_PORT"]  
 restartPolicy: OnFailure

Команди у pod завжди перекривають команду в Docker образі.

5. Технічне обслуговування кластера:

  1. Як виконати обслуговування вузла:
  • крок 1: Виконати drain для вузла kubectl drain
  • крок 2: Здійснити оновлення ОС або обслуговування вузла.
  • крок 3: Перевірити систему.
  • крок 4: Дозволити планування робочих навантажень на вузлі знову kubectl uncordon.

2. Випуски Kubernetes (версії програмного забезпечення):

Kubernetes використовує структуровану систему версіонування для керування випусками:

  • Основні випуски (Major Releases) (vX): Впроваджують значні зміни, включаючи ламаючі оновлення та нові функції.
  • Маленькі випуски (Minor Releases) (vX.Y): Включають нові функціональності та покращення. Випускаються, як правило, кожні кілька місяців.
  • Випуски патчів (Patch Releases) (vX.Y.Z): Зосереджуються на виправленнях помилок та незначних покращеннях для забезпечення стабільності.
    #### Створення Secret (секрету)
apiVersion: v1  
kind: Secret  
metadata:  
 name: app-secret  
data:  
 DB_Host: mysql  
 DB_User: root  
 DB_Password: paswrd

kubectl create secret generic db-secret --from-literal=DBHost=sql01 --from-literal=DBUser=root --from-literal=DB_Password=password123

Використання Secret у Pod

apiVersion: v1  
kind: Pod  
metadata:  
 labels:  
 name: webapp-pod  
 name: webapp-pod  
 namespace: default  
spec:  
 containers:  
 - image: kodekloud/simple-webapp-mysql  
 imagePullPolicy: Always  
 name: webapp  
 envFrom:  
 - secretRef:  
 name: db-secret

3. Масштабування застосунку:

kubectl scale deployment my-app --replicas=5  

## або у yaml файлі  

spec:  
 replicas: 5

4. Pods з кількома контейнерами

apiVersion: v1  
 kind: Pod  
 metadata:  
 name: myapp  
 labels:  
 name:simple-webapp  
 spec:  
 containers:  
 - name: simple-webapp  
 image: simple-webapp  
 ports:  
 - containerPort: 8080  
 - name: log-agent  
 image: log agent  
~~  

### Init Container

apiVersion: v1
kind: Pod
metadata:
name: myapp-pod
labels:
app: myapp
spec:
containers:
- name: myapp-container
image: busybox:1.28
command: ['sh', '-c', 'echo The app is running! && sleep 3600']
initContainers:
- name: init-myservice
image: busybox:1.28
command: ['sh', '-c', 'until nslookup myservice; do echo waiting for myservice; sleep 2; done;']
- name: init-mydb
image: busybox:1.28
command: ['sh', '-c', 'until nslookup mydb; do echo waiting for mydb; sleep 2; done;']
```

Команди:

apiVersion: v1  
kind: Pod   
metadata:  
 name: ubuntu-sleeper-3  
spec:  
 containers:  
 - name: ubuntu  
 image: ubuntu  
 command:  
 - "sleep"  
 - "1200"  
# або  

apiVersion: v1  
kind: Pod  
metadata:  
 name: command-demo  
 labels:  
 purpose: demonstrate-command  
spec:  
 containers:  
 - name: command-demo-container  
 image: debian  
 command: ["printenv"]  
 args: ["HOSTNAME", "KUBERNETES_PORT"]  
 restartPolicy: OnFailure

Команди у pod завжди перекривають команду в Docker образі.

5. Технічне обслуговування кластера:

  1. Як виконати обслуговування вузла:
  • крок 1: Виконати drain для вузла kubectl drain
  • крок 2: Здійснити оновлення ОС або обслуговування вузла.
  • крок 3: Перевірити систему.
  • крок 4: Дозволити планування робочих навантажень на вузлі знову kubectl uncordon.

2. Випуски Kubernetes (версії програмного забезпечення):

Kubernetes використовує структуровану систему версіонування для керування випусками:

  • Основні випуски (Major Releases) (vX): Впроваджують значні зміни, включаючи ламаючі оновлення та нові функції.
  • Маленькі випуски (Minor Releases) (vX.Y): Включають нові функціональності та покращення. Випускаються, як правило, кожні кілька місяців.
  • Випуски патчів (Patch Releases) (vX.Y.Z): Зосереджуються на виправленнях помилок та незначних покращеннях для забезпечення стабільності.
    Процес оновлення кластера:

Кожен компонент Kubernetes (наприклад, kube-apiserver, kube-controller-manager, kube-proxy) має свою власну версію, що узгоджена з циклом випуску Kubernetes.

Оновлення компонентів Kubernetes виконується у такому порядку:

  • Компоненти Control Plane: Почніть з kube-apiserver, потім оновлюйте kube-controller-manager і kube-scheduler.
  • Etcd (якщо самостійно керується): Оновлюється після оновлення control plane.
  • Компоненти на вузлах: Оновіть kubelet і kube-proxy на робочих вузлах.

Правило: Завжди оновлюйте одну малу версію за раз (наприклад, з 1.25 до 1.26) і перевіряйте сумісність перед оновленням до наступної версії.

  • Ключові кроки для kubeadm upgrade:
# Перевірка сумісності поточної версії:  
kubeadm upgrade plan  
# Оновлення Control Plane:  
kubeadm upgrade apply   
# Оновлення kubelet та kubectl:  
apt-get install -y kubelet= kubectl=  
systemctl restart kubelet  
# Оновлення робочих вузлів:  
# дренування вузлів :  
kubectl drain  --ignore-daemonsets --delete-emptydir-data  
# оновлення робочих вузлів :  
apt-get upgrade -y kubeadm=  
apt-get upgrade -y kubelet=  
kubeadm upgrade node config - kubelet-version   
systemctl restart kubelet  
# розблокування робочих вузлів :  
kubectl uncordon

4. Методи резервного копіювання та відновлення:

  • Резервне копіювання конфігурації ресурсів:
kubectl get all --all-namespaces > all-deploy-services.yaml
  • Резервне копіювання та відновлення даних etcd:
# Резервне копіювання даних etcd  
ETCDCTL_API=3 etcdctl snapshot save snapshot.db  
ETCDCTL_API=3 etcdctl snapshot status snapshot.db  
# Відновлення даних etcd  
ETCDCTL_API=3 etcdctl snapshot restore snapshot.db \  
 --data-dir /var/lib/etcd \  
 --name default.local  
# Створення резервної копії etcd (Ця команда необхідна для виробничих середовищ, де комунікація з etcd зашифрована і застосовується автентифікація. Це забезпечує безпечний доступ до кластеру etcd.)  
ETCDCTL_API=3 etcdctl --endpoints=https://127.0.0.1:2379 \  
 --cacert=/etc/kubernetes/pki/etcd/ca.crt \  
 --cert=/etc/kubernetes/pki/etcd/server.crt \  
 --key=/etc/kubernetes/pki/etcd/server.key \  
 snapshot save /opt/snapshot-pre-boot.db
  • Керування кластером:
# Перегляд кластерів:  
kubectl config get-clusters  
kubectl config view  
# Перемикання між кластерами:  
kubectl config use-context   
# Перевірка типу розгортання etcd:  
# Якщо pods etcd працюють поруч з іншими системними pod'ами (наприклад, kube-apiserver), то це стекована конфігурація.  
kubectl get pods -n kube-system  
kubectl describe pod kube-apiserver-node -n kube-system | grep etcd

Як kubectl взаємодіє з кластерами

Інструмент командного рядка kubectl спілкується з API сервером Kubernetes через HTTP запити.

API сервер є основною точкою управління кластером, обробляючи запити, перевіряючи їх та оновлюючи стан кластера.

Контекст у Kubernetes: Контекст поєднує кластер, користувача та простір імен. Використовуйте команду kubectl config use-context, щоб перемикатися між контекстами.

Трюки:

  • Іноді ви не можете виконати дренування деяких вузлів для обслуговування, оскільки ці pod'и не керуються контролером (наприклад, Deployment, ReplicaSet, StatefulSet, чи DaemonSet).
  • Щоб зробити вузол не запланованим, використовуйте команду cordon: kubectl cordon
  • Щоб побачити версію etcd, перегляньте логи або опис pod і подивіться на Image.
  • Якщо вам потрібно знайти, за якою адресою можна звертатися до кластеру ETCD, опишіть pod etcd і подивіться на параметр — listen-client-urls.
  • Сертифікат сервера ETCD знаходиться в — cert-file.
  • Для відновлення etcd використовуйте команду ETCDCTL_API=3 etcdctl — data-dir /var/lib/etcd-from-backup \
    snapshot restore /opt/snapshot-pre-boot.db, а потім змініть
- hostPath:  
 path: /var/lib/etcd-from-backup  
 type: DirectoryOrCreate  
name: etcd-data

в /etc/kubernetes/manifests/etcd.yaml

6. Безпека:

1.
Процес оновлення кластера:

Кожен компонент Kubernetes (наприклад, kube-apiserver, kube-controller-manager, kube-proxy) має свою власну версію, узгоджену з циклом випуску Kubernetes.

Оновлення компонентів Kubernetes відбувається в такому порядку:

  • Компоненти Control Plane: Почніть з kube-apiserver, потім оновлюйте kube-controller-manager і kube-scheduler.
  • Etcd (якщо керується самостійно): Оновіть після оновлення control plane.
  • Компоненти на вузлах: Оновіть kubelet і kube-proxy на робочих вузлах.

Правило: Завжди оновлюйте одну малу версію за раз (наприклад, з 1.25 до 1.26) і перевіряйте сумісність перед оновленням до наступної версії.

  • Ключові кроки для kubeadm upgrade:
# Перевірка сумісності поточної версії:  
kubeadm upgrade plan  
# Оновлення Control Plane:  
kubeadm upgrade apply   
# Оновлення kubelet і kubectl:  
apt-get install -y kubelet= kubectl=  
systemctl restart kubelet  
# Оновлення робочих вузлів:  
# дренування вузлів :  
kubectl drain  --ignore-daemonsets --delete-emptydir-data  
# оновлення робочих вузлів :  
apt-get upgrade -y kubeadm=  
apt-get upgrade -y kubelet=  
kubeadm upgrade node config - kubelet-version   
systemctl restart kubelet  
# розблокування робочих вузлів :  
kubectl uncordon

4. Методи резервного копіювання та відновлення:

  • Резервне копіювання конфігурації ресурсів:
kubectl get all --all-namespaces > all-deploy-services.yaml
  • Резервне копіювання та відновлення даних etcd:
# Резервне копіювання даних etcd  
ETCDCTL_API=3 etcdctl snapshot save snapshot.db  
ETCDCTL_API=3 etcdctl snapshot status snapshot.db  
# Відновлення даних etcd  
ETCDCTL_API=3 etcdctl snapshot restore snapshot.db \  
 --data-dir /var/lib/etcd \  
 --name default.local  
# Створення резервної копії etcd (Ця команда необхідна для виробничих середовищ, де комунікація з etcd зашифрована і застосовується автентифікація. Це забезпечує безпечний доступ до кластеру etcd.)  
ETCDCTL_API=3 etcdctl --endpoints=https://127.0.0.1:2379 \  
 --cacert=/etc/kubernetes/pki/etcd/ca.crt \  
 --cert=/etc/kubernetes/pki/etcd/server.crt \  
 --key=/etc/kubernetes/pki/etcd/server.key \  
 snapshot save /opt/snapshot-pre-boot.db
  • Керування кластером:
# Перегляд кластерів:  
kubectl config get-clusters  
kubectl config view  
# Перемикання між кластерами:  
kubectl config use-context   
# Перевірка типу розгортання etcd:  
# Якщо pods etcd працюють поруч з іншими системними pod'ами (наприклад, kube-apiserver), то це стекована конфігурація.  
kubectl get pods -n kube-system  
kubectl describe pod kube-apiserver-node -n kube-system | grep etcd

Як kubectl взаємодіє з кластерами

Інструмент командного рядка kubectl спілкується з API сервером Kubernetes через HTTP запити.

API сервер є основною точкою управління кластером, обробляючи запити, перевіряючи їх та оновлюючи стан кластера.

Контекст у Kubernetes: Контекст поєднує кластер, користувача та простір імен. Використовуйте команду kubectl config use-context, щоб перемикатися між контекстами.

Трюки:

  • Іноді ви не можете виконати дренування деяких вузлів для обслуговування, оскільки ці pod'и не керуються контролером (наприклад, Deployment, ReplicaSet, StatefulSet чи DaemonSet).
  • Щоб зробити вузол незапланованим, використовуйте команду cordon: kubectl cordon
  • Щоб побачити версію etcd, перегляньте логи або опис pod і подивіться на Image.
  • Якщо вам потрібно знайти адресу, за якою можна звертатися до кластера ETCD, опишіть pod etcd і подивіться на параметр — listen-client-urls.
  • Сертифікат сервера ETCD знаходиться в — cert-file.
  • Для відновлення etcd використовуйте команду ETCDCTL_API=3 etcdctl — data-dir /var/lib/etcd-from-backup \
    snapshot restore /opt/snapshot-pre-boot.db, а потім змініть
- hostPath:  
 path: /var/lib/etcd-from-backup  
 type: DirectoryOrCreate  
name: etcd-data

в /etc/kubernetes/manifests/etcd.yaml

6. Безпека:

1.
Примітиви безпеки:

Щоб забезпечити безпеку хоста Kubernetes:

  • Вимкніть доступ root.
  • Вимкніть аутентифікацію за допомогою пароля.
  • Дозвольте лише аутентифікацію за допомогою SSH-ключів.

2. Доступність (хто може отримати доступ до кластера):

Методи аутентифікації:

  • Ідентифікатор користувача/пароль (не рекомендується).
  • Ім'я користувача та токени.
  • Сертифікати.
  • Інтеграція з LDAP.

TLS Сертифікати:

  • Визначення: Забезпечує, що комунікація між клієнтом і сервером зашифрована за допомогою TLS.
  • Асиметричне шифрування:
  • Дані шифруються за допомогою публічного ключа та дешифруються за допомогою приватного ключа.
  • Приклад: Використання ssh-keygen для генерації пар ключів для доступу через SSH.

Основні поняття:

  • Публічні ключі зберігаються в файлах, таких як .cert або .pem.
  • Приватні ключі зберігаються в файлах, таких як .key або -key.pem.
  • Сертифікати та ключі керуються в межах PKI (Інфраструктура відкритих ключів).

TLS Сертифікати в Kubernetes:

API Server:

apiserver.cert та apiserver.key.

etcd:

etcdserver.cert та etcdserver.key.

Kubelet:

kubelet.cert та kubelet.key.

Сертифікати клієнтів:

kubeproxy.cert та kubeproxy.key.

controller-manager.cert та controller-manager.key.

scheduler.cert та scheduler.key.

admin.cert та admin.key.

pic

  • Моделі авторизації:
  1. RBAC (Role-Based Access Control):

Зв'язує користувачів/групи з конкретними ролями та дозволами.

1.
Примітиви безпеки:

Щоб забезпечити безпеку хоста Kubernetes:

  • Вимкніть доступ root.
  • Вимкніть аутентифікацію за допомогою пароля.
  • Дозвольте лише аутентифікацію за допомогою SSH-ключів.

2. Доступність (хто може отримати доступ до кластера):

Методи аутентифікації:

  • Ідентифікатор користувача/пароль (не рекомендується).
  • Ім'я користувача та токени.
  • Сертифікати.
  • Інтеграція з LDAP.

TLS Сертифікати:

  • Визначення: Забезпечує, що комунікація між клієнтом і сервером зашифрована за допомогою TLS.
  • Асиметричне шифрування:
  • Дані шифруються за допомогою публічного ключа та дешифруються за допомогою приватного ключа.
  • Приклад: Використання ssh-keygen для генерації пар ключів для доступу через SSH.

Основні поняття:

  • Публічні ключі зберігаються в файлах, таких як .cert або .pem.
  • Приватні ключі зберігаються в файлах, таких як .key або -key.pem.
  • Сертифікати та ключі керуються в межах PKI (Інфраструктура відкритих ключів).

TLS Сертифікати в Kubernetes:

API Server:

apiserver.cert та apiserver.key.

etcd:

etcdserver.cert та etcdserver.key.

Kubelet:

kubelet.cert та kubelet.key.

Сертифікати клієнтів:

kubeproxy.cert та kubeproxy.key.

controller-manager.cert та controller-manager.key.

scheduler.cert та scheduler.key.

admin.cert та admin.key.

pic

  • Моделі авторизації:
  1. RBAC (Role-Based Access Control):

Зв'язує користувачів/групи з конкретними ролями та дозволами.

1.
Інші моделі:

Авторизація вузлів.

ABAC (Attribute-Based Access Control — Контроль доступу на основі атрибутів).

Webhook авторизація.

  • Управління сертифікатами в Kubernetes

Запити на підписання сертифікатів (CSR):

CSR — це запит до CA (Certificate Authority — Центр сертифікації) для видачі сертифікату.

kubectl get csr  
kubectl certificate approve   
kubectl certificate deny   

# за допомогою YAML реалізації (декларативно)  

apiVersion: certificates.k8s.io/v1  
kind: CertificateSigningRequest  
metadata:  
 name: my-client-cert  
spec:  
 request:   
 signerName: kubernetes.io/kube-apiserver-client  
 usages:  
 - client auth  
# створити і затвердити сертифікат  
kubectl create -f my-client-cert.yaml  
kubectl certificate approve my-client-cert

RBAC в Kubernetes:

  • Визначте ролі та призначайте їх за допомогою RoleBindings.
  • Ролі можуть бути специфічними для простору імен або глобальними (ClusterRoles).
kubectl get roles  
kubectl get rolebinding  

# Роль кластеру  

kubectl get clusterroles  
kubectl get clusterrolebinding

Облікові записи служб

  • Облікові записи користувачів: Адміни, розробники тощо.
  • Облікові записи служб: Використовуються автоматизованими інструментами, такими як Jenkins або Prometheus.
kubectl create serviceaccount dashboard-sa   
kubectl get serviceaccount   
kubectl create token dashboard-sa

Безпека зображень

Забезпечте доступ до контейнерних зображень за допомогою секретів Docker registry:

kubectl create secret docker-registry myregistrykey \
--docker-server= \
--docker-username= \
--docker-password= \
--docker-email=

Мережеві політики:

Мережеві політики в Kubernetes — це набір правил, які контролюють потік трафіку між Pods і іншими мережевими кінцевими точками.

kubectl get networkpolicies.networking.k8s.io   
# Приклад мережевої політики:  
apiVersion: networking.k8s.io/v1  
kind: NetworkPolicy  
metadata:  
 name: internal-policy  
 namespace: default  
spec:  
 podSelector:  
 matchLabels:  
 name: internal  
 policyTypes:  
 - Egress  
 - Ingress  
 ingress:  
 - {}  
 egress:  
 - to:  
 - podSelector:  
 matchLabels:  
 name: mysql  
 ports:  
 - protocol: TCP  
 port: 3306  

 - to:  
 - podSelector:  
 matchLabels:  
 name: payroll  
 ports:  
 - protocol: TCP  
 port: 8080  

 - ports:  
 - port: 53  
 protocol: UDP  
 - port: 53  
 protocol: TCP

Трюки:

  • щоб знайти сертифікат для об'єкта в Kubernetes, потрібно перейти в папку з визначенням і використати команду cat для YAML файлу. Наприклад, для kubeapi server використовуйте cat /etc/kubernetes/manifests/kube-apiserver.yaml.
  • команда openssl x509 -in /path/to/certificate.crt -noout -text використовується для перегляду та перевірки деталей сертифіката X.509 у зручному для людини форматі.
  • шлях за замовчуванням до файлу kubeconfig: ~/.kube/config.
  • переглянути кількість кластерів: kubectl config view.
  • режим авторизації в pod kube-apiserver-controlplane.
  • Role: Використовується для дозволів у конкретному просторі імен.
  • ClusterRole: Використовується для дозволів у всіх просторах імен кластеру або для ресурсів, що охоплюють увесь кластер.
  • RoleBinding та ClusterRoleBinding: Використовуються для асоціації користувачів, груп або облікових записів служб з Role або ClusterRole.
  • Кожен простір імен має обліковий запис служби за замовчуванням, який автоматично асоціюється з Pods, якщо не вказаний інший обліковий запис служби.

7. Зберігання в Kubernetes:

1.
Інші моделі:

Авторизація вузлів.

ABAC (Attribute-Based Access Control — Контроль доступу на основі атрибутів).

Webhook авторизація.

  • Управління сертифікатами в Kubernetes

Запити на підписання сертифікатів (CSR):

CSR — це запит до CA (Certificate Authority — Центр сертифікації) для видачі сертифікату.

kubectl get csr  
kubectl certificate approve   
kubectl certificate deny   

# за допомогою YAML реалізації (декларативно)  

apiVersion: certificates.k8s.io/v1  
kind: CertificateSigningRequest  
metadata:  
 name: my-client-cert  
spec:  
 request:   
 signerName: kubernetes.io/kube-apiserver-client  
 usages:  
 - client auth  
# створити і затвердити сертифікат  
kubectl create -f my-client-cert.yaml  
kubectl certificate approve my-client-cert

RBAC в Kubernetes:

  • Визначте ролі та призначайте їх за допомогою RoleBindings.
  • Ролі можуть бути специфічними для простору імен або глобальними (ClusterRoles).
kubectl get roles  
kubectl get rolebinding  

# Роль кластеру  

kubectl get clusterroles  
kubectl get clusterrolebinding

Облікові записи служб

  • Облікові записи користувачів: Адміни, розробники тощо.
  • Облікові записи служб: Використовуються автоматизованими інструментами, такими як Jenkins або Prometheus.
kubectl create serviceaccount dashboard-sa   
kubectl get serviceaccount   
kubectl create token dashboard-sa

Безпека зображень

Забезпечте доступ до контейнерних зображень за допомогою секретів Docker registry:

kubectl create secret docker-registry myregistrykey \
--docker-server= \
--docker-username= \
--docker-password= \
--docker-email=

Мережеві політики:

Мережеві політики в Kubernetes — це набір правил, які контролюють потік трафіку між Pods і іншими мережевими кінцевими точками.

kubectl get networkpolicies.networking.k8s.io   
# Приклад мережевої політики:  
apiVersion: networking.k8s.io/v1  
kind: NetworkPolicy  
metadata:  
 name: internal-policy  
 namespace: default  
spec:  
 podSelector:  
 matchLabels:  
 name: internal  
 policyTypes:  
 - Egress  
 - Ingress  
 ingress:  
 - {}  
 egress:  
 - to:  
 - podSelector:  
 matchLabels:  
 name: mysql  
 ports:  
 - protocol: TCP  
 port: 3306  

 - to:  
 - podSelector:  
 matchLabels:  
 name: payroll  
 ports:  
 - protocol: TCP  
 port: 8080  

 - ports:  
 - port: 53  
 protocol: UDP  
 - port: 53  
 protocol: TCP

Трюки:

  • щоб знайти сертифікат для об'єкта в Kubernetes, потрібно перейти в папку з визначенням і використати команду cat для YAML файлу. Наприклад, для kubeapi server використовуйте cat /etc/kubernetes/manifests/kube-apiserver.yaml.
  • команда openssl x509 -in /path/to/certificate.crt -noout -text використовується для перегляду та перевірки деталей сертифіката X.509 у зручному для людини форматі.
  • шлях за замовчуванням до файлу kubeconfig: ~/.kube/config.
  • переглянути кількість кластерів: kubectl config view.
  • режим авторизації в pod kube-apiserver-controlplane.
  • Role: Використовується для дозволів у конкретному просторі імен.
  • ClusterRole: Використовується для дозволів у всіх просторах імен кластеру або для ресурсів, що охоплюють увесь кластер.
  • RoleBinding та ClusterRoleBinding: Використовуються для асоціації користувачів, груп або облікових записів служб з Role або ClusterRole.
  • Кожен простір імен має обліковий запис служби за замовчуванням, який автоматично асоціюється з Pods, якщо не вказаний інший обліковий запис служби.

7. Зберігання в Kubernetes:

1.
Зберігання в Docker:

Docker пропонує різні варіанти зберігання для керування даними між контейнерами.

Каталоги файлової системи:

Docker зберігає дані в наступних каталогах:

  • /var/lib/docker: Головний каталог для зберігання Docker.
  • /aufs: Сховище, яке використовує драйвер AUFS (якщо застосовно).
  • /containers: Дані, специфічні для контейнерів.
  • /images: Сховище для зображень контейнерів.
  • /volumes: Сховище для томів Docker.
  • /data_volume: Сховище для об'ємів, визначених користувачем.

Типи монтувань:spec.vo

  • Volume Mount (іменоване монтування): Використовує томи Docker для зберігання сталих даних.
  • Bind Mount: Монтує каталог із хост-системи в контейнер.
# bind mount  
docker run -v /data/mysql:/var/lib/mysql mysql   
# volume mount або іменоване монтування  
docker run -v db:/var/lib/mysql mysql
  1. Томах Kubernetes:

У Kubernetes томи використовуються для керування сталим зберіганням.

# HostPath Volume: Монтує файл або каталог з файлової системи хост-ноута в pod.  
volumeMounts:  
 - mountPath: /foo  
 name: example-volume  
 readOnly: true  
 volumes:  
 - name: example-volume  
 hostPath:  
 path: /data/foo   
 type: Directory  
# AWS Elastic Block Store (EBS): Для сталого зберігання за допомогою томів AWS EBS.  
volumes:  
 - name: data-volume  
 awsElasticBlockStore:  
 volumeID:   
 fsType: ext4

3. Постійні томи (PV) і запити на постійні томи (PVC):

# PV — це фактичні ресурси зберігання в кластері.  
apiVersion: v1  
kind: PersistentVolume  
metadata:  
 name: example-pv  
spec:  
 capacity:  
 storage: 500Mi  
 accessModes:  
 - ReadWriteOnce  
 persistentVolumeReclaimPolicy: Retain  
 storageClassName: manual  
 hostPath:  
 path: /mnt/data  

# PVC — це запити на зберігання, які подаються pods. Вони зв'язуються з доступними PV для зберігання.  
apiVersion: v1  
kind: PersistentVolumeClaim  
metadata:  
 name: myclaim  
spec:  
 accessModes:  
 - ReadWriteOnce  
 resources:  
 requests:  
 storage: 500Mi  

# зв'язати pod з PVC  

apiVersion: v1  
kind: Pod  
metadata:  
 name: example-pod  
spec:  
 containers:  
 - name: app-container  
 image: nginx  
 volumeMounts:  
 - mountPath: /data  
 name: data-volume  
 volumes:  
 - name: data-volume  
 persistentVolumeClaim:  
 claimName: myclaim

5. Класи зберігання:

StorageClass у Kubernetes — це шаблон конфігурації для динамічного створення Persistent Volumes (PV). Він визначає тип зберігання (наприклад, SSD, HDD), постачальника (наприклад, AWS EBS, Azure Disk) та параметри, як-от розмір або рівень продуктивності.

apiVersion: storage.k8s.io/v1  
kind: StorageClass  
metadata:  
 name: delayed-volume-sc  
provisioner: kubernetes.io/no-provisioner  
volumeBindingMode: WaitForFirstConsumer

Трюки:

  • якщо режими доступу в PV і PVC не однакові, вони не будуть приєднуватися.
  • після видалення PVC і pod, який був прив'язаний до цього PVC, PV буде в стані "release", а не "pending".

8. Мережі:

  1. Мережі Linux:
  • Перемикання (Switching): Осуществляет зв'язок всередині тієї ж локальної мережі (LAN) через MAC-адреси.
  • Перемикання в Linux дозволяє здійснювати зв'язок всередині однієї LAN, створюючи міст інтерфейсів для зв'язку пристроїв на рівні MAC-адрес.
  • Маршрутизація (Routing): Осуществляет зв'язок між різними мережами через IP-адреси.
  • Маршрутизація в Linux здійснює підключення різних мереж, пересилаючи пакети між ними на основі їх IP-адрес.
  • За замовчуванням шлюз (Default Gateway): Направляє трафік на невідомі адреси (за межі локальної мережі).
  • За замовчуванням шлюз в Linux забезпечує маршрут трафіку на невідомі адреси (наприклад, Інтернет) до правильного upstream пристрою (зазвичай маршрутизатора).

Корисні команди:

  • ip link: Керує мережевими інтерфейсами.
  • ip addr: Відображає або змінює IP-адреси.

У відображених IP-адресах можна знайти eth0, lo...
Зберігання в Docker:

Docker надає різноманітні варіанти зберігання для керування даними між контейнерами.

Каталоги файлової системи:

Docker зберігає дані в наступних каталогах:

  • /var/lib/docker: Основний каталог для зберігання Docker.
  • /aufs: Сховище, що використовує драйвер AUFS (якщо застосовно).
  • /containers: Дані, що належать конкретному контейнеру.
  • /images: Сховище для зображень контейнерів.
  • /volumes: Сховище для томів Docker.
  • /data_volume: Сховище для об'ємів, визначених користувачем.

Типи монтувань:spec.vo

  • Volume Mount (іменоване монтування): Використовує томи Docker для зберігання сталих даних.
  • Bind Mount: Монтує каталог з хост-системи в контейнер.
# bind mount  
docker run -v /data/mysql:/var/lib/mysql mysql   
# volume mount або іменоване монтування  
docker run -v db:/var/lib/mysql mysql
  1. Томах Kubernetes:

У Kubernetes томи використовуються для керування сталим зберіганням.

# HostPath Volume: Монтує файл або каталог з файлової системи хост-ноута в pod.  
volumeMounts:  
 - mountPath: /foo  
 name: example-volume  
 readOnly: true  
 volumes:  
 - name: example-volume  
 hostPath:  
 path: /data/foo   
 type: Directory  
# AWS Elastic Block Store (EBS): Для сталого зберігання за допомогою томів AWS EBS.  
volumes:  
 - name: data-volume  
 awsElasticBlockStore:  
 volumeID:   
 fsType: ext4

3. Постійні томи (PV) і запити на постійні томи (PVC):

# PV — це фактичні ресурси зберігання в кластері.  
apiVersion: v1  
kind: PersistentVolume  
metadata:  
 name: example-pv  
spec:  
 capacity:  
 storage: 500Mi  
 accessModes:  
 - ReadWriteOnce  
 persistentVolumeReclaimPolicy: Retain  
 storageClassName: manual  
 hostPath:  
 path: /mnt/data  

# PVC — це запити на зберігання, які подаються pods. Вони зв'язуються з доступними PV для зберігання.  
apiVersion: v1  
kind: PersistentVolumeClaim  
metadata:  
 name: myclaim  
spec:  
 accessModes:  
 - ReadWriteOnce  
 resources:  
 requests:  
 storage: 500Mi  

# зв'язати pod з PVC  

apiVersion: v1  
kind: Pod  
metadata:  
 name: example-pod  
spec:  
 containers:  
 - name: app-container  
 image: nginx  
 volumeMounts:  
 - mountPath: /data  
 name: data-volume  
 volumes:  
 - name: data-volume  
 persistentVolumeClaim:  
 claimName: myclaim

5. Класи зберігання:

StorageClass у Kubernetes — це шаблон конфігурації для динамічного створення Persistent Volumes (PV). Він визначає тип зберігання (наприклад, SSD, HDD), постачальника (наприклад, AWS EBS, Azure Disk) та параметри, такі як розмір або рівень продуктивності.

apiVersion: storage.k8s.io/v1  
kind: StorageClass  
metadata:  
 name: delayed-volume-sc  
provisioner: kubernetes.io/no-provisioner  
volumeBindingMode: WaitForFirstConsumer

Трюки:

  • якщо режими доступу в PV і PVC не однакові, вони не приєднуються.
  • після видалення PVC і pod, що був прив'язаний до цього PVC, PV буде в стані "release", а не "pending".

8. Мережі:

  1. Мережі Linux:
  • Перемикання (Switching): Осуществляє зв'язок всередині однієї LAN за допомогою MAC-адрес.
  • Перемикання в Linux дозволяє здійснювати зв'язок в одній LAN, створюючи міст інтерфейсів для зв'язку пристроїв на рівні MAC-адрес.
  • Маршрутизація (Routing): Осуществляє зв'язок між різними мережами за допомогою IP-адрес.
  • Маршрутизація в Linux забезпечує підключення різних мереж, пересилаючи пакети між ними на основі їх IP-адрес.
  • За замовчуванням шлюз (Default Gateway): Направляє трафік на невідомі адреси (за межами локальної мережі).
  • За замовчуванням шлюз в Linux гарантує, що трафік до невідомих адрес (наприклад, Інтернет) буде маршрутизовано до правильного upstream пристрою (зазвичай маршрутизатора).

Корисні команди:

  • ip link: Керує мережевими інтерфейсами.
  • ip addr: Відображає або змінює IP-адреси.

У відображених IP-адресах можна знайти eth0, lo...
Це означає наступне:

  • lo: Внутрішня комунікація (localhost).
  • eth0: Зв'язок з зовнішніми мережами.
  • flannel.1: Overlay-мережа Kubernetes для комунікації між pod на різних вузлах.
  • cni0: Міст для комунікації pod між собою в межах одного вузла.
  • veth*: Інтерфейси, що зв'язують pod з мережею вузла.
  • ip addr add 192.168.1.10/24 dev eth0: Призначення IP-адреси.
  • ip route: Керування маршрутами.
  • ip route add 192.168.1.0/24 via 192.168.2.1: Додавання маршруту.
  • dig і nslookup для усунення неполадок з DNS.
  • Команда netstat -nplt — швидкий і потужний спосіб перевірити всі активні TCP порти, що прослуховуються, та програми, пов'язані з ними.
  • ps -aux | grep kubelet | grep --color container-runtime-endpoint: команда для отримання endpoint контейнера kubelet.

2. Мережа Docker:

Типи мереж Docker:

  • None: Без мережі; контейнер ізольований.
  • Host: Використовує мережевий стек хоста.
  • Bridge: За замовчуванням; створює приватну віртуальну мережу для контейнерів.

Контейнери без мережі отримують мережу bridge за замовчуванням від Docker або Kubernetes.

Простір імен мережі для ізоляції мережевих ресурсів.

CNI (Container Network Interface):

  • CNI використовується для налаштування мережевих інтерфейсів контейнерів.
  • Kubernetes використовує плагіни CNI для забезпечення мережевої взаємодії pod.

3. Мережа Kubernetes:

Ми розгортаємо інструменти, такі як Weave Net, в Kubernetes або інших контейнеризованих середовищах для надання мережевих можливостей і з'єднаності для pod.

  1. Комунікація між pod: Забезпечує можливість зв'язку pod між собою на різних вузлах.
  2. Комунікація pod зі службами: Дозволяє pod доступати до служб, використовуючи стабільні кінцеві точки.
  3. Зв'язок з зовнішніми службами: Дозволяє зовнішнім клієнтам доступати до служб, що працюють у кластері.

Kubernetes слідує простій мережевій моделі:

  • Кожен pod отримує унікальну IP-адресу.
  • Pod можуть спілкуватися між собою без використання NAT (Network Address Translation).
  • Контейнери в pod поділяють одну і ту саму мережеву простір імен.

Основні інструменти та компоненти для мережі Kubernetes:

  1. CNI (Container Network Interface):
  • Керує мережею pod.
  • Приклади: Calico, Flannel, Weave Net, Cilium.

2. Kube-Proxy:

  • Реалізує мережу служб за допомогою керування правилами iptables або IPVS.
  • Забезпечує маршрутизацію трафіку до правильного pod на основі конфігурації служби.

3. Мережеві політики (Network Policies):

  • Керує потоком трафіку між pod за допомогою правил (наприклад, дозволити/блокувати трафік).
  • Приклад інструментів для виконання: Calico, Cilium.

4. Ingress:

  • Керує HTTP/S трафіком від зовнішніх клієнтів до служб у кластері.
  • Ingress Controllers (наприклад, NGINX Ingress, Traefik, HAProxy) реалізують правила Ingress.

5. Служби (Services):

  • Публікують групу pod як одну мережеву кінцеву точку.

  • Типи служб:

    • ClusterIP: Внутрішня комунікація в межах кластера.
    • NodePort: Публікує службу на статичному порту на кожному вузлі.
    • LoadBalancer: Створює балансувальник навантаження в хмарі.
    • ExternalName: Прив'язує службу до зовнішнього DNS-імені.
      Ось що вони означають:

  • lo: Внутрішня комунікація (localhost).

  • eth0: Зв'язок з зовнішніми мережами.

  • flannel.1: Overlay-мережа Kubernetes для комунікації між pod на різних вузлах.

  • cni0: Міст для комунікації pod між собою в межах одного вузла.

  • veth*: Інтерфейси, що зв'язують pod з мережею вузла.

  • ip addr add 192.168.1.10/24 dev eth0: Призначення IP-адреси.

  • ip route: Керування маршрутами.

  • ip route add 192.168.1.0/24 via 192.168.2.1: Додавання маршруту.

  • dig і nslookup для усунення неполадок з DNS.

  • Команда netstat -nplt — швидкий і потужний спосіб перевірити всі активні TCP порти, що прослуховуються, та програми, пов'язані з ними.

  • ps -aux | grep kubelet | grep --color container-runtime-endpoint: команда для отримання endpoint контейнера kubelet.

2. Мережа Docker:

Типи мереж Docker:

  • None: Без мережі; контейнер ізольований.
  • Host: Використовує мережевий стек хоста.
  • Bridge: За замовчуванням; створює приватну віртуальну мережу для контейнерів.

Контейнери без мережі отримують мережу bridge за замовчуванням від Docker або Kubernetes.

Простір імен мережі для ізоляції мережевих ресурсів.

CNI (Container Network Interface):

  • CNI використовується для налаштування мережевих інтерфейсів контейнерів.
  • Kubernetes використовує плагіни CNI для забезпечення мережевої взаємодії pod.

3. Мережа Kubernetes:

Ми розгортаємо інструменти, такі як Weave Net, в Kubernetes або інших контейнеризованих середовищах для надання мережевих можливостей і з'єднаності для pod.

  1. Комунікація між pod: Забезпечує можливість зв'язку pod між собою на різних вузлах.
  2. Комунікація pod зі службами: Дозволяє pod доступати до служб, використовуючи стабільні кінцеві точки.
  3. Зв'язок з зовнішніми службами: Дозволяє зовнішнім клієнтам доступати до служб, що працюють у кластері.

Kubernetes слідує простій мережевій моделі:

  • Кожен pod отримує унікальну IP-адресу.
  • Pod можуть спілкуватися між собою без використання NAT (Network Address Translation).
  • Контейнери в pod поділяють одну і ту саму мережеву простір імен.

Основні інструменти та компоненти для мережі Kubernetes:

  1. CNI (Container Network Interface):
  • Керує мережею pod.
  • Приклади: Calico, Flannel, Weave Net, Cilium.

2. Kube-Proxy:

  • Реалізує мережу служб за допомогою керування правилами iptables або IPVS.
  • Забезпечує маршрутизацію трафіку до правильного pod на основі конфігурації служби.

3. Мережеві політики (Network Policies):

  • Керує потоком трафіку між pod за допомогою правил (наприклад, дозволити/блокувати трафік).
  • Приклад інструментів для виконання: Calico, Cilium.

4. Ingress:

  • Керує HTTP/S трафіком від зовнішніх клієнтів до служб у кластері.
  • Ingress Controllers (наприклад, NGINX Ingress, Traefik, HAProxy) реалізують правила Ingress.

5. Служби (Services):

  • Публікують групу pod як одну мережеву кінцеву точку.
  • Типи служб:
    • ClusterIP: Внутрішня комунікація в межах кластера.
    • NodePort: Публікує службу на статичному порту на кожному вузлі.
    • LoadBalancer: Створює балансувальник навантаження в хмарі.
    • ExternalName: Прив'язує службу до зовнішнього DNS-імені.
      Шлях до JSON (JSON Path):

JSONPath — потужна мова запитів, що використовується в Kubernetes для фільтрації та форматування результатів команд kubectl.

Основи синтаксису:

  • .: Доступ до дочірніх полів (наприклад, .metadata.name).
  • []: Індексація масиву (наприклад, .items[0].metadata.name).
  • [*]: Вайлдкард для масивів (наприклад, .items[*].metadata.name).
  • @: Відноситься до поточного об'єкта, який обробляється.
  • {}: Використовується для створення власних шаблонів виводу (наприклад, {.metadata.name}).
  • [?()]: Фільтрує масив

Звичні сценарії використання:

# отримати вузли у форматі JSON  
kubectl get nodes -o json   
# отримати всі імена pod  
kubectl get pods -o jsonpath='{.items[*].metadata.name}'  
# Користувацькі стовпці  
kubectl -n admin2406 get deployment -o custom-columns=DEPLOYMENT:.metadata.name,CONTAINER_IMAGE:.spec.template.spec.containers[].image,READY_REPLICAS:.status.readyReplicas,NAMESPACE:.metadata.namespace --sort-by=.metadata.name   
kubectl get pods -o jsonpath='{range .items[*]}{"Name: "}{.metadata.name}{" Status: "}{.status.phase}{"\n"}{end}'  
kubectl get pods -o jsonpath='{range .items[*]}{"Pod: "}{.metadata.name}{" | Environment: "}{.metadata.labels.env}{"\n"}{end}'

**Шлях до JSON (JSON Path):**

JSONPath — потужна мова запитів, що використовується в Kubernetes для фільтрації та форматування результатів команд `kubectl`.

## Основи синтаксису:

- `.`: Доступ до дочірніх полів (наприклад, `.metadata.name`).
- `[]`: Індексація масиву (наприклад, `.items[0].metadata.name`).
- `[*]`: Вайлдкард для масивів (наприклад, `.items[*].metadata.name`).
- `@`: Відноситься до поточного об'єкта, який обробляється.
- `{}`: Використовується для створення власних шаблонів виводу (наприклад, `{.metadata.name}`).
- `[?()]`: Фільтрує масив

Звичні сценарії використання:

отримати вузли у форматі JSON

kubectl get nodes -o json

отримати всі імена pod

kubectl get pods -o jsonpath='{.items[*].metadata.name}'

Користувацькі стовпці

kubectl -n admin2406 get deployment -o custom-columns=DEPLOYMENT:.metadata.name,CONTAINERIMAGE:.spec.template.spec.containers[].image,READYREPLICAS:.status.readyReplicas,NAMESPACE:.metadata.namespace --sort-by=.metadata.name
kubectl get pods -o jsonpath='{range .items[]}{"Name: "}{.metadata.name}{" Status: "}{.status.phase}{"\n"}{end}'
kubectl get pods -o jsonpath='{range .items[]}{"Pod: "}{.metadata.name}{" | Environment: "}{.metadata.labels.env}{"\n"}{end}'

Перекладено з: Kubernetes Essentials: Cheat Sheet for Beginners and Pros

Вам також може сподобатися

Топ 10 пакетів Laravel для побудови мікросервісів
TRIPLESTRENGTH атакує хмарні платформи за допомогою криптомайнингу та програм-вимагачів
Node.js 4: Підключення до бази даних

Leave a Reply

Your email address will not be published. Required fields are marked *