kubernetes基本概念和术语
kubeernetes中的大部分概念如Node,Pod,Replication Controller ,Serverce等都可以看作一种“资源对象”,几乎所有的资源对象都可以通过
kubernetes提供的kubectl工具(或者API编程调用)执行增删改查等操作并将其保存在etcd中持久化存储。从这个角度来看,kubernetes其实
是一个高度自动化的资源控制系统,它通过跟踪对比etcd库里保存的“资源期望状态”与当前环境中的“实际资源状态”的差异来实现自动控制
和自动纠错的高级功能。
kubernetes提供的kubectl工具(或者API编程调用)执行增删改查等操作并将其保存在etcd中持久化存储。从这个角度来看,kubernetes其实
是一个高度自动化的资源控制系统,它通过跟踪对比etcd库里保存的“资源期望状态”与当前环境中的“实际资源状态”的差异来实现自动控制
和自动纠错的高级功能。
Master
Master:集群控制节点。每个Kubernetes集群里需要有一个Master节点来负责整个集群的管理和控制。基本上Kubernetes所有的控制命令都是
发给它,它来负责具体的执行过程,我们后面所有执行的命令都是在Master节点上运行的。Master节点通常会占据一个独立的X86服务器(或者
一个虚拟机),一个主要的原因是它太重要了,它是整个集群的“首脑”,如果它宕机或者不可用,那么我们所有的控制命令都失效。
在Master节点上运行着一下一组关键进程:
发给它,它来负责具体的执行过程,我们后面所有执行的命令都是在Master节点上运行的。Master节点通常会占据一个独立的X86服务器(或者
一个虚拟机),一个主要的原因是它太重要了,它是整个集群的“首脑”,如果它宕机或者不可用,那么我们所有的控制命令都失效。
在Master节点上运行着一下一组关键进程:
Kuberneres API Server(kube-apiserver),提供了HTTP Rest 接口的关键服务进程,是Kubernetes里所有资源的增删改查等操作的唯一入口,也是
集群控制的入口进程。
Kubernetes Controller Manager ,Kubernetes里所有资源对象的自动化控制中心,可以理解为资源对象的“大总管”。
Kubernetes Scheduler ,负责资源调度的进程,相当于公交司机的“调度室”
其实Master节点上往往还启动了一个etcd Server 进程,因为Kubernetes里所有的资源对象的数据全部是保存在etcd中。
Node
除了Master ,Kubernetes集群中的其他机器被称为Node节点。和Master一样,Node节点可以是一台物理主机,也可以是一台虚拟机。Node节点
才是Kubernetes集群中的工作负载节点,每个Node都会被Master分配一些工作负载(Docker容器),当某个Node宕机时,其上的工作负载会被
Master自动转移到其他节点上去。
才是Kubernetes集群中的工作负载节点,每个Node都会被Master分配一些工作负载(Docker容器),当某个Node宕机时,其上的工作负载会被
Master自动转移到其他节点上去。
每个Node节点上都运行着一组关键进程:
kubelet:负责Pod对应的容器的创建,启停等任务,同时与Master节点密切协作 ,实现集群管理的基本功能。 kube-proxy: 实现Kubernetes Service的通信与负载均衡机制的重要组建。 Docker Engine(docker):Docker引擎,负责本机的容器创建和管理工作。 Node 节点可以在运行期间动态增加到Kubernetes集群中,一旦Node被纳入集群管理范围,kubelet进程就会定时向Master节点汇报自身的情报, 例如操作系统,Docker版本,机器的CPU和内存情况,以及之前有哪些Pod在运行等,这样Master可以获知每个Node的资源使用情况,并实现 高效均衡的资源调度策略。而某个Node超过指定时间不上报信息时,会被Master判定为"失联",Node的状态被标记为不可用(not ready),随后Master 会触发“工作负载大转移”的自动流程。 查看集群中有多少个Node: kubectl get nodes 查看某个nodede 详细信息: kubectl describe node <node name>
Pod
pod是kubernetes的最重要也是最基本的概念,Pod是Kubernetes最基本的操作单元,包含一个或多个紧密相关的容器,一个Pod是一组相关容器的组合。一个Pod可以被一个容器
化的环境看作应用层的“逻辑宿主机”;每个Pod都有一个特殊的容器被称为"根容器"的Pause容器。Pause容器对应的镜像是Kubenetes平台的一部分,
除了Pause容器, 每个Pod还包含一个或多个紧密相关的用户业务容器。为何Kubernetes会设计出一个Pod概念呢?
每个容器都代表一个应用,一组相关容器要相互通信,在一个Pod中,多个业务容器共享Pause容器的IP,共享Pause容器挂接的Volume,这样既简化了密切
关联的关系密切的关系容器之间的通信问题,也解决了他们之间的文件共享问题
化的环境看作应用层的“逻辑宿主机”;每个Pod都有一个特殊的容器被称为"根容器"的Pause容器。Pause容器对应的镜像是Kubenetes平台的一部分,
除了Pause容器, 每个Pod还包含一个或多个紧密相关的用户业务容器。为何Kubernetes会设计出一个Pod概念呢?
每个容器都代表一个应用,一组相关容器要相互通信,在一个Pod中,多个业务容器共享Pause容器的IP,共享Pause容器挂接的Volume,这样既简化了密切
关联的关系密切的关系容器之间的通信问题,也解决了他们之间的文件共享问题
![](https://i-blog.csdnimg.cn/blog_migrate/5d417cbc4705cb11c01fc7fea40ddae0.png)
Service
在Kubernetes的世界里,虽然每个Pod都会被分配一个单独的IP地址,但这个IP地址会随着Pod的销毁而消失,这就引出一个问题:如果有一组Pod组成一个集群来提供服务,那么如何来访问它呢?Service!
一个Service可以看作一组提供相同服务的Pod的对外访问接口,Service作用于哪些Pod是通过Label Selector来定义的。
- 拥有一个指定的名字(比如my-mysql-server);
- 拥有一个虚拟IP(Cluster IP、Service IP或VIP)和端口号,销毁之前不会改变,只能内网访问;
- 能够提供某种远程服务能力;
- 被映射到了提供这种服务能力的一组容器应用上;
如果Service要提供外网服务,需指定公共IP和NodePort,或外部负载均衡器;
NodePort
系统会在Kubernetes集群中的每个Node上打开一个主机的真实端口,这样,能够访问Node的客户端就能通过这个端口访问到内部的Service了