Kubernetes

容器化：

想到容器技术，首先会想到Container这个单词，它直译过来，是容器，集装箱，货柜

其实容器技术是一种沙盒技术。顾名思义，沙盒就是能够像一个集装箱一样，把我们的应用"装"起来的一种技术。

这样，应用与应用之间，就因为有了边界而不至于相互干扰；而被装进集装箱的应用，也可以被方便地搬来搬去。

容器技术的核心功能：是通过约束和修改进程的动态表现，从而为其创造出一个"边界"。进而为每个应用创造了独立的运行空间

那他底层是如何实现的呢？是使用Linux 容器最基础的两种技术：Namespace 和 Cgroups

• Namespace：作用是"隔离"，它让应用进程只能看到该 Namespace 内的"世界"
• Cgroups ：作用是"限制"，它给这个"世界"围上了一圈看不见的墙

这么一折腾，进程就真的被"装"在了一个与世隔绝的房间里，而这些房间就是 PaaS 项目赖以生存的应用"沙盒"。

paas阶段，平台已经被包装成一个服务了，那用户如何使用这个服务，如何把自己的应用打包放到paas平台，这是paas需要解决的用户层面的问题。paas如何给应用打包问题，这样是不是就已经解决了？对，就是解决了！

这也是 Docker 项目刚刚开源不久，就能够带领一家原本默默无闻的 PaaS 创业公司脱颖而出，又迅速占领了所有云计算领域头条的技术原因！

总结下，我们可以简单理解为，容器，就是一种特殊的进程。

容器技术有以下优点：

1. 一致的运行环境
2. 更高效的利用系统资源
3. 更快速的启动时间
4. 持续交付和部署
5. 更轻松的迁移
6. 更轻松的维护和扩展

总结下来：安全性、隔离性、便携性、可配额

**举个例子：**一致的运行环境。主要是指：因为云端与本地服务器环境不同，应用的打包过程，一直是使用 PaaS 时最"痛苦"的一个步骤。

但有了容器之后，更准确地说，有了容器镜像之后，这个问题被非常优雅地解决了。

另外，因为容器是一个特殊的进程，他更小了，所以资源利用率和启动时间变得更高更快了。

容器编排：

随着互联网需求的爆发，服务暴增，出现了容器编排，而且容器从最开始一个开发者手里的小工具，一跃成为了云计算领域的绝对主角；这也标志着它真正得到了市场和生态的认可。

而能够定义容器组织和管理规范的"容器编排"技术，就当仁不让地坐上了容器技术领域的"头把交椅"。

这其中，最具代表性的容器编排工具，属于：

1. Docker 公司的 Compose+Swarm 组合

2. Google 与 RedHat 公司共同主导的 Kubernetes 项目

应用部署方式演变：

在部署应用程序的方式上，主要经历了三个时代：

1. **传统部署：**互联网早期，会直接将应用程序部署在物理机上

​ 优点：简单，不需要其它技术的参与

​ 缺点：不能为应用程序定义资源使用边界，很难合理地分配计算资源，而且程序之间容易产生影响

2. **虚拟化部署：**可以在一台物理机上运行多个虚拟机，每个虚拟机都是独立的一个环境

​ 优点：程序环境不会相互产生影响，提供了一定程度的安全性

​ 缺点：增加了操作系统，浪费了部分资源

3. **容器化部署：**与虚拟化类似，但是共享了操作系统

​ 可以保证每个容器拥有自己的文件系统、CPU、内存、进程空间等

​ 运行应用程序所需要的资源都被容器包装，并和底层基础架构解耦

​ 容器化的应用程序可以跨云服务商、跨Linux操作系统发行版进行部署

容器化部署方式给带来很多的便利，但是也会出现一些问题，比如说：

• 一个容器故障停机了，怎么样让另外一个容器立刻启动去替补停机的容器
• 当并发访问量变大的时候，怎么样做到横向扩展容器数量

这些容器管理的问题统称为容器编排问题，为了解决这些容器编排问题，就产生了一些容器编排的软件：

• Swarm：Docker自己的容器编排工具
• Mesos：Apache的一个资源统一管控的工具，需要和Marathon结合使用
• Kubernetes：Google开源的的容器编排工具

K8s简介：

kubernetes，是一个全新的基于容器技术的分布式架构方案，是谷歌严格保密十几年的秘密武器。

Kubernetes的目标是让部署容器化应用简单并且高效，Kubernetes提供了应用部署，规划，更新，维护的一种机制。

Kubernetes 项目最主要的设计思想：**从更宏观的角度，以统一的方式来定义任务之间的各种关系，并且为将来支持更多种类的关系留有了很多余地。**从一开始，Kubernetes 项目就没有像同时期的各种"容器云"项目那样，把 Docker 作为整个架构的核心，而仅仅把它作为最底层的一个容器运行时实现。**它真正的价值，在于提供了一套基于容器构建分布式系统的基础依赖。**这也是k8s能长久发展的一个原因。

Kubernetes是一种通用的、大规模、分布式应用程序的运维工具 。它所管辖的应用程序有一些限制条件，不是所有的应该程序都适合使用K8S管辖 ，它管辖的应用程序对象必须是容器化后的应用程序，只有容器化后的微服务应用程序才适合使用K8S管辖，也就是说，如果想利用K8S的优点和带来的价值，必须要先对应用程序进行改造。

kubernetes的本质是一组服务器集群，它可以在集群的每个节点上运行特定的程序，来对节点中的容器进行管理。目的是实现资源管理的自动化，主要提供了如下的主要功能：

• **自动装箱：**基于容器对应用运行环境的资源配置要求自动部署应用容器。

• **自我修复：**一旦某一个容器崩溃，能够在1秒中左右迅速启动新的容器。

• **弹性伸缩：**可以根据需要，自动对集群中正在运行的容器数量进行调整。

• **服务发现：**服务可以通过自动发现的形式找到它所依赖的服务。

• **负载均衡：**如果一个服务起动了多个容器，能够自动实现请求的负载均衡。

• **版本回退：**如果发现新发布的程序版本有问题，可以立即回退到原来的版本。

• **存储编排：**可以根据容器自身的需求自动创建存储卷。

• **水平扩展：**通过命令、用户UI 界面或基于CPU等资源使用情况，对应用容器进行规模扩大或规模剪裁。

• **滚动更新：**可以根据应用的变化，对应用容器运行的应用，进行一次性或批量式更新。

• **密钥和配置管理：**在不需要重新构建镜像的情况下，可以部署和更新密钥和应用配置，类似热部署。

• **批处理：**提供一次性任务，定时任务；满足批量数据处理和分析的场景。

k8s能做什么：

• 多个进程（作为容器运行）协同工作。（Pod）
• 存储系统挂载
• Distributing secrets（分发机密）
• 应用健康检测
• 应用实例的复制
• Pod自动伸缩/扩展
• Naming and discovering（命名和发现）
• 负载均衡
• 滚动更新
• 资源监控
• 日志访问
• 调试应用程序
• 提供认证和授权

k8s组成：

Kubernetes 主要由以下几个核心组件组成：

• etcd 保存了整个集群的状态；
• kube-apiserver 提供了资源操作的唯一入口，并提供认证、授权、访问控制、API 注册和发现等机制；
• kube-controller-manager 负责维护集群的状态，比如故障检测、自动扩展、滚动更新等；
• kube-scheduler 负责资源的调度，按照预定的调度策略将 Pod 调度到相应的机器上；
• kubelet 负责维持容器的生命周期，同时也负责 Volume（CVI）和网络（CNI）的管理；
• Container runtime 负责镜像管理以及 Pod 和容器的真正运行（CRI），默认的容器运行时为 Docker；
• kube-proxy 负责为 Service 提供 cluster 内部的服务发现和负载均衡；

K8S与Docker：

它是基于容器（通常是docker）之上的。kubernetes是docker plus。

docker是kubernetes的一部分，kubernetes里集成了docker和别的组件。

K8S与SWARM：

在软件架构中的：

K8S与SWARM都是架构在docker之上，都是对集群化的容器服务进行部署、运维的工具。

swarm和k8s本质都是容器编排服务,。

swarm本身就是内嵌在docker引擎之中的，与docker引擎融为一体。

k8s自身大部分功能也是以容器的方式部署，来完成容器编排的任务 。

在软件工程中的位置：

设计理念的区别：基于容器VS基于业务：

swarm和K8S，虽然都是架构在容器之上，处于同一层次。但是，他们的侧重点却不相同。

swarm：内嵌在容器引擎内部，是容器引擎的一部分，与容器深度绑定，swarm偏重的是容器的部署，侧重于容器技术的扩展。

k8s：独立于docker，与docker是分离的，并完全不依赖于底层的docker，它侧重于业务应用的集群部署。k8s对容器的所有操作都渗透着为应用而服务的理念。以服务为中心，docker仅仅是其底层技术支撑的一种技术。

管理的业务场景的规模与复杂度不同：中小规模VS超大规模

在调度策略方面：

swarm只有三种调度策略：Host宿主机负载、宿主机运行容器的多寡、随机调度指定宿主机。

K8s除此之外，策略更加丰富，它的策略数量是swarm的2倍以上。比如它还有端口冲突策略（在大规模部署docker时，端口冲突是必须要考虑的场景）、容器挂载的卷冲突策略、指定特定宿主机策略等。

K8S调度测试的多样化，使得K8S更能够适应和解决杂场景下应用的部署。

k8s的组件要比swarm多得多，即便似乎功能类似的组件，k8s特殊场景支持上要优于swarm。

因此，k8s更适合大规模、超大规模、部署场景复杂的场合。

swarm更适合中小规模，部署场景简单的场合。

工具的安装复杂度和学习难度不同：内嵌与额外安装：

swarm与docker天然集成，安装和使用很简单，特别是docker 1.12及以上版本，swarm已经集成到了docker的engine中，因此docker安装后swarm的部署已经完成了一半，而且swarm的操作都是通过docker api来实现，掌握了docker的操作命令后上手swarm很简单，基本上一个星期就可以掌握。

k8s虽然是基于docker，但围绕着应用的部署，K8S开发了很多组件，这些组件很多并不依赖于docker的api，在部署时需要单独规划和实施，而且因为组件中很多策略适应不同的部署场景，所以在部署前不仅仅要明白场景需求，而且还要对组件的设计逻辑了如指掌。所以安装和熟悉过程相比swarm而言要曲折很多，需要独立于docker之外，安装很多套件。

因此，K8S的学习难度也要比swarm大很多。

调度的最小单元不同：docker vs pod：

在swarm中，被创建、调度和管理的最小单元就是container。

在k8s中，最小单元则是pod（豌豆荚），pod由一个或者多个为实现某个特定功能，逻辑紧密的容器组成。在pod内的docker共享volume和网络namespace，彼此之间可以通过localhost通信或者标准进程间通信。以便pod内部的docker之间实现紧密地"交流"。

用pod有什么好处呢？

我们试想这样一个场景：我们有一个web应用的容器，现在我们为了收集web日志需要安装一个日志插件，我们面临两种选择：

1）把插件安装在web应用容器的里面，则会面临如下一些问题：如果插件有更新，尽管web应用没有变化，但因为两者共享一个镜像，则必须把整个镜像构建一遍；如果插件存在内存泄露的问题，整个容器就会有被拖垮的风险。

2）如果把插件安装在不同的容器，同样也不合适：那样的话，就需要想办法解决插件所在容器读取web容器的日志的问题。

但有了pod以后，这些问题都可以迎刃而解。

在pod里面，为日志插件和web应用各自创建一个容器，两者共享volume（即文件系统目录），web应用容器只需将日志保存到volume，便可以很方便的让日志容器插件读取。同时，两个容器拥有各自的镜像，彼此更新互不影响。他们通过文件系统的Volume实现了镜像的解耦，由保留了他们之间在业务上的紧密性，相关性。

负载均衡的机制不同：

swarm自带的负载均衡机制应用不广，大部分还是采用nginx+consul。nginx本身也是单独的容器，而consul保存了各个docker中应用的网络信息（IP和端口），nginx镜像在compose时，在dockerfile中指定consul的地址，取出consul中保存的应用的网络信息，作为参数配置到nginx的config file中，从而实现负载均衡。

这种模式的缺点就是：nginx的容器中的配置文件无法跟着应用docker的网络信息发生变化而更改，也就是说，如果新增加了docker，新增加的docker IP和应用端口则需要手动添加到nginx的config file中，或者重新构建nginx的容器。

kubernetes的负载均衡要完善很多，内部集成了负载均衡。而且，对于dockerIP变更的问题也有很好的处理机制：k8s通过service实现负载均衡，service是pod（pod包含了容器，容器中包含了应用）的访问入口，它指向一组有相同label的多个pod。每个service创建的时候会在k8s内置的dns服务器中写入一条记录：service的名称和service的IP。当需要访问pod中的应用时，只需访问service的名称即可，pod的IP对访问者来说是透明的，因此不管怎么变都不会影响负载均衡。

灰度发布的程度不同：

灰度发布（又名金丝雀发布）是指在黑与白之间，能够平滑过渡的一种发布方式。

业务软件系统可以同时进行A/B testing，即让一部分用户继续用产品原有特性A，一部分用户开始用产品新特性B，如果用户对B没有什么反对意见，那么逐步扩大范围，把所有用户都迁移到新特性B上面来。

灰度发布可以保证整体系统的稳定，在初始灰度的时候就可以发现、调整问题，降低问题的影响面。

支持灰度发布的系统，把软件的运行系统由原先的测试系统和运营系统，划分为三个子系统：开发测试系统、生成测试系统、运营系统。经过测试开发后的软件，先部署在生成测试系统。开发测试系统与运营系统共享相同的数据库系统。

并通过负载设备，把一部分用户的业务请求转到生产测试系统，大部分用户的请求保留在原有的运营系统，经过生产测试验证后，就可以升级到运营系统 。

swarm和K8S两者都支持灰度发布。

但swarm的灰度发布是一次发布。

