前言

K8S 是什么？ K8S是（Kubernetes）的全称作用：用于自动部署、扩展和管理“容器化（containerized）应用程序”的开源系统

简单来讲：K8S是负责自动化运维管理多个Docker程序的集群 包括 服务的部署、更新、卸载和扩容、缩容等

官网： https://kubernetes.io

GitHub： https://github.com/kubernetes/kubernetes

k8s特点： ●弹性伸缩使用命令、UI或者基于CPU使用情况自动快速扩容和缩容应用程序实例，保证应用业务高峰并发时的高可用性；业务低峰时回收资源，以最小成本运行服务。

●自我修复在节点故障时重新启动失败的容器，替换和重新部署，保证预期的副本数量；杀死健康检査失败的容器，并且在未准备好之前不会处理客户端请求，确保线上服务不中断。

●服务发现和负载均衡 K8S为多个容器提供一个统一访问入口(内部IP地址和一个DNS名称)，并且负载均衡关联的所有容器，使得用户无需考虑容器IP问题。

●自动发布（默认滚动发布模式）和回滚 K8S采用滚动更新策略更新应用，一次更新一个或者部分Pod，而不是同时删除所有Pod，如果更新过程中出现问题，将回滚更改，确保升级不影响业务。

●集中化配置管理和密钥管理管理机密数据和应用程序配置，而不需要把敏感数据暴露在镜像里，提高敏感数据安全性。并可以将一些常用的配置存储在K8S中，方便应用程序使用。

●存储编排，支持外挂存储并对外挂存储资源进行编排挂载外部存储系统，无论是来自本地存储，公有云（如AWS），还是网络存储（如NFS、Glusterfs、Ceph）都作为集群资源的一部分使用，极大提高存储使用灵活性

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

k8s是怎么做的？

官方的组件图

K8S是属于主从设备模型（Master-Slave架构），即有Master节点负责核心的调度、管理和运维，Slave节点则在执行用户的程序。但是在K8S中，主节点一般被称为Master Node或者Head Node，而从节点则被称为Worker Node或者Node。

注：Master Node和Worker Node是分别安装了K8S的Master和Woker组件的实体服务器，每个Node都对应了一台实体服务器（虽然Master Node可以和其中一个Worker Node安装在同一台服务器，但是建议Master Node单独部署），所有Master Node和Worker Node组成了K8S集群，同一个集群可能存在多个Master Node和Worker Node。

Master Node的组件

API Server K8S的请求入口服务。 API Server负责接收K8S所有请求（来自UI界面或者CLI命令行工具），然后，API Server根据用户的具体请求，去通知其他组件干活。从图中可以知道，API Server实际可以部署多个实例，以增大请求吞吐。

Scheduler K8S中的调度服务。当用户部署服务时，Scheduler会选择最合适的Worker Node（服务器）来部署（通过调度算法/策略把 Pod 放到合适的 Node 中去。）。从上图可以知道，Scheduler也可以部署多个实例，以增大处理能力。

Controller Manager，K8S的控制服务 Controller Manager本身就是总称，实际上有很多具体的Controller，在文章Components of Kubernetes Architecture中提到的有Node Controller、Service Controller、Volume Controller等，分别负责不同K8S对象。举个例子，比如用户要求A服务部署2个副本，那么当其中一个服务挂了的时候，Controller会马上调整，让Scheduler再选择一个Worker Node重新部署服务。

etcd，K8S的存储服务，存储整个集群的状态 etcd存储了K8S的关键配置和用户配置，K8S中仅API Server才具备读写权限，其他组件必须通过API Server的接口才能读写数据

Worker Node组件

Kubelet。Worker Node的监视器，以及与Master Node的通讯器 Kubelet是Master Node安插在Worker Node上的“眼线”，它会定期向Master Node汇报自己Node上运行的服务的状态，并接受来自Master Node的命令，并执行。

Kube-Proxy。K8S的网络代理。称呼为Network-Proxy可能更适合。Kube-Proxy负责Node在K8S的网络通讯、以及对外部网络流量的负载均衡。

Container Runtime。Worker Node的运行环境。安装了容器化所需的软件环境确保容器化程序能够跑起来，比如Docker Engine。通常理解就是帮忙装好了Docker运行环境，使其可以正常运行起来。

Logging Layer。K8S的监控状态收集器。 Logging Layer负责采集Node上所有服务的CPU、内存、磁盘、网络等监控项信息。

Add-Ons。K8S管理运维Worker Node的插件组件。让用户可以扩展更多定制化功能

k8s中的重要概念

pod

官方的解释是：

Pod是可以在 Kubernetes 中创建和管理的、最小的可部署的计算单元。

一个 Pod 代表集群上正在运行的一个进程。可以理解为Pod就是K8S中一个服务的闭包。简单来说，Pod可以被理解成一群可以共享网络、存储和计算资源的容器化服务的集合（Pod 理解成豌豆荚，而同一 Pod 内的每个容器是一颗颗豌豆。）注：同一个Pod之间的Container可以通过localhost互相访问，并且可以挂载Pod内所有的数据卷；但是不同的Pod之间的Container不能用localhost访问，也不能挂载其他Pod的数据卷。

Volume 数据卷

K8S支持很多类型的volume数据卷挂载，可参考K8S卷。可以理解为需要手动mount的磁盘，：数据卷volume是Pod内部的磁盘资源。 volume是K8S的对象，对应一个实体的数据卷；而volumeMounts只是container的挂载点，对应container的其中一个参数。但是，volumeMounts依赖于volume，只有当Pod内有volume资源的时候，该Pod内部的container才可能有volumeMounts。

