升级到Kubernetes1.8.4的配置细节差异以及k8s几个不常见的坑

kubernetes已经发布了1.8，今天需要在一个新机房部署k8s环境，于是决定尝试最新版本1.8,部署过程中故意和以前的部署步骤有些不同，故而出现了一些问题，并且发现k8s这有个新版本本身几个差异地方记录如下：

1.首先遇到的问题便是get-kub-binaries.sh执行之后，无法正常下载到新版的程序压缩包了，在1.7以前都不需要科学上网就可以下载的。我只好在设置好代理的服务器上执行它下载好，然后传到服务器上把client按照以前旧版本的路径规划解压到platform目录下，把server直接解压到server目录。

2.kubelet的启动参数中，--require-kubeconfig已经不用了，如果配置了会在日志中看到警告。并且，--experimental-bootstrap-kubeconfig已经去掉了experimental-这个单词。

3.新版本的kubelet启动时会严格判断swap是否开启，如果开启会报错，使用sfdisk -l查看一下哪个区分是swap分区，使用swapoff /dev/xvda2这样的命令把它关闭，或者直接swapoff -a关闭所有的swap分区，并且把/etc/fstab文件中指定swap那一行删除，使用swapoff 命令报错提示无法分配到内存。那是因为内存已经使用了太多，超过了物理内存，使用了swap，所以必需释放一些内存以便操作系统将swap中已经使用的转移到物理内存中，如果是docker启动了太多容器，systemctl restart docker就可以了。另外一种方式是在配置文件中指定--fail-swap-on为false,但是这样会影响k8s的调度决策算法。

4.在1.8.4增加了Node Authorization机制，需要在kubelet中的配置文件中--authorization-mode=增加一个Node值，并在--admission-control=...,增加一个NodeRestriction,..不然会报错。并删除 system:node cluster role binding

5.dashboard从1.7.1升级到1.8.0时，移除了kubernetes-dashboard-init-amd64这个镜像，仅使用kubernetes-dashboard-amd64镜像就可以了，但是配置tls的密钥的路径却由绝对路径改为了相对路径，原来的- --tls-key-file=/certs/tls.key和 - --tls-cert-file=/certs/tls.crt要改为- --tls-key-file=tls.key和          - --tls-cert-file=tls.crt,否则会报一个错误open /certs//certs/tls.crt: no such file or directory，然后就失败了。

顺便记录一下我遇到的几个不常见的坑。

1.网络上的示例都是使用自签名的证书，我尝试了采用CA签名的证书，因为是通配符2级域名的，所以尝试了好多次都失败了，甚至ETCD集群本身使用这种CA机构签名的证书都不能建立起集群。由于对证收的检验机制还算不上完全掌握，所以暂时放弃。

2.如果在启动kubelet时，日志中提示No api server defined - no node status update will be sent.这很有可能是kubelet的配置文件或启动参数中忘记指定api-server或者参数写错了。

3.如果一个node已经发送了certificate请求，并且在master上已经approve了，但是查看csr的状态却发现只有approved，没有issued,这很可能是kube-manager-controller没有启动或者是无意停掉了。我因为这个事情就浪费了一上午的时间去排查，最后才发现这个原因。

4.在pod中使用nfs时，如果提示一个错误

09/volumes/kubernetes.io~nfs/nfs-data-storage
Output: Running scope as unit run-30478.scope.
mount: wrong fs type, bad option, bad superblock on 10.0.0.150:/data,
       missing codepage or helper program, or other error
       (for several filesystems (e.g. nfs, cifs) you might
       need a /sbin/mount.<type> helper program)


       In some cases useful info is found in syslog - try
       dmesg | tail or so.

那是因为pod所在的node没有安装nfs-utils，最好在每个node上都安装好nfs-utils

5.如果启动kubelet时报错failed to run Kubelet: cannot create certificate signing request: certificatesigningrequests.certificates.k8s.io is forbidden: User "kubelet-bootstrap" cannot create certificatesigningrequests，是由于在master上忘记创建

clusterrolebinding ，执行

kubectl create--insecure-skip-tls-verifyclusterrolebinding kubelet-bootstrap \ --clusterrole=system:node-bootstrapper \ --user=kubelet-bootstrap就可以解决了。

6.nginx-ingress的https问题，已经配置好了证书，后端是k8s的dashboard组件，它也是必需用https访问，但在官网的示例中大都在nginx就终止了tls，转向后端http了。这样访问时会在dashboard中输出错误http: TLS handshake error from 10.1.64.0:51000: tls: first record does not look like a TLS handshake，而看nginx-ingress-controller也会有一个错误，大致表现为：[error] 3790#3790: *215 upstream sent no valid HTTP/1.0 header while reading response header from upstream, client: x.x.x.x, server: k8s.domain.com, request: "GET / HTTP/2.0", upstream: "http://10.1.x.x:8443/", host: "k8s.domain.com",进一步查看对应的ingress生成的nginx配置文件，发现它转发的上游是http并非https，所以导致这个错误，查看官方文档得知，

需要在metadata指定一下metadata，

annotations: ingress.kubernetes.io/ssl-passthrough: "true"

7.nginx-ingress代理k8s的dashboard的问题，如果我们有权限机构发放的证书，肯定希望访问k8s的dashboard时也使用这个证书，浏览器的地址栏是绿色的多酷啊。但是k8s的dashboard的官方示例中，证书是叫做dashboard.crt和dashboard.key，它的yaml文件中也是指定这两个文件名。如果ingress也使用通过这两个文件创建的那个secret，dashboard启动没有问题，ingress-controller会报错，error obtaining PEM from secret kube-system/kubernetes-dashboard-certs: no keypair or CA cert could be found in kube-system/kubernetes-dashboard-certs，其实并不是真的证书有问题，而是它默认寻找的是叫tls.crt和tls.key的证书，所以这个dashboard.crt它不能正确的识别。

8.当启用了nginx-ingress-controller的basic认证时，日志中出现错误 [crit] 1438#1438: *11994 crypt_r() failed (22: Invalid argument)。原来是由于在创建密码文件时使用了htpasswd命令中的-B选项(

-B Force bcrypt encryption of the password (very secure).

)，在docker-registry仓库的认证是支持这种方式的，但在nginx中是不支持的，所以不能使用-B选项

9. traefik-ingress-controller它不支持ingress.kubernetes.io/ssl-passthrough这个annotation，写了也不起作用的。

持续更新....