当执行swarm update操作时，所有旧的docker逐一全部替换 成新的版本。如果在替换过程中发现新版本存在问题时，只能强行终止update，然后执行回滚，整个更新就失败。在这个过程中对线上的应用会有全局性的影响。

而k8s有replication controller的机制，是基于Pod 的逐步发布 。

在发布的过程中，可以让k8s通过replication controller起一小部分新版本的pod并减少对应数量老版本的pod，新的pod可响应用户的请求，如果新的pod比较顺利，则慢慢增加新版本的数量而减少老版本数量，直至新版本全部替换老版本，如果新的pod出现了问题，此时让新pod立即下线，从而不对整个线上业务造成影响。

k8s的发布过程还可以人为干预，因此在重大发布时，这种方式其实更优。

弹性伸缩：

弹性伸缩是指根据宿主机硬件资源承载的情况以及外部的业务请求的情况，做出的一种容器部署架构动态变化的过程，比如某台宿主机的CPU使用率使用偏高，需要进行动态调度。

k8s可以根据Pod的使用率，自动、动态调整宿主机中Pod的个数，保障服务可用性。

但swarm的最小单元是容器，则不具备上述这种能力，只能基于容器进行弹性调度。

生态：

swarm是docke官方推出的集群方案，重在对容器的动态调度。

k8s是脱胎于google的一款基于容器的应用部署和管理打造一套强大并且易用的管理平台，重在对业务的动态调度。

从github上也可以到看到k8s项目的star和fork 都很高，而且网上找的资料也非常丰富。

也正是基于k8s的生态影响力，导致docker不得不在新发布的docker EE（Enterprise Edition）将k8s整合进来。

结论：

综上所述，K8S作为一款企业级的容器云方案，

Swarm轻量级、实施快、比较适合小规模部署，K8S则是企业级、功能全、支撑场景多，适合做企业级大规模云方案。

套用业界流行的话：swarm懂容器与技术，但K8S更懂管理云运营。

K8s组成：

一个kubernetes集群主要是由控制节点(master)、**工作节点(node)**构成，每个节点上都会安装不同的组件。

master：集群的控制平面，负责集群的决策 ( 管理 )

• ApiServer : 资源操作的唯一入口，接收用户输入的命令，提供认证、授权、API注册和发现等机制。

• Scheduler : 负责集群资源调度，按照预定的调度策略将Pod调度到相应的node节点上。

• ControllerManager : 负责维护集群的状态，比如程序部署安排、故障检测、自动扩展、滚动更新等。

• Etcd ：负责存储集群中各种资源对象的信息。

node：集群的数据平面，负责为容器提供运行环境 ( 干活 )

• Kubelet : 负责维护容器的生命周期，即通过控制docker，来创建、更新、销毁容器。

• KubeProxy : 负责提供集群内部的服务发现和负载均衡。

• Docker（容器运行）: 负责节点上容器的各种操作。

常用术语：

• 主机（Master）： 用于控制 Kubernetes 节点的计算机。所有任务分配都来自于此。
• **节点（Node）：**负责执行请求和所分配任务的计算机。由 Kubernetes 主机负责对节点进行控制。
• **容器集（Pod）：**被部署在单个节点上的，且包含一个或多个容器的容器组。同一容器集中的所有容器共享同一个 IP 地址、IPC、主机名称及其它资源。容器集会将网络和存储从底层容器中抽象出来。这样，您就能更加轻松地在集群中移动容器。
• **复制控制器（Replication controller）：**用于控制应在集群某处运行的完全相同的容器集副本数量。
• **服务（Service）：**将工作内容与容器集分离。Kubernetes 服务代理会自动将服务请求分发到正确的容器集------无论这个容器集会移到集群中的哪个位置，甚至可以被替换掉。
• **Kubelet：**运行在节点上的服务，可读取容器清单（container manifest），确保指定的容器启动并运行。
• kubectl： Kubernetes 的命令行配置工具。

K8S系统的"三大面"数据流：

（1）管理面

cubectl -> API server -> controller manager

cubectl -> API server -> scheduler manager

cubectl -> API server -> ...

cubectl -> API server -> ...

三大管理管理接口：

• kubectl命令行接口
• dashboard UI接口
• Restful API接口

二大管理方式：

• 命令行方式
• yaml配置文件

（2）控制面

controller manager -> API server -> etcd -> scheduler -> API server -> Kubelet -> pod

（3）业务面

来自于用户的服务请求，cubeprox -> pod

K8S的分层：

协议分层：

• 核心层：Kubernetes最核心的功能，对外提供API构建高层的应用，对内提供插件式应用执行环境
• 应用层：部署（无状态应用、有状态应用、批处理任务、集群应用等）和路由（服务发现、DNS解析等）
• 管理层：系统度量（如基础设施、容器和网络的度量），自动化（如自动扩展、动态Provision等）以及策略管理（RBAC、Quota、
• PSP、NetworkPolicy等）
• 接口层：kubectl命令行工具、客户端SDK以及集群联邦
• 生态系统：在接口层之上的庞大容器集群管理调度的生态系统，可以划分为两个范畴
  • Kubernetes外部：日志、监控、配置管理、CI、CD、Workflow、FaaS、OTS应用、ChatOps等
  • Kubernetes内部：CRI、CNI、CVI、镜像仓库、Cloud Provider、集群自身的配置和管理等

网络架构分层与生态：

在该生态中，K8S处于四层，主要职责实现容器与服务的编排 。

向下有：docker、LXD, rkt等容器引擎，docker只是其中一种容器的实现。

向上有：容器管理平台。

集群 Cluster：

集群有多个节点组成且可以按需添加节点（物理机/虚拟机），每一个节点都包含一定数量的 CPU 和内存 RAM。

容器 Container：

k8s 本身是一个容器调度平台，从宿主机操作系统来看，容器就是一个一个的进程。从容器内部来看容器就是一个操作系统，它有着自己的网络、CPU、文件系统等资源。

副本集 ReplicaSet：

一个应用发布时会发布多个 POD 实例，副本集可对应一个应用的一组 POD，它可以通过模板来规范某个应用的容器镜像、端口，副本数量等。运行时副本集会监控和维护 POD 的数量，数量过多则会下线 POD，过少则启动 POD。

Master：

集群控制节点，每个集群需要至少一个master节点负责集群的管控。

Node：

工作负载节点，由master分配容器到这些node工作节点上，然后node节点上的docker负责容器的运行。

Pod：

**容器集（Pod）：**被部署在单个节点上的，且包含一个或多个容器的容器组。同一容器集中的所有容器共享同一个 IP 地址、IPC、主机名称及其它资源。容器集会将网络和存储从底层容器中抽象出来。这样，您就能更加轻松地在集群中移动容器。

kubernetes的最小控制单元，容器都是运行在pod中的。POD的IP地址是随机的，删除POD会改变IP。POD都有一个根容器。

• 一个POD内可以由一个或多个容器组成
• 一个POD内的容器共享根容器的网络命名空间
• 一个POD内的网络地址由根容器提供

Pod是kubernetes集群进行管理的最小单元，程序要运行必须部署在容器中，而容器必须存在于Pod中。Pod可以认为是容器的封装，一个Pod中可以存在一个或者多个容器。

pod和docker 容器的关系？

pod 将一个或多个docker容器封装成一个统一的整体进行管理并对外提供服务。

Pod是kubernetes的最小管理单元，在kubernetes中，按照pod的创建方式可以将其分为两类：

• 自主式pod：kubernetes直接创建出来的Pod，这种pod删除后就没有了，也不会重建
• 控制器创建的pod：kubernetes通过控制器创建的pod，这种pod删除了之后还会自动重建

Pod控制器是管理pod的中间层，使用Pod控制器之后，只需要告诉Pod控制器，想要多少个什么样的Pod就可以了，它会创建出满足条件的Pod并确保每一个Pod资源处于用户期望的目标状态。如果Pod资源在运行中出现故障，它会基于指定策略重新编排Pod。

在kubernetes中，有很多类型的pod控制器，每种都有自己的适合的场景，常见的有下面这些：

• ReplicationController：比较原始的pod控制器，已经被废弃，由ReplicaSet替代
• ReplicaSet：保证副本数量一直维持在期望值，并支持pod数量扩缩容，镜像版本升级
• Deployment：通过控制ReplicaSet来控制Pod，并支持滚动升级、回退版本
• Horizontal Pod Autoscaler：可以根据集群负载自动水平调整Pod的数量，实现削峰填谷
• DaemonSet：在集群中的指定Node上运行且仅运行一个副本，一般用于守护进程类的任务
• Job：它创建出来的pod只要完成任务就立即退出，不需要重启或重建，用于执行一次性任务
• Cronjob：它创建的Pod负责周期性任务控制，不需要持续后台运行
• StatefulSet：管理有状态应用

Pod创建流程：

1、客户端提交创建请求，可以通过API Server的Restful API，也可以使用kubectl命令行工具。支持的数据类型包括JSON和YAML。

2、API Server处理用户请求，存储Pod数据到etcd。

3、调度器通过API Server查看未绑定的Pod。尝试为Pod分配主机。

4、过滤主机 (调度预选)：调度器用一组规则过滤掉不符合要求的主机。比如Pod指定了所需要的资源量，那么可用资源比Pod需要的资源量少的主机会被过滤掉。

5、主机打分(调度优选)：对第一步筛选出的符合要求的主机进行打分，在主机打分阶段，调度器会考虑一些整体优化策略，比如把容一个Replication Controller的副本分布到不同的主机上，使用最低负载的主机等。

6、选择主机：选择打分最高的主机，进行binding操作，结果存储到etcd中。

7、kubelet根据调度结果执行Pod创建操作： 绑定成功后，scheduler会调用APIServer的API在etcd中创建一个boundpod对象，描述在一个工作节点上绑定运行的所有pod信息。运行在每个工作节点上的kubelet也会定期与etcd同步boundpod信息，一旦发现应该在该工作节点上运行的boundpod对象没有更新，则调用Docker API创建并启动pod内的容器。

在整个生命周期中，Pod会出现5种状态（相位），分别如下：

• 挂起(Pending): apiserver已经创建了pod资源对象，但它尚未被调度完成或者仍处于下载镜像的过程中
• 运行中(Running): pod已经被调度至某节点，并且所有容器都已经被kubelet创建完成
• 成功(Succeeded): pod中的所有容器都已经成功终止并且不会被重启
• 失败(Failed): 所有容器都已经终止，但至少有一个容器终止失败，即容器返回了非0值的退出状态
• 未知(Unknown): apiserver无法正常获取到pod对象的状态信息，通常由网络通信失败所导致

ReplicaSet(RS)：

ReplicaSet的主要作用是保证一定数量的pod正常运行，它会持续监听这些Pod的运行状态，一旦Pod发生故障，就会重启或重建。同时它还支持对pod数量的扩缩容和镜像版本的升降级。

Deployment(Deploy)：

为了更好的解决服务编排的问题，kubernetes在V1.2版本开始，引入了Deployment控制器。值得一提的是，这种控制器并不直接管理pod，而是通过管理ReplicaSet来简介管理Pod，即：Deployment管理ReplicaSet，ReplicaSet管理Pod。所以Deployment比ReplicaSet功能更加强大。

Deployment主要功能有下面几个：

• 支持ReplicaSet的所有功能
• 支持发布的停止、继续
• 支持滚动升级和回滚版本

Horizontal Pod Autoscaler(HPA)：

在前面的课程中，我们已经可以实现通过手工执行kubectl scale命令实现Pod扩容或缩容，但是这显然不符合Kubernetes的定位目标--自动化、智能化。 Kubernetes期望可以实现通过监测Pod的使用情况，实现pod数量的自动调整，于是就产生了Horizontal Pod Autoscaler（HPA）这种控制器。

HPA可以获取每个Pod利用率，然后和HPA中定义的指标进行对比，同时计算出需要伸缩的具体值，最后实现Pod的数量的调整。其实HPA与之前的Deployment一样，也属于一种Kubernetes资源对象，它通过追踪分析RC控制的所有目标Pod的负载变化情况，来确定是否需要针对性地调整目标Pod的副本数，这是HPA的实现原理。

DaemonSet(DS)：

DaemonSet类型的控制器可以保证在集群中的每一台（或指定）节点上都运行一个副本。一般适用于日志收集、节点监控等场景。也就是说，如果一个Pod提供的功能是节点级别的（每个节点都需要且只需要一个），那么这类Pod就适合使用DaemonSet类型的控制器创建。

DaemonSet控制器的特点：

• 每当向集群中添加一个节点时，指定的 Pod 副本也将添加到该节点上
• 当节点从集群中移除时，Pod 也就被垃圾回收了

Job：

Job，主要用于负责**批量处理(一次要处理指定数量任务)短暂的一次性(每个任务仅运行一次就结束)**任务。Job特点如下：

• 当Job创建的pod执行成功结束时，Job将记录成功结束的pod数量
• 当成功结束的pod达到指定的数量时，Job将完成执行

CronJob(CJ)：

CronJob控制器以 Job控制器资源为其管控对象，并借助它管理pod资源对象，Job控制器定义的作业任务在其控制器资源创建之后便会立即执行，但CronJob可以以类似于Linux操作系统的周期性任务作业计划的方式控制其运行时间点及重复运行的方式。也就是说，CronJob可以在特定的时间点(反复的)去运行job任务。

kubernetes在集群启动之后，集群中的各个组件也都是以Pod方式运行的。可以通过下面命令查看：

[root@master ~]# kubectl get pod -n kube-system
NAMESPACE     NAME                             READY   STATUS    RESTARTS   AGE
kube-system   coredns-6955765f44-68g6v         1/1     Running   0          2d1h
kube-system   coredns-6955765f44-cs5r8         1/1     Running   0          2d1h
kube-system   etcd-master                      1/1     Running   0          2d1h
kube-system   kube-apiserver-master            1/1     Running   0          2d1h
kube-system   kube-controller-manager-master   1/1     Running   0          2d1h
kube-system   kube-flannel-ds-amd64-47r25      1/1     Running   0          2d1h
kube-system   kube-flannel-ds-amd64-ls5lh      1/1     Running   0          2d1h
kube-system   kube-proxy-685tk                 1/1     Running   0          2d1h
kube-system   kube-proxy-87spt                 1/1     Running   0          2d1h
kube-system   kube-scheduler-master            1/1     Running   0          2d1h

