zxcx

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

===== Deployments =====
Контроллер развертывания (Deployment controller) предоставляет возможность декларативного обновления для объектов типа поды (Pods) и наборы реплик (ReplicaSet)\\


<details>
<summary>:!: Мат часть</summary>
Кроме обычных, обязательных полей ("apiVersion", "kind" и "metadata"), должна присутствовать секция ".spec"\\

В секции ".spec" обязательно должна присутствовать вложенная секция ".spec.template" - шаблон пода\\
Кроме обязательных полей в секции "template" нужно указать метки, ".spec.template.metadata.labels" и политику перезапуска ".spec.template.spec.restartPolicy" (хотя тут вроде единственное значение Always и так дефолтное)\\

:?: ".spec.labels" - пары ключ-значение, добавляемые к объектам. Можно использовать для группировки и выбора подмножеств объектов. Могут быть добавлены к объектам во время создания и изменены в любое время\\
<code yaml>
"metadata": {
  "labels": {
    "key1" : "value1",
    "key2" : "value2"
  }
}
</code>


Поле ".spec.replicas" указывает сколько экземпляров должно быть запущено, по умолчанию 1\\
Поле ".spec.selector" необязательное (?), если указано то должно соответствовать лейблам указанным выше, иначе проигнорируется\\

".spec.strategy" стратегия обновления старых подов новыми. Допустимо "Recreate" или "RollingUpdate". В первом случае все удаляются, затем создаются заново, во втором планомерно, дефолт\\
Для второго случая есть доп параметры "maxUnavailable" (макс кол-во подов которое может быть недоступно) и "maxSurge" (макс кол-во разбухания кол-ва для мягкого обновления)\\
</details>



<details>
<summary>:!: Пример (nginx)</summary>
<code yaml>
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
  	app: nginx
spec:
  replicas: 3
  selector:
  	matchLabels:
  		app: nginx
  template:
  	metadata:
  		labels:
  			app: nginx
  	spec:
  		containers:
  			- name: nginx
  				image: nginx:1.7.9
  				ports:
  					- containerPort: 80
</code>
	* Имя деплоймента "metadate: name nginx-deployment"
	* Три экземпляра пода (replicas)
	* В поле селектора указано, как деплоймент обнаружит, какими подами нужно управлять
	* В описании шаблона пода (template) указано "запустить докер контейнер nginx", поду будет присвоена указанная метка
	* Деплоймент открывает 80й порт контейнера, так что контейнер может отправлять и принимать трафик
</details>



<details>
<summary>:!: Работа в консоли с примером выше</summary>
<code bash>
	# Создаем объект (пар-р "record" для сохранения истории)
kubectl create -f nginx-deployment.yml --record


	# Просмотр деплойментов
kubectl get deployments


	# Текущий статус развертывания
kubectl rollout status deployment/nginx-deployment


	# Деплойментом создается набор реплик (ReplicaSet)
kubectl get rs


	# Увидеть какие поды к какому набору относятся, можно по авто-лейблам с хешем
kubectl get pods --show-labels


	# Применение обновлений
kubectl apply -f nginx-deployment.yml


	# Откат к предыдущей версии деплоймента (если есть в истории (--record))
kubectl rollout history deployment/nginx-deployment
		# Просмотр конкретной версии 
		kubectl rollout history deployment/nginx-deployment --revision=2

kubectl rollout undo deployment/nginx-deployment
kubectl rollout undo deployment/nginx-deployment --to-revision=2


	# Скейлинг (увеличение/уменьшение) кол-ва подов в рантайме
kubectl scale deployment nginx-deployment --replicas=10


	# Горизонтальное масштабирование подов (HPA) (если включено в кластере)
kubectl autoscale deployment nginx-deployment --min=10 --max=15 --cpu-percent=80
</code>
</details>



==== Docker Registry ====
Поле "imagePullPolicy" указывает политику скачивания образов, варианты "IfNotPresent" и "Always" (есть еще latest но вроде не рекоммендуется)\\


=== Private Registry ===
K8s поддерживает несколько способов передачи кредлов для авторизации, от google, aws и тд. один из вариантов это указать "ImagePullSecrets" в описании пода\\


<details>
<summary>:!: ImagePullSecrets</summary>

<code bash>
kubectl create secret docker-registry myregkey --docker-server=REG_URL --docker-username=USER --docker-password=PASSWD --docker-email=EMAIL
</code>

