zxcx

Мат часть

Кроме обычных, обязательных полей («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» (макс кол-во разбухания кол-ва для мягкого обновления)

Пример (nginx)

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

• Имя деплоймента «metadate: name nginx-deployment»
• Три экземпляра пода (replicas)
• В поле селектора указано, как деплоймент обнаружит, какими подами нужно управлять
• В описании шаблона пода (template) указано «запустить докер контейнер nginx», поду будет присвоена указанная метка
• Деплоймент открывает 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

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