Облачная платформаВсе платформы

Доступ к кластеру с использованием kubectl

Язык статьи: Русский
Показать оригинал
Страница переведена автоматически и может содержать неточности. Рекомендуем сверяться с английской версией.

kubectl — это инструмент командной строки, предоставляемый Kubernetes, позволяющий управлять ресурсами кластера, просматривать состояние кластера, развертывать приложения и отлаживать проблемы через CLI. Чтобы получить доступ к кластеру CCE с помощью kubectl, вы можете использовать любой из следующих методов:

  • Private access: Клиенты получают доступ к API‑серверу кластера через внутренний IP‑адрес, удерживая трафик данных внутри сети и повышая безопасность.
  • Public access: API‑сервер кластера предоставляет публичный API, позволяя клиентам получать доступ к кластеру Kubernetes через Интернет. При использовании доступа через Интернет вы можете выбрать, включать ли двустороннее доверие к доменному имени.
    • Если двустороннее доверие к доменному имени отключено, kubectl и API‑сервер используют одностороннюю аутентификацию сертификатом, что менее безопасно. В этом режиме только kubectl проверяет сертификат API‑сервера, тогда как API‑сервер не проверяет сертификат kubectl.
    • Если двустороннее доверие к доменному имени включено, kubectl и API‑сервер используют взаимную аутентификацию сертификатом, что безопаснее. В этом режиме kubectl проверяет сертификат API‑сервера, а API‑сервер проверяет сертификат kubectl (указанный в client-certificate-data поле в файле kubeconfig). Для получения более подробной информации см. Two-Way Domain Name Trust.

В этом разделе используется стандартный кластер CCE в качестве примера, описывающего, как получить доступ к кластеру CCE с помощью kubectl.

How It Works

kubectl получает информацию о кластере из файла kubeconfig и взаимодействует с API‑сервером Kubernetes. kubeconfig файл является учетными данными для kubectl для доступа к кластеру Kubernetes. Он содержит информацию о подключении к кластеру (например, адрес API‑сервера и сертификат CA), учетные данные аутентификации пользователя (например, клиентский сертификат и токен), а также контекст (кластер, пользователь и пространство имен по умолчанию). Имея эти детали, kubectl может взаимодействовать с кластером Kubernetes для выполнения управленческих задач.

Рисунок 1 Использование kubectl для доступа к кластеру


Prerequisites

  • Доступен клиент, который может обращаться к Интернету.
  • Если приватный доступ используется, клиент и кластер, к которому будет выполнен доступ, должны находиться в одной VPC.
  • Если публичный доступ используется, у кластера, к которому будет доступ, привязан EIP. Для получения подробной информации о привязке EIP см. Procedure.
    Note

    В кластере с привязанным EIP kube-apiserver будет доступен из Интернета и может быть атакован. Чтобы решить эту проблему, вы можете настроить Advanced Anti-DDoS для EIP узла, на котором работает kube-apiserver, или настроить правила группы безопасности.

Constraints

Файл kubeconfig содержит учетные данные аутентификации пользователя. При использовании этого файла для доступа к кластеру kubectl получает доступ к кластеру на основе указанных в файле учетных данных и разрешений.

Для получения подробной информации о разрешениях пользователей см. Cluster Permissions (IAM-based) and Namespace Permissions (Kubernetes RBAC-based).

Step 1: Download kubectl

Перед тем как использовать kubectl для доступа к кластеру, установите kubectl на клиенте. Выполните команду kubectl version команду, чтобы проверить, установлен ли kubectl. Если он установлен, пропустите этот шаг. В этом разделе используется Linux в качестве примера для описания установки и настройки kubectl. Для получения подробной информации см. Installing kubectl.

  1. Войдите в свой клиент и загрузите kubectl. v1.25.0 указывает версию. При необходимости замените её.

    cd /home
    curl -LO https://dl.k8s.io/release/v1.25.0/bin/linux/amd64/kubectl

  2. Выполните следующую команду для установки kubectl:

    chmod +x kubectl
    mv -f kubectl /usr/local/bin

  3. Выполните следующую команду, чтобы проверить, установлен ли kubectl:

    kubectl version

    Если отображается информация, похожая на следующую, kubectl установлен:

    Client Version: xxx
    Kustomize Version: xxx
    Server Version: xxx

Step 2: Obtain the kubectl Configuration File (kubeconfig)

Получите kubeconfig (файл конфигурации kubectl) из кластера для доступа.

  1. Войдите в CCE console и щелкните название кластера, чтобы открыть консоль кластера.
  2. На странице Overview консоли кластера, найдите раздел Connection Information область и нажмите Configure рядом с kubectl.

  3. В выдвижной панели найдите Download the kubeconfig file область, выберите Private access or Public access для Current data, и скопируйте файл конфигурации.

    Note
    • kubeconfig используется для аутентификации кластера. Если файл будет утек, ваш кластер может быть атакован.
    • Разрешения Kubernetes, назначенные файлом конфигурации, загруженным пользователями IAM, совпадают с разрешениями, назначенными пользователям IAM в консоли CCE.
    • В Linux, если переменная среды KUBECONFIG установлена, kubectl загрузит её вместо $home/.kube/config.
    • Выданный сертификат kubeconfig остается действительным, даже если пользователь, запросивший его, удалён. Чтобы обеспечить безопасность кластера, вручную отзовите учетные данные доступа пользователя к кластеру. Для получения более подробной информации см. Revoking a Cluster Access Credential.

