Панель управления kubernetes доступна с помощью curl, но не chrome / firefox через прокси-сервер kubectl - PullRequest
Новая
       64

Панель управления kubernetes доступна с помощью curl, но не chrome / firefox через прокси-сервер kubectl

0 голосов
/ 27 мая 2020

У меня есть два очень разных кластера (один kubernetes 1.13 с приборной панелью 1.0 и созданный с помощью kops в aws; другой использует kubernetes 1.14 с приборной панелью 2.0 и создан с помощью EKS) одинаковая проблема для обоих, и я использую kubectl 1.17 для взаимодействия с обоими. Как только я запустил kubectl proxy, я смогу добраться до панели управления, которую я только что установил, через curl . Например, с приборной панелью 2.0 в более новом кластере EKS:

В одном терминале: 

$ kubectl proxy 
Starting to serve on 127.0.0.1:8001

В другом терминале 

$ curl http://127.0.0.1:8001/api/v1/namespaces/kubernetes-dashboard/services/https:kubernetes-dashboard:/proxy/
<!--
Copyright 2017 The Kubernetes Authors.

Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
You may obtain a copy of the License at

    http://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.
-->

<!doctype html>
<html lang="en">

<head>
  <meta charset="utf-8">
  <title>Kubernetes Dashboard</title>
  <link rel="icon" type="image/png" href="assets/images/kubernetes-logo.png"/>
  <meta name="viewport" content="width=device-width">
<link rel="stylesheet" href="styles.d8a1833bf9631b49f8ae.css"></head>

<body>
  <kd-root></kd-root>
<script src="runtime.a3c2fb5c390e8fb10577.js" defer=""></script><script src="polyfills-es5.ddf623b9f96429e29863.js" nomodule="" defer=""></script><script src="polyfills.24a7a4821c30c3b30717.js" defer=""></script><script src="scripts.391d299173602e261418.js" defer=""></script><script src="main.a0d83b15387cfc420c65.js" defer=""></script></body>

</html>

Очевидно, что служба приборной панели доступна и отвечает на запрос. html немного отличается от другой комбинации кластера / приборной панели, но все еще без ошибок.

Однако тот же самый URL-адрес из chrome или firefox (работающий на том же хосте, конечно) дает мне ошибка: 

This site can’t be reached
127.0.0.1 refused to connect.
Try:
Checking the connection
Checking the proxy and the firewall
ERR_CONNECTION_REFUSED

Сама приборная панель 2.0 кажется счастливой: 

$ kubectl get all -n kubernetes-dashboard
NAME                                             READY   STATUS    RESTARTS   AGE
pod/dashboard-metrics-scraper-76679bc5b9-k7qjp   1/1     Running   0          136m
pod/kubernetes-dashboard-565688d4c4-dtw5w        1/1     Running   0          136m

NAME                                TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)    AGE
service/dashboard-metrics-scraper   ClusterIP   172.20.42.193    <none>        8000/TCP   142m
service/kubernetes-dashboard        ClusterIP   172.20.232.104   <none>        443/TCP    142m

NAME                                        READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/dashboard-metrics-scraper   1/1     1            1           142m
deployment.apps/kubernetes-dashboard        1/1     1            1           142m

NAME                                                   DESIRED   CURRENT   READY   AGE
replicaset.apps/dashboard-metrics-scraper-6c554969c6   0         0         0       137m
replicaset.apps/dashboard-metrics-scraper-76679bc5b9   1         1         1       142m
replicaset.apps/kubernetes-dashboard-565688d4c4        1         1         1       142m
replicaset.apps/kubernetes-dashboard-56c5f95c6b        0         0         0       137m

Есть идеи, что не так? Как это возможно, что он работает с curl, а не с веб-браузером?

Обновленная информация:

Я проверил ifconfig: 

$ ifconfig
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 172.17.0.2  netmask 255.255.0.0  broadcast 172.17.255.255
        ...    
lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        ...

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

В одном терминале: 

kubectl proxy --address='172.17.0.2' --accept-hosts='.*'

Затем chrome браузер на http://172.17.0.2: 8001 / api / v1 / namespaces / kubernetes-dashboard / services / https:kubernetes-dashboard: / proxy / показывает экран входа в систему.

Оба флага необходимы, иначе ни curl, ни браузер не будут работать (ответ запрещен, если я не использую --accept-hosts, хотя этот ответ исходит от службы, поэтому он, по крайней мере, лучше, чем при использовании шлейф).

Замена на 127.0.0.1 на localhost не помогает. Я могу получить доступ к серверу api, только если я использовал полную команду прокси и http://172.17.0.2: 8001 / api .

Кто-нибудь знает, почему chrome не обрабатывает 127.0.0.1, тогда как curl обрабатывает, и почему этот accept-hosts необходим при скручивании 172,12 IP, но не при использовании 127 IP?

1 Ответ

1 голос
/ 27 мая 2020

Что ж, это неловко, но я полагаю, что могу оставить этот вопрос и опубликовать ответ на случай, если кто-то забудет очевидное:

Меня поместили в контейнер docker, работающий на моем хосте, когда выполнение команд прокси curl и kubectl (я забыл! поскольку он работает без остановки). Контейнер совместно использует сеть хоста, поэтому 172.17 работал из браузера, но не через loopback.

Если вы настроили контейнер для переадресации портов, скажем, с порта 8080 на 8080 (docker ... -p 8080:8080 ...), тогда также работает следующая команда прокси (изнутри этого контейнера): 

$ kubectl proxy --port 8080 --address='0.0.0.0'

ie просмотр http://localhost: 8080 / api / v1 / namespaces / kubernetes-dashboard / services / https:kubernetes-dashboard: / proxy / # / login на хосте работает.

Извините за ошибку!

...