Container 容器

一个Pod内可以有多个容器container。容器分类：

标准容器 Application Container。
初始化容器 Init Container。
边车容器 Sidecar Container。（一个 Pod 里可以运行多个容器）
临时容器 Ephemeral Container。

一般来说，大多使用的是标准容器（ Application Container）。（一个pod 部署一个容器）

Deployment 和 ReplicaSet（简称RS）

官方给出了一个要命的解释：

一个 Deployment 控制器为 [Pods] 和 [ReplicaSets] 提供声明式的更新能力。你负责描述 Deployment 中的 目标状态，而 Deployment 控制器以受控速率更改实际状态，使其变为期望状态。你可以定义 Deployment 以创建新的 ReplicaSet，或删除现有 Deployment，并通过新的 Deployment 收养其资源。

简单概括：Deployment的作用是管理和控制Pod和ReplicaSet，管控它们运行在用户期望的状态中。形象比喻是：Deployment就是包工头，主要负责监督底下的工人Pod干活，确保每时每刻有用户要求数量的Pod在工作。如果一旦发现某个工人Pod不行了，就赶紧新拉一个Pod过来替换它。

ReplicaSets官方解释

ReplicaSet 的目的是维护一组在任何时候都处于运行状态的 Pod 副本的稳定集合。因此，它通常用来保证给定数量的、完全相同的 Pod 的可用性。

ReplicaSet的作用就是管理和控制Pod，管控他们好好干活。ReplicaSet受控于Deployment。形象来说，ReplicaSet就是总包工头手下的小包工头。

Service，Ingress和Istio

Service官网定义：将运行在一组 [Pods]上的应用程序公开为网络服务的抽象方法。使用 Kubernetes，您无需修改应用程序即可使用不熟悉的[服务发现]机制。 Kubernetes 为 Pods 提供自己的 IP 地址，并为一组 Pod 提供相同的 DNS 名，并且可以在它们之间进行负载均衡。简单理解：K8S中的服务（Service）并不是我们常说的“服务”的含义，而更像是网关层，是若干个Pod的流量入口、流量均衡器。

使用service原因官方给的解释是： Kubernetes Pod是有生命周期的。它们可以被创建，而且销毁之后不会再启动。如果您使用Deployment 来运行您的应用程序，则它可以动态创建和销毁 Pod。每个 Pod 都有自己的 IP 地址，但是在 Deployment 中，在同一时刻运行的 Pod 集合可能与稍后运行该应用程序的 Pod 集合不同。这导致了一个问题：如果一组 Pod（称为“后端”）为群集内的其他 Pod（称为“前端”）提供功能，那么前端如何找出并跟踪要连接的 IP 地址，以便前端可以使用工作量的后端部分？

K8S集群内的每一个Pod都有自己的IP（类似于一个Pod就是一台服务器，然而事实上是多个Pod存在于一台服务器上，只不过是K8S做了网络隔离），在K8S集群内部还有DNS等网络服务（一个K8S集群就如同管理了多区域的服务器，可以做复杂的网络拓扑）

总结： Service是K8S服务的核心，屏蔽了服务细节，统一对外暴露服务接口，真正做到了“微服务”。举个例子，我们的一个服务A，部署了3个备份，也就是3个Pod；对于用户来说，只需要关注一个Service的入口就可以，而不需要操心究竟应该请求哪一个Pod。优势非常明显：一方面外部用户不需要感知因为Pod上服务的意外崩溃、K8S重新拉起Pod而造成的IP变更，外部用户也不需要感知因升级、变更服务带来的Pod替换而造成的IP变化，另一方面，Service还可以做流量负载均衡。 K8S的Service有3种类型（最新出了一种新的ClusterName，可以直接提供DNS Name），总结如下：

ClusterIP：只能提供K8S集群内可以访问的IP和Port。
NodePort：在上面的基础上，提供K8S集群外部可以访问的Port，IP则是集群内任意一个NodeIP。
LoadBlancer：在上面的基础上，提供K8S集群外可以访问的IP和Port。需要注意的是，在LoadBlancer中可以设置关闭NodePort。还有一点需要注意，LoadBlanacer依赖集群底座的能力，并不是所有的K8S都能使用LoadBlancer。

Ingerss 官方解释 Ingress 是对集群中服务的外部访问进行管理的 API 对象，典型的访问方式是 HTTP。 Ingress 可以提供负载均衡、SSL 终结和基于名称的虚拟托管

Ingress是官方团队推出的K8S集群接入层，Istio则是社区开发和运维的适配K8S的接入层组件。在实际项目中，我们往往需要功能更为复杂的网关层，比如流量转发，熔断等。而Service提供的功能太过简单，流量只能导入到单点或者有限服务上，无法满足实际生产需求，因此Ingress和Istio应运而生。其中，Istio又发展最好，功能和生态最丰富，是目前主流采用的网关组件。

namespace 命名空间

namespace跟Pod没有直接关系，而是K8S另一个维度的对象。或者说，前文提到的概念都是为了服务Pod的，而namespace则是为了服务整个K8S集群的。

官方定义： Kubernetes 支持多个虚拟集群，它们底层依赖于同一个物理集群。这些虚拟集群被称为名字空间。

简单理解：namespace是为了把一个K8S集群划分为若干个资源不可共享的虚拟集群而诞生的

可以通过在K8S集群内创建namespace来分隔资源和对象。

# 位于命名空间中的资源
kubectl api-resources --namespaced=true

# 不在命名空间中的资源
kubectl api-resources --namespaced=false