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

Ingress controller#

Если при создании кластера вы выбрали опцию 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:

Пример конфигурации 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
Пример конфигурации 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 необходимо внести следующие изменения:

Необходимые изменения в конфигурации 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
Необходимые изменения в конфигурации 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 управлять дисками в К2 Облаке и использовать их в качестве Persistent Volumes в Kubernetes. Сервис способен работать как с существующими дисками, так и создавать их самостоятельно.

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

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

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

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

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

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

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

Для использования существующего диска в К2 Облаке в конфигурации 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 в К2 Облаке поддерживает 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.
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.
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>"

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

Примечание

Политика EKSCSIPolicy предоставляет ему все необходимые разрешения.

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

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

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

kubectl apply -f https://s3.k2.cloud/kaas/latest/deployment/1.25.11/ebs/ebs.yaml

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

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

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

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

В случае если установка пройдёт успешно (под с префиксом snapshot-controller* в имени будет запущен), в К2 Облаке можно будет делать снимки дисков, которые используются в качестве 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. Получите токен для авторизации в К2 Облаке. Информацию о токене для доступа в Kubernetes Dashboard можно найти на вкладке Информация в разделе Кластеры Kubernetes.

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

    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}}"