k8s简介

目录

k8s是什么

集群管理

master

node

k8s资源对象

namespace

容器

初始化容器 initContainers

Pod

Pod Volume

Endpoints

Service

Headless Service

service对象的type取值

从k8s集群外部访问Service

Deployment

Deployment对象参数说明

ReplicaSet

ingress

有状态服务与无状态服务

什么是无状态服务和有状态服务及区别

StatefulSet

Kubernetes Operator

批处理应用--Job

Job

CronJob

k8s通用配置

Label 与标签选择器

ConfigMap

业务场景

传统解决方案

k8s解决方案

Secret

自动伸缩

自动伸缩概念

HPA( Horizontal Pod Autoscaler）水平伸缩

VPA( Vertical Pod Autoscaler )垂直伸缩

Kubernetes 集群自动缩放器（CA）

存储类对象

概述

pod中如何挂载存储卷

    VOL_TYPE举例：

PV自动创建实现原理

Dynamic Volume Provisioning

Background

Enabling Dynamic Provisioning

安全类对象

Secret

k8s支持的用户类型

ServiceAccout

ServiceAccount结构

Service Account准入控制器

ServiceAcount访问API Server认证过程

自定义具备cluster-admin角色的ServiceAccount并绑定到pod

角色权限相关对象

Subjects

Role/RoleBinding

ClusterRole/ClusterRoleBinding

k8s内置角色

k8s 内置cluster role（集群角色） cluster-admin、admin、 edit、 view的作用范围及区别_51CTO博客_k8s cluster api

NetworkPolicy

kublet命令

问题

如何部署一个服务

术语

---

k8s是什么

Kube:netes 是谷歌十几年来大规模容器技术应用的重要成果，是谷歌严格保密十几年的秘密武器— -Borg 的一个开源版本。

Kubemetes 也是一个全新的基于容器技术的分布式架构 领先方案，是 器云的优秀平台选型方案，已成为新 代的基于容器技术的 PaaS 平台的 重要底层框架，也是云原生技术生态圈的核心，服务网格 (Service Mesh) 无服务器架构 (Serverless) 等新 代分布式架构框架及技术纷纷基于 Kubemetes 现，这些都奠定了 Kubernetes 在基础架构领域的王者地位

有了k8s，我们不必再费心于负载均衡器的选型和部署实施问题，不必再考虑引入或自已开发一个复杂的服务治理框架，不必再头疼于服务监控和故障处理模块的开发。这些都已被k8s实现。 使用 Kubernetes 提供的解决方案，我们不仅节省了不少于30 ％的开发成本，还可以将精力更加集中于业务本身，而且由于 Kubernetes 提供了强大的自动化机制，所以系统后期的运维难度和运维成本大幅 度降低。

然后， Kubernetes 是一个开放的开发平台， 它不局限于任何一种语言， 没有限定任何编程接口，任何语音编写的 服务，都可以部署到k8s上 ，并通过标准的 TCP 通信协议进行交互此外， Kubemetes 平台对现有的编程语言 编程框架、中间件没有任何侵入性，因此现有的系统也很容易改造升级并迁移到 Kubernetes 平台上。

最后， Kubernetes 是一个完备的分布式系统支撑平台。 Kubernetes 具有完备的集群管

理能力，包括多层次的安全防护和准入机制、多租户应用支撑能力 透明的服务注册和服

务发现机制、内建的智能负载均衡器、强大的故障发现和自我修复能力 服务滚动升级和

在线扩容能力、可扩展的资源自动调度机制，以及多粒度的资源配额管理能力 同时，

Kubernetes 提供了完善的 管理工具，这些工具涵盖了 包括开发 、部署测试、运维监控在内

的各个环节 因此， kubernetes 是一个全新的基于容器技术的分布式架构侔决方案，并且

是一个一站式的完备的分布式系统开发和支撑平台。

集群管理

集群 (Cluster) 表示一个由 Master和Node 组成的 kubernetes 集群。

master

Master 指的是集群的控制节点 在每个 Kubemetes 集群中都需要有一个或 组被称为

Master 的节点，来负责整个集群的管理和控制 Master 通常占据一个独立的服务器（在高

可用部署中建议至少使用 台服务器），是整个集群的“大脑”，如果它发生宒机或者不可

用，那么对集群内容器应用的管理都将无法实施。

Master 上运行着集群管理相关的一些进程： ku be-apiserver kube-controller-manager kube-scheduler, 这些进程实现了整 集群的资源管理、 Pod 度、弹性伸缩、安全控制、系统监控和纠错等 管理功能，并且都是自动完成的。

• Kubemetes API Server(kube-apiserver) ：提供 HTTP RESTful API 接口的主要服务，Kubernetes 里对所有资源进行增、删 查等操作的唯 入口，也是集群控 制的入口进程

• Kubernetes Controller Manager ( kube-controller-manager)：Kubernetes 里所有 资源 对象的自动化控制中心 ，可以将其理解为资源对象的“大总管”。
• Kubemetes Scheduler kube-scheduler) ：负责资源调度 Pod 调度 的进程，相当于公交公司的调度室

