外部 清理 lac six 基本上 新的 容器 所有
Node 作为集群中的工作节点,运行真正的应用程序,在 Node 上 Kubernetes 管理的最小运行单元是 Pod。Node 上运行着 Kubernetes 的 Kubelet、kube-proxy 服务进程,这些服务进程负责 Pod 的创建、启动、监控、重启、销毁、以及实现软件模式的负载均衡。
Node 包含的信息:
查看 Node 信息:
- kubectl describe node
Pod 是 Kubernetes 最基本的操作单元,包含一个或多个紧密相关的容器,一个 Pod 可以被一个容器化的环境看作应用层的 "逻辑宿主机";一个 Pod 中的多个容器应用通常是紧密耦合的,Pod 在 Node 上被创建、启动或者销毁;每个 Pod 里运行着一个特殊的被称之为 Pause 的容器,其他容器则为业务容器,这些业务容器共享 Pause 容器的网络栈和 Volume 挂载卷,因此他们之间通信和数据交换更为高效,在设计时我们可以充分利用这一特性将一组密切相关的服务进程放入同一个 Pod 中。
同一个 Pod 里的容器之间仅需通过 localhost 就能互相通信。
一个 Pod 中的应用容器共享同一组资源:
Pod 的生命周期通过 Replication Controller 来管理;通过模板进行定义,然后分配到一个 Node 上运行,在 Pod 所包含容器运行结束后,Pod 结束。
Kubernetes 为 Pod 设计了一套独特的网络配置,包括:为每个 Pod 分配一个 IP 地址,使用 Pod 名作为容器间通信的主机名等。
在 Kubernetes 的世界里,虽然每个 Pod 都会被分配一个单独的 IP 地址,但这个 IP 地址会随着 Pod 的销毁而消失,这就引出一个问题:如果有一组 Pod 组成一个集群来提供服务,那么如何来访问它呢?Service!
一个 Service 可以看作一组提供相同服务的 Pod 的对外访问接口,Service 作用于哪些 Pod 是通过 Label Selector 来定义的。
如果 Service 要提供外网服务,需指定公共 IP 和 NodePort,或外部负载均衡器;
NodePort
系统会在 Kubernetes 集群中的每个 Node 上打开一个主机的真实端口,这样,能够访问 Node 的客户端就能通过这个端口访问到内部的 Service 了
Volume 是 Pod 中能够被多个容器访问的共享目录。
Label 以 key/value 的形式附加到各种对象上,如 Pod、Service、RC、Node 等,以识别这些对象,管理关联关系等,如 Service 和 Pod 的关联关系。
Kubernetes 通过 RC 中定义的 Lable 筛选出对应的 Pod 实例,并实时监控其状态和数量,如果实例数量少于定义的副本数量(Replicas),则会根据 RC 中定义的 Pod 模板来创建一个新的 Pod,然后将此 Pod 调度到合适的 Node 上启动运行,直到 Pod 实例数量达到预定目标。
Kubernetes 将集群中的机器划分为一个 Master 节点和一群工作节点(Node)。其中,Master 节点上运行着集群管理相关的一组进程 etcd、API Server、Controller Manager、Scheduler,后三个组件构成了 Kubernetes 的总控中心,这些进程实现了整个集群的资源管理、Pod 调度、弹性伸缩、安全控制、系统监控和纠错等管理功能,并且全都是自动完成。在每个 Node 上运行 Kubelet、Proxy、Docker daemon 三个组件,负责对本节点上的 Pod 的生命周期进行管理,以及实现服务代理的功能。
流程
通过 Kubectl 提交一个创建 RC 的请求,该请求通过 API Server 被写入 etcd 中,此时 Controller Manager 通过 API Server 的监听资源变化的接口监听到这个 RC 事件,分析之后,发现当前集群中还没有它所对应的 Pod 实例,于是根据 RC 里的 Pod 模板定义生成一个 Pod 对象,通过 API Server 写入 etcd,接下来,此事件被 Scheduler 发现,它立即执行一个复杂的调度流程,为这个新 Pod 选定一个落户的 Node,然后通过 API Server 讲这一结果写入到 etcd 中,随后,目标 Node 上运行的 Kubelet 进程通过 API Server 监测到这个 "新生的"Pod,并按照它的定义,启动该 Pod 并任劳任怨地负责它的下半生,直到 Pod 的生命结束。
随后,我们通过 Kubectl 提交一个新的映射到该 Pod 的 Service 的创建请求,Controller Manager 会通过 Label 标签查询到相关联的 Pod 实例,然后生成 Service 的 Endpoints 信息,并通过 API Server 写入到 etcd 中,接下来,所有 Node 上运行的 Proxy 进程通过 API Server 查询并监听 Service 对象与其对应的 Endpoints 信息,建立一个软件方式的负载均衡器来实现 Service 访问到后端 Pod 的流量转发功能。
客户端通过 Kubectl 命令行工具或 Kubectl Proxy 来访问 Kubernetes 系统,在 Kubernetes 集群内部的客户端可以直接使用 Kuberctl 命令管理集群。Kubectl Proxy 是 API Server 的一个反向代理,在 Kubernetes 集群外部的客户端可以通过 Kubernetes Proxy 来访问 API Server。
API Server 内部有一套完备的安全机制,包括认证、授权和准入控制等相关模块。
K8S 基础概念
来源: http://www.bubuko.com/infodetail-2158530.html