《 Kubernetes进阶实战》一2.2.2集群运行模式
2.2.2 集群运行模式
Kubernetes集群支持三种运行模式:一是“独立组件”模式,系统各组件直接以守护进程的方式运行于节点之上,各组件之间相互协作构成集群,如图2-7b所示;第二种是“静态Pod模式”,除kubelet和Docker之外的其他组件(如etcd、kube-apiserver、kube-controller-manager和kube-scheduler等)都是以静态Pod对象运行于Master主机之上的,如图2-7a所示;第三种是Kubernetes的“自托管”(self-hosted)模式,它类似于第二种方式,将除了kubelet和Docker之外的其他组件运行为集群之上的Pod对象,但不同的是,这些Pod对象托管运行在集群自身之上受控于DaemonSet类型的控制器,而非静态的Pod对象。
图2-7 Kubernetes集群的运行模式(图2-7a为静态Pod模式)
使用kubeadm部署的Kubernetes集群可运行为第二种或第三种模式,默认为静态Pod对象模式,需要使用自托管模式时,kubeadm init命令使用“--features-gates=selfHosting”选项即可。第一种模式集群的构建需要将各组件运行于系统之上的独立守护进程中,其间需要用到的证书及Token等认证信息也都需要手动生成,过程烦琐且极易出错;若有必要用到,则建议使用GitHub上合用的项目辅助进行,例如,通过ansible playbook进行自动部署等。
2.2.3 准备用于实践操作的集群环境
本书后面的篇幅中用到的测试集群如图2-8所示,该集群由一个Master主机和三个Node主机组成,它基于kubeadm部署,除了kubelet和Docker之外其他的集群组件都运行于Pod对象中。多数情况下,两个或以上的独立运行的Node主机即可测试分布式集群的核心功能,因此其数量可按需定义,但两个主机是模拟分布式环境的最低需求。生产实践中,应该至少部署三个协同工作的Master节点以确保控制平面的服务可用性,不过,在测试环境中仅部署一个Master
节点也是常见的选择。
各Node上采用的容器运行时环境为docker,后续的众多容器的运行任务都将依赖于Docker Registry服务,包括DockerHub、GCR(Google Container Registry)和Quay等,甚至是私有的Registry服务,本书假设读者对Docker容器技术有熟练的使用基础。另外,本部署示例中使用的用于为Pod对象提供网络功能的插件是f?lannel,其同样以Pod对象的形式托管运行于Kubernetes系统之上。
具体的部署过程以及本书用到的集群环境请参考附录A,本章后续的操作都将依赖于根据其步骤部署完成的集群环境,读者需要根据其内容成功搭建出Kubernetes测试集群后才能进行后面章节的学习。
- 点赞
- 收藏
- 关注作者
评论(0)