创建并运行：

kubernetes没有提供单独运行Pod的命令，都是通过Pod控制器来实现的

# 命令格式： kubectl run (pod控制器名称) [参数] 
# --image  指定Pod的镜像
# --port   指定端口
# --namespace  指定namespace
[root@master ~]# kubectl run nginx --image=nginx:latest --port=80 --namespace dev 
deployment.apps/nginx created

查看pod信息：

# 查看Pod基本信息
[root@master ~]# kubectl get pods -n dev
NAME    READY   STATUS    RESTARTS   AGE
nginx   1/1     Running   0          43s

# 查看Pod的详细信息
[root@master ~]# kubectl describe pod nginx -n dev
Name:         nginx
Namespace:    dev
Priority:     0
Node:         node1/192.168.5.4
Start Time:   Wed, 08 May 2021 09:29:24 +0800
Labels:       pod-template-hash=5ff7956ff6
              run=nginx
Annotations:  <none>
Status:       Running
IP:           10.244.1.23
IPs:
  IP:           10.244.1.23
Controlled By:  ReplicaSet/nginx
Containers:
  nginx:
    Container ID:   docker://4c62b8c0648d2512380f4ffa5da2c99d16e05634979973449c98e9b829f6253c
    Image:          nginx:latest
    Image ID:       docker-pullable://nginx@sha256:485b610fefec7ff6c463ced9623314a04ed67e3945b9c08d7e53a47f6d108dc7
    Port:           80/TCP
    Host Port:      0/TCP
    State:          Running
      Started:      Wed, 08 May 2021 09:30:01 +0800
    Ready:          True
    Restart Count:  0
    Environment:    <none>
    Mounts:
      /var/run/secrets/kubernetes.io/serviceaccount from default-token-hwvvw (ro)
Conditions:
  Type              Status
  Initialized       True
  Ready             True
  ContainersReady   True
  PodScheduled      True
Volumes:
  default-token-hwvvw:
    Type:        Secret (a volume populated by a Secret)
    SecretName:  default-token-hwvvw
    Optional:    false
QoS Class:       BestEffort
Node-Selectors:  <none>
Tolerations:     node.kubernetes.io/not-ready:NoExecute for 300s
                 node.kubernetes.io/unreachable:NoExecute for 300s
Events:
  Type    Reason     Age        From               Message
  ----    ------     ----       ----               -------
  Normal  Scheduled  <unknown>  default-scheduler  Successfully assigned dev/nginx-5ff7956ff6-fg2db to node1
  Normal  Pulling    4m11s      kubelet, node1     Pulling image "nginx:latest"
  Normal  Pulled     3m36s      kubelet, node1     Successfully pulled image "nginx:latest"
  Normal  Created    3m36s      kubelet, node1     Created container nginx
  Normal  Started    3m36s      kubelet, node1     Started container nginx

访问Pod：

# 获取podIP
[root@master ~]# kubectl get pods -n dev -o wide
NAME    READY   STATUS    RESTARTS   AGE    IP             NODE    ... 
nginx   1/1     Running   0          190s   10.244.1.23   node1   ...

#访问POD
[root@master ~]# curl http://10.244.1.23:80
<!DOCTYPE html>
<html>
<head>
	<title>Welcome to nginx!</title>
</head>
<body>
	<p><em>Thank you for using nginx.</em></p>
</body>
</html>

删除指定Pod：

# 删除指定Pod
[root@master ~]# kubectl delete pod nginx -n dev
pod "nginx" deleted

# 此时，显示删除Pod成功，但是再查询，发现又新产生了一个 
[root@master ~]# kubectl get pods -n dev
NAME    READY   STATUS    RESTARTS   AGE
nginx   1/1     Running   0          21s

# 这是因为当前Pod是由Pod控制器创建的，控制器会监控Pod状况，一旦发现Pod死亡，会立即重建
# 此时要想删除Pod，必须删除Pod控制器

# 先来查询一下当前namespace下的Pod控制器
[root@master ~]# kubectl get deploy -n  dev
NAME    READY   UP-TO-DATE   AVAILABLE   AGE
nginx   1/1     1            1           9m7s

# 接下来，删除此PodPod控制器
[root@master ~]# kubectl delete deploy nginx -n dev
deployment.apps "nginx" deleted

# 稍等片刻，再查询Pod，发现Pod被删除了
[root@master ~]# kubectl get pods -n dev
No resources found in dev namespace.

配置操作：

创建一个pod-nginx.yaml，内容如下：

apiVersion: v1
kind: Pod
metadata:
  name: nginx
  namespace: dev
spec:
  containers:
  - image: nginx:latest
    name: pod
    ports:
    - name: nginx-port
      containerPort: 80
      protocol: TCP

然后就可以执行对应的创建和删除命令了：

创建：kubectl create -f pod-nginx.yaml

删除：kubectl delete -f pod-nginx.yaml

Controller：

控制器，通过它来实现对pod的管理，比如启动pod、停止pod、伸缩pod的数量等等。

用来管理POD。控制器的种类有很多：

• RC Replication Controller：控制POD有多个副本
• RS ReplicaSet：RC控制的升级版
• Deployment：推荐使用，功能更强大，包含了RS控制器
• DaemonSet：保证所有的Node上有且只有一个Pod在运行
• StatefulSet：有状态的应用，为Pod提供唯一的标识，它可以保证部署和scale的顺序

Service：

pod对外服务的统一入口，下面可以维护者同一类的多个pod。

虽然每个Pod都会分配一个单独的Pod IP，然而却存在如下两问题：

• Pod ip 会随着Pod的重建产生变化，ip地址不是固定的
• Pod ip 仅仅是集群内可见的虚拟IP，外部无法访问

这样对于访问这个服务带来了难度。因此，kubernetes设计了Service来解决这个问题。

Service对象拥有如下关键特征：

• 拥有一个唯一指定的名字
• 拥有一个虚拟IP（Cluster IP、Service IP、或VIP）和端口号
• 能够体统某种远程服务能力
• 被映射到了提供这种服务能力的一组容器应用上

Service会对提供同一个服务的多个pod进行聚合，并且提供一个统一的入口地址。通过访问Service的入口地址就能访问到后面的pod服务。Service可以看作是一组同类Pod对外的访问接口。借助Service，应用可以方便地实现服务发现和负载均衡。

理解三个不同的ip：NodeIP、CluterIP、POD IP。

Service在很多情况下只是一个概念，真正起作用的其实是kube-proxy服务进程，每个Node节点上都运行着一个kube-proxy服务进程。当创建Service的时候会通过api-server向etcd写入创建的service的信息，而kube-proxy会基于监听的机制发现这种Service的变动，然后它会将最新的Service信息转换成对应的访问规则。

# 10.97.97.97:80 是service提供的访问入口
# 当访问这个入口的时候，可以发现后面有三个pod的服务在等待调用，
# kube-proxy会基于rr（轮询）的策略，将请求分发到其中一个pod上去
# 这个规则会同时在集群内的所有节点上都生成，所以在任何一个节点上访问都可以。
[root@node1 ~]# ipvsadm -Ln
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags
  -> RemoteAddress:Port           Forward Weight ActiveConn InActConn
TCP  10.97.97.97:80 rr
  -> 10.244.1.39:80               Masq    1      0          0
  -> 10.244.1.40:80               Masq    1      0          0
  -> 10.244.2.33:80               Masq    1      0          0

kube-proxy目前支持三种工作模式:

userspace 模式：

userspace模式下，kube-proxy会为每一个Service创建一个监听端口，发向Cluster IP的请求被Iptables规则重定向到kube-proxy监听的端口上，kube-proxy根据LB算法选择一个提供服务的Pod并和其建立链接，以将请求转发到Pod上。 该模式下，kube-proxy充当了一个四层负责均衡器的角色。由于kube-proxy运行在userspace中，在进行转发处理时会增加内核和用户空间之间的数据拷贝，虽然比较稳定，但是效率比较低。

iptables 模式：

iptables模式下，kube-proxy为service后端的每个Pod创建对应的iptables规则，直接将发向Cluster IP的请求重定向到一个Pod IP。 该模式下kube-proxy不承担四层负责均衡器的角色，只负责创建iptables规则。该模式的优点是较userspace模式效率更高，但不能提供灵活的LB策略，当后端Pod不可用时也无法进行重试。

ipvs 模式：

ipvs模式和iptables类似，kube-proxy监控Pod的变化并创建相应的ipvs规则。ipvs相对iptables转发效率更高。除此以外，ipvs支持更多的LB算法。

# 此模式必须安装ipvs内核模块，否则会降级为iptables
# 开启ipvs
[root@k8s-master01 ~]# kubectl edit cm kube-proxy -n kube-system
# 修改mode: "ipvs"
[root@k8s-master01 ~]# kubectl delete pod -l k8s-app=kube-proxy -n kube-system
[root@node1 ~]# ipvsadm -Ln
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags
  -> RemoteAddress:Port           Forward Weight ActiveConn InActConn
TCP  10.97.97.97:80 rr
  -> 10.244.1.39:80               Masq    1      0          0
  -> 10.244.1.40:80               Masq    1      0          0
  -> 10.244.2.33:80               Masq    1      0          0

Service类型：

Service的资源清单文件：

kind: Service  # 资源类型
apiVersion: v1  # 资源版本
metadata: # 元数据
  name: service # 资源名称
  namespace: dev # 命名空间
spec: # 描述
  selector: # 标签选择器，用于确定当前service代理哪些pod
    app: nginx
  type: # Service类型，指定service的访问方式
  clusterIP:  # 虚拟服务的ip地址
  sessionAffinity: # session亲和性，支持ClientIP、None两个选项
  ports: # 端口信息
    - protocol: TCP 
      port: 3017  # service端口
      targetPort: 5003 # pod端口
      nodePort: 31122 # 主机端口

• ClusterIP：默认值，它是Kubernetes系统自动分配的虚拟IP，只能在集群内部访问
• NodePort：将Service通过指定的Node上的端口暴露给外部，通过此方法，就可以在集群外部访问服务
• LoadBalancer：使用外接负载均衡器完成到服务的负载分发，注意此模式需要外部云环境支持
• ExternalName： 把集群外部的服务引入集群内部，直接使用

Endpoint：

Endpoint是kubernetes中的一个资源对象，存储在etcd中，用来记录一个service对应的所有pod的访问地址，它是根据service配置文件中selector描述产生的。

一个Service由一组Pod组成，这些Pod通过Endpoints暴露出来，Endpoints是实现实际服务的端点集合。换句话说，service和pod之间的联系是通过endpoints实现的。

负载分发策略：

对Service的访问被分发到了后端的Pod上去，目前kubernetes提供了两种负载分发策略：

• 如果不定义，默认使用kube-proxy的策略，比如随机、轮询

• 基于客户端地址的会话保持模式，即来自同一个客户端发起的所有请求都会转发到固定的一个Pod上。此模式可以使在spec中添加sessionAffinity:ClientIP选项

NodePort类型的Service：

在之前的样例中，创建的Service的ip地址只有集群内部才可以访问，如果希望将Service暴露给集群外部使用，那么就要使用到另外一种类型的Service，称为NodePort类型。NodePort的工作原理其实就是将service的端口映射到Node的一个端口上，然后就可以通过NodeIp:NodePort来访问service了。

LoadBalancer类型的Service：

LoadBalancer和NodePort很相似，目的都是向外部暴露一个端口，区别在于LoadBalancer会在集群的外部再来做一个负载均衡设备，而这个设备需要外部环境支持的，外部服务发送到这个设备上的请求，会被设备负载之后转发到集群中。

ExternalName类型的Service：

ExternalName类型的Service用于引入集群外部的服务，它通过externalName属性指定外部一个服务的地址，然后在集群内部访问此service就可以访问到外部的服务了。

Ingress介绍：

在前面课程中已经提到，Service对集群之外暴露服务的主要方式有两种：NotePort和LoadBalancer，但是这两种方式，都有一定的缺点：

NodePort方式的缺点是会占用很多集群机器的端口，那么当集群服务变多的时候，这个缺点就愈发明显

LB方式的缺点是每个service需要一个LB，浪费、麻烦，并且需要kubernetes之外设备的支持

基于这种现状，kubernetes提供了Ingress资源对象，Ingress只需要一个NodePort或者一个LB就可以满足暴露多个Service的需求。工作机制大致如下图表示：

实际上，Ingress相当于一个7层的负载均衡器，是kubernetes对反向代理的一个抽象，它的工作原理类似于Nginx，可以理解成在Ingress里建立诸多映射规则，Ingress Controller通过监听这些配置规则并转化成Nginx的反向代理配置 , 然后对外部提供服务。在这里有两个核心概念：

• ingress：kubernetes中的一个对象，作用是定义请求如何转发到service的规则
• ingress controller：具体实现反向代理及负载均衡的程序，对ingress定义的规则进行解析，根据配置的规则来实现请求转发，实现方式有很多，比如Nginx, Contour, Haproxy等等

Ingress（以Nginx为例）的工作原理如下：

• 用户编写Ingress规则，说明哪个域名对应kubernetes集群中的哪个Service
• Ingress控制器动态感知Ingress服务规则的变化，然后生成一段对应的Nginx反向代理配置
• Ingress控制器会将生成的Nginx配置写入到一个运行着的Nginx服务中，并动态更新
• 到此为止，其实真正在工作的就是一个Nginx了，内部配置了用户定义的请求转发规则

创建集群内部可访问的Service：

# 暴露Service
[root@master ~]# kubectl expose deploy nginx --name=svc-nginx1 --type=ClusterIP --port=80 --target-port=80 -n dev
service/svc-nginx1 exposed

