k8s资源类型及作用(k8s资源类型详解)

扫码添加渲大师小管家，免费领取渲染插件、素材、模型、教程合集大礼包！

大家好，今天来介绍k8s资源类型及作用(k8s概念详解)的问题，以下是渲大师小编对此问题的归纳和整理，感兴趣的来一起看看吧！

k8s中statefulset资源类型的深入理解

statefulset是枯配为了解决 有状态服务 的问题，而产生的一种资源类型（deployment和replicaSets是解决无状态服务而设计的）。

这里可能有人说，mysql是有状态服务吧，但我使用的是deploment资源类型，mysql的data数据通过pv的方式存储在第三方文件系统中，也能解决mysql数据存储问题。

是的，如果你的mysql是单节点，使用deployment类型确实可以解决数据存储问题。但是如果你的有状态服务是集群,节点之间有主备或者主从之分，且每个节点分片存储的情况下，deployment则不适用这种场景，因为deployment不会保证pod的有序性，集群通常需要主没旅指节点先启动，从节点在加入集群，statefulset则可以保证，其镇团次deployment资源的pod内的pvc是共享存储的，而statefulset下的pod内pvc是不共享存储的，每个pod拥有自己的独立存储空间，正好满足了分片的需求，实现分片的需求的前提是statefulset可以保证pod重新调度后还是能访问到相同的持久化数据。

适用statefulset常用的服务有elasticsearch集群,mogodb集群,redis集群等等。

基于上面的特性，可以发现statefulset由以下几个部分组成：

创建一个headless service,service.yaml文件。

注意：该headless类型service和clusterIp类型的serivice有明显区别，spec下是 clusterIp: None

接着创建一个statefulSet的资源，statefulset.yaml文件。

可以注意到statefulset资源pvc的创建是使用的volumesClaimTemplates,会在俩个pod中分别创建一个资源互相隔离的pvc。

在spec相比deployment多了一个serviceName配置，该值就是对应的headless service。

删除statefulset后，pvc不会自动删除需要我们手动删除

v1.7+支持statefulset的自动更新，通过 spec.updateStrategy 设置更新策略，目前支持俩种策略：

RollingUpdate更新策略还支持Partitions,通过 spec.updateStategy.rollingUpdate.partition 来设置。当partition设置后，只有序号大于或者等于partition的pod会在 spec.templdate 更新的时候滚动更新，而其他pod则保持不变（即便是删除后也是使用以前版本重新创建）。

v1.7+可以通过 .spec.podManagementPolicy 设置pod的管理策略，支持以下俩中方式

使用statefulset资源类型的服务通常有以下几点特点

K8S的概念是什么

k8s全称为Kubernetes，Kubernetes是Google 2014年创建管理梁答的，是Google
10多年大规模容器管理技术Borg的开源版本。它是容器集群管理系统，是一个开源的平台，可以实现容器集群的自动化部署、自动扩缩容、维护等功能。

通过Kubernetes你可以：

快速部槐脊署应用

快速扩展应用

无缝对接新的应用功能

节省资源，优化硬件资源的使用

Kubernetes 特点:

可移植: 支持公有云，私有云，混合云，多橡明慧重云(multi-cloud)

可扩展: 模块化, 插件化, 可挂载, 可组合

自动化: 自动部署，自动重启，自动复制，自动伸缩/扩展

k8s五分钟快速入门

k8s是谷歌开源的容器集群管理系统，是谷歌多年大规模容器管理技术Borg的开源版本，主要功能包括：

从功能上讲Kubernetes是一种综合的基于容器构建分布式系统的基础架构环境，它不仅能够实现基本的拉取用户镜像、运行容器，还可以提供路由网关、水平扩展、监控、备份、灾难恢复等一系列运维能力，而更重要的是Kubernetes可以按照用户的意愿和整个系统的规则，高度自动化的处理好容器之掘纯间的各种关系实现“编排”能力。

简单概括，提供创建应用>应用部署>提供服务>动态伸缩>应用更新一系列服务。

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

一个kubernetes集群由分布式存储etcd、控制节点controller以及服务节点Node组成。

如上图所示，Kubernetes在架构上主要由Master和Node两种类型的节点组成，这两种节点分别对应着控制节点和计算节点。其中Master即控制节点，是整个Kubernetes集群的大脑，负责整个集群的管理，比如容器的调度、维护资源的状态、自动扩展以及滚动更新等，并能根据集群系统资源的整体使用情况将作业任务自动分发到可用Node计算节点。

