Preguntas Frecuentes - FAQ

Обзор

На этой странице представлены основные команды, которые позволяют пользователям создавать, управлять и удалять кластеры Kubernetes с помощью CSE. Основным инструментом для этих операций является команда клиента vcd cse.

Здесь представлен обзор процесса, который должен выполнить администратор vOrg, чтобы установить vcd cse и создать кластер. Он включает в себя некоторые внутренние аспекты CSE, чтобы вы могли понять, что происходит "за кадром".

Кластеры CSE Kubernetes могут включать постоянные тома, смонтированные на NFS. Процедуры создания и управления узлами NFS можно найти в разделе Управление узлами NFS.

Полезные команды

vcd cse ... команды используются администраторами и пользователями организации для:

• список шаблонов
• получение статуса сервера CSE
• create, list, info, delete clusters/nodes

Ниже приведена краткая информация о командах, доступных для просмотра шаблонов и управления кластерами и узлами:

Для версий CSE < 3.0, по умолчанию, CSE Client будет отображать ход выполнения задачи до тех пор, пока задача не завершится или не завершится неудачно. Флаг --no-wait может быть использован для пропуска ожидания задачи. Клиент CSE по-прежнему будет отображать информацию о задаче в консоли, и конечный пользователь может выбрать мониторинг хода выполнения задачи вручную.

> vcd --no-wait cse cluster create CLUSTER_NAME --network intranet --ssh-key ~/.ssh/id_rsa.pub

# отобразить статус и ход выполнения задачи
> vcd task wait 377e802d-f278-44e8-9282-7ab822017cbd

# список текущих запущенных задач в организации
> vcd task list running

CSE 3.0 Команда Cluster apply

