容器的单进程模型 容器的单进程模型是指推荐在一个容器里只运行一个进程。 容器的单进程模型并不是说容器里只能运行一个进程，而是因为容器本身没有管理多个进程的能力，推荐在一个容器里只运行一个进程。 在正常的Linux操作系统里都有个1号进程init，例如CentOS的systemd，所有的其他进程都是1号进程的子进程或者是子进程的子进程。 1号进程具有进程管理能力，例如对僵尸进程的管理。而容器中的1号进程就是容器运行的应用本身，它是没有进程管理能力的，所以推荐在容器中只运行一个进程。
在最近25~28节，学习了容器镜像构建的一些实践和技巧，使用Containerd替代Docker后，使用buildkit作为容器镜构建工具，到此对容器镜像构建的学习先告一段落。 在前面第6节学习了容器资源限制背后的技术cgroups的基本概念，并以cgroups cpu子系统为例体验一下手动设置cgroup。 先简单复习一下第6节的内容。使用CGroups可以控制的资源有: CPU、内存、网络、IO、文件设备等，因为计算资源(CPU)是cgroups资源限制中最重要的一种资源之一，本节将详细介绍一下如何使用cpu cgroup限制容器CPU的使用。
kubeadm是Kubernetes官方提供的用于快速安部署Kubernetes集群的工具，伴随Kubernetes每个版本的发布都会同步更新，kubeadm会对集群配置方面的一些实践做调整，通过实验kubeadm可以学习到Kubernetes官方在集群配置上一些新的最佳实践。
最近跨网段配置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日志一直报下面的错误: ... kubelet.go:2209] node "node1" not found ... 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 ... 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" ... 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之间的渊源和纠葛。 1.Docker, OCI和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官方在集群配置上一些新的最佳实践。
1.kubectl插件机制简介 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集群，这个需求更加必要。针对这个需求，有以下两种实现方式：