看Master节点主要由三个紧密协作的独立组件组合而成。
需要说明的是，上述组件在工作状态下还会产生许多需要进行持久化的数据，这些数据会通过kube-apiserver处理后统一保存到Etcd存储服务中。 所以从这个角度看kube-apiserver不仅是外部访问Kubernetes集群的入口，也是维护整个Kubernetes集群状态的信息中枢。

而在Kubernetes计算节点中，除了上述3个系统组件外，其他基本与Master节点相同，而其中最核心的部分就是kubelet组件。它的核心功能具如下：

在Kubernetes中kubelet会通御誉过CRI接口同容器运行时进行交互，而容器运行时则通过叫做OCI容器运行时规范与底层Linux操作系统进行交互(涉及对Namespace、Cgroups等资源的操作，具体可以了解下Docker的技术原理)。需要强调的是，这里所说的容器运行时并不仅仅指Docker，而是所有实现了CRI接口规范的容器项目都可以作为Kubernetes的容器运行时存在。这是因为Kubernetes从设计之初就没有把Docker作为整个架构的核心，而只是将其作为最底层的一个容器运行时来实现。

况且从Kubernetes架构设计上判拆咐看，Kubernetes并没有打算重复造轮子而对已有的容器技术进行替代，它更关注的是对运行在大规模集群中的各种任务根据其关系进行作业编排及管理，所以任何实现了CRI、CNI、CSI等协议标准的容器技术都可以无缝地与Kubernetes集成。从这个角度看，Docker与Kubernetes的关系并不是替代的关系，而是平台与组件的关系，Kubernetes可以利用现有的Docker容器运行时技术，但却并不完全依赖Docker。而这也正是Kubernetes为什么被称作容器编排技术而不仅仅只是容器技术的原因。

[1] Kubernetes和Docker的关系是什么？
[2] 《k8s入门指南》这是一个博主写的书

Kubernetes基础知识笔记

大背景就先不记了（CloudNative、康威定律这些了解一下就好了），先写之前已经学习理解的内容
那就在之前的笔记上面做补充吧

Static pod ： 在Node上手动创建的（未通过Master的api server创建的pod），也未存储于etcd当中

endpoint ： pod的ip+容器暴露的端口

pause容器 ：每一个POD里面都会有一个Pause容器（Pod内所有容器共享Pause容器的ip以及Volume），方便实现容器之间的网络通信以及卷共享粗数逗，同时Pause容器一般比业务容器要稳定可靠，可以作为Pod的状态标识向Kube-master反映整个Pod的状态
资源： K8s当中管理的对象都叫做K8s的资源，从pod、RC、Server、Node到Cluster（相应的在Yaml或者Json的配置文件当中，根据资源的类型来创建不同的对象）

Replicate描述 ：相当于期望Pod的一个运行状态，在其中会定义好Pod的副本数量，Pod使用的容器（容器repository、端口、容器的限额），Pod的label（replicate controller和Service controller后续都会通过label-select来定位到具体的pod进行管理）
也就是说 Service是通过label来关联它的所有POD的

三种IP地址 ： Node IP、Cluster IP、Pod IP，其中Node IP即毕启为宿主机的IP地址，就是实际的物理ip地址，Cluster IP为K8s内部为每一个Service分配的唯一虚拟IP地址，Cluster IP无法用来与外部进行网络交互，只能在K8s内部使用；Pod IP为Docker0网桥网段里拿到的ip； 需要注意的是这三种IP在互相交互的时候使用的不是通常的路由规则，而是由K8s内部自定义的规则来进行网络通信的

service关联Pod ：在通常情况下，Service当中定义的属性是通过Linux环境变量的方式"注入"到Pod当中的（在容器创建的时候自动引入这些环境变量，主要是Service地址），这些变量已ServiceName_变量属性的方式进行命名；在最新的k8s版本当中，已经引入了DNS来根据Service的名称做Service地址获取（Service域名发现）

NameSpace ：在K8s集群当中也有Namespace的概念，其实就是为了方便多租户共同使用同一套K8s集群所设定的规则，所以在创建任何资源的时候都可以带上--namespace标签来定义对应的租户，如果不带标签的话，或将这些资源挂到default namespace下面

