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

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:

Для версии 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 управлять дисками в К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

NLB-провайдер

NLB-провайдер позволяет развернуть балансировщик нагрузки для кластера Kubernetes в К2 Облаке. Вы можете создать балансировщик для распределения как внешнего, так и внутреннего трафика (см. подробнее официальную документацию Kubernetes). Балансировщик нагрузки можно подключить к кластерам Kubernetes, как созданным с помощью соответствующего сервиса К2 Облака, так и развёрнутым вами самостоятельно в инфраструктуре К2 Облака.

Важно

В К2 Облаке с кластерами Kubernetes можно использовать только сетевые балансировщики нагрузки. По умолчанию для них доступен только один тип целевых ресурсов (target-type): instance.

Настройка кластера Kubernetes для работы с балансировщиком нагрузки

Для создания балансировщика нагрузки в Kubernetes необходимо добавить следующий манифест для объекта Service:

Пример конфигурации Service для внутреннего балансировщика нагрузки

apiVersion: v1
kind: Service
metadata:
  name: my-webserver
spec:
  selector:
      app: web
  ports:
      - protocol: TCP
        port: 80
        targetPort: 80
  type: LoadBalancer

либо:

Пример конфигурации Service для внешнего балансировщика нагрузки

apiVersion: v1
kind: Service
metadata:
  name: my-webserver
  annotations:
    service.beta.kubernetes.io/aws-load-balancer-scheme: "internet-facing"
spec:
  selector:
      app: web
  ports:
      - protocol: TCP
        port: 80
        targetPort: 80
  type: LoadBalancer

Важно

При создании балансировщика в группу безопасности, которая была автоматически создана вместе с кластером Kubernetes, добавляется входящее правило для порта балансировщика нагрузки, разрешающее TCP-трафик с любых IP-адресов. Чтобы запретить добавление этого правила, в манифест Service необходимо включить следующую аннотацию: service.beta.kubernetes.io/aws-load-balancer-manage-backend-security-group-rules: "false".

Чтобы балансировщик нагрузки знал, куда направлять трафик, необходимо создать приложение в Kubernetes (deployment). В приложении должна быть указана та же метка, что и в селекторе балансировщика нагрузки (web в данном примере). Если не задать целевое приложение для балансировщика нагрузки, то сервис в Kubernetes и, соответственно, облачный балансировщик нагрузки не будут созданы.

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

apiVersion: apps/v1
kind: Deployment
metadata:
   name: webserver
   labels:
     app: web
spec:
   selector:
     matchLabels:
       app: web
   replicas: 2
   template:
     metadata:
       labels:
         app: web
     spec:
       containers:
         - name: webserver
           image: nginx:latest
           ports:
           - containerPort: 80

Подключение NLB-провайдера к собственному кластеру Kubernetes

Если вы самостоятельно развернули кластер Kubernetes в К2 Облаке, то вы также можете использовать облачный балансировщик нагрузки для распределения трафика между его подами. Чтобы установить NLB-провайдер от К2 Облако в свой кластер Kubernetes, необходимо выполнить следующие действия (на примере кластера Kubernetes версии 1.30.2):

1. Создайте отдельного пользователя и назначьте ему политику EKSNLBPolicy, либо создайте собственную политику со следующими разрешениями:

   • все права на сервис ec2;

   • права на сервис elb.

2. В группу безопасности, которая назначена узлам кластера в К2 Облаке, добавьте тег с ключём kubernetes.io/cluster/<имя кластера> и пустым значением.

3. На каждый узел в кластере (и на присоединяемые впоследствии) установите providerId с помощью команды:

   kubectl patch node <nodename> -p '{"spec": {"providerID": "cloud/<instance-id>"}}'
   

4. Примените конфигурацию Deployment для менеджера сертификатов:

   kubectl apply -f https://s3.k2.cloud/kaas/v20/deployment/1.30.2/nlb/cert-manager.yaml
   

   Важно

   Прежде чем выполнять дальнейшие действия, необходимо подождать 120 сек до окончания инициализации менеджера сертификатов.

5. Скачайте конфигурацию Deployment для секрета NLB, добавьте в неё идентификационные данные ранее созданного пользователя и примените конфигурацию командой:

   kubectl apply -f nlb-secret.yaml
   

6. Скачайте следующие конфигурации для объектов Deployment:

   • https://s3.k2.cloud/kaas/v20/deployment/1.30.2/nlb/deployment_patch.yaml

   • https://s3.k2.cloud/kaas/v20/deployment/1.30.2/nlb/kustomization.yaml

   • https://s3.k2.cloud/kaas/v20/deployment/1.30.2/nlb/nlb.yaml

   Примечание

   В файле deployment_patch.yaml может потребоваться заменить эндпоинты и cluster-name на актуальные.

   Для применения конфигураций выполните команду:

   kubectl apply -k <directory>
   

   где directory — каталог, куда были загружены файлы.

При успешной установке будут запущены поды с префиксами aws-load-balancer-* и cert-manager-* в имени, после чего с кластером Kubernetes можно будет использовать балансировщик нагрузки К2 Облака.

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