RuntimeClassnode
构成Kubernetes 的 Components (组件) 主要有三类,Master 组件, Node 组件,Addons (辅助类插件) 。分别承担不一样的工做,共同构建了kubernetes。nginx
Master 组件提供群集的控制平面。主组件对集群作出全局决策(例如,调度),而且它们检测并响应集群事件(例如,当复制控制器的replicas
字段未知足时启动新的pod )。主组件能够在群集中的任何计算机上运行。可是,为简单起见,设置脚本一般会在同一台计算机上启动全部主组件,而且不在此计算机上运行用户容器。git
***上述说明来自官方解释,我理解就是一个控制台,在现有IT 架构中不少硬件或者软件采用这种方式,Master 和node 的方式。Master 负载策略下发,管理node 运行的生命周期。至关于Kubernetes 的大脑,负责整个集群的管理和控制。那么一般不会在这台机器上部署node 不会运行容器(container )的功能。docker
Master 节点上运行了如下一组关键进程:编程
kube-apiserver :提供了 HTTP Rest ful 风格的接口的关键服务进程,是Kubernetes 里全部资源的增,删,改,查等操做的惟一入口,也是Kubernetes 集群的管理的入口进程。后端
kube-controller-manager :Kunernetes 里全部资源的自动化控制中心,api
这些控制器包括:服务器
kube-scheduler : 负责 pod 调度的进程,调度决策所考虑的因素包括我的和集体资源需求,硬件/软件/策略约束,亲和力和反亲和性规范,数据位置,工做负载间干扰和最后期限网络
etcd :负责Kubernetes 全部资源存储的进程。架构
除了Master Kubernetes 中其余节点都称为Node 节点,Node 能够是物理机也能够是虚拟机,Node 节点是Kubernetes 中的工做负载节点,每一个Node 都会由Master 调度承担运行
容器(Docker )的工做。
*****注意Node 节点能够在Kubernetes 集群动态运行时加入,前提是这个Node 完成可初始化配置,默认状况下Kublete 模块向Master 申请注册,一旦Node 申请被接受,Kublete 会
定时向master 节点提交本身的状态,软件和硬件资源信息。由 master 评估后进行资源调度,若是超时不上报。就会被标记为不可用,Master 会进行故障转移的调度。
每一个节点都运行一组关键进程:
Kubelet :负责Pod 对应容器的建立,启停等任务,同时与master 协同工做,实现Kubernetes 运行的基本组件。
Kube-proxy :是在群集中的每一个节点上运行的网络代理。它经过维护主机上的网络规则并执行链接转发来实现Kubernetes服务抽象。kube-proxy
负责请求转发。kube-proxy
容许经过一组后端功能进行TCP和UDP流转发或循环TCP和UDP转发。实现kubernetes service 的通讯和与负载工做
Container Runtime:负责容器运行,容器建立和管理。
插件是实现集群功能的pod和服务工具,能够是第三方工具。
DNS:虽然其余插件并不是严格要求,但全部Kubernetes集群都应具备集群DNS,由于许多示例都依赖于它。群集DNS是DNS服务器,除了您环境中的其余DNS服务器以外,它还为Kubernetes服务提供DNS记录。
Kubernetes启动的容器会在DNS搜索中自动包含此DNS服务器
Web UI:Kubernetes 集群可视化管理工具和图表工具
Container Resource Monitoring:容器资源监视工具。‘
Cluster-level Logging: 集群运行日志分析工具。
’
Containers
Images : 镜像仓库,Kubernetes 对容器的管理依赖于选择的容器管理工具,好比 Docker
Container Environment Variables:
RuntimeClass: RuntimeClass是用于选择容器运行时配置的功能。容器运行时配置用于运行Pod的容器
Container Lifecycle Hooks: 相似于许多具备组件生命周期hooks的编程语言框架,例如Angular,Kubernetes为Containers提供了生命周期hooks。hooks使Container可以了解其管理生命周期中的事件,并在执行相应的生命周期hooks时运行在处理程序中实现的代码。
Workloads
1.Pods
pod 是一组一个或一个以上的 容器(例如Docker容器),具备共享存储/网络,以及如何运行容器的规范。Pod的内容始终位于同一位置并共同调度,并在共享上下文中运行。Pod模拟特定于应用程序的“逻辑主机” - 它包含一个或多个相对紧密耦合的应用程序容器 - 在预容器世界中,在同一物理或虚拟机上执行意味着在同一逻辑主机上执行。就Docker构造而言,Pod被建模为一组具备共享命名空间和共享文件系统卷的Docker容器.
Pod是多个合做过程模式的模型,造成了一个有凝聚力的服务单元。它们经过提供比其组成应用程序集更高级别的抽象来简化应用程序部署和管理。Pod用做部署,水平扩展和复制的单元。对Pod中的容器自动处理共置(共同调度),共享命运(例如终止),协调复制,资源共享和依赖关系管理。
2.pod controllers ReplicaSet
ReplicaSet使用字段定义,包括指定如何识别它能够获取的Pod的选择器,指示它应该维护多少Pod的多个副本,以及指定它应该建立的新Pod的数据的pod模板以知足该数量复制品标准。而后,ReplicaSet经过根据须要建立和删除Pod来达到其目的,以达到所需的数量。当ReplicaSet须要建立新Pod时,它使用其Pod模板。
ReplicaSet与其Pods的连接是经过Pods的metadata.ownerReferences 字段,该字段指定当前对象所拥有的资源。ReplicaSet获取的全部Pod在其ownerReferences字段中拥有其拥有的ReplicaSet标识信息。经过此连接,ReplicaSet知道它正在维护的Pod的状态并相应地进行计划。
ReplicaSet使用其选择器标识要获取的新Pod。若是Pod没有OwnerReference或者OwnerReference不是控制器而且它与ReplicaSet的选择器匹配,则它将当即由所述ReplicaSet获取。
Services, Load Balancing, and Networking
Service : 一种抽象的方式暴露在一组运行的应用程序pod做为网络服务。无需修改应用程序便可使用不熟悉的服务发现机制。Kubernetes为pod提供了本身的IP地址和一组pod的单个DNS名称,而且能够在它们之间进行负载平衡。为pod 提供了对外业务的入口。
DNS for Services and Pods :Kubernetes DNS在群集上安排DNS Pod和服务,并配置kubelet以告知各个容器使用DNS服务的IP来解析DNS名称
Connecting Applications with Services:默认状况下,Docker使用主机 - 专用网络,所以只有当容器位于同一台计算机上时,容器才能与其余容器通讯。为了使Docker容器跨节点进行通讯,必须在计算机自己的IP地址上分配端口,而后将其转发或代理到容器。这显然意味着容器必须很是当心地协调它们使用的端口,或者必须动态分配端口。跨多个开发人员协调端口很是难以大规模地进行,并使用户暴露在他们没法控制的集群级别问题以外。Kubernetes假设豆荚能够与其余豆荚通讯,不管它们落在哪一个主机上。咱们为每一个pod提供了本身的集群专用IP地址,所以您无需在pod之间显式建立连接或将容器端口映射到主机端口。这意味着Pod中的容器能够在localhost上到达彼此的端口,而且群集中的全部pod均可以在没有NAT的状况下看到彼此。本文档的其他部分将详细说明如何在这种网络模型上运行可靠的服务
Ingress: 管理群集中服务的外部访问的API对象,一般是HTTP。Ingress能够提供负载平衡,SSL终止和基于名称的虚拟主机。
Ingress Controllers:
为了使Ingress资源正常工做,群集必须运行入口控制器。
与做为kube-controller-manager
二进制文件一部分运行的其余类型的控制器不一样,Ingress控制器不会自动与集群一块儿启动。使用此页面选择最适合您的群集的入口控制器实施。Kubernetes做为一个项目目前支持和维护GCE和 nginx控制器。
Kubeadm 是一个工具,它提供了 kubeadm init
以及 kubeadm join
这两个命令做为快速建立 kubernetes 集群的最佳实践。