Либо вариант с артефактом
<code yaml>
apiVersion: v1
kind: Secret
metadata:
	name: myreskey
	namespace: awesomeapps
data:
	.dockerconfigjson: <base64-string>
type: kubernetes.io/dockerconfigjson
</code>


Применение
<code yaml>
apiVersion: v1
kind: Pod
metadata:
	name: foo
	namespace: awesome
spec:
	containers:
		- name: foo
			image: myreg/awesome:v1
	imagePullSecrets:
		- name: myregkey
</code>
</details>




==== Resources ====
Есть два типа ресурсов: память и проц\\
Есть два типа параметров: "Requests" и "Limit". Первое это требования для планировщика к нодам размещения, второе это жесткое ограничение для контейнера\\

В политике работы с ресурсами, поды делятся на три класса:
  * "Guaranteed" (гарантированный) - заданы оба параметра и равны (request и limits), наиболее приоритетный для планировщика, при дефиците трогается самый последний
  * "Burstable" (взрывоопасный) - второй по приоритету, является таким если не задан кто то или пар-ры не равны 
  * "Best-effort" (максимально эффективный) - если не установлено то и другое


<code yaml>
resources:
  limits:
    cpu: "2"
    memory: 2Gi
  requests:
    cpu: "2"
    memory: 2Gi
</code>


=== Memory ===
С точки зрения кибера, ограничения по памяти считаются "несжимаемыми", поэтому при превышении троттлинг невозможен и ядро будет агрессивно очищать кэш страниц и может быть вызван "OOM killer"\\ 



=== CPU ===
Единица подразумевает один процессорное ядро предоставляемое ОС (вне зависимости физическое оно или виртуальное)\\

В отличии от памяти является "сжимаемым" ограничением, поэтому при превышении начинается "CPU Throttling" - снижение частоты процессора и сл-но снижение производительности\\

На самом деле указывается лишь время использования процессора (CPU time) на всех доступных ядрах ноды, под будет использовать все доступные на ноде ядра, в пределах указанного времени использования\\

Например на ноде 8 ядер, если в лимите указать 4 то контейнер будет использовать эквивалент 4х ядер на всех 8ми, топишь в данном случае 50%\\

Варианты указания (эквивалент целого ядра и два варианта по половине)
<code yaml>
resources:
  limits:
    cpu: "1"
    memory: "1G"
---
resources:
  limits:
    cpu: "0.5"
    memory: "0.5G"
---
resources:
  limits:
    cpu: "500m"
    memory: "500M"
</code>



==== Пробы приложения k8s ====
Описываются в деплойменте, в блоке "containers"\\
У обоих есть параметры: "initialDelaySeconds", "periodSeconds", "timeoutSeconds", "successThreshold", "failureThreshold", "terminationGracePeriodSeconds"\\


=== liveness ===
Проверка "живучести" контейнера, отвечает "да" или "нет" на вопрос запущено ли приложение\\
По умолчанию, для этого оценивается процесс с PID 1, на основании его состояния делаются такие выводы, в случае фейла, среда перезапускает под\\


<details>
<summary>:!: Примеры</summary>
<code yaml>
    spec:
      containers:
      - image: quay.io/<username>/my-application-nginx:latest
        name: my-application-nginx
        imagePullPolicy: Always
        ports:
        - containerPort: 8443
          protocol: TCP
        livenessProbe:
          exec:
            command:
            - /bin/sh
            - -c
            - "[ -f /run/nginx.pid ] && ps -A | grep nginx"
          initialDelaySeconds: 10
          periodSeconds: 5
      - image: quay.io/<username>/my-application-app-server:latest
        name: my-application-app-server
        imagePullPolicy: Always
        ports:
        - containerPort: 8080
          protocol: TCP
        livenessProbe:
          exec:
            command:
            - /bin/sh
            - -c
            - "/usr/bin/my-application-web --alive"
          initialDelaySeconds: 10
          periodSeconds: 5
</code>
</details>



=== readiness ===
Проверка готовности приложения к принятию сетевого трафика, эта проверка для того чтобы отделить период инициализации приложения\\
При фейле, среда выводит под из балансера, но ничего не делает с самим подом, считает что приложение скоро само придет в статус готовности\\