1. vcd cse cluster apply <create_cluster.yaml> команда - Принимает файл спецификации кластера в качестве входных данных и применяет его к ресурсу кластера. Ресурс кластера будет создан, если он не существует.
   
   • Примеры использования команды:

       vcd cse cluster apply <resize_cluster.yaml> (применяет спецификацию к указанному ресурсу; ресурс кластера будет создан, если он не существует). 
       vcd cse cluster apply --sample --tkg (создает образец файла спецификации для кластеров tkg).
       vcd cse cluster apply --sample --native (создает образец файла спецификации для стандартных кластеров).
     

   • Образец файла спецификации входных данных
     

       # Краткое описание различных свойств, используемых в данном примере конфигурации кластера
       # kind: Вид кластера Kubernetes.
       #
       # metadata: Это обязательный раздел.
       # metadata.cluster_name: Имя кластера, который необходимо создать или изменить размер.
       # metadata.org_name: Название организации, в которой необходимо создать или управлять кластером.
       # metadata.ovdc_name: Имя vdc организации, в котором необходимо создать или управлять кластером.
       #
       # spec: Пользовательские спецификации желаемого состояния кластера.
       # spec.control_plane: Дополнительный подраздел для желаемого состояния control-plane кластера. Свойства "sizing_class" и "storage_profile" могут быть указаны только на этапе создания кластера. Эти свойства больше не будут изменяться в последующих операциях обновления, таких как "resize" и "upgrade".
       # spec.control_plane.count: Количество узлов control plane. Поддерживается единственный control plane.
       # spec.control_plane.sizing_class: Политика определения объема вычислительной мощности, которой узел control-plane должен быть обеспечен в данном "ovdc".  Предполагается, что указанная политика масштабирования будет предварительно опубликована в данном ovdc.
       # spec.control_plane.storage_profile: Профиль хранилища, с которым должна быть создана control-plane в данном "ovdc". Ожидается, что указанный профиль хранилища будет доступен на данном ovdc.
       #
       # spec.k8_distribution: Это обязательный подраздел.
       # spec.k8_distribution.template_name: Имя шаблона, основанное на гостевой ОС, версии Kubernetes и версии ПО Weave.
       # spec.k8_distribution.template_revision: номер ревизии
       #
       # spec.nfs: Опциональный подраздел для желаемого состояния nfs кластера. Свойства "sizing_class" и "storage_profile" могут быть указаны только на этапе создания кластера. Эти свойства больше не будут изменяться в последующих операциях обновления, таких как "resize" и "upgrade".
       # spec.nfs.count: Узлы Nfs можно только увеличивать; уменьшать их нельзя. Значение по умолчанию равно 0.
       # spec.nfs.sizing_class: Политика определения объема вычислительных ресурсов, согласно которой узел nfs должен быть обеспечен в данном "ovdc". Ожидается, что указанная политика будет предварительно опубликована в данном ovdc.
       # spec.nfs.storage_profile: Профиль хранилища, с которым nfs должен быть развернут в данном "ovdc". Ожидается, что указанный профиль хранилища будет доступен на данном ovdc.
       #
       # spec.settings: Это обязательный подраздел.
       # spec.settings.network: Это значение является обязательным. Имя сети виртуального центра обработки данных организации.
       # spec.settings.rollback_on_failure: Необязательное значение, которое по умолчанию равно true. При любом сбое в работе кластера, если значение установлено в true, затронутые ВМ узла будут автоматически удалены.
       # spec.settings.ssh_key: Необязательный ssh-ключ, который пользователи могут использовать для входа в узловые ВМ без явного указания паролей.
       #
       # spec.workers: Опциональный подраздел для определения состояния воркера. Свойства "sizing_class" и "storage_profile" могут быть указаны только на этапе создания кластера. Эти свойства больше не будут изменяться в последующих операциях обновления, таких как "resize" и "upgrade". Не поддерживаются разные узлы воркеров в кластерах.
       # spec.workers.count: количество узлов воркеров (значение по умолчанию:1) Узлы воркеров можно увеличивать и уменьшать.
       # spec.workers.sizing_class: Политика размерности вычислительной мощности, с которой воркеры должны быть обеспечены в данном "ovdc". Ожидается, что указанная политика будет предварительно опубликована для данного ovdc.
       # spec.workers.storage_profile: Профиль хранилища, которым должны быть обеспечены узлы воркеров в данном "ovdc". Ожидается, что указанный профиль будет доступен на данном ovdc.
       #
       # status: Текущее состояние кластера на сервере. Этот раздел не является обязательным ни для одной из операций.
              
       api_version: ''
       kind: native
       metadata:
         cluster_name: cluster_name
         org_name: organization_name
         ovdc_name: org_virtual_datacenter_name
       spec:
         control_plane:
           count: 1
           sizing_class: Large_sizing_policy_name
           storage_profile: Gold_storage_profile_name
         expose: false
         k8_distribution:
           template_name: ubuntu-16.04_k8-1.17_weave-2.6.0
           template_revision: 2
         nfs:
           count: 1
           sizing_class: Large_sizing_policy_name
           storage_profile: Platinum_storage_profile_name
         settings:
           network: ovdc_network_name
           rollback_on_failure: true
           ssh_key: null
         workers:
           count: 2
           sizing_class: Medium_sizing_policy_name
           storage_profile: Silver_storage_profile
       status:
         cni: null
         exposed: False
         docker_version: null
         kubernetes: null
         nodes: null
         os: null
         phase: null
         task_href: null
     

Обновление программного обеспечения, установленного на кластерах Kubernetes

Kubernetes - это быстро развивающееся программное обеспечение, которое каждые три месяца выпускает новый второстепенный релиз и многочисленные исправления (включая исправления безопасности) в промежутках между этими второстепенными релизами. Чтобы поддерживать уже развернутые кластеры в актуальном состоянии, в CSE 2.6.0 добавили поддержку обновления программного обеспечения на месте для кластеров Kubernetes. Програмное обеспечение, которое можно обновить до новых версий:

• Компонены kubernetes в т.ч. kube-server, kubelet, kubedns etc.
• Weave (CNI)
• Docker engine

