Kubernetes：etcdコンポーネントサービスの健全性はどのようにチェックされていますか？

Question

AWSに部分的に見えるk8sクラスタがありますが、実際には展開は行われません。コンポーネントの健全性を見ると、etcdは不健全なものとして表示されます。それがhttpsに対するHTTPとして照会なっetcdエンドポイントの問題だようにこれが見えます：

kubectl --kubeconfig=Lab_42/kubeconfig.yaml get componentstatuses --namespace=default 
NAME     STATUS  MESSAGE                         ERROR 
controller-manager Healthy  ok                          
scheduler   Healthy  ok                          
etcd-2    Unhealthy Get http://ip-10-42-2-50.ec2.internal:2379/health: malformed HTTP response "\x15\x03\x01\x00\x02\x02" 
etcd-1    Unhealthy Get http://ip-10-42-2-41.ec2.internal:2379/health: malformed HTTP response "\x15\x03\x01\x00\x02\x02" 
etcd-0    Unhealthy Get http://ip-10-42-2-40.ec2.internal:2379/health: malformed HTTP response "\x15\x03\x01\x00\x02\x02" 

私は--ca-configオプションを使用しますが、apiserver実行で直接設定値を入れていませんよ。マイapiserverの設定：

command: 
    - /hyperkube 
    - apiserver 
    - --advertise-address=10.42.2.50 
    - --admission_control=NamespaceLifecycle,NamespaceAutoProvision,LimitRanger,SecurityContextDeny,ServiceAccount,ResourceQuota 
    - --allow-privileged=true 
    - --authorization-mode=AlwaysAllow 
    - --bind-address=0.0.0.0 
    - --client-ca-file=/etc/ssl/kubernetes/k8s-ca.pem 
    - --etcd-cafile=/etc/ssl/etcd/etcd-ca.pem 
    - --etcd-certfile=/etc/ssl/etcd/etcd-client.pem 
    - --etcd-keyfile=/etc/ssl/etcd/etcd-client-key.pem 
    - --etcd-servers=https://127.0.0.1:2379 
    - --kubelet-certificate-authority=/etc/ssl/kubernetes/k8s-ca.pem 
    - --kubelet-client-certificate=/etc/ssl/kubernetes/k8s-apiserver-client.pem 
    - --kubelet-client-key=/etc/ssl/kubernetes/k8s-apiserver-client-key.pem 
    - --kubelet-https=true 
    - --logtostderr=true 
    - --runtime-config=extensions/v1beta1/deployments=true,extensions/v1beta1/daemonsets=true,api/all 
    - --secure-port=443 
    - --service-account-lookup=false 
    - --service-cluster-ip-range=10.3.0.0/24 
    - --tls-cert-file=/etc/ssl/kubernetes/k8s-apiserver.pem 
    - --tls-private-key-file=/etc/ssl/kubernetes/k8s-apiserver-key.pem 

実際の問題は、単純な展開が、実際に何もしないということであり、私たちはミックスで他の多くの証明書を持っていないとしても、問題を引き起こしている不健康であることetcdかどうかわからないんだけど。私は地元のhttpsを使用する場合、私は実際にクエリを直接etcdでき

kubectl --kubeconfig=Lab_42/kubeconfig.yaml get deployments --namespace=default 
NAME    DESIRED CURRENT UP-TO-DATE AVAILABLE AGE 
nginx-deployment 3   0   0   0   2h 

が

/usr/bin/etcdctl --ca-file /etc/ssl/etcd/etcd-ca.pem --cert-file /etc/ssl/etcd/etcd-client.pem --key-file /etc/ssl/etcd/etcd-client-key.pem 
--endpoints 'https://127.0.0.1:2379' \ 
get /registry/minions/ip-10-42-2-50.ec2.internal | jq "." 
{ 
    "kind": "Node", 
    "apiVersion": "v1", 
    "metadata": { 
    "name": "ip-10-42-2-50.ec2.internal", 
    "selfLink": "/api/v1/nodes/ip-10-42-2-50.ec2.internal", 
...SNIP 

Answer 1

エンドポイントだから、コンポーネントステータスが赤ニシンだったことが判明します。実際の問題は、私のコントローラーの設定が間違っていたためです。マスタはhttp://127.0.0.1:8080の代わりにhttp://master_ip:8080に設定されました。 apiserverの安全でないポートは外部インターフェイスには公開されていないため、コントローラは接続できませんでした。

ループバックが安全でないか、または：443が問題を解決しました。

CoreOSハイパーキューブとkubelet-wrapperを使用すると、自動的にリンクされた/ var/log/containersのコンテナログが失われます。それらを見つけるには、次のようなことをすることができます：

ls -latr /var/lib/docker/containers/*/*-json.log 

私は実際にこのように私の問題の原因となるエラーを見ることができました。

Answer 2

私はあなたのKUBE-apiserverのconfigオプション--etcd-server=xxx