ETCD搭建
-
- systemd啟動etcd服務的時候出現錯誤：Failed at step CHDIR spawning /usr/bin/etcd: No such file or directory
解決辦法：etcd.service服務配置文件中設置的工作目錄WorkingDirectory=/var/lib/etcd/必須存在，否則會報以上錯誤
-
- systemd啟動etcd服務的時候出現錯誤：cannot assign requested address
解決辦法：綁定阿里雲的私網IP
-
- dial tcp 127.0.0.1:4001: getsockopt: connection refused
解決辦法：ETCD_LISTEN_CLIENT_URLS需要配置http://127.0.0.1:2379，特別注意，此處是http而不是https
- flannel
- failed to retrieve network config: 100: Key not found (/atomic.io)
解決辦法：/etc/sysconfig/flanneld中的內容，FLANNEL_ETCD_PREFIX很可能是/atomic.io/network，將其改為/coreos.com/network。或者也可以通過-etcd-prefix指定
-
- failed to retrieve network config: invalid character '.' after object key:value pair
解決辦法：這種問題一般是向etcd中導入網絡信息的時候出錯了，檢查寫入的字符的中英文，ip地址是否有引號等語法問題
-
- 新增etcd節點后，啟動systemd服務出現Job for etcd.service failed because a timeout was exceeded
解決辦法：首先確保服務配置正確。出現該問題的原因可能時因為etcd的data-dir中的殘留信息導致的，刪除data-dir中的內容，重新啟動etcd服務
-
- 部署app的時候出現類似如下錯誤，這種一般是模板中定義的類型錯誤引起的，如下錯誤為 v1.ObjectMeta: Annotations: ReadString: expects " or n, but found t，可以查看Annotations中是否有錯誤
Error from server (BadRequest): error when creating "sample-app.deploy.yaml": Deployment in version "v1beta2" cannot be handled as a Deployment: v1beta2.Deployment: Spec: v1beta2.DeploymentSpec: Template: v1.PodTemplateSpec: ObjectMeta: v1.ObjectMeta: Annotations: ReadString: expects " or n, but found t, error found in #10 byte of ...|/scrape":true},"labe|..., bigger context ...|rometheus.io/port":"8080","prometheus.io/scrape":true},"labels":{"app":"sample-app"}},"spec":{"conta|...
- kubelet
- 啟動kubelet的時候出現如下錯誤，導致kubelet啟動失敗。查看kube-apiserver節點的系統日志messages，可以看到錯誤日志“authentication.go:64] Unable to authenticate the request due to an error: [invalid bearer token, [invalid bearer token, invalid bearer token]]”，檢查kuber-apiserver啟動參數中的token.csv和kubelet啟動參數中指定的bootstrap文件bootstrap.kubeconfig中的token值是否一致，此外該token必須為實際數值，不能使用變量代替。出現網絡錯誤日志的原因是部署中使用了flannel插件。
1 Mar 22 00:27:00 node1 kubelet[701]: W0322 00:27:00.078565 701 cni.go:171] Unable to update cni config: No networks found in /etc/cni/net.d 2 Mar 22 00:27:00 node1 kubelet[701]: I0322 00:27:00.081847 701 server.go:374] Version: v1.10.0-alpha.3 3 Mar 22 00:27:00 node1 kubelet[701]: I0322 00:27:00.081897 701 feature_gate.go:226] feature gates: &{{} map[]} 4 Mar 22 00:27:00 node1 kubelet[701]: I0322 00:27:00.081960 701 plugins.go:89] No cloud provider specified. 5 Mar 22 00:27:00 node1 kubelet[701]: F0322 00:27:00.106954 701 server.go:231] failed to run Kubelet: cannot create certificate signing request: Unauthorized
疑問解決
-
kubelet使用tls bootstrapping功能時，kubeconfig文件中指定的了token，為何設置集群參數的時候還需要指定CA公鑰？
# 設置集群參數 kubectl config set-cluster kubernetes \ --certificate-authority=/etc/kubernetes/ssl/ca.pem \ --embed-certs=true \ --server=${KUBE_APISERVER} \ --kubeconfig=bootstrap.kubeconfig # 設置客戶端認證參數 kubectl config set-credentials kubelet-bootstrap \ --token=${BOOTSTRAP_TOKEN} \ --kubeconfig=bootstrap.kubeconfig原因是，kubelet使用bootstrap功能時，需要使用ca證書通過apiserver的認證，使用token進行授權。證書和token分別屬於兩個階段使用的內容。
-
k8s中哪些組件需要進行tls證書認證，哪些不需要？
kube-scheduler、kube-controller-manager 一般和 kube-apiserver 部署在同一台機器上，它們使用非安全端口和 kube-apiserver通信，非安全端口默認為http的8080，可以使用--insecure-port指定，監聽非安全端口的地址默認為127.0.0.1，可以使用--insecure-bind-address指定；
kubelet、kube-proxy、kubectl 部署在其它 Node 節點上，如果通過安全端口訪問 kube-apiserver，則必須先通過 TLS 證書認證，再通過 RBAC 授權。安全端口默認為https的6443，可以使用--secure-port指定，監聽安全端口的地址默認為0.0.0.0（監聽所有接口），可以使用--bind-address指定。