Основи Kubernetes: Шпаргалка для початківців та професіоналів

pic

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

Вступ:

  • Цей блог створений для початківців, які хочуть зрозуміти Kubernetes, а також для тих, хто готується до сертифікації CKA і хоче освіжити знання про основні концепти та команди перед тестуванням своїх навичок. Це не замінює офіційні курси. Вся інформація, що подається, надихнута курсом "Підготовка до сертифікації Certified Kubernetes Administrator з живими практичними тестами прямо у вашому браузері — CKA" від Mumshad Mannambeth, що доступний на KodeKloud Labs.

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

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

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

  • *Компоненти майстра:* kube-apiserver, controller manager, кластер ETCD, kube-scheduler
  • *Компоненти робочих вузлів:* kubelet, kube-proxy, контейнерний 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  
~

**Namespaces:**

- Логічні розділи всередині кластера для організації та ізоляції ресурсів.
- Загальні команди:

kubectl create namespace
kubectl get namespaces
kubectl get ns --no-headers | wc -l #щоб дізнатися кількість просторів імен
kubectl get --all-namespaces #отримати всі сервіси в усіх просторах імен
kubectl delete 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:

  • Визначає дозволи в межах конкретного простору імен.
  • Загальні команди:
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 у межах конкретного простору імен.
  • Загальні команди:
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, пам'ять) в межах просторів імен.
  • Загальні команди:
kubectl create -f   
kubectl get resourcequota  
kubectl describe resourcequota   
kubectl delete resourcequota

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

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

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

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

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 і Tolerations (Забруднення та Допустимість):

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. Селектори вузлів (Node Selectors):

Селектори вузлів дозволяють 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):

Афінність вузлів є більш розширеною версією селекторів вузлів. Вона дозволяє встановлювати м'які (бажані) та жорсткі (необхідні) правила для розміщення 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. Вимоги до ресурсів (Resource Requirements):

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

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

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

  • Один гіперпотік апаратного процесора (якщо використовується bare metal).
  • Один віртуальний процесор, якщо застосовуються віртуалізовані платформи (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 (Static 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

Поради :

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

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

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

Важливими метриками є кількість вузлів у кластері, скільки pod працює і здорові, а також показники продуктивності, такі як CPU, пам'ять, мережа, диск I/O тощо.

# створити 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. Rolling Updates, Rollbacks та Versioning:
kubectl apply -f deployment.yaml (створюється нова версія розгортання)  
kubectl set image deployment/ = або kubectl apply -f (rolling update)  
kubectl rollout undo deployment/ (відкат)  
kubectl rollout status (показати статус оновлень)  
kubectl rollout history (показати версії оновлень)

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

strategy:  
 type: RollingUpdate

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

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

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

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

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

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


env:  
 - name: APP_COLOR  
 value: pink  


### ConfigMap  

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

#### Конфігурація 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: 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=DB_Host=sql01 --from-literal=DB_User=root --from-literal=DB_Password=password123  


#### Використання секретів у 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
  1. Масштабування застосунку:
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  

### Ініціалізаційний контейнер  

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 : відключити ноду за допомогою kubectl drain
  • крок 2: виконати оновлення ОС або обслуговування ноди
  • крок 3 : протестувати систему
  • крок 4: дозволити знову планувати навантаження на ноді за допомогою *kubectl uncordon *

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

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

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

3.
Cluster Upgrade Process :

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

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

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

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

  • Ключові кроки для kubeadm upgrade :
# Перевірка сумісності поточної версії:  
kubeadm upgrade plan  
# Оновлення контрольної плати:  
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:  
# Якщо pod 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: Контекст поєднує кластер, користувача та простір імен (namespace). Використовуйте команду 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. Доступність (хто може отримати доступ до кластера):

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

  • ID користувача/Пароль (не рекомендується).
  • Ім’я користувача та токени.
  • Сертифікати.
  • Інтеграція з 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 (Контроль доступу на основі ролей):

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

Інші моделі:

Авторизація за допомогою Node.

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  

# Cluster role  

kubectl get clusterroles  
kubectl get clusterrolebinding

Облікові записи сервісів

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

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

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

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

Політика мережі:

Політика мережі (Network Policy) в 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 серверу: 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:

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

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

Директорії файлової системи:

Docker зберігає дані в таких директоріях:

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

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

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

2. Томі в 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. Постійні томи (PVs) та запити на постійні томи (PVCs):

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

# PVCs — це запити на зберігання, які роблять pods. Вони зв'язуються з доступними PVs для зберігання.  
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 — це шаблон конфігурації для створення постійних томів (PVs) динамічно. Він визначає тип зберігання (наприклад, 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 забезпечує перенаправлення трафіку до невідомих напрямків (наприклад, в Інтернет) на відповідний зовнішній пристрій (зазвичай маршрутизатор).

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

  • ip link: Керування мережевими інтерфейсами.
  • ip addr: Перегляд або зміна IP-адрес.

В відображених IP-адресах ви можете знайти eth0, lo...
текст перекладу
Ось як це розуміється:

  • lo: Внутрішня комунікація (localhost).
  • eth0: Комунікація з зовнішніми мережами.
  • flannel.1: Overlay-мережа Kubernetes для комунікації між подами на різних вузлах.
  • cni0: Міст для комунікації між подами в межах одного вузла.
  • veth*: Інтерфейси, що з'єднують поди з мережею вузла.
  • 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 для забезпечення мережевої взаємодії між подами.

3. Мережі Kubernetes:

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

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

Kubernetes дотримується простого мережевого моделі:

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

Ключові інструменти та компоненти мережі Kubernetes

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

2. Kube-Proxy:

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

3. Політики мережі (Network Policies):

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

4. Ingress:

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

5. Сервіси (Services):

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

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

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

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

Типові випадки використання:

# отримати вузли у форматі JSON  
kubectl get nodes -o json   
# отримати всі імена подів  
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}'




Перекладено з: [Kubernetes Essentials: Cheat Sheet for Beginners and Pros](https://medium.com/@yahya.mlaouhi/kubernetes-essentials-cheat-sheet-for-beginners-and-pros-44916273d778)

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

Що таке коллбек-функція (callback function) в javascript?
Найкращі місця для пошуку наборів даних для ваших проектів
Прив’язка класів

Leave a Reply

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