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

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

• Доступен клиент, который может подключаться к Интернету.
• Если используется 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. На странице Overview консоли кластера найдите область Connection Information и нажмите Configure рядом с kubectl.

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

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

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

1. Войдите в клиент.
2. Create the kubeconfig.yaml file. You can change the file name as needed. The file is used to store the configuration file information obtained in 3.

   vim kubeconfig.yaml
   
   

   Copy the configuration file information obtained in 3 to kubeconfig.yaml and save the file.

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).

• использование X25519 не разрешено в режиме только FIPS 140

  При запуске 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.