Дополнительные сервисы

Ingress controller

Внимание

Использование версий Kubernetes младше 1.25.x сопряжено с рисками из-за уязвимости в ingress-controller. Если вам необходим Ingress Controller, рекомендуем выбирать версию Kubernetes 1.25 и старше.

Если при создании кластера вы выбрали опцию Ingress Controller, то в кластере будет развёрнут дополнительный рабочий узел, который позволит настраивать доступ к сервисам, запущенным внутри кластера, через единую точку входа. Чтобы сервис стал доступен через Ingress Controller, нужно создать ресурс типа Ingress.

Ниже приведён пример конфигурации кластера с Ingress Controller Elastic IP: 185.12.31.21. В этом кластере развёрнут сервис, к которому необходимо предоставить доступ по адресу http://185.12.31.211/example.

Пример конфигурации сервиса в кластере

apiVersion: v1
kind: Pod
metadata:
  name: example
  labels:
    k8s-app: example
spec:
  containers:
  - name: example-app
    image: quay.io/coreos/example-app:v1.0
  imagePullSecrets:
  - name: regcred

---
kind: Service
apiVersion: v1
metadata:
  name: example-service
  namespace: default
spec:
  selector:
    k8s-app: example
  ports:
  - protocol: TCP
    port: 80
  type: LoadBalancer

Чтобы он стал доступен по адресу http://185.12.31.211/example, необходимо открыть порт 80 и создать конфигурацию Ingress:

Для версии 1.21 и младше

Пример конфигурации Ingress

apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: example-ingress
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
spec:
  rules:
  - http:
      paths:
      - path: /example
        pathType: Prefix
        backend:
          serviceName: example-service
          servicePort: 80

Для версии 1.22 и старше

Пример конфигурации Ingress

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: example-ingress
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
spec:
  rules:
  - http:
      paths:
      - path: /example
        pathType: Prefix
        backend:
          service:
            name: example-service
            port:
              number: 80

Настройка HTTPS на Ingress Controller

Эта инструкция обеспечит безопасность сервисов, которые обрабатывают чувствительные данные, поскольку HTTPS-соединения являются важной частью безопасного веб-сервиса и гарантируют конфиденциальность и целостность данных.

Для использования HTTPS на вашем Ingress Controller вам необходимо иметь:

• Доменное имя для Elastic IP, который был назначен для Ingress Controller.

• Закрытый ключ TLS и сертификат.

В данном примере мы будем дополнять конфигурацию Ingress из инструкции, описанной выше.

Чтобы защитить Ingress, укажите Kubernetes Secret, который содержит закрытый ключ TLS tls.key и сертификат tls.crt.

Пример конфигурации Kubernetes Secret

apiVersion: v1
kind: Secret
metadata:
  name: tls-secret
  namespace: ingress-nginx
data:
  tls.crt: base64 encoded cert
  tls.key: base64 encoded key
type: kubernetes.io/tls

TLS не будет работать с правилом по умолчанию, поэтому в конфигурацию Ingress необходимо внести следующие изменения:

Для версии 1.21 и младше

Необходимые изменения в конфигурации Ingress

apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: example-ingress
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
spec:
  tls:
    - hosts:
      - "Your Domain"
      secretName: tls-secret
  rules:
  - host: "Your Domain"
    http:
      paths:
      - path: /example
        pathType: Prefix
        backend:
          serviceName: example-service
          servicePort: 80

Для версии 1.22 и старше

Необходимые изменения в конфигурации Ingress

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: example-ingress
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
spec:
  tls:
    - hosts:
      - "Your Domain"
      secretName: tls-secret
  rules:
  - host: "Your Domain"
    http:
      paths:
      - path: /example
        pathType: Prefix
        backend:
          service:
            name: example-service
            port:
              number: 80

После применения этих конфигураций вы сможете использовать защищённый протокол HTTPS для Ingress Controller.

EBS-провайдер

Если при создании кластера вы выбрали опцию EBS-провайдер, то в кластер будет установлен сервис, который позволяет Kubernetes управлять дисками в Облаке КРОК и использовать их в качестве Persistent Volumes в Kubernetes. Сервис способен работать как с существующими дисками, так и создавать их самостоятельно.