Матрица обновления строится на основе собственных шаблонов CSE (read more about them here). Шаблон, первоначально использованный для развертывания кластера, определяет допустимые целевые шаблоны для обновления. Поддерживаемые пути обновления можно обнаружить с помощью следующей команды

vcd cse cluster upgrade-plan 'mycluster'

Допустим, наш кластер был развернут с использованием шаблона T1, который основан на Kubernetes версии x.y.z. Наши потенциальные шаблоны для обновления будут удовлетворять хотя бы одному из следующих критериев:

• Последняя ревизия шаблона T1, основанная на версии Kubernetes x.y.w, где w > z.
• Шаблон T2, который имеет ту же базовую ОС и основан на дистрибутиве Kubernetes x.(y+1).v, где v может быть любым.

If you don’t see a desired target template for upgrading your cluster, please feel free to file a GitHub issue .

Обновление кластера выполняется с помощью следующей команды.

vcd cse cluster upgrade 'mycluster'

Процесс обновления требует практически нулевого времени простоя, если соблюдены следующие условия,

1. Docker не обновляется.
2. Weave (CNI) не обновляется.
3. Обновление версии Kubernetes ограничено только версией патча.

Если какое-либо из вышеуказанных условий не будет выполнено, кластер остановится примерно на минуту или более (зависит от фактического процесса обновления).

Автоматизация

vcd cse команды могут быть написаны для автоматизации создания и работы кластеров и узлов Kubernetes.

Пользователи могут взаимодействовать с CSE через пакет Python (container-service-extension) или через REST API CSE, предоставляемый через VCD.

Следующий скрипт Python создает кластер Kubernetes на vCloud Director:

#!/usr/bin/env python3
from pyvcloud.vcd.client import BasicLoginCredentials
from pyvcloud.vcd.client import Client
from container_service_extension.client.cluster import Cluster

client = Client('vcd.mysp.com')
client.set_credentials(BasicLoginCredentials('usr1', 'org1', '******'))

cse = Cluster(client)
result= cse.create_cluster('vdc1', 'net1', 'cluster1')
task = client.get_resource(result['task_href'])
task = client.get_task_monitor().wait_for_status(task)
print(task.get('status'))

client.logout()

Примеры использования

Обратите внимание, что некоторые из команд зависят от версии. Не все команды применимы ко всем версиям CSE. Пожалуйста, обратитесь к командам CLI для каждой версии CSE

# [CSE 3.0] создать кластер
> vcd cse cluster apply create_cluster.yaml

# [CSE 3.0] изменить размер кластера
> vcd cse cluster apply resize_cluster.yaml

# [CSE 3.0] масштабирование узлов nfs в заданном кластере
> vcd cse cluster apply scale_up_nfs.yaml

# [CSE 3.0] Удаление узла Nfs в заданном кластере
> vcd cse cluster delete-nfs mycluster nfsd-ghyt

# создать кластер mycluster с одной control plane и двумя узлами, подключенными к предоставленной сети
# предоставляется публичный ключ для входа в виртуальные машины по протоколу ssh
> vcd cse cluster create mycluster --network intranet --ssh-key ~/.ssh/id_rsa.pub

# список воркер нод кластера
> vcd cse node list mycluster

# создать кластер mycluster с одной control plane, тремя узлами и подключенными к предоставленной сети
> vcd cse cluster create mycluster --network intranet --nodes 3 --ssh-key ~/.ssh/id_rsa.pub

# создать кластер с одним узлом воркера, подключенным к указанной сети. Узлы могут быть добавлены позже
> vcd cse cluster create mycluster --network intranet --nodes 0 --ssh-key ~/.ssh/id_rsa.pub

# создать кластер mycluster с одной control plane, тремя узлами воркеров, подключенными к предоставленной сети
# и один узел типа NFS-сервер
> vcd cse cluster create mycluster --network intranet --nodes 3 --ssh-key ~/.ssh/id_rsa.pub --enable-nfs