另外，在 Master 上通常还需要部署 etcd 服务。

node

Node 作为集群中的工作节点，其上运行着真正的应用程序，是 Kubemetes 集群中的工作负载节点。

Node 上， Ku bernetes 管理的最小运行单元是 Pod。

Node 上运行着 Kubemetes kubelet、 kube-proxy 服务进程，这些服务进程负责 Pod 的创建、启动 监控、重启 销毁，以及实现软件模式的负载均衡器。

• kubelet: 负责 Po 对应容器的创建 启停等任务，同时与 Master 密切协作，实现 集群管理的基本功能
• kube-proxy: 实现 Kubemetes Service 的通信与负载均衡机制的服务
• 容器运行时（如 Docker )：负责本机的容器创建和管理

Node 以在运行期间动态增加到 Kubernetes 集群中，前提是 在这个 Node 上已正确安

装、配置和启动了上述关键进程 在默认情况下， kubelet 会向 Master 注册自己，这也是

Kubernetes 推荐的 Node 管理方式 。一 Node 被纳入集群管理范畴， kubelet 进程就会定

时向 Master 汇报自身的情报，例如操作系统、主机 CPU 和内存使用情况，以及当前有哪些

Pod 在运行等，这样 Master 就可以获知每个 Node 的资源使用情况，并实现高效均衡的

资源调度策略 而某个 Node 在超过指定时间不上报信息时，会被 Master 判定为“失联”,该

Node 的状态就被标记为不可用 (Not Ready), Master 随后会触 发”工作负载大转移”

的自动流程。

Taint Nod和Toleration Pod：当需要节点需要运维、下线或升级时，需剔除节点上运行的服务，并防止新的pod被调度到该节点，可以通过给节点打上一种特殊的标签---污点(Taint)来实现。node一旦打了该标签，新的容器被不会被调度到该Node，但Pod可以定义可以 （短期）容忍 （Toleration ）某种污点的存在，这些Pod可以继续将其调度到该 Node。Taint和Toleration 这两个术语属于Kubernetes 调度相关的重要术语和概念。

k8s资源对象

namespace

namespace在很多情况下用于实现多租户 的资源隔离，典型的一种思路就是给每个租户都分配一 个命名空间。

命名空间属于Kubernetes 集群范畴的资源对象，在一个集群里可以创建多个命名空间，每个命名 间都是相互独立的存在，属于不同命名空间的资源对象从逻辑上相互隔离。

在每个 Kubernetes集群安装完成且正常运行之后， Master 会自动创建两个命名空间，一个是默认的 (default)，一个是系统级的 (kube-systern). 用户创建的资源对象如果没有指定命名空间，则被默认存放在 default 命名空间中；而系统相关的资源对象如网络组件 DNS 组件 监控类组件等，都被安装在 kube-systern 命名空间中。

我们可以通过命名空间将集群内部的资源对象“分配”到不同的命名空间中，形成逻辑上分 的不同项目 、小 组或用户组，便于不同的分组在共享使用整个集群 资源的同时能被分别管理。

当给每个租户都创建一个命名空间来实现多租户的资源隔离时 还能结合 Kubernetes 的资源配额管理，限定不同租户能占用的资源，例如 CP 蜇、 存使用证等。

容器

初始化容器 initContainers

Pod

pod用于定义运行在其中的一个或多个业务容器，k8s通过pod提供了强大的服务隔离能力，将一组容器（业务）封装到一起共同部署和卸载，在每个 Pod 中都运行着一个特殊的技称为 Pause 容器，其他容器则为业务容器，这些业务容器共享 Pause 容器的网络栈和 Volume挂载卷。