Все созданные диски будут доступны в подразделе Диски раздела Хранение данных.

EBS-провайдер поддерживает следующие версии Kubernetes: 1.27.3, 1.26.6, 1.25.11, 1.22.3, 1.20.9 и 1.18.2.

Для использования дисков в качестве Persistent Volumes в Kubernetes необходимо описать следующие конфигурации:

1. Storage class — описание класса хранилища. Подробную информация о Storage class можно получить в официальной документации.

2. Persistent Volume — описание непосредственно подключаемого диска и его характеристик.

3. Persistent Volume Claim — запрос на Persistent Volume, в котором описываются требуемые характеристики диска. Если Persistent Volume с такими (или лучшими) характеристиками найден, Kubernetes будет использовать его.

Сценарий использования существующего диска в Облаке КРОК

Для использования существующего диска в Облаке КРОК в конфигурации Persistent Volume в поле driver необходимо указать ebs.csi.aws.com, а в поле volumeHandle указать volume ID:

Пример использования существующего диска

apiVersion: v1
kind: PersistentVolume
metadata:
  name: static-pv
spec:
  capacity:
    storage: 48Gi
  volumeMode: Filesystem
  accessModes:
    - ReadWriteOnce
  storageClassName: ebs-static
  csi:
    driver: ebs.csi.aws.com
    volumeHandle: vol-9991C120
    fsType: xfs
  nodeAffinity:
    required:
      nodeSelectorTerms:
      - matchExpressions:
        - key: topology.ebs.csi.aws.com/zone
          operator: In
          values:
          - ru-msk-vol51

Важно, чтобы в секции nodeAffinity (в последней строке примера выше) была указана зона доступности, в которой создан указанный диск, а сам диск и экземпляр, к которому предполагается присоединение, находились в одной зоне доступности, иначе присоединение диска к экземпляру будет невозможным.

В дальнейшем для использования этого диска достаточно создать Persistent Volume Claim, отвечающий характеристикам диска и использовать его в необходимом ресурсе. При этом важно, чтобы storageClassName этого Claim совпадал с указанным в Persistent Volume.

Пример конфигурации для создания пода с диском размером 20 ГиБ

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: static-claim
spec:
  accessModes:
    - ReadWriteOnce
  storageClassName: ebs-static
  resources:
    requests:
      storage: 20Gi
---
apiVersion: v1
kind: Pod
metadata:
  name: app
spec:
  containers:
  - name: app
    image: centos
    command: ["/bin/sh"]
    args: ["-c", "while true; do echo $(date -u) >> /data/out.txt; sleep 5; done"]
    volumeMounts:
    - name: persistent-storage
      mountPath: /data
  volumes:
  - name: persistent-storage
    persistentVolumeClaim:
      claimName: static-claim

Сценарий с созданием новых дисков

Для создания новых дисков в конфигурации Storage class в поле provisioner нужно указать ebs.csi.aws.com. В поле parameters можно указать параметры создаваемых дисков:

Параметр	Возможные значения	Значение по умолчанию	Описание
csi.storage.k8s.io/fsType	xfs, ext2, ext3, ext4	ext4	Файловая система, в которую будет отформатирован создаваемый диск
type	io2, gp2, st2	gp2	Тип диска
iopsPerGB			IOPS на гибибайт создаваемого диска. Необходим при указании дисков типа io2

В случае отсутствия какого-либо параметра будет использовано значение по умолчанию.

Пример конфигурации

kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
  name: ebs-dynamic
provisioner: ebs.csi.aws.com
volumeBindingMode: WaitForFirstConsumer
reclaimPolicy: Retain
parameters:
  csi.storage.k8s.io/fstype: xfs
  type: io2
  iopsPerGB: "50"
  encrypted: "true"

При создании новых дисков Persistent Volume будет создан по запросу Persistent Volume Claim.

Persistent Volume в Облаке КРОК поддерживает accessModes только со значением ReadWriteOnce для EBS, ссылка на документацию kubernetes.