APIServer ： 本质上是一个Restful Server（对外提供k8s当中的各类资源的各种API），同时将这些资源的信息存储于Master上面的etcd当中；
Controller Manager、Scheduler都是通过访问这些API来知晓当前Node上面的资源的状态的，同时采取相应的管理动作，指的一提的是，apiserver本身也是k8s当中的一个Service，其他进程访问Apiserver相当于访问一个Service

Controller Manager ：包含了各种资源、状态的Controller， Replication Controller、Node Controller、ResourceQuota Controller、Namespace、Service Account、Token、Service、Endpoint Controller

Schedule Controller ： 接收由Replicate Controller创建的Pod，将其安置到合适的Node，交给后面Node上面的Kubelet来创建实际的POD；
Schedule Controller会按照一定的规则来针对当前集群中的所有Node进行打分（资源消耗最小原则、资源消耗均衡原则、标签优先原则），然后根据打分岩卖以及POD定义当中的一些属性来选择出合适的Node

kubelet ： Node上面的kubelet有几种方式获取Pod清单：

容器健康管理 ： kubelet定期会调用容器的Liveness探针来确定容器的健康状况，liveness探针包括三种方式：

kube-proxy : kube-porxy作为Service的反向代理与负载均衡器，Service外部以Service的Cluster-ip+port或者node ip+Nodeport的方式访问Service业务的时候，这些访问请求会首先被重定向到kube-porxy，然后经过kube-porxy的路由再到达最终的POD
kube-porxy是通过添加iptables来实现重定向的，具体实现是首先kube-porxy会获取一个随机端口作为自己的重定向监听端口，然后添加从外部容器、主机通过Cluster-ip访问的iptables，以及本地的容器、主机通过Nodeport访问的iptables（对于本地容器，重定向目的为kube-porxy的端口，对于外部对象，目的为proxy的ip+proxy的port）
kube-porxy中使用的负载均衡规则为Round Robin算法，除了通常的负载均衡功能之外，还可以配置会话保持（未超时的session一直重定向到同一个Pod），以及配置亲和性（比如按Client ip配置亲和性，让同一个Client ip过来的请求一直访问同一个Pod）

安全管理 ：安全管理分几个阶段，首先是认证，再是授权，最后是准入控制；认证阶段有三种方式进行认证，分别是SSL认证（就是HTTPS），HTTP Token，以及使用用户名+密码来认证；
这里一并写一下HTTPS的认证，HTTPS认证是依赖于CA证书的一种认证方式，Web服务方会向第三方机构申请CA证书（默认这个第三方机构是可信的），然后服务方就有这个CA证书了，然后在服务方接收到请求方的请求之后，会将证书发送给请求方（这个发送过程需要确保这个CA证书不会被中间窃听修改），发送前会用CA证书的私钥进行计算生成数字签名（对于证书的任何篡改都会改变这个数字签名，可以将这个数字签名理解为证书的指纹），请求方收到之后使用CA证书的公钥来解密数字签名，然后按照证书的HASH算法计算出HASH值对证书里的HASH值进行对比，通过之后就算是认证通过服务方是可信的了；后面双方还是进行协商生成一个加密的key用于实际HTTP请求报文的加密，保证HTTP内容不会被中间者窃听获取
授权阶段其实就是Master上面配置的user权限，可以访问哪些资源，是否有读写权限，允许访问哪个Namespace等等配置
最后是准入控制，就是Apiserver针对每一个kubelet的请求去匹配准入控制的列表，比如常用的安全控制（比如禁止使用Security Context），配合ResourceQuota、LimiteRanger进根据资源限制进行调控
其中还有一个比较重要的概念是Service Account，上面说的授权是针对Kubernetes内的user账号的，这里的Service Account相当于是针对Pod内进程的账号（比User账号更加灵活、轻量级，添加也更加简单），配合Secret对象进行工作（Secret对象为保存Token、SSH key、SSL key等凭证的对象，在创建Service Account的时候会声明此Service account拥有的Secret）；Pod进程使用Service Account的方式其实就是获取Secret的过程（使用Secret对象以通过apiserver进行鉴权）； Pod获取Secret也有三种方式：

