Блог

Главная - Вопросы по программированию - Ошибка при подключении к частному кластеру kubernetes с помощью службы oci bastion

Ошибка при подключении к частному кластеру kubernetes с помощью службы oci bastion

#linux #kubernetes #ssh #oracle-cloud-infrastructure #bastion-host

Вопрос:

Я только что создал частный кластер Kubernetes в Oracle Cloud. Обычный способ подключения к API кластера-через службу Bastion. Я выполнил точные действия, как указано в этой статье: https://www.ateam-oracle.com/using-oci-bastion-service-to-manage-private-oke-kubernetes-clusters

После выполнения команды ssh переадресация портов (Шаг 4 в статье) оболочка блокируется по назначению, но я не получаю никаких разумных результатов от запуска kubectl:

 $ kubectl cluster-info

To further debug and diagnose cluster problems, use 'kubectl cluster-info dump'.
Unable to connect to the server: net/http: TLS handshake timeout

Вот вывод при переходе -v по ssh:

 OpenSSH_8.4p1, OpenSSL 1.1.1k  25 Mar 2021
debug1: Reading configuration data /home/praj/.ssh/config
debug1: Reading configuration data /usr/etc/ssh/ssh_config
debug1: /usr/etc/ssh/ssh_config line 24: include /etc/ssh/ssh_config.d/*.conf matched no files
debug1: /usr/etc/ssh/ssh_config line 26: Applying options for *
debug1: Connecting to host.bastion.ap-mumbai-1.oci.oraclecloud.com [192.29.162.226] port 22.
debug1: Connection established.
debug1: identity file /home/praj/.ssh/id_rsa type 0
debug1: identity file /home/praj/.ssh/id_rsa-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_8.4
debug1: Remote protocol version 2.0, remote software version Go
debug1: no match: Go
debug1: Authenticating to host.bastion.ap-mumbai-1.oci.oraclecloud.com:22 as 'ocid1.bastionsession.oc1.ap-mumbai-1.amaaaaaafvm2mgaa5inuqsfwe73eitjgead23h2avusdwryx5hlz6orz7jea'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: curve25519-sha256@libssh.org
debug1: kex: host key algorithm: ssh-rsa
debug1: kex: server->client cipher: aes128-ctr MAC: hmac-sha2-256-etm@openssh.com compression: none
debug1: kex: client->server cipher: aes128-ctr MAC: hmac-sha2-256-etm@openssh.com compression: none
debug1: kex: curve25519-sha256@libssh.org need=32 dh_need=32
debug1: kex: curve25519-sha256@libssh.org need=32 dh_need=32
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ssh-rsa SHA256:JTeqM8qvS9EO9reRIF/qyllvs6px8Y69LEveK9NFzZc
debug1: Host 'host.bastion.ap-mumbai-1.oci.oraclecloud.com' is known and matches the RSA host key.
debug1: Found key in /home/praj/.ssh/known_hosts:13
debug1: rekey out after 4294967296 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: rekey in after 4294967296 blocks
debug1: pubkey_prepare: ssh_get_authentication_socket: No such file or directory
debug1: Will attempt key: /home/praj/.ssh/id_rsa RSA SHA256:380ueVYrrzxGrkPRep4huj pHdElPoz8iCTSYvKD5Hg explicit
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Offering public key: /home/praj/.ssh/id_rsa RSA SHA256:380ueVYrrzxGrkPRep4huj pHdElPoz8iCTSYvKD5Hg explicit
debug1: Server accepts key: /home/praj/.ssh/id_rsa RSA SHA256:380ueVYrrzxGrkPRep4huj pHdElPoz8iCTSYvKD5Hg explicit
Enter passphrase for key '/home/praj/.ssh/id_rsa': 
debug1: Authentication succeeded (publickey).
Authenticated to host.bastion.ap-mumbai-1.oci.oraclecloud.com ([192.29.162.226]:22).
debug1: Local connections to LOCALHOST:6443 forwarded to remote address 10.0.0.14:6443
debug1: Local forwarding listening on 127.0.0.1 port 6443.
debug1: channel 0: new [port listener]
debug1: Entering interactive session.
debug1: pledge: network
debug1: Connection to port 6443 forwarding to 10.0.0.14 port 6443 requested.
debug1: channel 1: new [direct-tcpip]
debug1: Connection to port 6443 forwarding to 10.0.0.14 port 6443 requested.
debug1: channel 2: new [direct-tcpip]
debug1: Connection to port 6443 forwarding to 10.0.0.14 port 6443 requested.
debug1: channel 3: new [direct-tcpip]
debug1: Connection to port 6443 forwarding to 10.0.0.14 port 6443 requested.
debug1: channel 4: new [direct-tcpip]
debug1: channel 1: free: direct-tcpip: listening port 6443 for 10.0.0.14 port 6443, connect from 127.0.0.1 port 44054 to 127.0.0.1 port 6443, nchannels 5
debug1: Connection to port 6443 forwarding to 10.0.0.14 port 6443 requested.
debug1: channel 1: new [direct-tcpip]
debug1: channel 2: free: direct-tcpip: listening port 6443 for 10.0.0.14 port 6443, connect from 127.0.0.1 port 44056 to 127.0.0.1 port 6443, nchannels 5
debug1: channel 3: free: direct-tcpip: listening port 6443 for 10.0.0.14 port 6443, connect from 127.0.0.1 port 44058 to 127.0.0.1 port 6443, nchannels 4
debug1: channel 4: free: direct-tcpip: listening port 6443 for 10.0.0.14 port 6443, connect from 127.0.0.1 port 44060 to 127.0.0.1 port 6443, nchannels 3
debug1: channel 1: free: direct-tcpip: listening port 6443 for 10.0.0.14 port 6443, connect from 127.0.0.1 port 44062 to 127.0.0.1 port 6443, nchannels 2
^Cdebug1: channel 0: free: port listener, nchannels 1
Killed by signal 2.

Мой кластер работает на двух узлах на базе ARM (гибкая виртуальная машина A1) с ОС Oracle Linux 7.9 по умолчанию в качестве ОС и Kubernetes версии 1.20.8

Кто-нибудь может сказать мне, в чем проблема? Требуется ли какая-либо дополнительная конфигурация для подключения к API Kubernetes?

Комментарии:

1. Возможной причиной может быть то, что теперь у вас может быть правильная запись в списке безопасности, позволяющая подключаться от Бастиона к узлам Kubernetis. Пожалуйста, проверьте, есть ли у вас входная связь от бастиона(в основном 192.X.X.X или 172.X.X.X) с виртуальной машиной kubernetis

2. Я тоже пробовал это, разрешая подключения к порту API Kube (6443) с IP-адреса Бастиона. Также стоит отметить, что правила входа по умолчанию для 6443 в первую очередь разрешали 0.0.0.0/0 (полный интернет). Но, как ни странно, это не сработало. Может быть, это какая-то ошибка/проблема с сервисом от oci, которую я не смог уловить.

3. Являются как бастион, так и кластер Кубернетов на одном и том же VCN. Пожалуйста, проверьте, есть ли маршрут в таблице маршрутов между ними. docs.oracle.com/en-us/iaas/Content/Network/Tasks/…

Ответ №1:

Быстрый вопрос:

  • Предполагая, что вы настроили правильные правила входа в список безопасности подсети Bastion и создали сеанс и переадресацию портов (SSH-туннель), можете ли вы войти в рабочий узел со своего ПК с помощью простой команды SSH на порту 6443?

Примечание: Вам понадобится закрытый ключ для входа в рабочий узел, и что рабочий узел должен быть создан с открытым ключом для интерактивного входа.

Ответ №2:

Я смог подключиться к частному кластеру K8s со своего локального компьютера по SSH с помощью следующих действий:

  1. Создайте отдельную общедоступную подсеть внутри того же VCN кластера для целевой подсети bastion.
  2. Используйте таблицу общедоступных маршрутов сети кластера по умолчанию для новой подсети. В этой таблице маршрутов уже есть правило маршрута с целью интернет-шлюза, которое позволит передавать трафик с локального компьютера на API кластера и наоборот.
  3. Добавьте список безопасности в подсеть с правилом выхода 0.0.0.0/0 в качестве CIDR назначения, разрешающего все порты.
  4. Обязательно добавьте CIDR порта подсети в вход списка безопасности подсети, используемой API кластера.
  5. Создайте бастион OCI. Не забудьте использовать новую подсеть в качестве целевой подсети.
Метки: