Доступ к кластеру с помощью kubectl

kubectl retrieves cluster information from a kubeconfig file and communicates with the Kubernetes API server. The kubeconfig file is the credential for kubectl to access a Kubernetes cluster. It contains the cluster connection information (such as the API server address and CA certificate), user authentication credentials (such as the client certificate and token), and context (cluster, user, and default namespace). With these details, kubectl can interact with the Kubernetes cluster to perform management tasks.

• Доступен клиент, способный подключаться к Интернету. IP‑адрес клиента не может находиться в CIDR‑блоке, где размещён контрольный план кластера. Подробнее см. Common Issues.
• Если используется private access, клиент и целевой кластер должны находиться в одной VPC.
• Если используется public access, к целевому кластеру привязан EIP. Подробнее о привязке EIP см. Procedure.
  Note

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

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

Для получения подробной информации о разрешениях пользователя см. Relationship Between IAM Role/Policy Permissions and Namespace Permissions.

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

1. Войдите в клиент и скачайте kubectl. В качестве примера используется версия v1.35.0. При необходимости замените её на требуемую версию.

   cd /home
   curl -LO https://dl.k8s.io/release/v1.35.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
   
   

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

1. Войдите в CCE console и нажмите название кластера, чтобы открыть консоль кластера.
2. On the Overview page of the cluster console, locate the Connection Information area and click Configure next to kubectl.

3. On the slide-out panel, locate the Download the kubeconfig file area, select Private access or Public access for Current data, and copy the configuration file.
   Note

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

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

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

   vim kubeconfig.yaml
   
   

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

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

   To persist the environment variable, add export KUBECONFIG="<your-path>" to your shell configuration file (for example, ~/.bashrc), and run source ~/.bashrc to apply the changes.

   cd /home
   mkdir -p $HOME/.kube
   mv -f ~/kubeconfig.yaml $HOME/.kube/config  # Change  kubeconfig.yaml  to the file name.
   
   

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    # Check the cluster information.
   
   

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

   Kubernetes control plane is running at https://xx.xx.xx.xx:5443
   CoreDNS is running at https://xx.xx.xx.xx:5443/api/v1/namespaces/kube-system/services/coredns:dns/proxy
   To further debug and diagnose cluster problems, use 'kubectl cluster-info dump'.
   
   

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

• После привязки EIP к API server двухстороннее доверие к доменному имени отключается по умолчанию, если для доступа к кластеру используется 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 Двухстороннее доверие отключено для доменных имен

  
  

• Error from server Forbidden

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

  # kubectl get deploy Error from server (Forbidden): deployments.apps is forbidden: User "0c97ac3cb280f4d91fa7c0096739e1f8" cannot list resource "deployments" in API group "apps" in the namespace "default"
  
  

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

• The connection to the server localhost:8080 was refused

  Когда вы используете kubectl для создания или запроса ресурсов Kubernetes, возвращается следующий вывод:

  The connection to the server localhost:8080 was refused - did you specify the right host or port?
  
  

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

• use of X25519 is not allowed in FIPS 140-only mode

  Когда вы запускаете kubectl, отображается следующая информация:

  failed to download openapi: Get "https://x.x.x.x:5443/openapi/v2?timeout=32s": crypto/ecdh: use of X25519 is not allowed in FIPS 140-only mode; if you choose to ignore these errors, turn validation off with --validate=false
  
  

  Выполните следующие шаги для устранения этой проблемы:

  • Добавьте --validate=false к kubectl apply -f, чтобы пропустить проверку.
  • Скачайте последнюю версию kubectl. Для получения подробностей см. Accessing a Cluster Using kubectl.
• Доступ к Kubernetes API не удаётся, когда IP-адрес клиента находится в CIDR‑блоке управляющего плана кластера.

  Войдите в консоль CCE и нажмите имя кластера, чтобы открыть консоль кластера. В панели Networking Configuration на странице Overview просмотрите CIDR‑блок, где расположен управляющий план кластера.

  Если IP-адрес клиента находится в CIDR‑блоке, где расположен управляющий план кластера, внутренняя маршрутизация системы может распознать трафик, отправляемый к серверу API, как обратный вызов или локальный трафик узла. В результате доступ к Kubernetes API может завершиться неудачей. Если доступ не удался, переключите IP-адрес клиента на другой CIDR‑блок и повторите попытку.