# добавить 2 воркера в кластер с 4 ГБ оперативной памяти и 4 процессорами каждый, из шаблона photon,
# используя указанный профиль хранения
> vcd cse node create mycluster --nodes 2 --network intranet --ssh-key ~/.ssh/id_rsa.pub --memory 4096 --cpu 4 --template-name sample_photon_template --template-revision 1 --storage-profile sample_storage_profile

# добавить 1 узел nfsd в кластер с 4 Гб оперативной памяти и 4 процессорами каждый, из шаблона photon,
# используя указанный профиль хранения
> vcd cse node create mycluster --nodes 1 --type nfsd --network intranet --ssh-key ~/.ssh/id_rsa.pub --memory 4096 --cpu 4 --template-name sample_photon_template --template-revision 1 --storage-profile sample_storage_profile

# изменить размер кластера, чтобы в нем было 8 воркеров. Если изменение размера не удается, кластер возвращается к исходному размеру.
# '--network' применимо только для кластеров, использующих собственный (VCD) провайдер Kubernetes.
> vcd cse cluster resize mycluster --network mynetwork --nodes 8

# информация о данном узле. Если узел имеет тип nfsd, то отображается информация об экспорте.
> vcd cse node info mycluster nfsd-dj3s

# удалить 2 узла из кластера
> vcd cse node delete mycluster node-dj3s node-dj3s --yes

# список доступных кластеров
> vcd cse cluster list

# информация о данном кластере
> vcd cse cluster info

# получить конфигурацию кластера
> vcd cse cluster config mycluster > ~/.kube/config

# проверить конфигурацию кластера
> kubectl get nodes

# развернуть образец приложения
> kubectl create namespace sock-shop

> kubectl apply -n sock-shop -f "https://github.com/microservices-demo/microservices-demo/blob/master/deploy/kubernetes/complete-demo.yaml?raw=true"

# проверить, что все pods запущены и готовы к работе
> kubectl get pods --namespace sock-shop

# доступ к приложению
> IP=`vcd cse cluster list|grep '\ mycluster'|cut -f 1 -d ' '`
> open "http://${IP}:30001"

# удалить кластер, если он больше не нужен
> vcd cse cluster delete mycluster --yes

Создание кластеров в организациях с маршрутизируемыми сетями OrgVDC

Обычно CSE требует прямого подключения к сети OrgVDC для развертывания кластера K8s. Это необходимо для того, чтобы убедиться, что виртуальные машины кластера доступны извне сети OrgVDC. В NSX-T сети OrgVDC с прямым подключением не предлагаются, и для развертывания кластеров K8s используются маршрутизируемые сети OrgVDC. Чтобы предоставить доступ в Интернет виртуальным машинам кластера, подключенным к маршрутизируемым сетям OrgVDC с поддержкой NSX-T, и сохранить доступ к кластерам, CSE 3.0.2 предлагает опцию expose кластера.

Обязательным условием является то, что сеть настроена на прием внешнего трафика и отправку трафика вовне.

Пользователи, развертывающие кластеры, должны обладать следующими правами, если они хотят использовать функциональность expose.

• Gateway View
• NAT View Only
• NAT Configure

Если хотя бы одно из этих прав отсутствует, CSE проигнорирует запрос на раскрытие кластера K8s.

Пользователь может использовать expose в свой кластер K8s во время первой команды vcd cse cluster apply, указав expose : True в разделе spec файла спецификации кластера. Следует отметить, что любая попытка expose после создания кластера будет проигнорирована CSE. После того как кластер будет опубликован, в разделе status кластера появится новое поле exposed, которое будет иметь значение True.

Пользователи могут снять публикацию кластера, установив значение поля expose  в False и применив обновленную спецификацию к кластеру с помощью vcd cse cluster apply. Значение поля exposed будет равно False для кластеров, которые не опубликованы. Открытый кластер, если он был скрыт, не может быть снова открыт.

Вы уже работаете с сервисами Cloud4Y?

Перейти на вебсайт

Попробовать бесплатно