<details>
<summary>:!: Примеры</summary>
<code yaml>
    spec:
      containers:
      - image: quay.io/<username>/my-application-nginx:latest
        name: my-application-nginx
        imagePullPolicy: Always
        ports:
        - containerPort: 8443
          protocol: TCP
        readinessProbe:
          httpGet:
            scheme: HTTPS
            path: /index.html
            port: 8443
          initialDelaySeconds: 10
          periodSeconds: 5

      - image: quay.io/<username>/my-application-app-server:latest
        name: my-application-app-server
        imagePullPolicy: Always
        ports:
        - containerPort: 8080
          protocol: TCP
        readinessProbe:
          httpGet:
            scheme: HTTP
            path: /healthz
            port: 8080
          initialDelaySeconds: 10
          periodSeconds: 5
</code>
</details>


==== Завершение приложения ====
**terminationGracePeriodSecond** - макс период который k8s ожидает после отправки SIGTERM, перед отправкой "SIGKILL" и принудительным завершением.\\
Контейнеру дается это время для корректного, самостоятельного завершения, дается "не больше" этого времени\\
Задается в блоке "containers" в деплойменте, по умолчанию 30 сек\\




=== preStop ===
Спец команда или HTTP-запрос, который отправляется контейнерам в поде\\
А, похоже это альтернатива сигнала "SIGTERM" для приложения, если оно некорректно завершается от этого сигнала и нет возможности править само приложение\\
Хотя даже не альтернатива а доп код, для выполнения каких либо действий\\





==== Приоритет подов ====
В отличии от приоритета Linux, который задает как часто процесс будет исполняться, приоритет k8s задает в каком порядке поды будут убиваться при дефиците ресурсов или недостатке ресурсов при размещении новых подов, сравнивается приоритет нового пода с существующими\\

Приоритет задается на под, целое число, чем больше тем выше приоритет\\


=== PriorityClass ===
Это объект кластера, не привязываемый к namespace. Присваивает имя целочисленному значению приоритета\\
Есть системные классы, созданные для служебных объектов\\

Есть доп поля:\\
  * globalDefault - задает этот класс классом по умолчанию для всех подов
  * description - описание
  * preemptionPolicy - доп политика поведения (см гугл) 


<details>
<summary>:!: Примеры</summary>
Манифест класса
<code yaml>
apiVersion: scheduling.k8s.io/v1
kind: PriorityClass
metadata:
  name: high-priority
value: 1000000
globalDefault: false
preemptionPolicy: Never
description: "The maximal priority on the cluster"
</code>

<code bash>
kubectl get pc
</code>

Применение
<code yaml>
apiVersion: v1
kind: Pod
metadata:
  name: openresty
  labels:
    app: openresty
spec:
  containers:
  - name: openresty
    image: openresty:latest
    imagePullPolicy: IfNotPresent
  priorityClassName: high-priority
</code>
</details>








==== PodDisruptionBudget ====

Позволяет контролировать какое кол-во подов приложения могут быть недоступны в момент времени. Т.е позволяет держать запущенными минимально необходимое кол-во подов приложения\\
:!: PDB помогает только в случае добровольного прерывания, k8s не даст остановить под пока указанная политика не будет выполнена, в случае непредвиденного сбоя, эта ф-я ес-но не поможет\\



<details>
<summary>:!: Примеры</summary>
<code yaml>
apiVersion: policy/v1beta1
kind: PodDisruptionBudget
metadata:
  name: app-pdb
spec:
  maxUnavailable: 1
  selector:
    matchLabels:
      app: app
</code>


<code yaml>
apiVersion: policy/v1beta1
kind: PodDisruptionBudget
metadata:
  name: app-pdb
spec:
  minAvailable: 80%
  selector:
    matchLabels:
      app: app
</code>
</details>





==== Примеры ====

<details>
<summary>:!: Именованные порты сервиса</summary>
<code yaml>
apiVersion: v1
kind: Pod
metadata:
  name: named-port-pod
  labels:
    app: named-port-pod
spec:
  containers:
    - name: echoserver
      image: gcr.io/google_containers/echoserver:1.4
      ports:
      - name: pod-custom-port
        containerPort: 8080
---
apiVersion: v1
kind: Service
metadata:
  name: named-port-svc
spec:
  ports:
    - port: 80
      targetPort: pod-custom-port
  selector:
    app: named-port-pod
</code>
</details>




<details>
<summary>:!: </summary>

<code yaml>
</code>
</details>
zxcx

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

Инструменты сайта

Инструменты страницы