k8s网络原理 ：终于来到了重中之重的知识点了，在总结k8s的网络之前，要先回忆一下原生Docker网络的一些原理了
首先原生的Docker在Docker engine启动之后会创建一个Docker0虚拟网桥（作为虚拟交换机），Docker0拥有一个16位的网段，它将会从这个网段当中抠出地址分配给新建的容器使用，同一台宿主机上面的容器网络交互都是通过Docker0进行交换的（具体原理就是创建容器的时候容器的端口也会在Docker0上面创建一个veth端口，相当于容器与虚拟交换机有了一个连线，这样容器的收发流量都能流过Docker0），但是原生的Docker不支持不同主机之间容器的网络通信，最明显的一个点就是，每一台宿主机的Docker0的网段都是一样的，同样的网段如何进行通信
具体的实现原理就是，Docker会针对Docker0的网段创建相应的ip route以及iptables（iptables这个东西就先不细写了），实现一个效果就是所有本地访问Docker容器的ip包都会被转到Docker0上面去（通过iptable进行forward），以及非本地的访问经过iptables的dnat转换也会走到Docker0上面去，这样就实现了ip报文的重定向
对于k8s来说，它致力于解决的几个主要问题就是解决容器与容器之间、Pod与Pod之间的通信问题

kubeadm init -- 启动kubernetes集群的命令，在集群启动之后，会提示添加一些环节变量，同时会生成token，需要在Node上面的启动命令携带token完成鉴权
kubeadm reset -- 重启kube集群

K8s 精选Kubernetes CRD 简介

CRD 本身是一种 Kubernetes 内置的资源类型，即 自定义资源的定义 ，用于描述用户定义的资源是什么样子。CRD 的相关概念：① 从 Kubernetes 的用户角度来看，所有东西都叫资源 Resource ，就是 Yaml 里的字段 Kind 的内容，例如 Service、Deployment 等。② 除了常见内置资源之外，Kubernetes 允许用户自定义资源 Custom Resource，而 CRD 表示自定义资源的定义 。

参考 Future of CRDs: Structural Schemas ，Schema 可以确保 Yaml 描述的资源是规范的、合法的。 CRD 本质是一个 Open Api 的 Schema，向 Kubernetes 集群注册一种新资源，并告诉 ApiServer，这种资源怎么被合法的定义 。

拓展：什么是控制器模式？
以 Deployment 为实例，Deployment 没有直接创建 Pod，而是管理 RS，而 RS 管理 Pod，这就是控制器模式。控制器模式允许基于已有的资源定义更高阶的控制器，用来实现更复杂的能力，详情可参考 Kubernetes 控制器的工作原理解读

用户可以自定义控制器的逻辑，实者含消现 Kubernetes 集群原生不支持的功能。下面利用 Kubebuilder 创建 CRD 实现 Kubernetes 集群内置微服务管理 。

App 负责管理整个应用的生命周期， MicroService 负责管理微服务的生命周期 。① 部署方面 ： App 可以直接管理多个 MicroService ，同时 MicroService 利用控制器模式，可以为每个版本创建一个 Deployment ， 实现多个版本同时部署。

② 发布方面 ：微服务管理具备 蓝绿发布 、 灰度发布 的功能。 MicroService 为自己创建 1 个首知的 LoadBalance ，也为每个版本创建了 Service 。如下图所示， MicroService 下的每个版本（对应每个 Deployment ）都有 Service ，而本身也有 LoadBalance ，即总共拥有 n+1 个 Service 。 LoadBalance 和 CurrentVersion 实现了蓝绿发老液布 。 MicroService 利用 nginx ingress controller 的能力，通过修改 LoadBalance 的 canary 配置，实现按照 header/cookie/比例 的灰度发布

CRD 配置详解可以参考 Kuberneters(K8s)CRD资源详解

利用 Kubebuilder 实现 Kubernetes 集群内置微服务管理 ， App 和 MicroService 的 Controller 的主要逻辑如下：

① 从 功能 角度分析， CRD 是积木 。用户可以把 Kubernetes 已有的资源和能力自由堆砌起来，从而拓展了 Kubernetes 原生不具备的能力。
② 从 产品 角度分析， CRD 允许用户基于自己产品的概念，让 Kubernetes 已有的资源为用户服务 ，而不是思考如何将场景应用到 Kubernetes。基于 Kubernetes 开发产品，无法避免如何将产品概念想 Kubernetes 靠拢，例如一个服务就是一个 Deployment ，一个实例就是一个 Pod 等。