Pod是k8s进行调度部署的最小单位。运行在一个被称为节点 (Node） 的环境中， 这个节点既可以是物理机，也可以是私有云或者公有云 的一个虚拟机，在每个节点上能 够运行多个 Pod;

可以为pod设置多个不同标签，以为pod进行识别和分组。其它对象（如Service、Deployment对象）通过pod的标签来关联满足条件的pod。

为什么 Kubernetes 会设计出一个全新的 Pod 概念并且 Pod 有这样特殊的组成结构？原如下：

• 为多进程之间的协作提供 个抽象模型，使用 Pod 作为基本的调度 复制等管理工作的最小单位，让多个应用进程能一起有效地调度和伸缩。
• Pod 里的 多个业务容器共享 Pause 容器的 IP, 共享 Pause 容器挂接的 Vo lume,样既简化了密切关联的业务容器之间的通信问题，也很好地解决了它们之间的文件共享问题。

Kubernete 为每个 Pod 分配了唯一 IP 地址，称之为 Pod IP, 一个 Pod 里的 多个
容器共享 Pod IP 地址。Kubernetes 要求底层网络支待集群内任意两个 Po 之间的 TCP/IP
直接通信，这通常 采用虚拟二层网络技术实现，例如 Flannel Open vSwitch 等，因此我们
需要牢记一点 Kubernetes 里， 一个 Pod 里的容器与另外主机上的 Po 容器能够直接通信。

Pod 其实有两种类型：普通的 Pod 及静态 Pod (Static Pod） 。后者比较特殊，它并没被存放在 Kubernetes etcd 中，而是被存放在某个具体的 Node 上的 一个具体文件中，并且只能在此 Node 启动、运行 而普通的 Pod 旦被创建，就会被放入 etcd 中存储，随后被Kuberntes Master 调度到某个具体的 Node 上并绑定 Binding Pod 技对应的 node上的 ub 进程实例化成一组相关的 Docker 容器并启动。在默认情况下，当 里的某个容器停 时， Kubernetes 会自动检测到这个问题并且重新启动这个 Pod （重启 Pod 里的所有容器），如果 Pod 所在的 Node 宥机，就会将这个 Node 上的所有 Pod 都重新调度到其他节点上

问题：静态pod的用途？

Pod Volume

Pod Volume 是被定义在 Pod 上，然后被各个容器挂载到自己的文件系统中 的。 Volume 单来

说就是被挂载到 Pod 里的文件目录。

Endpoints

pod中包含了业务容器， Pod IP 加上这里的容器端口 (containerPort)组成了一个新的概念一 Endpoint, 代表此 Pod 里的 一个服务进程的对外通信地址。

一个 Pod 存在具有多个 Endpo int 的情况，比如 当我们把 Tomcat 定义为一个 Pod 时，可以对外暴露 管理端口与服务端口这两个 En dpoint。

相同的业务（pod）可以被k8s调度运行在多个主机上，形成服务集群，这些服务列表被封装在EndPoints对象中。

Service

Ku bernetes 中， Service 是分布式集群架构的核心 。一个 Servi ce 象拥有如下关键

特征。

• 拥有唯一指定的名称（比如 mys ql- serve
• 拥有一个虚拟 地址 (Clu sterI 地址）和端口号
• 能够提供某种远程服务能力
• 能够将客户端对服务的访问请求转发到一组负载上，即一个Service对应一个Endpoints。

Service 的服务进程通常基于 Socket 通信方式对外提供服务，比如 Redis Memcached MySQL Web Server ，或者是实现了某个具体业务的特定 TCP Server 进程 。

虽然一个 Service 通常由多个相关的服务进程提供服务 每个服务进程都有一个独立的 Endpoint ( IP+Port ) 访问点，但 Kubernetes 能够让我们通过 service (ClusterIP+Service Port ）连接指定的服务。

在创建Service定义中，若不指定type，则默认为ClusterIP类型的Service，这样的Service创建后，k8s会自动为其分配一个ClusterIP，Service 本身一 创建就不再变化，且在service的整个生命周期内，ClusterIP（若存在）不会改变。

ClusterIP 地址是一种虚拟 IP 地址，它有以下特点：

• ClusterIP 地址仅仅作用于 Kubemetes Service 这个对象， 并由 Kubemetes 管理和分IP 地址（来源于 ClusterIP 地址池），与 Node Master 所在的物理网络完全无关。
• ClusterIP没有一个“实体网络对象”来对应，所以 ClusterIP 地址无法被 Ping通。
  Cluster IP 地址只能与 Service Port 组成一个具体的服务访问 端点，单独的 ClusterIP 不具备 TCP IP 通信的基础。
• ClusterIP 属于 Kubernetes 集群这个封闭的空间，集群外的节点无法直接访问，若想访问则需要做一些额外的工作。

k8s内部的服务发现机制

在k8s内部，除了可以通过Service的ClusterIP访问Service，更希望通过service name而不是ClusterIP访问servie，因此需要k8s提供服务发现机制。

k8s通过Add-On增值包的方式引入kube-dns，为每一个Service名称生成一条dns记录，name是service名称，port为该service的port。 定义Service时若不指定port，k8s会自动为其创建随机端口，推荐让k8s自动为其创建port。

k8s内部的负载均衡实现机制

k8s的基于iptables+IPVS为ClusterIP类型的Service添加了负载均衡和会话保持功能。通过负载均衡，将集群内发出的到clusterIP（也叫VIP）:servicePort的请求路由到后端某个具体的Endpoint上。同时还实现了会话保持机制。

k8s在集群的每一个节点上上都运行了一套全局的虚拟负载均衡器，其实现原理是通过cube-proxy为集群内的所有service，添加并自动实时依据最新的Service Endpoint列表更新iptabless规则，结合ipvs机制，把对 Service 的请求转发到其后端对应的某个 Pod 实例上，并在内部实现服务的负载均衡与会话保待机制。

从实现原理上可以看出，k8s是交友位于请求发起端的iptables规则+ipvs实现了负载均衡能力，因此是一种客户端的负载均衡（而非将负载均衡作为一个独立的服务组件）。

问题：

1. 会话保持机制如何实现的

答：在k8s内部访问服务，走的是k8s内部的负载均衡，会话保持基于客户端IP实现。由于请求端和服务端位于二层虚拟网络，client ip不会被中途篡改（ 问题：是这样吗？），会话保持机制不会有问题。

通过k8s外部的ingress访问内部服务时，走的是nginx上的负载均衡，而非k8s内部的负载均衡，会话保持实现机制就不是基于客户端ip了，可以是其它实现方式，因而也不会有问题。

2. k8s内部的负载均衡策略如何设置？

3. istio 是利用 k8s 的服务发现 + 负载均衡机制，还是自己设计了独立的负载均衡机制 ?

Headless Service

除了正常的 service ，还有一种特殊的 Service--Headless Service ，只要在Service的定义中设置了clusterIP:none就定义了一个Headless Service, 它与普通Service的关键区别在于它没有ClusterIP 地址，如果解析Headless Service 的DNS域名，则返回的是该Service 对应的全部 Pod的Endpoint列表，这意味着客户端是直接与后端的Pod建立 TCP/IP连接进行通信的，没有通过虚拟ClusterIP 地址进行转发，因此通信性能最高，等同于”原生网络通信”。

问题：何时用Headless Service？不需要对外保留服务地址时？

service对象的type取值

1. ClusterIP（默认）：k8s会为当前Service分配ClusterIP地址（设置ClusterIP:None，即Headless Service则会不分配ClusterIP），负载均衡一组Pod对应的Endpoints负载。从集群外无法直接访问
2. NodePort：在ClusterIP基础上，将服务的ip映射到节点上。其实现方式是，在 Kubernetes 集群的每个 Kode 上都为需要外部访问的Service 开启 一个对应的 监听端口，外部系统只要用任意一个 Node IP 地址＋NodePort端口号即可访问此服务，在任意 Node 上运行 netstat 命令，就可以看到有 NodePort 端口被监听。 缺点：每个端口只能是一种服务，另外端口范围只能是 30000-32767，另外如果节点/VM 的 IP 地址发生变化，需要能处理这种情况，因此不建议使用NodePort类型的Service。若不指定nodePort，系统将选择一个随机端口。应该让 Kubernetes 来选择端口，因为用户自己来选择可用端口代价太大。 不推荐这种方式暴露服务到k8s外部。
3. ExternalName：通过返回 CNAME 和对应值，可以将服务映射到 externalName 字段的内容（例如，foo.bar.example.com）。 无需创建任何类型代理
4. LoadBalancer：使用云提供商的负载均衡器向外部暴露服务。 外部负载均衡器可以将流量路由到自动创建的 NodePort 服务和 ClusterIP 服务上。缺点是每个服务都要有自己的公网IP， 付费，成本太高。要从外部访问service，推荐使用Ingress.

从k8s集群外部访问Service

几种实现方式：

• 将Service类型定义为NodePort；不推荐
• 将Service类型定义LoadBanlancer；不推荐
• 通过ingress对象访问service。推荐

Deployment

Deployment用于执行pod的线上部署操作。通过Deployment可以定义哪个pod需要部署，部署几份实例，以及pod所需的运行的环境、配置信息、资源，并可以定义系统资源（CPU、内存）的配额。定义Deployment时，可同时定义Pod。

Kubemetes 集群中，只需为需要扩容的 Service 关联的 Pod 创建 Deployment
象，服务扩容以至服务升级等令人头疼的问题就都迎刃而解了 在一个 Deployment 定义
文件中包括以下 个关键信息

• 目标 Pod 的定义
• 目标 Pod 需要运行的副本数益 (Replicas)
• 要监控的目标 Pod 标签

在创建好 Deployment 之后， Kubemetes 会根据这一定义创建符合要求的 Pod, 并且通
过在 Dep loyment 中定义的 Label 筛选出对应的 Pod 实例并实时监控其状态和数量 如果
实例数量少于定义的副本数量，则会根据在 Dep loyment 对象中定义的 Pod 模板创建一个
新的 Pod, 然后将此 Pod 调度到合适的 Node 上启动运行，直到 Pod 实例的数噩达到预定
目标。这个过程完全是自动化的，无须人工干预 有了 Deployment, 服务扩容就变成一个
纯粹的简单数字游戏了，只需修改 Deployment 中的副 本数撮即可 后续的服务升级也将
通过修改 Deployment 来自动完成。

只有一个 Pod 副本实例时，我们是否也需要 Deployment 来自动创 Pod ？在大多数情况下，这个答案是＂需要“。这是因为 Deployment 除自动创建 Pod 副本外，还有一个很重要的特性：自动控制 举个例子，如果 Pod 所在的节点发生岩机事件， Kubernetes会第一时间观察到这个故障，并自动创建一个新的 Pod 象，将其调度到其他合适的节点上， Kubernetes 会实 时监控集群中目标 Pod 的副本数氮，并且尽力与 Deployment 声明的replicas 数量保持一致。

Deployment对象参数说明

参见：

k8s-deployment常见参数说明 | 努力挣扎的生活

 

Deployment配置对象可配置的参数包括：

1. 基本信息：Deployment名称、所属命名空间、pod选择器
2. 副本数 replicas
3. 更新策略，rollingUpdate(滚动更新默认)、Recreate（先全部删除已有的Pod对象，然后创建新版本的Pod对象）。对rollingUpdate(默认)，共T个pd，更新过程是先上m个，再下n个。其中m和n分布通过maxSurge和maxAvailable参数进行控制，可以是0、正整数或百分比，且二者不能同时为0。如：m=1,n=0表示逐个升级，先上一个新，再除一个旧。
4. 模板（Pod）定义，包括：
   1. 容器定义，包括：
      1. 镜像(image)及拉取策略(imagePullSecrets)、镜像拉取加密的用户密码(imagePullPolicy)、端口(ports)
      2. 启动/存活检测startupProbe/livenessProbe/readinessProbe：分别用于判断容器起到是否完成（用于控制起到完成之前不能对外提供服务）、端口是否正常、业务程序是否正常（端口正常不代表业务正常），检测失败后，将 Pod 的 IP:Port 从对应的 EndPoint 列表中删除
      3. 资源限制，包括初始资源请求（requests）和最大资源限制limits
      4. 容器内环境变量设置(env)、磁盘挂载（volumeMounts，通过name属性从volumes加载存储，挂载到mountPath下），如：

         #容器挂载
         volumeMounts:
         #容器挂载内部目录
         - mountPath: /usr/share/nginx/html/
           name: nginx-dp

   2. pod重启策略（restartPolicy）：
      • OnFailure：容器异常时自动重启，
      • Never:从不重启容器，
      • Always:只有容器不允许状态，就自动重启容器
      • restartPolicy: Always
   3. 亲和设置(affinity)：包括部署的节点亲和(nodeAffinity)和pod亲和性(podAffinity)（一定和某个pod部署在同一个节点上，希望pod部署在某个节点上）、pod反亲和性（podAntiAffinity，与亲和力相反，一定不能部署在某个节点上或不希望与某个pod一起部署）、尽量亲和（尽量但不必须）
   4. pod调度规则，包括：
      • 预选策略Predicates包括：
        • PodFitsPorts（PodFitsPorts）
        •  PodFitsResources（PodFitsResources）
        • NoDiskConflict（NoDiskConflict）
        • MatchNodeSelector（PodSelectorMatches）
        • HostName（PodFitsHost）
      • 节点亲和性(nodeAffinity)
      • pod亲和性（podAffinity）
      • 污点（Taint,Toleration）
   5. 安全上下文securityContext，举例：docker限制了最大文件句柄数，如何解除这个限制？
      参见：K8S为 Pod 或容器配置安全上下文securityContext,解决Docker容器限制文件句柄数的问题_运维@小兵的博客-CSDN博客_k8s securitycontext
   6. #优雅的终止服务(terminationGracePeriodSeconds)，默认30s,
   7. 挂载卷信息（volumes，为volumeMounts的name属性提供挂载存储块），volume数组，包括PVC如：
       

      #集群挂载信息
      volumes:
        #与容器volumeMounts部分的name相同
        - name: nginx-dp
      	#指定pvc类型
      	persistentVolumeClaim:
      	  #指定pvc名
      	  claimName: nginx-dp-pvc

      ​​​​
   8. Pod设置DNS的策略（dnsPolicy）：
      • ClusterFirst（默认）,所有请求会优先在集群所在域查询，如果没有才会转发到上游DNS,
      • Default:使用宿主机的/etc/resolv.conf,
      • ClusterFirstWithHostNet:Pod运行在hostNetwork:true的情况下强制指定的
      • None:自定义dns

 

ReplicaSet

Deployment 资源对象其实与 replicaSet 资源对象密切相关 k8s内部会根据Deployment 对象自动创建相关联的 plicaSet 对象，通过以下命令，我们可以看到它的命名与 Deployment 的名称有对应关系。

ingress

通过ingress对象，可以将多个k8s内部的service，以http地址的方式暴露到集群之外。不同的service的http uri不同。如外部访问http://mycompany.com/articile，就会路由到k8s内部的article服务上，当访问http://mycompany.com/vote，就会路由到k8s内部的vote服务上。

ingress对象配置示例：

#外部访问foo.bar.com时，路由到servicel
#访问bar.foo.com时，路由到service2 
kind: Ingress 
metadata: 
	name: name-virtual-host-ingress
spec: 
	rules: 
	  - host: foo.bar.com 
		http: 
		  paths: 
		  - backend: 
			  serviceName: servicel 
			  servicePort: 80 
	  - host: bar.foo.com 
		http: 
		  paths: 
		  - backend: 
			  serviceName: service2 
			  servicePort: 80 

ingress实现原理

k8s提供了IngressController，以DaemonSet方式，部署在k8s的所有节点上。

IngressController内置了nginx，作为反向代理服务器。

同时，还内置了一个对应的controller，通过与k8s api交互，实时、动态的去感知集群中ingress规则变化，根据最新的ingress定义，获取对应的Service和对应Endpoint列表（Endpoint列表在nginx中生成upstream），生成最新的nginx的配置，再写到nginx pod的nginx.conf，最后reload一下。

注意：写入nginx.conf的不是service地址，而是service backend的pod地址列表（nginx upstream片段），避免在service上增加一层负载均衡转发。

ingress对象定义的只是逻辑映射关系规则，IngerssController解析ingress时，并不是将各个service放到nginx的同一个upstream中，而是会从中提取出每一个service对应的Endpoint列表，为每一个service其生成访问的uri，并将其Endpoint列表放到upstream中。

参见：Ingress的概念和原理_m0_46172263的博客-CSDN博客_ingress

有状态服务与无状态服务

什么是无状态服务和有状态服务及区别

k8s有状态与无状态的区别_JulySeven_ju的博客-CSDN博客_k8s有状态和无状态服务

https://www.jianshu.com/p/1abdbe8e557d

有状态服务和无状态服务对比

对比维度	有状态服务	无状态服务
配管k8s对象	StatefulSet（对应无状态服务的Deployment）、Headless Service、Kubernete Operator	RC、Deployment、DaemonSet和Job
唯一性	唯一性。 有状态服务中的每一个pod的业务角色不同，因此集群中的每个Pod都需要具有唯一、稳定的网络标识。StatefulSet里的每个Pod都有稳定、唯一的网络标识，可以用来发现集群内的其他成员。唯一性体现在： 1. 每个pod都有唯一名称：StatefulSet-序号（从0开始），如mySql-0 2.  每个pod都有唯一DNS域名：pod名称.Headless service名称，如mySql-0-mySqlService。（StatefulSet要结合Headdless Service使用，在StatefulSet定义中声明它属于哪个Headless Service，在此基础上为每一个控制的pod实例都创建了一个唯一的DNS域名）	随机性。 通过Deployment创建的无状态服务中的每个pod实例实现的业务都完全相同，在集群内都是随机调度的，各Pod名称，IP、主机名、存储都是随机,不稳定的,并且Pod的创建与销毁也是无序的，没有唯一性和顺序性要求，集群中的某个成员节点岩机后，可在其他节点上随意启动 一个新的 Pod 实例。
稳定性	稳定。 Pod主机名,DNS地址、挂载的PV、不会随着Pod被重新调度而发生变化.	不稳定。 pod被重新启动调度后,它的名称与IP都会发生变化
顺序性	有序性 StatefulSet控制的Pod副本的启、停、更新、删除顺序是受控的，操作第n个Pod时，前n-1个Pod已经时运行且准备好的状态	无序性 启动、更新、停止、删除都没有顺序要求
状态特性	有状态。 有状态服务中的每一个pod都是有状态的、各自运行不同的功能，各自在其本地独立存储不同的数据、通常会持久化数据到永久存储中。每个实例对于同一个用户请求的响应结果不一致。 如果停止集群中的某个pod服务、或对应的存储发生损坏，则业务功能会受损甚至崩溃。	无状态。 无状态服务不会在本地（要么共享存储、要么无存储）存储持久化数据.多个服务实例对于同一个用户请求的响应结果是完全一致的.这种多服务实例之间是没有依赖关系, 某个pod故障后，随机找一个可用的节点重新调度一个新的pod即可。
存储特性	稳定的持久化存储: StatefulSet里的Pod采用稳定的持久化存储卷，通过PV/PVC来实现，删除Pod时默认不会删除与StatefulSet相关的存储卷（为了保证数据的安全） Pod被重新调度后,仍然能挂载原有的PV,从而保证了数据的完整性和一致性.	无存储或共享存储
集群规模	有状态服务中的集群规模是比较固定的，不能随意伸缩，需人为干预，在伸缩前后需要做大量工作。	业务规模可以根据访问压力自动伸缩。
举例	主从架构功能的服务，如数据库、Redis主从、 nginx、zookeeper、kafka	比如web应用,在k8s控制器 中动态启停无状态服务的pod并不会对其它的pod产生影响.

 

无状态服务与有状态服务存储对比：前者为共享存储，后者为独立存储。

StatefulSet

Kubernetes Operator

批处理应用--Job

批处理应用的特点是一个或多个进程处理一组数据（图像、文件、视频等），在这组数据都处理完成后，批处理任务自动结束。为了支持这类应用， k8s引入了新的资源对象一一Job与CronJob。

Job用于执行一次性任务，CronJob用于执行周期任务。

Job

用于执行一次性任务。举例如下（计算圆周率）：（注意apiVersion、kind、completions、parallelism几个参数）。

apiVersion:batch/vl 
kind:Job 
metadata:
    name:pi 
spec: 
    template:
        spec:
            containers: 
                - name: pi 
                image:perl 
                command:["perl ", "-Mbignum=bpi ", "-wle ", "print bpi (10:J) " J 
        restartPolicy: Never 
    #两个控制并发数的参数

    #表示需要运行任务数的总数
    completions:5

    #并发运行的个数
    parallelism: 1

CronJob

k8s通用配置

Label 与标签选择器

Label 通常在资源对象定义时确定，也可以在对象创建后动态添加或者删除。我们可以通过给指定的资湃对象捆绑一个或多个不同的 Labe] 来实现多维度的资源分组管理功能，以便灵活、方便地进行资源分配、调度 、配置、部署等管理工作，例如，部署不同版本的应用到不同的环境中，以及监控 分析应用（日志记录、监控、告警）等 一些常用的 Label 示例如下：

• 版本标签： release : stable release : canary
• 环境标签： environment : dev nvironment : qa env onment : production
• 架构标签： tier : frontend tier : backend tier : middleware
• 分区标签： partition : customerA partition : customerB
• 质量管控标签 track : daily track : weekly

给某 资源对象定义一个 Label, 就相当于给它打了一个标签，随后可以通过 Label Selector （标签选择器）查询和筛选拥有某些 Label 的资源对象， Kubemetes 通过这种方式实现了类似 SQL 的简单又通用的对象查询机制 Label Selector 可以被类比为 SQL 语句中where 查询条件，例如， “name=redis-slave" 这个 Label Selector 作用于 Pod 时，可以被类比为 “select* from pod where pod's name='redis-slave'" 这样的语句 。

当前有两种 LabelSelector 表达式：基于等式的 (Equality-based) Selector 表达式和基于集合的 Set-based)Selector 表达式;

基于等式的 Selector 表达式采用等式类表达式匹配标签，下面是一些具体的例子

• name = redis-slave: 匹配所有具有 name redis-slave 标签的资源对象
• env production: 匹配所有不具有 env=production 标签的资源对象，比如 “env=test"
• 就是满足此条件的标签之一。

基于集合的 Selector 表达式则使用集合操作类表达式匹配标签，下面是一些具体的例
子。

• name in ( redis-master, redis-slave) ：匹配所有具有 name=redis-master 签或者name= redis-slave 标签的资源对象
• name not in php-fronlend ：匹配所有不具有 name=php-frontend 标签的 资源对象。

可以通过多个 Label Selector 表达式的组合来实现复杂的条件选择 ，多个表达式之间用“,”进行分隔即可，几个条件之间是 “AND" 的关系，即同时满足多个条件，比如下面的例子：
narne=redis-slave,env!=preduction 
name notin (php-frontend),env !=production

下面是一个具体的例子。

apiVersion : apps/ v l 
kind: Dep.l:oyment 
metadata: 
name : frontend 
spec : 
    replicas : 1 
    selector: 
matchLabels : 
    tier : frontend 
    matchExpressions: 
    {key: tier, operator : In , values : [frontend]} 
template : 
   ...

ConfigMap

业务场景

每一个应用都需要一个静态配置文件提供启动参数，尤其是一个分布式应用，多个副本部署在不同的机器上，如何方便地分发它们的配置？

传统解决方案

很多多分布式系统本身都有一个配置中心组件来解决这个问题。但配置中心通常会引入新的API，从而导致应用的耦合和侵入。

k8s解决方案

Kubernetes则采用了一种简单的方案，即ConfigMap来规避传统解决方案的问题，如图所示，具体做法如下：

• 用户将配置文件的内容保存到ConfigMap中，文件名可作为key，value就是整个文件的内容，多个配置文件都可被放入同一个ConfigMap。
• 在建模用户应用时，在Pod里将ConfigMap定义为特殊的Volume进行挂载。在Pod被调度到某个具体Node上时，ConfigMap里的配置文件会被自动还原到本地目录下，然后映射到Pod里指定的配置目录下，这样用户的程序就可以无感知地读取配置了。
• 在ConfigMap的内容发生修改后，Kubernetes会自动重新获取ConfigMap的内容，并在目标节点上更新对应的文件。

Secret

Secret也用于解决应用配置的问题， 不过它解决的是对敏感信息的配置问题，比如数据库的用户名和密码、 应用的数字证书、 Token、 SSH密钥及其他需要保密的敏感配置 。对于这类敏感信息，我们可以创建一个Secret 对象，然后被Pod引用 。 Secret 中的数据要求以 BASE64编码格式存放。注意，BASE64编码并不是加密的。

在Kubernetes 1. 7版本以后， Secret中的数据才可以以加密的形式进行保存，更加安全。

自动伸缩

自动伸缩概念

什么是弹性伸缩？
弹性伸缩概述

HPA( Horizontal Pod Autoscaler）水平伸缩

Deployment来控制Pod，若手工伸缩，则执行命令kubectl scale命令来实现Pod扩容或缩容。

运维目标---自动化、智能化：k8s希望能动态追踪分析指定Deployment控制的所有目标Pod的负载变化情况，来确定是否需要有针对性地调整目标Pod的副本数量，做到无人值守，实现自动运维。

为此，k8s提供了HPA对象。可以将HPA理解为Pod横向自动扩容，即自动控制Pod数量的增加或减少。Kubernetes内置了基于Pod 的CPU利用率进行自动扩缩容的机制，应用开发者也可以自定义度量指标如每秒请求数， 来实现自定义的 HPA功能。

下面 是一个HPA定义的例子（副本数量限定在1-0范围，pod扩缩容的依据是CPU使用率超过了90%）：

HPA问题：需要运行基准测试任务来确定 CPU 和内存请求的合适值，这通常不易确定。一是需要一定的测试，有一定的工作量，二是可能不具备相对应的投产环境（如CPU、内存、网络、存储等）条件，无法得到一个合理的基准值。

解决办法：VPA。

VPA( Vertical Pod Autoscaler )垂直伸缩

HPA设置的资源阈值设置多少通常不易确定，因为实际运行过程中会动态变化（比如预估1000人访问，实际可能很多或很少，如高峰时段和闲暇时不一样），VPA是根据pod在投产环境运行过程中实际占用的资源量，自动推测并设置Pod合理的CPU和内存的需求指标（在定义Deployment时可以设置请求的最小和最大资源，有了VPA，），从而更加精确地调度Pod，实现整体上节省集群资源的目标， 因为无须人为操作， 因此也进一步提升了运维自动化的水平。

VPA优势：

• Pod 资源用其所需，所以集群节点使用效率高；
• Pod 会被安排到具有适当可用资源的节点上；
• 不必运行基准测试任务来确定 CPU 和内存请求的合适值；
• VPA 可以随时调整 CPU 和内存请求，无需人为操作，因此可以减少维护时间；

Kubernetes 集群自动缩放器（CA）

使用业务场景：我们从云厂商申请了1000核cpu，1T内存搭建k8s集群，随着部署的应用增多，当5个节点的资源达到瓶颈而出现pending pod时，希望云厂商能自动添加新的资源进来。

集群自动伸缩器（CA）基于待处理(状态:pedding)的pod扩展集群节点。它会定期检查是否有任何待处理的pod，如果需要更多的资源，并且扩展的集群仍然在用户提供的约束范围内，则会增加集群的大小。CA与云供应商接口，请求更多节点或释放空闲节点。它与GCP、AWS和Azure兼容。版本1.0（GA）与Kubernetes 1.8一起发布。

参见：

Kubernetes-自动扩展器HPA、VPA、CA_SRE运维充电站的博客-CSDN博客_hpa vpa

存储类对象

概述

目前k8s支持的存储卷可以大致分为一下几类，它们各自有着不同的实现插件：

• 临时存储卷：emptyDir
• 本地存储卷：hostPath
• 特殊存储卷：configmap、secret、gitRepo（通过挂载一个空目录，并从 Git 库克隆 clone 一个 git repository 以供Pod 使用）
• 网络存储卷：nfs、cinder、rbd、iscsi等
• 扩展支持第三方存储的存储接口：CSI （Container Storage Interface(容器存储接口)）

通常k8s内置的存储卷插件可以归类为In-Tree类型，它们通k8s源码一起发布迭代，而由存储厂商借助CSI接口扩展的独立于k8s源码的插件统称为Out-of-Tree类型，集群管理员可以根据需要创建自定义的扩展插件，CSI是比较常用的实现方式。目前k8s已经开始逐步将In-Tree类型的存储卷插件迁移到CSI，所以建议在新环境中使用CSI。

pod中如何挂载存储卷

在pod.spec中声明要挂载的存储卷，然后在container中将这些存储卷挂载到指定的目录。

spec:

  #声明要挂载的存储卷（可以有多个）
  volumes:
  - name  # 存储卷名称标识，仅可使用DNS标签格式的字符，在当前Pod中必须唯一
    VOL_TYPE