私は、マスターと3つのノードで構成されたKubernetesクラスタをセットアップしました。私は、セットアップのために、次の使用：
1. kubeadm（1.7.1）
2. kubectl（1.7.1）
3. kubelet（1.7.1）
4.織り（織り-KUBE-1.6）
5.ドッカ（17.06.0〜CE-0〜のdebian）クラスタ外からKubernetesダッシュボードにアクセスできない
すべての4つのインスタンスは、GoogleクラウドでセットアップされているとOSがあるのDebian GNU/Linuxの9（ストレッチ）
$ kubectl get pods --all-namespaces
NAMESPACE NAME READY STATUS RESTARTS AGE
kube-system etcd-master 1/1 Running 0 19m
kube-system kube-apiserver-master 1/1 Running 0 19m
kube-system kube-controller-manager-master 1/1 Running 0 19m
kube-system kube-dns-2425271678-cq9wh 3/3 Running 0 24m
kube-system kube-proxy-q399p 1/1 Running 0 24m
kube-system kube-scheduler-master 1/1 Running 0 19m
kube-system weave-net-m4bgj 2/2 Running 0 4m
$ kubectl get nodes
NAME STATUS AGE VERSION
master Ready 1h v1.7.1
node1 Ready 6m v1.7.1
node2 Ready 5m v1.7.1
node3 Ready 7m v1.7.1
apiserverプロセスは次のパラで実行されていますメートル：
root 1148 1101 1 04:38 ? 00:03:38 kube-apiserver
--experimental-bootstrap-token-auth=true --allow-privileged=true
--secure-port=6443
--insecure-port=0 --service-cluster-ip-range=10.96.0.0/12
--kubelet-preferred-address-types=InternalIP,ExternalIP,Hostname
--requestheader-username-headers=X-Remote-User
--authorization-mode=Node,RBAC --advertise-address=10.128.0.2
--etcd-servers=http://127.0.0.1:2379
私はダッシュボードにアクセスするために、次のコマンドを実行しました：
$ kubectl create -f https://rawgit.com/kubernetes/dashboard/master/src/deploy/kubernetes-dashboard.yaml
serviceaccount "kubernetes-dashboard" created
clusterrolebinding "kubernetes-dashboard" created
deployment "kubernetes-dashboard" created
をしかし、ダッシュボードにはアクセスできませんでしたので、それは非常に関連見えなかったが、私も次のコマンドを試してみました。それをどこかで見た。
kubectl create clusterrolebinding add-on-cluster-admin --clusterrole=cluster-admin --serviceaccount=kube-system:default
最後に、私は私の問題に関連して見linkに出くわしました。私が試したが、私は次のエラーになっています：
d:\Work>kubectl --kubeconfig=d:\Work\admin.conf proxy -p 80
Starting to serve on 127.0.0.1:80I0719 13:37:13.971200 5680 logs.go:41] http: proxy error: context canceled
I0719 13:37:15.893200 5680 logs.go:41] http: proxy error: dial tcp 124.179.54.120:6443: connectex: No connection could be made
because the target machine actively refused it.
私はポート22上の私のラップトップからマスターIP（124.179.54.120）へtelnetをすれば、それは動作しますが、それはポート6443.ポートでは動作しませんが以下に示すように6443は私のノードマシンから与えられたマスタポート上のncにできていて、マスタ上で開いている：私のラップトップ上で
[email protected]:~$ nc -zv 10.128.0.2 6443
master.c.kubernetes-174104.internal [10.128.0.2] 6443 (?) open
は、ファイアウォールがマスターですでに無効と私も無効にファイアウォールです。 Googleクラウドコンソールで
# iptables -L
Chain INPUT (policy ACCEPT)
target prot opt source destination
KUBE-SERVICES all -- anywhere anywhere /* kubernetes service portals */
Chain FORWARD (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
KUBE-SERVICES all -- anywhere anywhere /* kubernetes service portals */
Chain KUBE-SERVICES (2 references)
target prot opt source destination
、私はGoogleクラウドファイアウォールのルールで進入要求にTCPおよびUDPポート6443を追加しましたが、それでも私はhttp://localhost/ui
マスターの設定の詳細を使用してダッシュボードにアクセスすることができません： 
ファイアウォール設定の詳細：
UPDATE：d:\Work\admin.conf
apiVersion: v1
clusters:
- cluster:
certificate-authority-data: <CA_cert>
server: https://124.179.54.120:6443
name: kubernetes
contexts:
- context:
cluster: kubernetes
user: kubernetes-admin
name: [email protected]
current-context: [email protected]
kind: Config
preferences: {}
users:
- name: kubernetes-admin
user:
client-certificate-data: <client-cert>
client-key-data: <client-key>
の内容UPDATE1：kubectlプロキシのみ、着信localhostからの接続との両方のIPv4を受け入れるデフォルトで
[email protected]:~$ curl -v http://127.0.0.1:8001
* Rebuilt URL to: http://127.0.0.1:8001/
* Trying 127.0.0.1...
* TCP_NODELAY set
* Connected to 127.0.0.1 (127.0.0.1) port 8001 (#0)
> GET/HTTP/1.1
> Host: 127.0.0.1:8001
> User-Agent: curl/7.52.1
> Accept: */*
>
< HTTP/1.1 502 Bad Gateway
< Date: Thu, 20 Jul 2017 06:57:48 GMT
< Content-Length: 0
< Content-Type: text/plain; charset=utf-8
<
* Curl_http_done: called premature == 0
* Connection #0 to host 127.0.0.1 left intact
'kubectl get pods'が動作する場合は、' master-node：6443'と通信できることを意味します。これは、 'kubectl proxy'が何か他のものを参照していることを意味します。 'd：\ Work \ admin.conf'をここに貼り付けることができますか？また、ポート6443はIngressではなく 'kube-apiserver'に属します。 Ingressは、通常、ポート80と443で実行するように設定されています。 –
'kubectl get pods'がマスター自体で実行されました。私の地元のノートパソコンからコマンドが実行されたことはありません。また、Ingressによると、Google Containerの[ファイアウォールルール]（https://cloud.google.com/compute/docs/vpc/firewalls）を参照していました。上記のポストでは、ファイアウォールのスナップショットにホワイトリストに登録されたポートが表示されています。混乱させて申し訳ありません。 – Technext
@EugeneChow：個人的なメッセージを送る方法はないので、私はここで言及することを考えました。証明書を投稿する前に何百もの文字が削除されました。それでも間違いなく誰かが起こることは間違いありません。編集に感謝し、あなたの変更は間違いなく良く見えます。 :) – Technext