最近跨网段配置k8s calico网络遇到了问题，简短记录一下解决过程。 测试环境本地的物理服务器上有一个k8s集群，版本是1.20，calico网络组件版本为3.17。 现在需要往这个k8s集群中添加2个新的node节点，新的节点在本地Openstack的虚拟机上。 Openstack虚拟机的网络和测试环境物理服务器之间网络已经打通，但属于不同的网段， 已在Openstack中安全组中配置了允许物理机服务器网段所有TCP协议进入。
...近日使用团队内部一直在维护的ansible role playbook初始化一个新的k8s集群(v1.19)时遇到了问题，kubectl get node命令显示各个节点一直是NotReady状态，同时各节点上的kubelet日志一直报下面的错误:
1... kubelet.go:2209] node "node1" not found
2... reflector.go:127] k8s.io/client-go/informers/factory.go:134: Failed to watch *v1.Node: failed to list *v1.Node: nodes "node1" is forbidden: User "system:node:node1" cannot list resource "nodes" in API group "" at the cluster scope
3... failed to ensure node lease exists, will retry in 7s, error: leases.coordination.k8s.io "node1" is forbidden: User "system:node:node1" cannot get resource "leases" in API group "coordination.k8s.io" in...mespace "kube-node-lease"
4... kubelet_node_status.go:470] Error updating node status, will retry: error getting node "node1": nodes "node1" is forbidden: User "system:node:node1" cannot get resource "nodes" in API group "" at the cluster scope
从日志中初步分析是kubelet对apiserver的访问权限问题引起，由于使用这个ansible role是团队内部一直在维护的，目前管理着线上线下共4套k8s集群，一直没有这个问题出现。于是初步怀疑已有的4套集群是经历了各个历史版本逐步升级到1.19的，这个过程中可能k8s给自动做了相关的配置兼容性， 现在初始化的这个新集群因为是全新安装，可能我们的ansible playbook生成的配置已经不正确了。
...话说Kubernetes都要弃用Dockershim了，因此是时候学习Containerd了。 本文先简单整理一下Kubernetes、Docker、Containerd之间的渊源和纠葛。
这里略过早期Docker的发展历史，大概就是在docker如日中天的时候，社区要搞容器化标准，成立了OCI(Open Container Initiaiv)，OCI主要包含两个规范，一个是容器运行时规范(runtime-spec)，一个是容器镜像规范(image-spec)。
docker的公司也在OCI中，这里略过在推动标准化过程中各大厂各自心里的"小算盘"和"利益考虑"，docker在这个过程中由一个庞然大物逐渐拆分出了containerd、runc等项目，
docker公司将runc捐赠给了OCI，后来将containerd捐赠给了CNCF。
kubeadm是Kubernetes官方提供的用于快速安装Kubernetes集群的工具，伴随Kubernetes每个版本的发布都会同步更新，kubeadm会对集群配置方面的一些实践做调整，通过实验kubeadm可以学习到Kubernetes官方在集群配置上一些新的最佳实践。
...kubectl插件机制在Kubernetes 1.14宣布稳定，进入GA状态。kubectl的插件机制就是希望允许开发者以独立的二进制形式发布自定义的kubectl子命令。
kubectl插件可以使用任意语言开发，如可以是一个bash、python的脚本，也可以是其他语言开发编译的二进制可执行文件，只要最终将脚本或二进制可执行文件以kubectl-的前缀放到PATH中即可。使用kubectl plugin list可以在PATH中查看有哪些插件。
kubeadm是Kubernetes官方提供的用于快速安装Kubernetes集群的工具，伴随Kubernetes每个版本的发布都会同步更新，kubeadm会对集群配置方面的一些实践做调整，通过实验kubeadm可以学习到Kubernetes官方在集群配置上一些新的最佳实践。
...Kubernetes集群内部是一套单独的网络，与外部网络相隔离，Kubernetes提供了NodePort、LoadBalancer、Ingress等方式用于将集群内部的Service暴露到集群外部， 但这些方式都更适用于将边缘服务暴露出去。例如，一个产品由很多微服务组成，这些微服务大多数都是内部服务，只有少数作为边缘服务需要暴露到集群外部供用户使用。 而开发人员是存在从Kubernetes外部访问和调试这些内部服务的需求的，尤其是针对测试环境的Kubernetes集群，这个需求更加必要。针对这个需求，有以下两种实现方式：
...Kubernetes 1.13已经发布。我们线上的版本升级都是按照比官方低一个版本的节奏。 因此可以开始考虑将团队线上环境的Kubernetes集群从1.11升级到1.12了。 本文记录了在测试环境中的演练过程。
当前Kubernetes 1.12的小版本是1.12.5。 在升级之前一定要多读几遍官方的升级须知Kubernetes 1.12 - Action Required Before Upgrading。
...前面在Kubernetes Ingress实战(四)：Bare metal环境下Kubernetes Ingress边缘节点的高可用
和Kubernetes Ingress实战(五)：Bare metal环境下Kubernetes Ingress边缘节点的高可用(基于IPVS)中Bare metal环境下Kubernetes Ingress边缘节点的高可用的两种方法，都是基于externalIps来暴露nginx-ingress-controller的Service到集群外部的，前者的kube-proxy没有开启IPVS，后者的kube-proxy开启了IPVS。
前段时间测试将一套Kubernetes环境的kube-proxy切换成了ipvs模式，参见Kubernetes kube-proxy开启IPVS模式。
这套Kubernetes集群上主要运行http restful和gRPC两类服务，切换后这段时间还算稳定，只是最近某些客户端服务在调用gRPC服务时小概率出现Connection reset by peer的错误。