Это старая версия документа!
Контроллер развертывания (Deployment controller) предоставляет возможность декларативного обновления для объектов типа поды (Pods) и наборы реплик (ReplicaSet)
Кроме обычных, обязательных полей («apiVersion», «kind» и «metadata»), должна присутствовать секция «.spec«
В секции ».spec» обязательно должна присутствовать вложенная секция «.spec.template» - шаблон пода
Кроме обязательных полей в секции «template» нужно указать метки, «.spec.template.metadata.labels» и политику перезапуска «.spec.template.spec.restartPolicy» (хотя тут вроде единственное значение Always и так дефолтное)
«.spec.labels» - пары ключ-значение, добавляемые к объектам. Можно использовать для группировки и выбора подмножеств объектов. Могут быть добавлены к объектам во время создания и изменены в любое время
"metadata": { "labels": { "key1" : "value1", "key2" : "value2" } }
Поле «.spec.replicas» указывает сколько экземпляров должно быть запущено, по умолчанию 1
Поле «.spec.selector» необязательное (?), если указано то должно соответствовать лейблам указанным выше, иначе проигнорируется
«.spec.strategy» стратегия обновления старых подов новыми. Допустимо «Recreate» или «RollingUpdate». В первом случае все удаляются, затем создаются заново, во втором планомерно, дефолт
Для второго случая есть доп параметры «maxUnavailable» (макс кол-во подов которое может быть недоступно) и «maxSurge» (макс кол-во разбухания кол-ва для мягкого обновления)
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
# Создаем объект (пар-р "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
Поле «imagePullPolicy» указывает политику скачивания образов, варианты «IfNotPresent» и «Always» (есть еще latest но вроде не рекоммендуется)
K8s поддерживает несколько способов передачи кредлов для авторизации, от google, aws и тд. один из вариантов это указать «ImagePullSecrets» в описании пода
kubectl create secret docker-registry myregkey --docker-server=REG_URL --docker-username=USER --docker-password=PASSWD --docker-email=EMAIL
Либо вариант с артефактом
apiVersion: v1 kind: Secret metadata: name: myreskey namespace: awesomeapps data: .dockerconfigjson: <base64-string> type: kubernetes.io/dockerconfigjson
Применение
apiVersion: v1 kind: Pod metadata: name: foo namespace: awesome spec: containers: - name: foo image: myreg/awesome:v1 imagePullSecrets: - name: myregkey
Есть два типа ресурсов: память и проц
Есть два типа параметров: «Requests» и «Limit». Первое это требования для планировщика к нодам размещения, второе это жесткое ограничение для контейнера
В политике работы с ресурсами, поды делятся на три класса:
resources: limits: cpu: "2" memory: 2Gi requests: cpu: "2" memory: 2Gi
С точки зрения кибера, ограничения по памяти считаются «несжимаемыми», поэтому при превышении троттлинг невозможен и ядро будет агрессивно очищать кэш страниц и может быть вызван «OOM killer»
Единица подразумевает один процессорное ядро предоставляемое ОС (вне зависимости физическое оно или виртуальное)
В отличии от памяти является «сжимаемым» ограничением, поэтому при превышении начинается «CPU Throttling» - снижение частоты процессора и сл-но снижение производительности
На самом деле указывается лишь время использования процессора (CPU time) на всех доступных ядрах ноды, под будет использовать все доступные на ноде ядра, в пределах указанного времени использования
Например на ноде 8 ядер, если в лимите указать 4 то контейнер будет использовать эквивалент 4х ядер на всех 8ми, топишь в данном случае 50%
Варианты указания (эквивалент целого ядра и два варианта по половине)
resources: limits: cpu: "1" --- resources: limits: cpu: "0.5" --- resources: limits: cpu: "500m"
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