# 查看service
[root@master ~]# kubectl get svc svc-nginx1 -n dev -o wide
NAME         TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)   AGE     SELECTOR
svc-nginx1   ClusterIP   10.109.179.231   <none>        80/TCP    3m51s   run=nginx

# 这里产生了一个CLUSTER-IP，这就是service的IP，在Service的生命周期中，这个地址是不会变动的
# 可以通过这个IP访问当前service对应的POD
[root@master ~]# curl 10.109.179.231:80
<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
</head>
<body>
<h1>Welcome to nginx!</h1>
.......
</body>
</html>

创建集群外部也可访问的Service：

# 上面创建的Service的type类型为ClusterIP，这个ip地址只用集群内部可访问
# 如果需要创建外部也可以访问的Service，需要修改type为NodePort
[root@master ~]# kubectl expose deploy nginx --name=svc-nginx2 --type=NodePort --port=80 --target-port=80 -n dev
service/svc-nginx2 exposed

# 此时查看，会发现出现了NodePort类型的Service，而且有一对Port（80:31928/TC）
[root@master ~]# kubectl get svc  svc-nginx2  -n dev -o wide
NAME          TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)        AGE    SELECTOR
svc-nginx2    NodePort    10.100.94.0      <none>        80:31928/TCP   9s     run=nginx

# 接下来就可以通过集群外的主机访问 节点IP:31928访问服务了
# 例如在的电脑主机上通过浏览器访问下面的地址
http://192.168.90.100:31928/

删除Service：

[root@master ~]# kubectl delete svc svc-nginx-1 -n dev 
service "svc-nginx-1" deleted

配置方式：

创建一个svc-nginx.yaml，内容如下：

apiVersion: v1
kind: Service
metadata:
  name: svc-nginx
  namespace: dev
spec:
  clusterIP: 10.109.179.231 #固定svc的内网ip
  ports:
  - port: 80
    protocol: TCP
    targetPort: 80
  selector:
    run: nginx
  type: ClusterIP

然后就可以执行对应的创建和删除命令了：

创建：kubectl create -f svc-nginx.yaml

删除：kubectl delete -f svc-nginx.yaml

Label：

标签，用于对pod进行分类，同一类pod会拥有相同的标签。

Label是kubernetes系统中的一个重要概念。它的作用就是在资源上添加标识，用来对它们进行区分和选择。

Label的特点：

• 一个Label会以key/value键值对的形式附加到各种对象上，如Node、Pod、Service等等
• 一个资源对象可以定义任意数量的Label ，同一个Label也可以被添加到任意数量的资源对象上去
• Label通常在资源对象定义时确定，当然也可以在对象创建后动态添加或者删除

可以通过Label实现资源的多维度分组，以便灵活、方便地进行资源分配、调度、配置、部署等管理工作。

一些常用的Label 示例如下：

• 版本标签："version":"release", "version":"stable"...
• 环境标签："environment":"dev"，"environment":"test"，"environment":"pro"
• 架构标签："tier":"frontend"，"tier":"backend"

标签定义完毕之后，还要考虑到标签的选择，这就要使用到Label Selector，即：

Label用于给某个资源对象定义标识

Label Selector用于查询和筛选拥有某些标签的资源对象

当前有两种Label Selector：

1.基于等式的Label Selector：

• name = slave: 选择所有包含Label中key="name"且value="slave"的对象

• env != production: 选择所有包括Label中的key="env"且value不等于"production"的对象

2.基于集合的Label Selector：

• name in (master, slave): 选择所有包含Label中的key="name"且value="master"或"slave"的对象

• name not in (frontend): 选择所有包含Label中的key="name"且value不等于"frontend"的对象

标签的选择条件可以使用多个，此时将多个Label Selector进行组合，使用逗号","进行分隔即可。例如：

name=slave，env!=production

name not in (frontend)，env!=production

命令方式：

# 为pod资源打标签
[root@master ~]# kubectl label pod nginx-pod version=1.0 -n dev
pod/nginx-pod labeled

# 为pod资源更新标签
[root@master ~]# kubectl label pod nginx-pod version=2.0 -n dev --overwrite
pod/nginx-pod labeled

# 查看标签
[root@master ~]# kubectl get pod nginx-pod  -n dev --show-labels
NAME        READY   STATUS    RESTARTS   AGE   LABELS
nginx-pod   1/1     Running   0          10m   version=2.0

# 筛选标签
[root@master ~]# kubectl get pod -n dev -l version=2.0  --show-labels
NAME        READY   STATUS    RESTARTS   AGE   LABELS
nginx-pod   1/1     Running   0          17m   version=2.0
[root@master ~]# kubectl get pod -n dev -l version!=2.0 --show-labels
No resources found in dev namespace.

#删除标签
[root@master ~]# kubectl label pod nginx-pod version- -n dev
pod/nginx-pod labeled

配置方式：

apiVersion: v1
kind: Pod
metadata:
  name: nginx
  namespace: dev
  labels:
    version: "3.0" 
    env: "test"
spec:
  containers:
  - image: nginx:latest
    name: pod
    ports:
    - name: nginx-port
      containerPort: 80
      protocol: TCP

然后就可以执行对应的更新命令了：kubectl apply -f pod-nginx.yaml

Deployment：

在kubernetes中，Pod是最小的控制单元，但是kubernetes很少直接控制Pod，一般都是通过Pod控制器来完成的。Pod控制器用于pod的管理，确保pod资源符合预期的状态，当pod的资源出现故障时，会尝试进行重启或重建pod。

副本集就是一种基本的发布机制，可以实现基本的或者高级的应用发布，但操作较为繁琐。未来简化这些操作，k8s 引入了 Deployment 来管理 ReplicaSet，实现一些高级发布机制。

在kubernetes中Pod控制器的种类有很多，本章节只介绍一种：Deployment。

命令操作：

# 命令格式: kubectl create deployment 名称  [参数] 
# --image  指定pod的镜像
# --port   指定端口
# --replicas  指定创建pod数量
# --namespace  指定namespace
[root@master ~]# kubectl run nginx --image=nginx:latest --port=80 --replicas=3 -n dev
deployment.apps/nginx created

# 查看创建的Pod
[root@master ~]# kubectl get pods -n dev
NAME                     READY   STATUS    RESTARTS   AGE
nginx-5ff7956ff6-6k8cb   1/1     Running   0          19s
nginx-5ff7956ff6-jxfjt   1/1     Running   0          19s
nginx-5ff7956ff6-v6jqw   1/1     Running   0          19s

# 查看deployment的信息
[root@master ~]# kubectl get deploy -n dev
NAME    READY   UP-TO-DATE   AVAILABLE   AGE
nginx   3/3     3            3           2m42s

# UP-TO-DATE：成功升级的副本数量
# AVAILABLE：可用副本的数量
[root@master ~]# kubectl get deploy -n dev -o wide
NAME    READY UP-TO-DATE  AVAILABLE   AGE     CONTAINERS   IMAGES              SELECTOR
nginx   3/3     3         3           2m51s   nginx        nginx:latest        run=nginx

# 查看deployment的详细信息
[root@master ~]# kubectl describe deploy nginx -n dev
Name:                   nginx
Namespace:              dev
CreationTimestamp:      Wed, 08 May 2021 11:14:14 +0800
Labels:                 run=nginx
Annotations:            deployment.kubernetes.io/revision: 1
Selector:               run=nginx
Replicas:               3 desired | 3 updated | 3 total | 3 available | 0 unavailable
StrategyType:           RollingUpdate
MinReadySeconds:        0
RollingUpdateStrategy:  25% max unavailable, 25% max surge
Pod Template:
  Labels:  run=nginx
  Containers:
   nginx:
    Image:        nginx:latest
    Port:         80/TCP
    Host Port:    0/TCP
    Environment:  <none>
    Mounts:       <none>
  Volumes:        <none>
Conditions:
  Type           Status  Reason
  ----           ------  ------
  Available      True    MinimumReplicasAvailable
  Progressing    True    NewReplicaSetAvailable
OldReplicaSets:  <none>
NewReplicaSet:   nginx-5ff7956ff6 (3/3 replicas created)
Events:
  Type    Reason             Age    From                   Message
  ----    ------             ----   ----                   -------
  Normal  ScalingReplicaSet  5m43s  deployment-controller  Scaled up replicaset nginx-5ff7956ff6 to 3
  
# 删除 
[root@master ~]# kubectl delete deploy nginx -n dev
deployment.apps "nginx" deleted

配置操作：

创建一个deploy-nginx.yaml，内容如下：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx
  namespace: dev
spec:
  replicas: 3
  selector:
    matchLabels:
      run: nginx
  template:
    metadata:
      labels:
        run: nginx
    spec:
      containers:
      - image: nginx:latest
        name: nginx
        ports:
        - containerPort: 80
          protocol: TCP

然后就可以执行对应的创建和删除命令了：

创建：kubectl create -f deploy-nginx.yaml

删除：kubectl delete -f deploy-nginx.yaml

NameSpace：

命名空间，用来隔离pod的运行环境。

Namespace是kubernetes系统中的一种非常重要资源，它的主要作用是用来实现多套环境的资源隔离或者多租户的资源隔离。

默认情况下，kubernetes集群中的所有的Pod都是可以相互访问的。但是在实际中，可能不想让两个Pod之间进行互相的访问，那此时就可以将两个Pod划分到不同的namespace下。kubernetes通过将集群内部的资源分配到不同的Namespace中，可以形成逻辑上的"组"，以方便不同的组的资源进行隔离使用和管理。

可以通过kubernetes的授权机制，将不同的namespace交给不同租户进行管理，这样就实现了多租户的资源隔离。此时还能结合kubernetes的资源配额机制，限定不同租户能占用的资源，例如CPU使用量、内存使用量等等，来实现租户可用资源的管理。

kubernetes在集群启动之后，会默认创建几个namespace

[root@master ~]# kubectl  get namespace
NAME              STATUS   AGE
default           Active   45h     #  所有未指定Namespace的对象都会被分配在default命名空间
kube-node-lease   Active   45h     #  集群节点之间的心跳维护，v1.13开始引入
kube-public       Active   45h     #  此命名空间下的资源可以被所有人访问（包括未认证用户）
kube-system       Active   45h     #  所有由Kubernetes系统创建的资源都处于这个命名空间

下面来看namespace资源的具体操作：

查看：

# 1 查看所有的ns  命令：kubectl get ns
[root@master ~]# kubectl get ns
NAME              STATUS   AGE
default           Active   45h
kube-node-lease   Active   45h
kube-public       Active   45h     
kube-system       Active   45h     

# 2 查看指定的ns   命令：kubectl get ns ns名称
[root@master ~]# kubectl get ns default
NAME      STATUS   AGE
default   Active   45h

# 3 指定输出格式  命令：kubectl get ns ns名称  -o 格式参数
# kubernetes支持的格式有很多，比较常见的是wide、json、yaml
[root@master ~]# kubectl get ns default -o yaml
apiVersion: v1
kind: Namespace
metadata:
  creationTimestamp: "2021-05-08T04:44:16Z"
  name: default
  resourceVersion: "151"
  selfLink: /api/v1/namespaces/default
  uid: 7405f73a-e486-43d4-9db6-145f1409f090
spec:
  finalizers:
  - kubernetes
status:
  phase: Active
  
# 4 查看ns详情  命令：kubectl describe ns ns名称
[root@master ~]# kubectl describe ns default
Name:         default
Labels:       <none>
Annotations:  <none>
Status:       Active  # Active 命名空间正在使用中  Terminating 正在删除命名空间

# ResourceQuota 针对namespace做的资源限制
# LimitRange针对namespace中的每个组件做的资源限制
No resource quota.
No LimitRange resource.

创建：

# 创建namespace
[root@master ~]# kubectl create ns dev
namespace/dev created

删除：

# 删除namespace
[root@master ~]# kubectl delete ns dev
namespace "dev" deleted

配置方式：

首先准备一个yaml文件：ns-dev.yaml

apiVersion: v1
kind: Namespace
metadata:
  name: dev

然后就可以执行对应的创建和删除命令了：

• 创建：kubectl create -f ns-dev.yaml
• 删除：kubectl delete -f ns-dev.yaml

Ingress：

简单说，是一个代理，可以根据配置转发请求到指定的服务上。

通俗来讲，ingress和之前提到的Service、Deployment，也是一个k8s的资源类型，ingress用于实现用域名的方式访问k8s内部应用。

• ingress是k8s集群的请求入口，可以理解为对多个service的再次抽象.
• 通常说的ingress一般包括ingress资源对象及ingress-controller两部分组成
• ingress-controller有多种实现，社区原生的是ingress-nginx，根据具体需求选择
• ingress自身的暴露有多种方式，需要根据基础环境及业务类型选择合适的方式

Ingress为Kubernetes集群中的服务提供了入口，可以提供负载均衡、SSL终止和基于名称的虚拟主机，在生产环境中常用的Ingress有Treafik、Nginx、HAProxy、Istio等。

在Kubernetesv 1.1版中添加的Ingress用于从集群外部到集群内部Service的HTTP和HTTPS路由，流量从Internet到Ingress再到Services最后到Pod上，通常情况下，Ingress部署在所有的Node节点上。

Ingress可以配置提供服务外部访问的URL、负载均衡、终止SSL，并提供基于域名的虚拟主机。但Ingress不会暴露任意端口或协议。

由于K8S集群拥有强大的副本控制能力，Pod随时可能从一个节点上被驱逐到另一个节点上，或者直接销毁再来一个新的。

然而伴随着Pod的销毁和重生，Pod的IP等信息不断地在改变，此时使用K8S提供的Service机制可以解决这一问题，Service通过标签选定指定的Pod作为后端服务，并监听这些Pod的变化。

在对外暴露服务时，使用Service的NodePort是一个方法

问题1-如何管理端口：

当需要对外暴露的服务量比较多的时候，端口管理的问题变会暴露出来。

此时的一个处理方案是使用一个代理服务（例如nginx）根据请求信息将请求转发到不同的服务器上。

