Cloud Container Engine (CCE) — это сервис контейнеров, позволяющий эффективно запускать контейнеры в облаке. CCE предоставляет высокомасштабируемые, высокопроизводительные, корпоративного класса кластеры Kubernetes и поддерживает контейнеры Docker. С CCE вы можете легко развертывать, управлять и масштабировать контейнеризованные приложения в облаке.
В этом документе описывается, как использовать API для выполнения операций с CCE, таких как создание или удаление ресурсов CCE, изменение спецификаций ресурсов или добавление сетевых интерфейсов. Подробную информацию обо всех поддерживаемых операциях см. в API Overview.
Если вы планируете получать доступ к ресурсам CCE через API, убедитесь, что знакомы с концепциями CCE.
CCE поддерживает как API, совместимые с Kubernetes, так и собственные API. С помощью этих API вы можете использовать все функции CCE.
- CCE открыл API через API‑gateway для поддержки операций над инфраструктурой облачных сервисов (например, создание узла). Операции над ресурсами кластера (например, creating a workload) также поддерживаются.
- API, совместимые с Kubernetes: вы можете выполнять операции над ресурсами кластера (например, creating a workload) с помощью Kubernetes-native API server. Однако операции над инфраструктурой облачных сервисов (например, создание узла) не поддерживаются.
Подробную информацию о версиях API, совместимых с Kubernetes, см. в https://kubernetes.io/docs/concepts/overview/kubernetes-api/.
Note- В вызываемых в текущей версии API, совместимых с Kubernetes, не поддерживаются постоянные HTTP‑соединения.
- API, совместимые с Kubernetes, в текущей версии включают Beta‑API, названия версий которых содержат beta, например, v1beta1. Такие API различаются в зависимости от API, совместимых с Kubernetes. Поэтому рекомендуется использовать такие API в несущественных сценариях, например, в краткосрочных тестовых кластерах.
CCE поддерживает API, основанные на Representational State Transfer (REST), позволяющие вызывать API через HTTPS. Подробную информацию о вызове API см. в Calling APIs.
Endpoints
Эндпоинт — это request address для вызова API. Эндпоинты различаются в зависимости от сервисов и регионов. Эндпоинт можно получить из Regions and Endpoints.
Необходимо выбрать эндпоинт в соответствии с требованиями вашего сервиса.
- The URL format for cluster, node, node pool, add-on, and quota management is https://Endpoint/uri. In the URL, uri indicates the resource path, which is the path for API access.
- Формат URL для Kubernetes APIs, управления хранилищем и управления дополнениями выглядит так https://{clusterid}.Endpoint/uri. В URL {clusterid} указывает идентификатор кластера, а uri указывает путь к ресурсу, то есть путь для доступа к API.Note
- Формат URL, вызываемого API управления дополнениями, выглядит так https://{clusterid}.Endpoint/uri. Однако {clusterid} используется только в имени домена и не проверяется и не используется API. Установите {clusterid} в запросе или теле. Подробную информацию о {clusterid} см. в разделах управления дополнениями.
- {clusterid} требуется для Kubernetes APIs и управления хранилищем, он указывает кластер, к которому необходимо обратиться при вызове API.
Параметр | Описание |
|---|---|
{clusterid} | Идентификатор кластера. После создания кластера вызовите API for obtaining a cluster in a specified project, чтобы получить идентификатор кластера. |
Эндпоинт | Точка входа (URL) для веб‑сервиса. Эндпоинты различаются в зависимости от сервисов и регионов. |
uri | Путь доступа API для выполнения операции. Получите путь из URI API. Например, resource-path API, используемого для получения токена пользователя, равен v3/auth/tokens. |
Примечания и ограничения
- CCE накладывает квоту на количество и ёмкость ресурсов, к которым пользователь может получить доступ. По умолчанию в каждом регионе можно создать не более пяти кластеров, а кластер может содержать не более 50 узлов.
- Для получения дополнительных ограничений см. описание каждого API.
Концепции
- Домен
Домен создаётся после успешной регистрации. Домен имеет полные права доступа ко всем своим облачным сервисам и ресурсам. Его можно использовать для сброса паролей пользователей и предоставления пользователям разрешений. Домен является платежным субъектом, который не следует использовать напрямую для выполнения повседневного управления. В целях безопасности создавайте Identity and Access Management (IAM) users и предоставляйте им разрешения для повседневного управления.
- Пользователь
IAM user создаётся с помощью учётной записи для использования облачных сервисов. Каждый IAM user имеет собственные учётные данные (пароль и ключи доступа).
Для аутентификации API потребуются имя учётной записи, имя пользователя и пароль.
- Регион
Регион — это географическая область, в которой развертываются облачные ресурсы. Зоны доступности (AZ) в одном регионе могут взаимодействовать друг с другом через интранет, тогда как зоны доступности в разных регионах изолированы друг от друга. Развёртывание облачных ресурсов в разных регионах может лучше соответствовать определённым требованиям пользователей или соответствовать местным законам и нормативным актам.
- AZ
Зона доступности (AZ) состоит из одного или нескольких физических дата‑центров, оснащённых независимыми системами вентиляции, пожаротушения, водоотведения и электроснабжения. Вычислительные, сетевые, хранилищные и другие ресурсы в AZ логически разделены на несколько кластеров. Зоны доступности внутри региона соединены между собой высокоскоростными оптическими волокнами, что позволяет создавать кросс‑AZ, высокодоступные системы.
- Проект
Проект соответствует региону. По умолчанию проекты определяются для группировки и физической изоляции ресурсов (включая вычислительные, хранилищные и сетевые ресурсы) между регионами. Пользователям могут быть предоставлены разрешения в default project для доступа ко всем ресурсам их учётных записей в регионе, связанном с проектом. Если требуется более тонкий контроль доступа, создайте подпроекты в рамках default project и создавайте ресурсы в подпроектах. Затем вы можете назначить пользователям необходимые разрешения для доступа только к ресурсам в конкретных подпроектах.
Рисунок 1 Модель изоляции проекта