Пример запроса для создания пода с диском размером 4 ГиБ

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: ebs-dynamic-claim
spec:
  accessModes:
    - ReadWriteOnce
  storageClassName: ebs-dynamic
  resources:
    requests:
      storage: 4Gi

При создании пода, использующего этот запрос, Kubernetes автоматически создаст диск в облаке размером 4 ГиБ с характеристиками, указанными в storage class и присоединит его к этому поду.

Пример конфигурации пода

apiVersion: v1
kind: Pod
metadata:
  name: app
spec:
  containers:
  - name: app
    image: centos
    command: ["/bin/sh"]
    args: ["-c", "while true; do echo $(date -u) >> /data/out.txt; sleep 5; done"]
    volumeMounts:
    - name: persistent-storage
      mountPath: /data
  volumes:
  - name: persistent-storage
    persistentVolumeClaim:
      claimName: ebs-dynamic-claim

Сценарий с использованием снимка диска

Чтобы можно было делать снимки дисков, необходимо предварительно создать под с диском и Storage Class, а также Volume Snapshot Class.

Пример конфигурации Volume Snapshot Class для версий Kubernetes 1.20.9 и 1.18.2

apiVersion: snapshot.storage.k8s.io/v1beta1
kind: VolumeSnapshotClass
metadata:
  name: csi-aws-vsc
driver: ebs.csi.aws.com
deletionPolicy: Delete
parameters:
  csi.storage.k8s.io/snapshotter-secret-name: aws-secret
  csi.storage.k8s.io/snapshotter-secret-namespace: kube-system

Пример конфигурации Volume Snapshot Class для версий Kubernetes 1.27.3, 1.26.6, 1.25.11 и 1.22.3

apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshotClass
metadata:
  name: csi-aws-vsc
driver: ebs.csi.aws.com
deletionPolicy: Delete
parameters:
  csi.storage.k8s.io/snapshotter-secret-name: aws-secret
  csi.storage.k8s.io/snapshotter-secret-namespace: kube-system

При создании Volume Snapshot Class с помощью этого запроса будет автоматически создан объект класса VolumeSnapshotClass, при этом для авторизации в облаке используются те же данные, что и в EBS-провайдере. Кроме того, вам потребуется Volume Snapshot.

Пример конфигурации Volume Snapshot для версий Kubernetes 1.20.9 и 1.18.2

apiVersion: snapshot.storage.k8s.io/v1beta1
kind: VolumeSnapshot
metadata:
  name: ebs-volume-snapshot-2
  namespace: default
spec:
  volumeSnapshotClassName: csi-aws-vsc
  source:
    persistentVolumeClaimName: ebs-dynamic-claim

Пример конфигурации Volume Snapshot для версий Kubernetes 1.27.3, 1.26.6, 1.25.11 и 1.22.3

apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshot
metadata:
  name: ebs-volume-snapshot-2
  namespace: default
spec:
  volumeSnapshotClassName: csi-aws-vsc
  source:
    persistentVolumeClaimName: ebs-dynamic-claim

При создании Volume Snapshot с помощью этого запроса будут автоматически созданы объект класса VolumeSnapshot и снимки диска в облаке с учётом текущего состояния Persistent Volume Claim в кластере Kubernetes. Теперь этот Volume Snapshot можно использовать в качестве источника данных (dataSource) для Persistent Volume Claim.

Пример конфигурации Persistent Volume Claim

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: ebs-restore-claim
spec:
  dataSource:
    name: ebs-volume-snapshot-2
    kind: VolumeSnapshot
    apiGroup: snapshot.storage.k8s.io
  accessModes:
    - ReadWriteOnce
  storageClassName: ebs-dynamic
  resources:
    requests:
      storage: 32Gi

Пример конфигурации Persistent Volume Claim в конфигурации пода

apiVersion: v1
kind: Pod
metadata:
  name: app-restored
spec:
  containers:
  - name: app
    image: centos
    command: ["/bin/sh"]
    args: ["-c", "while true; do echo $(date -u) >> /data/out.txt; sleep 5; done"]
    volumeMounts:
    - name: persistent-storage-restored
      mountPath: /data
  volumes:
  - name: persistent-storage-restored
    persistentVolumeClaim:
      claimName: ebs-restore-claim