问题2-如何管理转发配置：

每当有新服务加入，都需要对该服务的配置进行修改、升级，在服务数量逐渐变多后，该配置项目会变得越来越大，手工修改的风险也会逐渐增高。

那么需要一个工具来简化这一过程，希望可以通过简单的配置动态生成代理中复杂的配置，最好还可以顺手重新加载配置文件。

K8S刚好也提供了此类型资源。

Pod漂移问题：

众所周知 Kubernetes 具有强大的副本控制能力，能保证在任意副本(Pod)挂掉时自动从其他机器启动一个新的，还可以动态扩容等，总之一句话，这个 Pod 可能在任何时刻出现在任何节点上，也可能在任何时刻死在任何节点上；那么自然随着 Pod 的创建和销毁，Pod IP 肯定会动态变化；那么如何把这个动态的 Pod IP 暴露出去？这里借助于 Kubernetes 的 Service 机制，Service 可以以标签的形式选定一组带有指定标签的 Pod，并监控和自动负载他们的 Pod IP，那么我们向外暴露只暴露 Service IP 就行了；这就是 NodePort 模式：即在每个节点上开起一个端口，然后转发到内部 Pod IP 上，如下图所示

端口管理问题：

采用 NodePort 方式暴露服务面临一个坑爹的问题是，服务一旦多起来，NodePort 在每个节点上开启的端口会及其庞大，而且难以维护；这时候引出的思考问题是 "能不能使用 Nginx 啥的只监听一个端口，比如 80，然后按照域名向后转发？" 这思路很好，简单的实现就是使用 DaemonSet 在每个 node 上监听 80，然后写好规则，因为 Nginx 外面绑定了宿主机 80 端口(就像 NodePort)，本身又在集群内，那么向后直接转发到相应 Service IP 就行了，如下图所示

域名分配及动态更新问题：

从上面的思路，采用 Nginx 似乎已经解决了问题，但是其实这里面有一个很大缺陷：每次有新服务加入怎么改 Nginx 配置？总不能手动改或者来个 Rolling Update 前端 Nginx Pod 吧？这时候 "伟大而又正直勇敢的" Ingress 登场，如果不算上面的 Nginx，Ingress 只有两大组件：Ingress Controller 和 Ingress

Ingress 这个玩意，简单的理解就是 你原来要改 Nginx 配置，然后配置各种域名对应哪个 Service，现在把这个动作抽象出来，变成一个 Ingress 对象，你可以用 yml 创建，每次不要去改 Nginx 了，直接改 yml 然后创建/更新就行了；那么问题来了："Nginx 咋整？"

Ingress Controller 这东西就是解决 "Nginx 咋整" 的；Ingress Controoler 通过与 Kubernetes API 交互，动态的去感知集群中 Ingress 规则变化，然后读取他，按照他自己模板生成一段 Nginx 配置，再写到 Nginx Pod 里，最后 reload 一下，工作流程如下图

当然在实际应用中，最新版本 Kubernetes 已经将 Nginx 与 Ingress Controller 合并为一个组件，所以 Nginx 无需单独部署，只需要部署 Ingress Controller 即可

Ingress 工作原理：

1. ingress-controller通过和 kubernetes APIServer 交互，动态的去感知集群中ingress规则变化，

2. 然后读取它，按照自定义的规则，规则就是写明了哪个域名对应哪个service，生成一段nginx配置，

3. 再写到nginx-ingress-controller的pod里，这个ingress-controller的pod里运行着一个Nginx服务，控制器会把生成的 nginx配置写入 /etc/nginx.conf文件中，

4. 然后reload一下使配置生效。以此达到域名区分配置和动态更新的作用。

在使用普通的Service时，集群中每个节点的kube-proxy在监听到Service和Endpoints的变化时，会动态的修改相关的iptables的转发规则。 客户端在访问时通过iptables设置的规则进行路由转发达到访问服务的目的。

而Ingress则跳过了kube-proxy这一层，通过Ingress Controller中的代理配置进行路由转发达到访问目标服务的目的。

实际上可以把IngressController看做一个拥有默认处理后端的代理，根据Ingress资源的配置动态修改代理的配置文件，以实现按照规则转发请求的功能。

Ingress配置项：

