13518219792
这篇文章给大家介绍怎样总结K8S 知识点，内容非常详细，感兴趣的小伙伴们可以参考借鉴，希望对大家能有所帮助。
目前成都创新互联公司已为上1000+的企业提供了网站建设、域名、网站空间、网站托管运营、企业网站设计、辛集网站维护等服务，公司将坚持客户导向、应用为本的策略，正道将秉承"和谐、参与、激情"的文化，与客户和合作伙伴齐心协力一起成长，共同发展。
Kubernetes是基于容器的分布式资源管理系统：对容器化的应用自动部署、资源的伸缩和管理。
如果想用k8s管理应用，首先要把应用打包成容器镜像（比如Docker镜像），然后再用k8s管理容器。k8s典型应用场景：
微服务场景，当请求流量增多，增加后台服务数，流量减少随之也减少服务数
大数据场景，spark、flink等结合k8s的Namespace，实现多租户资源隔离，比如白天可以多给在线计算分配工作节点、内存、cpu等资源，离线计算分配的少点；而到了凌晨，离线任务就要拉起来，多给离线计算分配资源，实时计算的就可以少些
Control Plane/Master
Kubernetes里的Master指的是集群控制节点，在每个Kubernetes集群里都需要有一个Master来负责整个集群的管理和控制，基本上Kubernetes的所有控制命令都发给它，它负责具体的执行过程。Master通常会占据一个独立的服务器（高可用部署建议用3台服务器），主要原因是它太重要了，是整个集群的“首脑”，如果它宕机或者不可用，那么对集群内容器应用的管理都将失效。master上运行的关键服务：
◎ Kubernetes API Server（kube-apiserver）：提供了HTTP Rest接口的关键服务进程，是Kubernetes里所有资源的增、删、改、查等操作的唯一入口，也是集群控制的入口进程。
◎Kubernetes Controller Manager（kube-controller-manager）：Kubernetes里所有资源对象的自动化控制中心
◎ Kubernetes Scheduler（kube-scheduler）：负责资源调度（Pod调度）的进程，比如监听一个新创建的没有分配节点的Pods，选择一个节点并且将其运行。
◎etcd：KV数据存储服务，Kubernetes里的所有资源对象的数据都被保存在etcd中。
Node
除了Master，Kubernetes集群中的其他机器被称为Node，Node作为集群中的工作节点，运行真正的应用程序，在Node上Kubernetes管理的最小运行单元是Pod。与Master一样，Node可以是一台物理主机，也可以是一台虚拟机。Node是Kubernetes集群中的工作负载节点，每个Node都会被Master分配一些工作负载（Docker容器），当某个Node宕机时，其上的工作负载会被Master自动转移到其他节点上。node上运行的关键服务：
◎ kubelet：负责Pod对应的容器的创建、启停等任务，同时与Master密切协作，实现集群管理的基本功能。
◎ kube-proxy：实现Kubernetes Service的通信与负载均衡机制的重要组件。
◎ Docker Engine（docker）：Docker引擎，负责本机的容器创建和管理工作。
Node可以在运行期间动态增加到Kubernetes集群中，前提是在这个节点上已经正确安装、配置和启动了上述关键进程，在默认情况下kubelet会向Master注册自己，这也是Kubernetes推荐的Node管理方式。一旦Node被纳入集群管理范围，kubelet进程就会定时向Master汇报自身的情报，例如操作系统、Docker版本、机器的CPU和内存情况，以及当前有哪些Pod在运行等，这样Master就可以获知每个Node的资源使用情况，并实现高效均衡的资源调度策略。而某个Node在超过指定时间不上报信息时，会被Master判定为“失联”，Node的状态被标记为不可用（Not Ready），随后Master会触发“工作负载大转移”的自动流程。
Pod是Kubernetes管理的最小运行单位，在每个Pod中都运行着一个特殊的被称为Pause的容器，其他容器则为业务容器，这些业务容器共享Pause容器的网络栈和Volume挂载卷，因此它们之间的通信和数据交换更为高效，在设计时我们可以充分利用这一特性将一组密切相关的服务进程放入同一个Pod中。
如果两个或两个以上的容器为紧耦合的关系，并组成一个整体对外提供服务，应将这两个容器导报成一个Pod；比如用Flume采集Nginx日志，那么就可以把Nginx容器和Flume容器放到一个Pod中。属于同一个Pod的多个容器应用之间相互访问时仅需要通过localhost就可以通信，使得这一组容器被“绑定”在了一个环境中。
Kubernetes为每个Pod都分配了唯一的IP地址，称之为PodIP，一个Pod里的多个容器共享Pod IP地址；当Pod重启后，Pod IP地址会发生变化。
Pod定义文件的重要参数：
◎ spec.resources.limits.cpu、spec.resources.limits.memory：该资源最大允许使用的量，不能被突破，当容器试图使用超过这个量的资源时，可能会被Kubernetes“杀掉”并重启
◎ spec.resources.requests.cpu、spec.resources.requests.memory：该资源的最小申请量
◎ nodeSelector：设置Node的Label，Pod将被调度上具有这些Lable的Node是上。如果期望某种Pod的副本全部在指定的一个或者一些节点上运行，比如希望将MySQL数据库调度到一个具有SSD磁盘的目标节点上，此时Pod模板中的NodeSelector属性就开始发挥作用了：1）把具有SSD磁盘的Node都打上自定义标签“disk=ssd” （2）在Pod模板中设定NodeSelector的值为“disk: ssd”。
kube-controller进程通过在资源对象RC上定义的LabelSelector来筛选要监控的Pod副本数量，使Pod副本数量始终符合预期设定的全自动控制流程。
Label相当于我们熟悉的“标签”。给某个资源对象定义一个Label，就相当于给它打了一个标签，随后可以通过LabelSelector（标签选择器）查询和筛选拥有某些Label的资源对象。
Label可以被附加到各种资源对象上，例如Node、Pod、Service、RC等，一个资源对象可以定义任意数量的Label，同一个Label也可以被添加到任意数量的资源对象上。我们可以通过给指定的资源对象捆绑一个或多个不同的Label来实现多维度的资源分组管理功能，以便灵活、方便地进行资源分配、调度、配置、部署等管理工作。例如，部署不同版本的应用到不同的环境中；监控和分析应用（日志记录、监控、告警）等；比如期望某种Pod的副本在k8s集群指定的某些节点上运行。Label使用场景：
◎ kube-controller进程通过在资源对象RC上定义的LabelSelector来筛选要监控的Pod副本数量，使Pod副本数量始终符合预期设定的全自动控制流程。
◎ kube-proxy进程通过Service的Label Selector来选择对应的Pod，自动建立每个Service到对应Pod的请求转发路由表，从而实现Service的智能负载均衡机制。
◎ 通过对某些Node定义特定的Label，并且在Pod定义文件中使用NodeSelector这种标签调度策略，kube-scheduler进程可以实现Pod定向调度的特性。
Label和LabelSelector共同构成了Kubernetes系统中核心的应用模型，使得被管理对象能够被精细地分组管理，同时实现了整个集群的高可用性。
RC资源对象定义了一个期望的场景，即声明某种Pod的副本数量在任意时刻都符合某个预期值，所以RC的定义包括如下几个部分：
1、 Pod期待的副本数量
2、 用于筛选目标Pod的Label Selector
3、当Pod的副本数量小于预期数量时，用于创建新Pod的Pod模板（template）。在RC定义文件里，对应的配置项：
◎ spec.selector：是RC的Pod标签选择器，即监控和管理拥有这些标签的Pod实例，确保在当前集群中始终有且仅有replicas个Pod实例在运行。当在集群中运行的Pod数量少于replicas时，RC会根据在spec.template定义的Pod模板来生成一个新的Pod实例
◎ spec.replicas：Pod副本的期待值
在我们定义了一个RC并将其提交到Kubernetes集群中后，Master上的Controller Manager组件里的Replication Controller（副本控制器）就得到通知，定期巡检系统中当前存活的目标Pod，并确保目标Pod实例的数量刚好等于此RC的期望值，如果有过多的Pod副本在运行，系统就会停掉一些Pod，否则系统会再自动创建一些Pod。可以说，通过RC，Kubernetes实现了用户应用集群的高可用性，并且大大减少了系统管理员在传统IT环境中需要完成的许多手工运维工作（如主机监控脚本、应用监控脚本、故障恢复脚本等）；在运行时，我们可以通过修改RC的副本数量，来实现Pod的弹性缩放（Scaling）；通过逐个替换Pod的方式来辅助服务的滚动更新。
最好不要越过RC直接创建Pod，因为Replication Controller（副本控制器）会通过RC管理Pod副本，实现自动创建、补足、替换、删除Pod副本，这样能提高系统的容灾能力，减少由于节点崩溃等意外状况造成的损失。即使应用程序只用到一个Pod副本，也强烈建议使用RC来定义Pod。
Replica Set与RC当前的唯一区别是，Replica Sets支持基于集合的Label selector（Set-based selector），而RC只支持基于等式的Label Selector（equality-based selector），这使得Replica Set的功能更强。
Deployment在内部使用了Replica Set来实现，无论从Deployment的作用与目的、YAML定义，还是从它的具体命令行操作来看，我们都可以把它看作RC的一次升级，两者的相似度超过90%。我们不应该使用底层的Replica Set来控制Pod副本，而应该使用管理Replica Set的Deployment对象来控制副本。
Deployment或RC的主要功能之一就是自动部署一个容器应用的多份副本，以及持续监控副本的数量，在集群内始终维持用户指定的副本数量。
如果Pod是通过Deployment创建的，则用户可以在运行时修改Deployment的Pod定义（spec.template）或镜像名称，并应用到Deployment对象上，系统即可完成Deployment的自动更新操作。如果在更新过程中发生了错误，则还可以通过回滚操作恢复Pod的版本。
一旦镜像名（或Pod定义）发生了修改，则将触发系统完成Deployment所有运行Pod的滚动升级操作。Deployment滚动升级Pod的过程是：初始创建Deployment时，系统创建了一个ReplicaSet，并按用户的需求创建了n个Pod副本。当更新Deployment时，系统创建了一个新的ReplicaSet，并将其副本数量扩展到1，然后将旧的ReplicaSet缩减为n-1。之后，系统继续按照相同的更新策略对新旧两个ReplicaSet进行逐个调整。最后，新的ReplicaSet运行了n个新版本Pod副本，旧的ReplicaSet副本数量则缩减为0。
每个Pod都可以对其能使用的服务器上的计算资源设置限额，当前可以设置限额的计算资源有CPU与Memory两种，其中CPU的资源单位为CPU（Core）的数量，是一个绝对值而非相对值，Memory配额也是一个绝对值，它的单位是内存字节数。在Kubernetes里，一个计算资源进行配额限定时需要设定以下两个参数：
◎ Requests：该资源的最小申请量，系统必须满足要求。
◎ Limits：该资源最大允许使用的量，不能被突破，当容器试图使用超过这个量的资源时，可能会被Kubernetes“杀掉”并重启。
在一个组织内部，不同的工作组可以在同一个Kubernetes集群中工作，Kubernetes通过命名空间和Context的设置对不同的工作组进行区分，使得它们既可以共享同一个Kubernetes集群的服务，也能够互不干扰，组合组之间创建的Pod、RC互不可见。Namespace在很多情况下用于实现多租户的资源隔离。
对于Kubernetes集群管理而言，配置每一个Pod的Requests和Limits是烦琐的，更多时候，我们需要对集群内的租户Requests和Limits的配置做一个全局限制。Namespace通过将集群内部的资源对象“分配”到不同的Namespace中，形成逻辑上分组的不同项目、小组或用户组，便于不同的分组在共享使用整个集群的资源的同时还能被分别管理。当给每个租户创建一个Namespace来实现多租户的资源隔离时，还能结合Kubernetes的资源配额管理，限定不同租户能占用的资源，例如CPU使用量、内存使用量等。
关于怎样总结K8S 知识点就分享到这里了，希望以上内容可以对大家有一定的帮助，可以学到更多知识。如果觉得文章不错，可以把它分享出去让更多的人看到。
