标签：映射 一个 文件的 describe 生命周期 lock 工作 哈哈 enc
K8S是谷歌在2014年开源的容器集群化管理系统，听说谷歌内部已经使用10余年（然后还是别人的一个阉割版本，哈哈哈哈，这或许就是技术公司的实力吧）
我们使用K8S主要是进行容器化应用的部署，至于K8S有什么作用我们下文详细说明，反正就四个字：简洁高效
Node
Node作为集群中的工作节点，运行真正的应用程序，在Node上Kubernetes管理的最小运行单元是Pod。Node上运行着Kubernetes的Kubelet、kube-proxy服务进程，这些服务进程负责Pod的创建、启动、监控、重启、销毁、以及实现软件模式的负载均衡。
Node包含的信息：
Node地址：主机的IP地址，或Node ID。
Node的运行状态：Pending、Running、Terminated三种状态。
Node Condition：…
Node系统容量：描述Node可用的系统资源，包括CPU、内存、最大可调度Pod数量等。
其他：内核版本号、Kubernetes版本等。
kubectl describe node //查看Node信息
Pod:
对于K8S而言，是最小的部署单元
是一组容器的集合，可以是一个容器，也可以是多个容器的集合
Pod内多个容器共享网络
其生命周期是短暂的，随时被创建，也随时被干掉
每个Pod里运行着一个特殊的被称之为Pause的容器，其他容器则为业务容器，这些业务容器共享Pause容器的网络栈和Volume挂载卷，因此他们之间通信和数据交换更为高效，在设计时我们可以充分利用这一特性将一组密切相关的服务进程放入同一个Pod中，同一个Pod里的容器之间仅需通过localhost就能互相通信，这里当然就要注意端口冲突的问题，Kubernetes为Pod设计了一套独特的网络配置，包括：为每个Pod分配一个IP地址，使用Pod名作为容器间通信的主机名等。
一个Pod中的应用容器共享同一组资源：
PID命名空间：Pod中的不同应用程序可以看到其他应用程序的进程ID；
网络命名空间：Pod中的多个容器能够访问同一个IP和端口范围；
IPC命名空间：Pod中的多个容器能够使用SystemV IPC或POSIX消息队列进行通信；
UTS命名空间：Pod中的多个容器共享一个主机名；
Volumes（共享存储卷）：Pod中的各个容器可以访问在Pod级别定义的Volumes；
RC [ Replication Controller ]
目标Pod的定义创建和灭亡管控
确保预期的Pod数量在对外提供服务
无状态应用部署
有状态应用部署
Replication Controller负责Pod的生命周期的自动管理，实现自动创建和消灭一个Pod，然后分配到一个Node上运行，以确保预期的Pod正常运行，Kubernetes通过 Replication Controller中定义的Lable筛选出对应的Pod实例，并实时监控其状态和数量，如果实例数量少于定义的副本数量（Replicas），则会根据RC中定义的Pod模板来创建一个新的Pod，然后将此Pod调度到合适的Node上启动运行，直到Pod实例数量达到预定目标。
Service
定义一组Pod的访问规则
Pod的IP都是由K8S自动分配的,但是随着Controller的介入，Pod的创建和灭亡都会产生新的IP和失效的IP，一个Service可以看作一组提供相同服务的Pod的对外访问接口，如果Service要提供外网服务，需指定公共IP和NodePort，或外部负载均衡器
NodePort：系统会在Kubernetes集群中的每个Node上打开一个主机的真实端口，这样，能够访问Node的客户端就能通过这个端口访问到内部的Service了
Volume
Volume是Pod中能够被多个容器访问的共享目录。
Label (标签)
Label以key/value的形式附加到各种对象上，如Pod、Service、RC、Node等，以识别这些对象，管理关联关系等，如Service和Pod的关联关系。
下面是一个单Master的集群架构图
从上图中我们大概可以分成三个部分来理解：Master Node、Worker Node、Etcd
Etcd
储存系统，用于储存集群相关的数据,持久化存储集群中所有的资源对象，如Node、Service、Pod、RC、Namespace等；API Server提供了操作etcd的封装接口API，这些API基本上都是集群中资源对象的增删改查及监听资源变化的接口。
Master Node（主控节点）
API Server
提供了资源对象的唯一操作入口，其他所有组件都必须通过它提供的API来操作资源数据，通过对相关的资源数据“全量查询”+“变化监听”，这些组件可以很“实时”地完成相关的业务功能。API Server内部有一套完备的安全机制，包括认证、授权和准入控制等相关模块
scheduler
节点调度，集群中的调度器，负责Pod在集群节点中的调度分配。
controller-manager
集群内部的管理控制中心，其主要目的是实现Kubernetes集群的故障检测和恢复的自动化工作，比如根据RC的定义完成Pod的复制或移除，以确保Pod实例数符合RC副本的定义；根据Service与Pod的管理关系，完成服务的Endpoints对象的创建和更新；其他诸如Node的发现、管理和状态监控、死亡容器所占磁盘空间及本地缓存的镜像文件的清理等工作也是由Controller Manager完成的。
Workder Node（工作节点）
kube-proxy
提供网络代理，负载均衡等操作
kubelet
负责本Node节点上的Pod的创建、修改、监控、删除等全生命周期管理，同时Kubelet定时“上报”本Node的状态信息到API Server里。
相当于就是Master节点派到此节点来监控此节点的使臣，负责管理本机容器
整个流程为：
通过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的流量转发功能。
搭建集群的方式有两种：kubeadm 和 二进制安装包搭建
kubeadm搭建：快速搭建，缺点就是出了问题不好把控
CentOS7虚拟机三台即可，配置允许小幅度降低
【Master Node】 2核心 4G内存 30G硬盘 * 1
【Worker Node】 4核心 6G内存 50G硬盘 * 2
系统初始化操作（修改必要配置文件，关闭防火墙......等等）
三个节点安装 Docker 、 Kubelet 、kubeadm 、 Kubectl
在Master 节点执行 kubeadm init 命令进行初始化
在Workder节点执行 kubeadm join命令将node节点添加到当前的集群里面
配置网络插件
下面我们就进入具体的搭建流程吧
.
标签：映射 一个 文件的 describe 生命周期 lock 工作 哈哈 enc
原文地址：https://www.cnblogs.com/msi-chen/p/14088352.html