Step 3: Configure kubectl

Файл kubeconfig хранится на клиенте, и kubectl использует его для доступа к кластеру и взаимодействия с ним.

  1. Войдите в свой клиент.
  2. Создайте kubeconfig.yaml файл. Вы можете изменить имя файла по необходимости. Файл используется для хранения информации конфигурационного файла, полученной в 3.

    vim kubeconfig.yaml

    Скопируйте информацию конфигурационного файла, полученную в 3 в kubeconfig.yaml и сохраните файл.

  3. Сохраните kubeconfig.yaml файл в $HOME/.kube/config. kubectl автоматически будет читать его. Если вы сохраняете kubeconfig.yaml файл в другом пути, установите переменную среды KUBECONFIG, указывающую на этот путь.

    cd /home
    mkdir -p $HOME/.kube
    mv -f ~/kubeconfig.yaml $HOME/.kube/config  # Change kubeconfig.yamlkubeconfig.yaml на имя файла.

  4. Переключите режим доступа kubectl в зависимости от сценариев обслуживания.

    • Если используется приватный доступ через VPC, выполните следующую команду:
      kubectl config use-context internal
    • Если публичный доступ включён и двустороннее доверие к доменному имени не требуется, убедитесь, что к кластеру привязан EIP. Затем выполните следующую команду:
      kubectl config use-context external
    • Если публичный доступ включён и требуется двустороннее доверие к доменному имени, убедитесь, что к кластеру привязан EIP. Затем выполните следующую команду:
      kubectl config use-context externalTLSVerify

      Для получения более подробной информации см. Two-Way Domain Name Trust.

  5. Выполните следующую команду на клиенте, чтобы проверить, может ли клиент получить доступ к кластеру с помощью kubectl:

    kubectl cluster-info    # Проверить информацию о кластере.

    Если отображается следующая информация, клиент может получить доступ к кластеру с помощью kubectl:

    Kubernetes control plane работает по адресу https://xx.xx.xx.xx:5443
    CoreDNS работает по адресу https://xx.xx.xx.xx:5443/api/v1/namespaces/kube-system/services/coredns:dns/proxy
    Для более детального отладки и диагностики проблем кластера используйте 'kubectl cluster-info dump'.

Two-Way Domain Name Trust

Two-way domain name trust является механизмом взаимной аутентификации, который проверяет подлинность как клиента, так и сервера. Этот режим повышает безопасность между кластерами и клиентами, препятствуя неавторизованному доступу.

  • После привязки EIP к API‑серверу двустороннее доверие к доменному имени отключается по умолчанию, если для доступа к кластеру используется kubectl. Вы можете выполнить kubectl config use-context externalTLSVerify для включения двустороннего доверия к доменному имени.
  • Когда EIP привязывается к кластеру или отлучается от него, либо настраивается или обновляется пользовательское доменное имя, адрес доступа к кластеру (включая привязанный к кластеру EIP и все пользовательские доменные имена, настроенные для кластера) будет добавлен в сертификат сервера кластера.
  • Асинхронная синхронизация кластера занимает около 5–10 минут. Вы можете просмотреть результат синхронизации в Synchronize Certificate в Operation Records.
  • Для кластера с привязанным EIP, если при использовании двустороннего доверия к доменному имени аутентификация не проходит (x509: certificate is valid), привяжите EIP повторно и загрузите kubeconfig.yaml снова.
  • Если двустороннее доверие к доменному имени не поддерживается, kubeconfig.yaml содержит "insecure-skip-tls-verify": true поле, как показано в Figure 2. Чтобы использовать двустороннее доверие к доменному имени, загрузите kubeconfig.yaml файл повторно и включите двустороннее доверие к доменному имени.

    Figure 2 Two-way trust disabled for domain names


Common Issues

  • Error from server Forbidden

    При использовании kubectl для создания или запроса ресурсов Kubernetes вывод выглядит следующим образом:

    # kubectl get deploy Ошибка от сервера (Forbidden): deployments.apps запрещено: Пользователь "0c97ac3cb280f4d91fa7c0096739e1f8" не может перечислять ресурс "deployments" в группе API "apps" в пространстве имен "default"

    Причина в том, что у пользователя нет прав для работы с ресурсами Kubernetes. Для получения подробной информации о назначении прав см. Configuring Namespace Permissions (Kubernetes RBAC-based).

  • Подключение к серверу localhost:8080 было отклонено

    При использовании kubectl для создания или запроса ресурсов Kubernetes вывод выглядит следующим образом:

    Подключение к серверу localhost:8080 было отклонено — указали ли вы правильный хост или порт?

    Причина в том, что аутентификация кластера не настроена для клиента kubectl. Для получения подробной информации см. Step 2: Obtain the kubectl Configuration File (kubeconfig).

Parent topic: Accessing a Cluster
Предыдущая статья
Обзор доступа к кластеру
Следующая статья
Доступ к кластеру с помощью X.509 сертификата
Поддержка Юридические документы Политика конфиденциальности
© 2026 Cloud.ru