type Ingress struct {
    metav1.TypeMeta `json:",inline"`
    metav1.ObjectMeta `json:"metadata,omitempty"`
 
    // Ingess配置。
    Spec IngressSpec `json:"spec,omitempty"`
 
    // Ingress资源当前状态。
    Status IngressStatus `json:"status,omitempty"`
}
type IngressSpec struct {
    // 默认的后端服务，当不匹配所有的Ingress规则的时候使用。
    // 一般情况默认后端都在Ingress控制器中配置，该字段不进行声明配置。
    // 如果没有主机或路径与 Ingress 对象中的 HTTP 请求匹配，则流量将路由到您的默认后端。
    Backend *IngressBackend `json:"backend,omitempty"`
 
    // TLS配置。目前Ingress只支持443一种TLS端口。
    // 如果列表中有多个不同的hosts，将会在ingress controller支持SNI的情况下,
    // 通过使用SNI TLS扩展中声明的主机名，在同个端口下使用多路复用。
    TLS []IngressTLS `json:"tls,omitempty"`
 
    // Ingress的规则。未匹配到规则列表中规则的请求将会被转发到默认后端上。
    Rules []IngressRule `json:"rules,omitempty"`
}
type IngressBackend struct {
    // 服务名。
    ServiceName string `json:"serviceName"`
 
    // 服务的端口。
    ServicePort intstr.IntOrString `json:"servicePort"`
}
type IngressRule struct {
    // 域名。
    // 不能使用IP地址，不能使用端口。对HTTP服务使用80端口，HTTPS服务使用443端口。
    Host string `json:"host,omitempty"`
 
    // 域名下的具体转发规则。
    // 未定义的情况下会将请求转发至默认后端。
    IngressRuleValue `json:",inline,omitempty"`
}
type IngressRuleValue struct {
    HTTP *HTTPIngressRuleValue `json:"http,omitempty"`
}
type HTTPIngressRuleValue struct {
    Paths []HTTPIngressPath `json:"paths"`
}
type HTTPIngressPath struct {
    // 匹配的路径，必须以/为开头。
    // 未定义的情况下会将请求转发至默认后端。
    Path string `json:"path,omitempty"`
 
    // 处理请求的后端服务。
    Backend IngressBackend `json:"backend"`

kubectl：

Kubernetes 的命令行配置工具。

组件解析：

pod 和 deployment 关系：

pod：

• Pod 是 k8s 的最小调度单位
• 一个 Pod 代表集群上正在运行的一个进程
• Pod 中运行一个容器，可以将 Pod 视为单个封装的容器，但是 K8s 是直接管理 Pod 而不是容器
• Pod 中运行多个容器，这些容器可以形成一个单一的内部service单位，可以相互通信，共享数据
• 一个 Pod 被分配一个独立的IP地址，Pod中的每个容器共享 IP 地址和网络端口，Pod 内的容器可以使用 localhost 相互通信。
• Pod 中的容器与Pod 外部通信时，他们必须协调如何使用共享网络资源（如端口）。

deployment：

• 创建 deployment 的时候一定会创建Pod
• Deployment 可以新建及管理多副本应用（即多个副本 Pod）
• deployment 可以部署多个Pod，所有 Pod 的名字后面会随机带一串随机数避免重复
• Deployement 会配合 RC 调度保障定量的 Pod 数量。

K8s使用：

结构模型：

k8s 是经典的一对多模型，有一个主要的管理节点master和许多的工作节点slaver。当然，k8s 也可以配置多个管理节点，拥有两个以上的管理节点被称为 高可用 。k8s 包括了许多的组件，每个组件都是单运行在一个docker容器中，然后通过自己规划的虚拟网络相互访问。你可以通过 kubectl get pod -n kube-system 查看所有节点上的组件容器。

在管理节点中会比工作节点运行更多的 k8s 组件，我们就是靠着这些多出来的组件来对工作节点发号施令。他们都叫什么这里就不详细提了。反正对于"基本使用"来说，这些名字并不重要。

理念：

要想理解一个东西就要先明白它的内在理念。通俗点就是，k8s 做了什么？为了提供更加可靠的服务，就要增加服务器的数量，减少每个服务器的体量来平摊负载，而越来越多的虚拟机就会带来越来越高的运维成本。如何让少量的运维人员就可以管理数量众多的服务器及其上的服务呢？这就是 k8s 做的工作。

k8s 把数量众多的服务器重新抽象为一个统一的资源池，对于运维人员来说，他们面前没有服务器1、服务器2的概念，而是一个统一的资源池，增加新的服务器对运维人员来说，只是增加自资源池的可用量。不仅如此，k8s 把所有能用的东西都抽象成了资源的概念，从而提供了一套更统一，更简洁的管理方式。

基本命令：

命令名	类型	作用
get	查	列出某个类型的下属资源
describe	查	查看某个资源的详细信息
logs	查	查看某个 pod 的日志
create	增	新建资源
explain	查	查看某个资源的配置项
delete	删	删除某个资源
edit	改	修改某个资源的配置项
apply	改	应用某个资源的配置项

执行了 kubectl get pod -n kube-system 命令后，你就可以看到如下内容：

其中每一行就是一个资源，这里我们看到的资源是 pod 。你看到的 pod 数量可能和我的不一致，因为这个列表里包含了 k8s 在所有节点上运行的 pod ，你加入的节点越多，那么显示的 pod 也就越多。我们来一列一列的看：

• NAME：第一列是 pod 的名字，k8s 可以为 pod 随机分配一个五位数的后缀。

• READY：第二列是 pod 中已经就绪的 docker 容器的数量，上文中我们提到了，pod 封装了一个或多个 docker 容器。在这里，1/1的含义为就绪1个容器/共计1个容器。

• STATUS：第三列是 pod 的当前状态，下面是一些常见的状态：

• RESTART：k8s 可以自动重启 pod，这一行就是标记了 pod 一共重启了多少次。

• AGE：pod 一共存在了多长时间。

状态名	含义
Running	运行中
Error	异常，无法提供服务
Pending	准备中，暂时无法提供服务
Terminaling	结束中，即将被移除
Unknown	未知状态，多发生于节点宕机
PullImageBackOff	镜像拉取失败

K8s原理：

• 通过Kubectl提交一个创建RC（Replication Controller）的请求，该请求通过APlserver写入etcd

• 此时Controller Manager通过API Server的监听资源变化的接口监听到此RC事件

• 分析之后，发现当前集群中还没有它所对应的Pod实例

• 于是根据RC里的Pod模板定义一个生成Pod对象，通过APIServer写入etcd

• 此事件被Scheduler发现，它立即执行执行一个复杂的调度流程，为这个新的Pod选定一个落户的Node，然后通过API Server讲这一结果写入etcd中

• 目标Node上运行的Kubelet进程通过APiserver监测到这个"新生的Pod.并按照它的定义，启动该Pod并任劳任怨地负责它的下半生，直到Pod的生命结束

• 随后，我们通过Kubectl提交一个新的映射到该Pod的Service的创建请求

• ControllerManager通过Label标签查询到关联的Pod实例，然后生成Service的Endpoints信息，并通过APIServer写入到etod中，

  上运行的Kubelet进程通过APiserver监测到这个"新生的Pod.并按照它的定义，启动该Pod并任劳任怨地负责它的下半生，直到Pod的生命结束

• 随后，我们通过Kubectl提交一个新的映射到该Pod的Service的创建请求

• ControllerManager通过Label标签查询到关联的Pod实例，然后生成Service的Endpoints信息，并通过APIServer写入到etod中，

• 接下来，所有Node上运行的Proxy进程通过APIServer查询并监听Service对象与其对应的Endponts信息，建立一个软件方式的负载均衡器来实现Service访问到后端Pod的流量转发功能

K8s资源管理：

在kubernetes中，所有的内容都抽象为资源，用户需要通过操作资源来管理kubernetes。

kubernetes的本质上就是一个集群系统，用户可以在集群中部署各种服务，所谓的部署服务，其实就是在kubernetes集群中运行一个个的容器，并将指定的程序跑在容器中。

kubernetes的最小管理单元是pod 而不是容器，所以只能将容器放在Pod 中，而kubernetes一般也不会直接管理Pod，而是通过Pod控制器来管理Pod的。

Pod可以提供服务之后，就要考虑如何访问Pod中服务，kubernetes提供了Service资源实现这个功能。

当然，如果Pod中程序的数据需要持久化，kubernetes还提供了各种存储系统。

学习kubernetes的核心，就是学习如何对集群上的Pod、Pod控制器、Service、存储等各种资源进行操作。

资源管理方式：

命令式对象管理：直接使用命令去操作kubernetes资源

kubectl run nginx-pod --image=nginx:1.17.1 --port=80

命令式对象配置：通过命令配置和配置文件去操作kubernetes资源

kubectl create/patch -f nginx-pod.yaml

声明式对象配置：通过apply命令和配置文件去操作kubernetes资源

kubectl apply -f nginx-pod.yaml

类型	操作对象	适用环境	优点	缺点
命令式对象管理	对象	测试	简单	只能操作活动对象，无法审计、跟踪
命令式对象配置	文件	开发	可以审计、跟踪	项目大时，配置文件多，操作麻烦
声明式对象配置	目录	开发	支持目录操作	意外情况下难以调试

命令式对象管理：

kubectl命令

kubectl是kubernetes集群的命令行工具，通过它能够对集群本身进行管理，并能够在集群上进行容器化应用的安装部署。kubectl命令的语法如下：

kubectl [command] [type] [name] [flags]

• comand：指定要对资源执行的操作，例如create、get、delete
• type：指定资源类型，比如deployment、pod、service
• name：指定资源的名称，名称大小写敏感
• flags：指定额外的可选参数

# 查看所有pod
kubectl get pod 

# 查看某个pod
kubectl get pod pod_name

# 查看某个pod,以yaml格式展示结果
kubectl get pod pod_name -o yaml

资源类型

kubernetes中所有的内容都抽象为资源，可以通过下面的命令进行查看：

kubectl api-resources

经常使用的资源有下面这些：

资源分类	资源名称	缩写	资源作用
集群级别资源	nodes	no	集群组成部分
namespaces	ns	隔离Pod
pod资源	pods	po	装载容器
pod资源控制器	replicationcontrollers	rc	控制pod资源
	replicasets	rs	控制pod资源
	deployments	deploy	控制pod资源
	daemonsets	ds	控制pod资源
	jobs		控制pod资源
	cronjobs	cj	控制pod资源
	horizontalpodautoscalers	hpa	控制pod资源
	statefulsets	sts	控制pod资源
服务发现资源	services	svc	统一pod对外接口
	ingress	ing	统一pod对外接口
存储资源	volumeattachments		存储
	persistentvolumes	pv	存储
	persistentvolumeclaims	pvc	存储
配置资源	configmaps	cm	配置
	secrets		配置

操作

kubernetes允许对资源进行多种操作，可以通过--help查看详细的操作命令

kubectl --help

经常使用的操作有下面这些：

命令分类	命令	翻译	命令作用
基本命令	create	创建	创建一个资源
	edit	编辑	编辑一个资源
	get	获取	获取一个资源
	patch	更新	更新一个资源
	delete	删除	删除一个资源
	explain	解释	展示资源文档
运行和调试	run	运行	在集群中运行一个指定的镜像
	expose	暴露	暴露资源为Service
	describe	描述	显示资源内部信息
	logs	日志输出容器在 pod 中的日志	输出容器在 pod 中的日志
	attach	缠绕进入运行中的容器	进入运行中的容器
	exec	执行容器中的一个命令	执行容器中的一个命令
	cp	复制	在Pod内外复制文件
	rollout	首次展示	管理资源的发布
	scale	规模	扩(缩)容Pod的数量
	autoscale	自动调整	自动调整Pod的数量
高级命令	apply	rc	通过文件对资源进行配置
	label	标签	更新资源上的标签
其他命令	cluster-info	集群信息	显示集群信息
	version	版本	显示当前Server和Client的版本

下面以一个namespace / pod的创建和删除简单演示下命令的使用：

# 创建一个namespace
[root@master ~]# kubectl create namespace dev

# 获取namespace
[root@master ~]# kubectl get ns
NAME              STATUS   AGE
default           Active   21h
dev               Active   21s
kube-node-lease   Active   21h
kube-public       Active   21h
kube-system       Active   21h

# 在此namespace下创建并运行一个nginx的Pod
[root@master ~]# kubectl run pod --image=nginx:latest -n dev
kubectl run --generator=deployment/apps.v1 is DEPRECATED and will be removed in a future version. Use kubectl run --generator=run-pod/v1 or kubectl create instead.
deployment.apps/pod created

# 查看新创建的pod
[root@master ~]# kubectl get pod -n dev
NAME  READY   STATUS    RESTARTS   AGE
pod   1/1     Running   0          21s

# 删除指定的pod
[root@master ~]# kubectl delete pod pod-864f9875b9-pcw7x
pod "pod" deleted

# 删除指定的namespace
[root@master ~]# kubectl delete ns dev
namespace "dev" deleted

命令式对象配置：

命令式对象配置就是使用命令配合配置文件一起来操作kubernetes资源。

1） 创建一个nginxpod.yaml，内容如下：

apiVersion: v1
kind: Namespace
metadata:
  name: dev

---

apiVersion: v1
kind: Pod
metadata:
  name: nginxpod
  namespace: dev
spec:
  containers:
  - name: nginx-containers
    image: nginx:latest

2）执行create命令，创建资源：

[root@master ~]# kubectl create -f nginxpod.yaml
namespace/dev created
pod/nginxpod created

此时发现创建了两个资源对象，分别是namespace和pod

3）执行get命令，查看资源：

[root@master ~]#  kubectl get -f nginxpod.yaml
NAME            STATUS   AGE
namespace/dev   Active   18s

NAME            READY   STATUS    RESTARTS   AGE
pod/nginxpod    1/1     Running   0          17s

这样就显示了两个资源对象的信息

4）执行delete命令，删除资源：

[root@master ~]# kubectl delete -f nginxpod.yaml
namespace "dev" deleted
pod "nginxpod" deleted

此时发现两个资源对象被删除了

总结：命令式对象配置的方式操作资源，可以简单的认为：命令 + yaml配置文件（里面是命令需要的各种参数）

声明式对象配置：

声明式对象配置跟命令式对象配置很相似，但是它只有一个命令apply。

# 首先执行一次kubectl apply -f yaml文件，发现创建了资源
[root@master ~]#  kubectl apply -f nginxpod.yaml
namespace/dev created
pod/nginxpod created

# 再次执行一次kubectl apply -f yaml文件，发现说资源没有变动
[root@master ~]#  kubectl apply -f nginxpod.yaml
namespace/dev unchanged
pod/nginxpod unchanged

总结：其实声明式对象配置就是使用apply描述一个资源最终的状态（在yaml中定义状态）

使用apply操作资源：

• 如果资源不存在，就创建，相当于 kubectl create
• 如果资源已存在，就更新，相当于 kubectl patch

扩展：kubectl可以在node节点上运行吗 ?

kubectl的运行是需要进行配置的，它的配置文件是$HOME/.kube，如果想要在node节点运行此命令，需要将master上的.kube文件复制到node节点上，即在master节点上执行下面操作：

scp  -r  HOME/.kube   node1: HOME/

使用推荐: 三种方式应该怎么用 ?

• 创建/更新资源 使用声明式对象配置 kubectl apply -f XXX.yaml
• 删除资源 使用命令式对象配置 kubectl delete -f XXX.yaml
• 查询资源 使用命令式对象管理 kubectl get(describe) 资源名称

K8s部署搭建：

集群类型：

kubernetes集群大体上分为两类：一主多从和多住多从

• 一主多从：一台master节点和多台node节点，搭建简单，但是有单机故障风险，适用于测试环境
• 多主多从：多台master节点和多台node节点，搭建麻烦，安全性高，适用于生产环境

部署k8s的两种方式：

目前生产部署Kubernetes集群主要有两种方式：

• kubeadm：Kubeadm是一个K8s部署工具，提供kubeadm init和kubeadm join，用于快速部署Kubernetes集群。

• 二进制包：从github下载发行版的二进制包，手动部署每个组件，组成Kubernetes集群。

数据存储：

在前面已经提到，容器的生命周期可能很短，会被频繁地创建和销毁。那么容器在销毁时，保存在容器中的数据也会被清除。这种结果对用户来说，在某些情况下是不乐意看到的。为了持久化保存容器的数据，kubernetes引入了Volume的概念。

Volume是Pod中能够被多个容器访问的共享目录，它被定义在Pod上，然后被一个Pod里的多个容器挂载到具体的文件目录下，kubernetes通过Volume实现同一个Pod中不同容器之间的数据共享以及数据的持久化存储。Volume的生命容器不与Pod中单个容器的生命周期相关，当容器终止或者重启时，Volume中的数据也不会丢失。

kubernetes的Volume支持多种类型，比较常见的有下面几个：

• 简单存储：EmptyDir、HostPath、NFS
• 高级存储：PV、PVC
• 配置存储：ConfigMap、Secret

基本存储：

EmptyDir：

EmptyDir是最基础的Volume类型，一个EmptyDir就是Host上的一个空目录。

EmptyDir是在Pod被分配到Node时创建的，它的初始内容为空，并且无须指定宿主机上对应的目录文件，因为kubernetes会自动分配一个目录，当Pod销毁时， EmptyDir中的数据也会被永久删除。 EmptyDir用途如下：

• 临时空间，例如用于某些应用程序运行时所需的临时目录，且无须永久保留
• 一个容器需要从另一个容器中获取数据的目录（多容器共享目录）

接下来，通过一个容器之间文件共享的案例来使用一下EmptyDir。

在一个Pod中准备两个容器nginx和busybox，然后声明一个Volume分别挂在到两个容器的目录中，然后nginx容器负责向Volume中写日志，busybox中通过命令将日志内容读到控制台。

创建一个volume-emptydir.yaml

apiVersion: v1
kind: Pod
metadata:
  name: volume-emptydir
  namespace: dev
spec:
  containers:
  - name: nginx
    image: nginx:1.17.1
    ports:
    - containerPort: 80
    volumeMounts:  # 将logs-volume挂在到nginx容器中，对应的目录为 /var/log/nginx
    - name: logs-volume
      mountPath: /var/log/nginx
  - name: busybox
    image: busybox:1.30
    command: ["/bin/sh","-c","tail -f /logs/access.log"] # 初始命令，动态读取指定文件中内容
    volumeMounts:  # 将logs-volume 挂在到busybox容器中，对应的目录为 /logs
    - name: logs-volume
      mountPath: /logs
  volumes: # 声明volume， name为logs-volume，类型为emptyDir
  - name: logs-volume
    emptyDir: {}

# 创建Pod
[root@k8s-master01 ~]# kubectl create -f volume-emptydir.yaml
pod/volume-emptydir created

# 查看pod
[root@k8s-master01 ~]# kubectl get pods volume-emptydir -n dev -o wide
NAME                  READY   STATUS    RESTARTS   AGE      IP       NODE   ...... 
volume-emptydir       2/2     Running   0          97s   10.42.2.9   node1  ......

# 通过podIp访问nginx
[root@k8s-master01 ~]# curl 10.42.2.9
......

# 通过kubectl logs命令查看指定容器的标准输出
[root@k8s-master01 ~]# kubectl logs -f volume-emptydir -n dev -c busybox
10.42.1.0 - - [27/Jun/2021:15:08:54 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.29.0" "-"

HostPath：

上节课提到，EmptyDir中数据不会被持久化，它会随着Pod的结束而销毁，如果想简单的将数据持久化到主机中，可以选择HostPath。

HostPath就是将Node主机中一个实际目录挂在到Pod中，以供容器使用，这样的设计就可以保证Pod销毁了，但是数据依据可以存在于Node主机上。

创建一个volume-hostpath.yaml：

apiVersion: v1
kind: Pod
metadata:
  name: volume-hostpath
  namespace: dev
spec:
  containers:
  - name: nginx
    image: nginx:1.17.1
    ports:
    - containerPort: 80
    volumeMounts:
    - name: logs-volume
      mountPath: /var/log/nginx
  - name: busybox
    image: busybox:1.30
    command: ["/bin/sh","-c","tail -f /logs/access.log"]
    volumeMounts:
    - name: logs-volume
      mountPath: /logs
  volumes:
  - name: logs-volume
    hostPath: 
      path: /root/logs
      type: DirectoryOrCreate  # 目录存在就使用，不存在就先创建后使用

关于type的值的一点说明：

• DirectoryOrCreate 目录存在就使用，不存在就先创建后使用
• Directory 目录必须存在
• FileOrCreate 文件存在就使用，不存在就先创建后使用
• File 文件必须存在
• Socket unix套接字必须存在
• CharDevice 字符设备必须存在
• BlockDevice 块设备必须存在

# 创建Pod
[root@k8s-master01 ~]# kubectl create -f volume-hostpath.yaml
pod/volume-hostpath created

# 查看Pod
[root@k8s-master01 ~]# kubectl get pods volume-hostpath -n dev -o wide
NAME                  READY   STATUS    RESTARTS   AGE   IP             NODE   ......
pod-volume-hostpath   2/2     Running   0          16s   10.42.2.10     node1  ......

#访问nginx
[root@k8s-master01 ~]# curl 10.42.2.10

[root@k8s-master01 ~]# kubectl logs -f volume-emptydir -n dev -c busybox

# 接下来就可以去host的/root/logs目录下查看存储的文件了
###  注意: 下面的操作需要到Pod所在的节点运行（案例中是node1）
[root@node1 ~]# ls /root/logs/
access.log  error.log

# 同样的道理，如果在此目录下创建一个文件，到容器中也是可以看到的

NFS：

HostPath可以解决数据持久化的问题，但是一旦Node节点故障了，Pod如果转移到了别的节点，又会出现问题了，此时需要准备单独的网络存储系统，比较常用的用NFS、CIFS。

NFS是一个网络文件存储系统，可以搭建一台NFS服务器，然后将Pod中的存储直接连接到NFS系统上，这样的话，无论Pod在节点上怎么转移，只要Node跟NFS的对接没问题，数据就可以成功访问。

1）首先要准备nfs的服务器，这里为了简单，直接是master节点做nfs服务器

# 在nfs上安装nfs服务
[root@nfs ~]# yum install nfs-utils -y

# 准备一个共享目录
[root@nfs ~]# mkdir /root/data/nfs -pv

# 将共享目录以读写权限暴露给192.168.5.0/24网段中的所有主机
[root@nfs ~]# vim /etc/exports
[root@nfs ~]# more /etc/exports
/root/data/nfs     192.168.5.0/24(rw,no_root_squash)

# 启动nfs服务
[root@nfs ~]# systemctl restart nfs

2）接下来，要在的每个node节点上都安装下nfs，这样的目的是为了node节点可以驱动nfs设备

# 在node上安装nfs服务，注意不需要启动
[root@k8s-master01 ~]# yum install nfs-utils -y

3）接下来，就可以编写pod的配置文件了，创建volume-nfs.yaml

apiVersion: v1
kind: Pod
metadata:
  name: volume-nfs
  namespace: dev
spec:
  containers:
  - name: nginx
    image: nginx:1.17.1
    ports:
    - containerPort: 80
    volumeMounts:
    - name: logs-volume
      mountPath: /var/log/nginx
  - name: busybox
    image: busybox:1.30
    command: ["/bin/sh","-c","tail -f /logs/access.log"] 
    volumeMounts:
    - name: logs-volume
      mountPath: /logs
  volumes:
  - name: logs-volume
    nfs:
      server: 192.168.5.6  #nfs服务器地址
      path: /root/data/nfs #共享文件路径

4）最后，运行下pod，观察结果

# 创建pod
[root@k8s-master01 ~]# kubectl create -f volume-nfs.yaml
pod/volume-nfs created

# 查看pod
[root@k8s-master01 ~]# kubectl get pods volume-nfs -n dev
NAME                  READY   STATUS    RESTARTS   AGE
volume-nfs        2/2     Running   0          2m9s

# 查看nfs服务器上的共享目录，发现已经有文件了
[root@k8s-master01 ~]# ls /root/data/
access.log  error.log

高级存储：

前面已经学习了使用NFS提供存储，此时就要求用户会搭建NFS系统，并且会在yaml配置nfs。由于kubernetes支持的存储系统有很多，要求客户全都掌握，显然不现实。为了能够屏蔽底层存储实现的细节，方便用户使用， kubernetes引入PV和PVC两种资源对象。

• PV（Persistent Volume）是持久化卷的意思，是对底层的共享存储的一种抽象。一般情况下PV由kubernetes管理员进行创建和配置，它与底层具体的共享存储技术有关，并通过插件完成与共享存储的对接。

• PVC（Persistent Volume Claim）是持久卷声明的意思，是用户对于存储需求的一种声明。换句话说，PVC其实就是用户向kubernetes系统发出的一种资源需求申请。

使用了PV和PVC之后，工作可以得到进一步的细分：

• 存储：存储工程师维护
• PV： kubernetes管理员维护
• PVC：kubernetes用户维护

PV：

PV是存储资源的抽象，下面是资源清单文件:

apiVersion: v1  
kind: PersistentVolume
metadata:
  name: pv2
spec:
  nfs: # 存储类型，与底层真正存储对应
  capacity:  # 存储能力，目前只支持存储空间的设置
    storage: 2Gi
  accessModes:  # 访问模式
  storageClassName: # 存储类别
  persistentVolumeReclaimPolicy: # 回收策略

PV 的关键配置参数说明：

• 存储类型：底层实际存储的类型，kubernetes支持多种存储类型，每种存储类型的配置都有所差异

• 存储能力（capacity）：目前只支持存储空间的设置( storage=1Gi )，不过未来可能会加入IOPS、吞吐量等指标的配置

• 访问模式（accessModes）：用于描述用户应用对存储资源的访问权限，访问权限包括下面几种方式：

  • ReadWriteOnce（RWO）：读写权限，但是只能被单个节点挂载

  • ReadOnlyMany（ROX）： 只读权限，可以被多个节点挂载

  • ReadWriteMany（RWX）：读写权限，可以被多个节点挂载

    需要注意的是，底层不同的存储类型可能支持的访问模式不同

• 回收策略（persistentVolumeReclaimPolicy）：当PV不再被使用了之后，对其的处理方式。目前支持三种策略：

  • Retain （保留） 保留数据，需要管理员手工清理数据

  • Recycle（回收） 清除 PV 中的数据，效果相当于执行 rm -rf /thevolume/*

  • Delete （删除） 与 PV 相连的后端存储完成 volume 的删除操作，当然这常见于云服务商的存储服务

    需要注意的是，底层不同的存储类型可能支持的回收策略不同

• 存储类别：PV可以通过storageClassName参数指定一个存储类别

  • 具有特定类别的PV只能与请求了该类别的PVC进行绑定
  • 未设定类别的PV则只能与不请求任何类别的PVC进行绑定

• 状态（status）：一个 PV 的生命周期中，可能会处于4中不同的阶段：

  • Available（可用）： 表示可用状态，还未被任何 PVC 绑定

  • Bound（已绑定）： 表示 PV 已经被 PVC 绑定

  • Released（已释放）： 表示 PVC 被删除，但是资源还未被集群重新声明

  • Failed（失败）： 表示该 PV 的自动回收失败

PVC：

PVC是资源的申请，用来声明对存储空间、访问模式、存储类别需求信息。下面是资源清单文件:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: pvc
  namespace: dev
spec:
  accessModes: # 访问模式
  selector: # 采用标签对PV选择
  storageClassName: # 存储类别
  resources: # 请求空间
    requests:
      storage: 5Gi

PVC 的关键配置参数说明：

• 访问模式（accessModes）:用于描述用户应用对存储资源的访问权限

• 选择条件（selector）：通过Label Selector的设置，可使PVC对于系统中己存在的PV进行筛选

• 存储类别（storageClassName）：PVC在定义时可以设定需要的后端存储的类别，只有设置了该class的pv才能被系统选出

• 资源请求（Resources ）：描述对存储资源的请求

生命周期：

PVC和PV是一一对应的，PV和PVC之间的相互作用遵循以下生命周期：

• **资源供应：**管理员手动创建底层存储和PV

• **资源绑定：**用户创建PVC，kubernetes负责根据PVC的声明去寻找PV，并绑定在用户定义好PVC之后，系统将根据PVC对存储资源的请求在已存在的PV中选择一个满足条件的。

  一旦找到，就将该PV与用户定义的PVC进行绑定，用户的应用就可以使用这个PVC了。如果找不到，PVC则会无限期处于Pending状态，直到等到系统管理员创建了一个符合其要求的PV

  PV一旦绑定到某个PVC上，就会被这个PVC独占，不能再与其他PVC进行绑定了

• **资源释放：**用户删除pvc来释放pv

  当存储资源使用完毕后，用户可以删除PVC，与该PVC绑定的PV将会被标记为"已释放"，但还不能立刻与其他PVC进行绑定。通过之前PVC写入的数据可能还被留在存储设备上，只有在清除之后该PV才能再次使用。

• **资源回收：**kubernetes根据pv设置的回收策略进行资源的回收

  对于PV，管理员可以设定回收策略，用于设置与之绑定的PVC释放资源之后如何处理遗留数据的问题。只有PV的存储空间完成回收，才能供新的PVC绑定和使用

配置存储

ConfigMap/Secret：

微服务在上线时需要设置一些可变配置，环境不同则配置值不同，有些配置如数据库的连接字符串在启动时就应该配好，有些配置则可以在运行中动态调整。为了实现针对不同环境灵活实现动态配置，微服务就需要 ConfigMap 的支持。

k8s 平台内置支持微服务的配置（ConfigMap），开发人员将配置填写在 ConfigMap 中，k8s 再 将 ConfigMap 中的配置以环境变量的形式注入 POD，这样 POD 中的应用就可以访问这些配置。

Secret 是一种特殊的 ConfigMap，提供更加安全的存储和访问配置机制。

ConfigMap：

ConfigMap是一种比较特殊的存储卷，它的主要作用是用来存储配置信息的。

创建configmap.yaml，内容如下：

apiVersion: v1
kind: ConfigMap
metadata:
  name: configmap
  namespace: dev
data:
  info: |
    username:admin
    password:123456

接下来，使用此配置文件创建configmap

# 创建configmap
[root@k8s-master01 ~]# kubectl create -f configmap.yaml
configmap/configmap created

# 查看configmap详情
[root@k8s-master01 ~]# kubectl describe cm configmap -n dev
Name:         configmap
Namespace:    dev
Labels:       <none>
Annotations:  <none>

Data
====
info:
----
username:admin
password:123456

Events:  <none>

接下来创建一个pod-configmap.yaml，将上面创建的configmap挂载进去

apiVersion: v1
kind: Pod
metadata:
  name: pod-configmap
  namespace: dev
spec:
  containers:
  - name: nginx
    image: nginx:1.17.1
    volumeMounts: # 将configmap挂载到目录
    - name: config
      mountPath: /configmap/config
  volumes: # 引用configmap
  - name: config
    configMap:
      name: configmap

# 创建pod
[root@k8s-master01 ~]# kubectl create -f pod-configmap.yaml
pod/pod-configmap created

# 查看pod
[root@k8s-master01 ~]# kubectl get pod pod-configmap -n dev
NAME            READY   STATUS    RESTARTS   AGE
pod-configmap   1/1     Running   0          6s

#进入容器
[root@k8s-master01 ~]# kubectl exec -it pod-configmap -n dev /bin/sh
# cd /configmap/config/
# ls
info
# more info
username:admin
password:123456

# 可以看到映射已经成功，每个configmap都映射成了一个目录
# key--->文件     value---->文件中的内容
# 此时如果更新configmap的内容, 容器中的值也会动态更新

Secret：

在kubernetes中，还存在一种和ConfigMap非常类似的对象，称为Secret对象。它主要用于存储敏感信息，例如密码、秘钥、证书等等。

1.首先使用base64对数据进行编码

[root@k8s-master01 ~]# echo -n 'admin' | base64 #准备username
YWRtaW4=
[root@k8s-master01 ~]# echo -n '123456' | base64 #准备password
MTIzNDU2

2.接下来编写secret.yaml，并创建Secret

apiVersion: v1
kind: Secret
metadata:
  name: secret
  namespace: dev
type: Opaque
data:
  username: YWRtaW4=
  password: MTIzNDU2

# 创建secret
[root@k8s-master01 ~]# kubectl create -f secret.yaml
secret/secret created

# 查看secret详情
[root@k8s-master01 ~]# kubectl describe secret secret -n dev
Name:         secret
Namespace:    dev
Labels:       <none>
Annotations:  <none>
Type:  Opaque
Data
====
password:  6 bytes
username:  5 bytes

3.创建pod-secret.yaml，将上面创建的secret挂载进去：

apiVersion: v1
kind: Pod
metadata:
  name: pod-secret
  namespace: dev
spec:
  containers:
  - name: nginx
    image: nginx:1.17.1
    volumeMounts: # 将secret挂载到目录
    - name: config
      mountPath: /secret/config
  volumes:
  - name: config
    secret:
      secretName: secret

# 创建pod
[root@k8s-master01 ~]# kubectl create -f pod-secret.yaml
pod/pod-secret created

# 查看pod
[root@k8s-master01 ~]# kubectl get pod pod-secret -n dev
NAME            READY   STATUS    RESTARTS   AGE
pod-secret      1/1     Running   0          2m28s

# 进入容器，查看secret信息，发现已经自动解码了
[root@k8s-master01 ~]# kubectl exec -it pod-secret /bin/sh -n dev
/ # ls /secret/config/
password  username
/ # more /secret/config/username
admin
/ # more /secret/config/password
123456

至此，已经实现了利用secret实现了信息的编码。

安全认证：

访问控制概述：

Kubernetes作为一个分布式集群的管理工具，保证集群的安全性是其一个重要的任务。所谓的安全性其实就是保证对Kubernetes的各种客户端 进行认证和鉴权操作。

客户端：

在Kubernetes集群中，客户端通常有两类：

• User Account：一般是独立于kubernetes之外的其他服务管理的用户账号。
• Service Account：kubernetes管理的账号，用于为Pod中的服务进程在访问Kubernetes时提供身份标识。

认证、授权与准入控制：

ApiServer是访问及管理资源对象的唯一入口。任何一个请求访问ApiServer，都要经过下面三个流程：

Authentication（认证）：身份鉴别，只有正确的账号才能够通过认证

Authorization（授权）： 判断用户是否有权限对访问的资源执行特定的动作

Admission Control（准入控制）：用于补充授权机制以实现更加精细的访问控制功能。

认证管理：

Kubernetes集群安全的最关键点在于如何识别并认证客户端身份，它提供了3种客户端身份认证方式：

• HTTP Base认证：通过用户名+密码的方式认证：这种认证方式是把"用户名:密码"用BASE64算法进行编码后的字符串放在HTTP请求中的Header Authorization域里发送给服务端。服务端收到后进行解码，获取用户名及密码，然后进行用户身份认证的过程。

• HTTP Token认证：通过一个Token来识别合法用户：这种认证方式是用一个很长的难以被模仿的字符串--Token来表明客户身份的一种方式。每个Token对应一个用户名，当客户端发起API调用请求时，需要在HTTP Header里放入Token，API Server接到Token后会跟服务器中保存的token进行比对，然后进行用户身份认证的过程。

• HTTPS证书认证：基于CA根证书签名的双向数字证书认证方式：这种认证方式是安全性最高的一种方式，但是同时也是操作起来最麻烦的一种方式。

HTTPS认证大体分为3个过程：

1. 证书申请和下发：HTTPS通信双方的服务器向CA机构申请证书，CA机构下发根证书、服务端证书及私钥给申请者

2. 客户端和服务端的双向认证：

   • 客户端向服务器端发起请求，服务端下发自己的证书给客户端，

     客户端接收到证书后，通过私钥解密证书，在证书中获得服务端的公钥，

     客户端利用服务器端的公钥认证证书中的信息，如果一致，则认可这个服务器

   • 客户端发送自己的证书给服务器端，服务端接收到证书后，通过私钥解密证书，

     在证书中获得客户端的公钥，并用该公钥认证证书信息，确认客户端是否合法

3. 服务器端和客户端进行通信：

   • 服务器端和客户端协商好加密方案后，客户端会产生一个随机的秘钥并加密，然后发送到服务器端。
   • 服务器端接收这个秘钥后，双方接下来通信的所有内容都通过该随机秘钥加密

注意: Kubernetes允许同时配置多种认证方式，只要其中任意一个方式认证通过即可

授权管理：

授权发生在认证成功之后，通过认证就可以知道请求用户是谁， 然后Kubernetes会根据事先定义的授权策略来决定用户是否有权限访问，这个过程就称为授权。

每个发送到ApiServer的请求都带上了用户和资源的信息：比如发送请求的用户、请求的路径、请求的动作等，授权就是根据这些信息和授权策略进行比较，如果符合策略，则认为授权通过，否则会返回错误。

API Server目前支持以下几种授权策略：

• AlwaysDeny：表示拒绝所有请求，一般用于测试
• AlwaysAllow：允许接收所有请求，相当于集群不需要授权流程（Kubernetes默认的策略）
• ABAC：基于属性的访问控制，表示使用用户配置的授权规则对用户请求进行匹配和控制
• Webhook：通过调用外部REST服务对用户进行授权
• Node：是一种专用模式，用于对kubelet发出的请求进行访问控制
• RBAC：基于角色的访问控制（kubeadm安装方式下的默认选项）

RBAC(Role-Based Access Control) 基于角色的访问控制，主要是在描述一件事情：给哪些对象授予了哪些权限

其中涉及到了下面几个概念：

• 对象：User、Groups、ServiceAccount
• 角色：代表着一组定义在资源上的可操作动作(权限)的集合
• 绑定：将定义好的角色跟用户绑定在一起

RBAC引入了4个顶级资源对象：

Role、ClusterRole：角色，用于指定一组权限

RoleBinding、ClusterRoleBinding：角色绑定，用于将角色（权限）赋予给对象

Role、ClusterRole：

一个角色就是一组权限的集合，这里的权限都是许可形式的（白名单）。

# Role只能对命名空间内的资源进行授权，需要指定nameapce
kind: Role
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
  namespace: dev
  name: authorization-role
rules:
- apiGroups: [""]  # 支持的API组列表,"" 空字符串，表示核心API群
  resources: ["pods"] # 支持的资源对象列表
  verbs: ["get", "watch", "list"] # 允许的对资源对象的操作方法列表

# ClusterRole可以对集群范围内资源、跨namespaces的范围资源、非资源类型进行授权
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
 name: authorization-clusterrole
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "watch", "list"]

需要详细说明的是，rules中的参数：

apiGroups: 支持的API组列表

"","apps", "autoscaling", "batch"

resources：支持的资源对象列表

"services", "endpoints", "pods","secrets","configmaps","crontabs","deployments","jobs",
"nodes","rolebindings","clusterroles","daemonsets","replicasets","statefulsets",
"horizontalpodautoscalers","replicationcontrollers","cronjobs"

verbs：对资源对象的操作方法列表

"get", "list", "watch", "create", "update", "patch", "delete", "exec"

RoleBinding、ClusterRoleBinding：

角色绑定用来把一个角色绑定到一个目标对象上，绑定目标可以是User、Group或者ServiceAccount。

# RoleBinding可以将同一namespace中的subject绑定到某个Role下，则此subject即具有该Role定义的权限
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
  name: authorization-role-binding
  namespace: dev
subjects:
- kind: User
  name: heima
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: authorization-role
  apiGroup: rbac.authorization.k8s.io

# ClusterRoleBinding在整个集群级别和所有namespaces将特定的subject与ClusterRole绑定，授予权限
kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
 name: authorization-clusterrole-binding
subjects:
- kind: User
  name: heima
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: authorization-clusterrole
  apiGroup: rbac.authorization.k8s.io

RoleBinding引用ClusterRole进行授权：

RoleBinding可以引用ClusterRole，对属于同一命名空间内ClusterRole定义的资源主体进行授权。

一种很常用的做法就是，集群管理员为集群范围预定义好一组角色（ClusterRole），然后在多个命名空间中重复使用这些ClusterRole。这样可以大幅提高授权管理工作效率，也使得各个命名空间下的基础性授权规则与使用体验保持一致。

# 虽然authorization-clusterrole是一个集群角色，但是因为使用了RoleBinding
# 所以heima只能读取dev命名空间中的资源
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
  name: authorization-role-binding-ns
  namespace: dev
subjects:
- kind: User
  name: heima
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: authorization-clusterrole
  apiGroup: rbac.authorization.k8s.io

实战：创建一个只能管理dev空间下Pods资源的账号

1）创建账号

# 1) 创建证书
[root@k8s-master01 pki]# cd /etc/kubernetes/pki/
[root@k8s-master01 pki]# (umask 077;openssl genrsa -out devman.key 2048)

# 2) 用apiserver的证书去签署
# 2-1) 签名申请，申请的用户是devman,组是devgroup
[root@k8s-master01 pki]# openssl req -new -key devman.key -out devman.csr -subj "/CN=devman/O=devgroup"     
# 2-2) 签署证书
[root@k8s-master01 pki]# openssl x509 -req -in devman.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out devman.crt -days 3650

# 3) 设置集群、用户、上下文信息
[root@k8s-master01 pki]# kubectl config set-cluster kubernetes --embed-certs=true --certificate-authority=/etc/kubernetes/pki/ca.crt --server=https://192.168.109.100:6443

[root@k8s-master01 pki]# kubectl config set-credentials devman --embed-certs=true --client-certificate=/etc/kubernetes/pki/devman.crt --client-key=/etc/kubernetes/pki/devman.key

[root@k8s-master01 pki]# kubectl config set-context devman@kubernetes --cluster=kubernetes --user=devman

# 切换账户到devman
[root@k8s-master01 pki]# kubectl config use-context devman@kubernetes
Switched to context "devman@kubernetes".

# 查看dev下pod，发现没有权限
[root@k8s-master01 pki]# kubectl get pods -n dev
Error from server (Forbidden): pods is forbidden: User "devman" cannot list resource "pods" in API group "" in the namespace "dev"

# 切换到admin账户
[root@k8s-master01 pki]# kubectl config use-context kubernetes-admin@kubernetes
Switched to context "kubernetes-admin@kubernetes".

2） 创建Role和RoleBinding，为devman用户授权

kind: Role
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
  namespace: dev
  name: dev-role
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "watch", "list"]
  
---

kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
  name: authorization-role-binding
  namespace: dev
subjects:
- kind: User
  name: devman
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: dev-role
  apiGroup: rbac.authorization.k8s.io

[root@k8s-master01 pki]# kubectl create -f dev-role.yaml
role.rbac.authorization.k8s.io/dev-role created
rolebinding.rbac.authorization.k8s.io/authorization-role-binding created

3）切换账户，再次验证

# 切换账户到devman
[root@k8s-master01 pki]# kubectl config use-context devman@kubernetes
Switched to context "devman@kubernetes".

# 再次查看
[root@k8s-master01 pki]# kubectl get pods -n dev
NAME                                 READY   STATUS             RESTARTS   AGE
nginx-deployment-66cb59b984-8wp2k    1/1     Running            0          4d1h
nginx-deployment-66cb59b984-dc46j    1/1     Running            0          4d1h
nginx-deployment-66cb59b984-thfck    1/1     Running            0          4d1h

# 为了不影响后面的学习,切回admin账户
[root@k8s-master01 pki]# kubectl config use-context kubernetes-admin@kubernetes
Switched to context "kubernetes-admin@kubernetes".

准入控制：

通过了前面的认证和授权之后，还需要经过准入控制处理通过之后，apiserver才会处理这个请求。

准入控制是一个可配置的控制器列表，可以通过在Api-Server上通过命令行设置选择执行哪些准入控制器：

--admission-control=NamespaceLifecycle,LimitRanger,ServiceAccount,PersistentVolumeLabel,
                      DefaultStorageClass,ResourceQuota,DefaultTolerationSeconds

只有当所有的准入控制器都检查通过之后，apiserver才执行该请求，否则返回拒绝。

当前可配置的Admission Control准入控制如下：

• AlwaysAdmit：允许所有请求
• AlwaysDeny：禁止所有请求，一般用于测试
• AlwaysPullImages：在启动容器之前总去下载镜像
• DenyExecOnPrivileged：它会拦截所有想在Privileged Container上执行命令的请求
• ImagePolicyWebhook：这个插件将允许后端的一个Webhook程序来完成admission controller的功能。
• Service Account：实现ServiceAccount实现了自动化
• SecurityContextDeny：这个插件将使用SecurityContext的Pod中的定义全部失效
• ResourceQuota：用于资源配额管理目的，观察所有请求，确保在namespace上的配额不会超标
• LimitRanger：用于资源限制管理，作用于namespace上，确保对Pod进行资源限制
• InitialResources：为未设置资源请求与限制的Pod，根据其镜像的历史资源的使用情况进行设置
• NamespaceLifecycle：如果尝试在一个不存在的namespace中创建资源对象，则该创建请求将被拒绝。当删除一个namespace时，系统将会删除该namespace中所有对象。
• DefaultStorageClass：为了实现共享存储的动态供应，为未指定StorageClass或PV的PVC尝试匹配默认的StorageClass，尽可能减少用户在申请PVC时所需了解的后端存储细节
• DefaultTolerationSeconds：这个插件为那些没有设置forgiveness tolerations并具有notready:NoExecute和unreachable:NoExecute两种taints的Pod设置默认的"容忍"时间，为5min
• PodSecurityPolicy：这个插件用于在创建或修改Pod时决定是否根据Pod的security context和可用的PodSecurityPolicy对Pod的安全策略进行控制

DashBoard：

kubernetes中完成的所有操作都是通过命令行工具kubectl完成的。为了提供更丰富的用户体验，kubernetes还开发了一个基于web的用户界面（Dashboard）。用户可以使用Dashboard部署容器化的应用，还可以监控应用的状态，执行故障排查以及管理kubernetes中各种资源。

部署Dashboard：

1）下载yaml，并运行Dashboard

# 下载yaml
[root@k8s-master01 ~]# wget  https://raw.githubusercontent.com/kubernetes/dashboard/v2.0.0/aio/deploy/recommended.yaml

# 修改kubernetes-dashboard的Service类型
kind: Service
apiVersion: v1
metadata:
  labels:
    k8s-app: kubernetes-dashboard
  name: kubernetes-dashboard
  namespace: kubernetes-dashboard
spec:
  type: NodePort  # 新增
  ports:
    - port: 443
      targetPort: 8443
      nodePort: 30009  # 新增
  selector:
    k8s-app: kubernetes-dashboard

# 部署
[root@k8s-master01 ~]# kubectl create -f recommended.yaml

# 查看namespace下的kubernetes-dashboard下的资源
[root@k8s-master01 ~]# kubectl get pod,svc -n kubernetes-dashboard
NAME                                            READY   STATUS    RESTARTS   AGE
pod/dashboard-metrics-scraper-c79c65bb7-zwfvw   1/1     Running   0          111s
pod/kubernetes-dashboard-56484d4c5-z95z5        1/1     Running   0          111s

NAME                               TYPE       CLUSTER-IP      EXTERNAL-IP  PORT(S)         AGE
service/dashboard-metrics-scraper  ClusterIP  10.96.89.218    <none>       8000/TCP        111s
service/kubernetes-dashboard       NodePort   10.104.178.171  <none>       443:30009/TCP   111s

2）创建访问账户，获取token

# 创建账号
[root@k8s-master01-1 ~]# kubectl create serviceaccount dashboard-admin -n kubernetes-dashboard

# 授权
[root@k8s-master01-1 ~]# kubectl create clusterrolebinding dashboard-admin-rb --clusterrole=cluster-admin --serviceaccount=kubernetes-dashboard:dashboard-admin

# 获取账号token
[root@k8s-master01 ~]#  kubectl get secrets -n kubernetes-dashboard | grep dashboard-admin
dashboard-admin-token-xbqhh        kubernetes.io/service-account-token   3      2m35s

[root@k8s-master01 ~]# kubectl describe secrets dashboard-admin-token-xbqhh -n kubernetes-dashboard
Name:         dashboard-admin-token-xbqhh
Namespace:    kubernetes-dashboard
Labels:       <none>
Annotations:  kubernetes.io/service-account.name: dashboard-admin
              kubernetes.io/service-account.uid: 95d84d80-be7a-4d10-a2e0-68f90222d039

Type:  kubernetes.io/service-account-token

Data
====
namespace:  20 bytes
token:      eyJhbGciOiJSUzI1NiIsImtpZCI6ImJrYkF4bW5XcDhWcmNGUGJtek5NODFuSXl1aWptMmU2M3o4LTY5a2FKS2cifQ.eyJpc3MiOiJrdWJlcm5ldGVzL3NlcnZpY2VhY2NvdW50Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9uYW1lc3BhY2UiOiJrdWJlcm5ldGVzLWRhc2hib2FyZCIsImt1YmVybmV0ZXMuaW8vc2VydmljZWFjY291bnQvc2VjcmV0Lm5hbWUiOiJkYXNoYm9hcmQtYWRtaW4tdG9rZW4teGJxaGgiLCJrdWJlcm5ldGVzLmlvL3NlcnZpY2VhY2NvdW50L3NlcnZpY2UtYWNjb3VudC5uYW1lIjoiZGFzaGJvYXJkLWFkbWluIiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9zZXJ2aWNlLWFjY291bnQudWlkIjoiOTVkODRkODAtYmU3YS00ZDEwLWEyZTAtNjhmOTAyMjJkMDM5Iiwic3ViIjoic3lzdGVtOnNlcnZpY2VhY2NvdW50Omt1YmVybmV0ZXMtZGFzaGJvYXJkOmRhc2hib2FyZC1hZG1pbiJ9.NAl7e8ZfWWdDoPxkqzJzTB46sK9E8iuJYnUI9vnBaY3Jts7T1g1msjsBnbxzQSYgAG--cV0WYxjndzJY_UWCwaGPrQrt_GunxmOK9AUnzURqm55GR2RXIZtjsWVP2EBatsDgHRmuUbQvTFOvdJB4x3nXcYLN2opAaMqg3rnU2rr-A8zCrIuX_eca12wIp_QiuP3SF-tzpdLpsyRfegTJZl6YnSGyaVkC9id-cxZRb307qdCfXPfCHR_2rt5FVfxARgg_C0e3eFHaaYQO7CitxsnIoIXpOFNAR8aUrmopJyODQIPqBWUehb7FhlU1DCduHnIIXVC_UICZ-MKYewBDLw
ca.crt:     1025 bytes

3）通过浏览器访问Dashboard的UI，在登录页面上输入上面的token

出现下面的页面代表成功

使用DashBoard：

本章节以Deployment为例演示DashBoard的使用

查看

选择指定的命名空间dev，然后点击Deployments，查看dev空间下的所有deployment

扩缩容

在Deployment上点击规模，然后指定目标副本数量，点击确定

编辑

在Deployment上点击编辑，然后修改yaml文件，点击确定

查看Pod

点击Pods, 查看pods列表

操作Pod

选中某个Pod，可以对其执行日志（logs）、进入执行（exec）、编辑、删除操作

Dashboard提供了kubectl命令的绝大部分功能，这里不再一一演示

K8s架构图：