Сценарий с увеличением размера диска

Чтобы включить возможность увеличить размер диска, требуется указать поле allowVolumeExpansion со значением True в конфигурации Storage Class.

Размер диска с файловой системой можно изменить только для файловых систем xfs, ext3, ext4.

Пример конфигурации пода с динамически создаваемым диском на 8 ГиБ, размер которого можно увеличить

kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
  name: ebs-dynamic
provisioner: ebs.csi.aws.com
allowVolumeExpansion: true
parameters:
  csi.storage.k8s.io/fstype: xfs
  type: gp2
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: ebs-dynamic-claim
spec:
  accessModes:
    - ReadWriteOnce
  storageClassName: ebs-dynamic
  resources:
    requests:
      storage: 8Gi
---
apiVersion: v1
kind: Pod
metadata:
  name: app
spec:
  containers:
  - name: app
    image: centos
    command: ["/bin/sh"]
    args: ["-c", "while true; do echo $(date -u) >> /data/out.txt; sleep 5; done"]
    volumeMounts:
    - name: persistent-storage
      mountPath: /data
  volumes:
  - name: persistent-storage
    persistentVolumeClaim:
      claimName: ebs-dynamic-claim

Для отправки запроса на увеличение размера ранее созданного диска требуется отредактировать поле spec.resources.requests.storage в конфигурации Persistent Volume Claim. Новое значение должно быть больше текущего размера диска и кратно 8 ГиБ.

Конфигурацию Persistent Volume Claim можно отредактировать с помощью команды:

kubectl edit pvc ebs-dynamic-claim

Изменение размера диска занимает некоторое время. Результат можно узнать, запросив текущую конфигурацию Persistent Volume Claim:

kubectl get pvc ebs-dynamic-claim -o yaml

После окончания операции поле status.capacity.storage должно содержать новый размер диска.

Установка EBS-провайдера в свой кластер Kubernetes

EBS-провайдер можно установить отдельно от сервиса облака.

Для этого необходимо создать Secret с данными для авторизации пользователя, от имени которого будет происходить работа с облаком:

Пример конфигурации секрета

apiVersion: v1
kind: Secret
metadata:
  name: aws-secret
  namespace: kube-system
stringData:
  key_id: "<AWS_ACCESS_KEY_ID>"
  access_key: "<AWS_SECRET_ACCESS_KEY>"

Для корректной работы пользователь с ролью Kubernetes EBS Provider user, данные которого подставляются в поля key_id и access_key, должен обладать привилегиями в инфраструктурном сервисе на следующие действия:

• attach_volume

• detach_volume

• describe_instances

• describe_volumes

Опционально, для возможности создавать и удалять диски, а также увеличивать их размер:

• create_volume

• delete_volume

• modify_volume

Опционально, для возможности использовать снимки дисков:

• create_snapshot

• delete_snapshot

• describe_snapshots

Чтобы проверить набор доступных действий для пользователя с ролью Kubernetes EBS Provider user или обновить их, перейдите в раздел IAM, откройте вкладку Проекты на странице пользователя и нажмите Настроить возле соответствующего проекта. Если в инфраструктурном сервисе не хватает каких-то действий, например, create_snapshot, delete_snapshot и describe_snapshots для использования снимков дисков или modify_volume для увеличения размера дисков, добавьте их.

Для расширения привилегий вы также можете удалить пользователя из проекта и добавить заново, указав роль Kubernetes EBS Provider user, однако в этом случае существующие EBS-провайдеры в развёрнутых кластерах перестанут работать.

После задания необходимых привилегий примените конфигурацию (на примере версии 1.22.3):

kubectl apply -f https://storage.cloud.croc.ru/kaas/latest/deployment/1.22.3/ebs/ebs.yaml

В случае если установка пройдёт успешно (поды с префиксом ebs-csi-* в имени будут запущены), станет доступным использование дисков Облака КРОК в Kubernetes.

Для использования снимков дисков выполните следующие действия:

