У меня есть два очень разных кластера (один 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.
Кто-нибудь знает, почему хром не обрабатывает 127.0.0.1, тогда как curl делает, и почему этот accept-hosts необходим при скручивании IP 172.12, но не при использовании 127 IP?
