Доступ к кластеру с помощью 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.

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

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

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

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

Перед использованием 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
   
   

Получите 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. 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, указывающую на этот путь.

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