1. На любом мастер-узле кластера Kubernetes выполнить команды (только для кластеров, которые были развёрнуты до 05.10.2021 и используют EBS-провайдер; на примере версии 1.22.3):

   kubectl delete -f https://storage.cloud.croc.ru/kaas/latest/deployment/1.22.3/ebs/ebs.yaml
   kubectl create -f https://storage.cloud.croc.ru/kaas/latest/deployment/1.22.3/ebs/ebs.yaml
   

2. Применить конфигурацию (на примере версии 1.22.3):

   kubectl create -f https://storage.cloud.croc.ru/kaas/latest/deployment/1.22.3/ebs/crd/snapshot.storage.k8s.io_volumesnapshotclasses.yaml
   kubectl create -f https://storage.cloud.croc.ru/kaas/latest/deployment/1.22.3/ebs/crd/snapshot.storage.k8s.io_volumesnapshotcontents.yaml
   kubectl create -f https://storage.cloud.croc.ru/kaas/latest/deployment/1.22.3/ebs/crd/snapshot.storage.k8s.io_volumesnapshots.yaml
   kubectl create -f https://storage.cloud.croc.ru/kaas/latest/deployment/1.22.3/ebs/snapshot-controller/rbac-snapshot-controller.yaml
   kubectl create -f https://storage.cloud.croc.ru/kaas/latest/deployment/1.22.3/ebs/snapshot-controller/setup-snapshot-controller.yaml
   

В случае если установка пройдёт успешно (под с префиксом snapshot-controller* в имени будет запущен), в Облаке КРОК можно будет делать снимки дисков, которые используются в качестве Persistent Volume Claim в Kubernetes.

Docker Registry

Docker Registry — это масштабируемое серверное приложение, которое хранит, позволяет вам распространять и в дальнейшем использовать образы Docker. Если при создании кластера вы выбрали сервис Docker Registry, то он будет установлен на мастер-узел.

Чтобы загружать в Docker Registry образы с локального компьютера, необходимо установить Docker.

После установки выполните команду и введите пароль:

docker login <IP-адрес docker-registry>

После этого загрузите образы, устанавливая для них тег, начинающийся с <IP-адрес docker-registry>:5000/. Например, для существующего образа quay.io/coreos/example-app:v1.0 тег будет таким:

docker tag quay.io/coreos/example-app:v1.0 185.12.31.211:5000/example-app:v1.0
docker push 185.12.31.211:5000/example-app:v1.0

В дальнейшем вместо публичного IP-адреса Docker Registry можно использовать приватный адрес, и наоборот.

Чтобы создать в кластере под из загруженного образа, используйте настроенные в кластере учётные данные regcred:

Пример конфигурации

apiVersion: v1
kind: Pod
metadata:
  name: example
spec:
  containers:
  - name: example-app
    image: '172.31.0.4:5000/example-app:v1.0'
  imagePullSecrets:
  - name: regcred

Kubernetes Dashboard

Kubernetes Dashboard — это веб-интерфейс пользователя Kubernetes. Панель мониторинга можно использовать для развёртывания контейнерных приложений в кластере Kubernetes, устранения неполадок в контейнерном приложении и управления ресурсами кластера. Панель мониторинга можно использовать для получения обзора приложений, запущенных в вашем кластере, а также для создания или изменения отдельных ресурсов Kubernetes. Например, вы можете масштабировать развёртывание, инициировать текущее обновление, перезапустить модуль или развернуть новые приложения.

По умолчанию в вашем кластере Kubernetes уже запущен сервис Kubernetes Dashboard. Чтобы получить к нему доступ, выполните следующие действия:

1. Настройте kubectl согласно инструкции.

2. После этого откройте в браузере ссылку http://localhost:8001/api/v1/namespaces/kubernetes-dashboard/services/https:kubernetes-dashboard:/proxy/#.

3. Получите токен для авторизации в Облаке КРОК. Информацию о токене для доступа в Kubernetes Dashboard можно найти на вкладке Информация в разделе Кластеры Kubernetes.

   Если у вас нет доступа в Облако КРОК или он ограничен, получить токен можно также с помощью команды:

   kubectl -n kubernetes-dashboard get secret $(kubectl -n kubernetes-dashboard get sa/admin-user -o jsonpath="{.secrets[0].name}") -o go-template="{{.data.token | base64decode}}"