Дополнительные сервисы
In this article:
Дополнительные сервисы#
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 необходимо описать следующие конфигурации:
Storage class — описание класса хранилища. Подробную информация о Storage class можно получить в официальной документации.
Persistent Volume — описание непосредственно подключаемого диска и его характеристик.
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.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. Чтобы получить к нему доступ, выполните следующие действия:
Настройте kubectl согласно инструкции.
После этого откройте в браузере ссылку http://localhost:8001/api/v1/namespaces/kubernetes-dashboard/services/https:kubernetes-dashboard:/proxy/#.
Получите токен для авторизации в К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}}"