Kubernetes架构原则和对象设计（三）

云原生学习路线导航页（持续更新中）

kubernetes学习系列快捷链接
- Kubernetes架构原则和对象设计（一）
- Kubernetes架构原则和对象设计（二）
- Kubernetes常见问题解答

本文主要对kubernetes的核心技术概念和核心API进行介绍，深入理解kubernetes对象设计原则

1.Kubernetes核心技术概念

1.1.Kubernetes API对象属性

在这里插入图片描述

kubernetes对象，是其设计最牛的地方。kubernetes诞生时，要和openStack、docker等技术争夺天下，项目是很难推进的，因此谷歌做了两件事：
- 基于强大的borg系统
- 通过定义API规范，将自己做成业界规范。因此kubernetes将云计算领域所有的对象，都纳入其管控范围
kubernetes为什么要定义规范？
- kubernetes把计算节点应该如何、作业应该如何、服务应该如何、入栈流量应该如何、防火墙规则应该如何等等，都定成标准和规范，自己专注于API层，就把自己的行业地位固化住了。
- 其他公司可以对kubernetes的API进行各种实现，这就相当于加入了kubernetes生态，拉着全世界所有的云计算公司站队kubernetes。
- 规范强大起来后，其他公司在自己另起炉灶的意义就不大了，就逐渐都复用这个完善的规范了。
一个kubernetes对象，一般包含4个部分：
- TypeMeta：定义对象是什么
- Metadata：定义对象元数据，如名字、标签、基本属性等
- Spec：对象的期望终态
- Status：对象的实时状态

1.2.TypeMeta

在这里插入图片描述

TypeMeta 的内容其实就是GKV
- group：将对象进行分组，类似java的package
- kind：表示对象的类型，类似java的class
- version：表示这个对象的不同版本
为什么要有version
- 社区以前是每年发4个版本，现在是每年发3个版本，相当于每个季度多点就会发一个新版本。
- 而我们做任何系统的时候都不是一个瀑布型的，都是有不停的迭代的，对象有可能发生变化，没有人能说第一天就把一个对象定义的特别清楚，所以要保证 API 的向前兼容。version就是为了保证API的向前兼容性
- 常见的version演进路线：alpha（demo）–>beta（基本稳定）–>v1（正式版）
- 每个对象在kubernetes系统内部中都存在两种版本：内部版本、外部版本
  - 内部版本：etcd中真正存储的对象版本，不会直接暴露给用户看到，只是为了便于实现所有版本之间的转换。
    - k8s对象，如果存在多版本，就需要为其提供一些conversion方法，负责 内部版本<–>所有外部版本 之间的转换，使得同一个对象，不论使用哪个版本读取，都能读出来。
    - 比如有10个版本，每个版本都提供和 internalVersion之间的转换方法，就可以实现所有版本之间的互相转换，而不需要把所有版本之间的互相转换方法都写全（v1->v2,v2->v3,v2->v5…），即：拓扑型–>星型
    - 如v1–>v2，只需要 v1–>internalVersion–>v2即可
  - 外部版本：暴露给用户使用的版本，比如 v1alpha1、v1beta1、v1等

1.3.Metadata

在这里插入图片描述

1.3.1.namespace 和 name 组成的对象唯一标识

k8s的对象可以分成2类：Namespace对象、NoNamespace对象
- Namespace对象：即使用了Namespace隔离，Namespace下共享，在不同Namespace下允许重名
- NoNamespace对象：即未使用Namespace隔离的全局对象，集群共享，全局中不允许存在重名对象
因此，对象唯一性可以这么归纳：
- Namespace对象：Namespace+Name需要唯一，不允许重复。如 Pod、Service
- NoNamespace对象：Name需要唯一，不允许重复。如 Node
namespace 和 name 组成的对象唯一标识，也被称为对象的Key

1.3.2.uid：对象唯一id

Metadata下是有唯一uid的，不过uid一般很少使用，有些场合下会用，之后遇到会讲。

1.3.3.label：标签

在这里插入图片描述

label：标签，map[string]string，一般用于filter查询过滤
- 比如 kubectl get ns -l a=b
label的使用场景
- 比如说现在做成本控制，每个作业或应用都要规定好属于哪个业务部门，这叫成本分配，最终要去统计资源利用率的时候，就知道 a部门到底产生了哪些作业或应用，最后公司财务再去review，审查每一个应用的财务开销。
- 这个例子中，作业或应用就可以打上特定的label，用于标识属于哪个业务部门

1.3.4.annotation：注解

在这里插入图片描述

annotation，map[string]string，一般用于扩展对象功能
当你觉得kubernetes对象里面的属性不太够用，但是改动CRD的动作太大（涉及到CRD升级回滚各种风险），此时就可以做一些附加属性写到annotation
annotation的key命名有一些不成文的规范：项目域名/功能名。比如：flannel.alpha.coreos.com/backend-type

1.3.5.Finalizer：对象终止器，资源锁

在这里插入图片描述

Finalizer：对象终止器，[]string，本质是一个资源锁
- 当Finalizer中存在值的时候，kubernetes是不会直接把pod删除的，delete命令只会让其进入Terminating状态。
- 只要Finalizer不为空即可，kubernetes不会管里面是什么，里面的值应该是Controller自己定义的
- 为什么要有Finalizer？
  - 假如我有一个CRD+对应的Controller，此时Controller有bug crush死掉了，或者OOM了。用户如果发送一个delete命令，kubernetes就会直接把它删了，等Controller 恢复后，就可能会丢数据或者丢事件
  - 而如果有Finalizer资源锁机制，Controller给自己管理的每个对象都打上特定的finalizer，并且只有自己会移除它。那么即便Controller死掉，pod也无法被真正的delete掉，Controller重启后会继续处理该pod的相关事件，处理完成后移除finalizer，kubernetes才会真正把pod删除
- Finalizer的使用场景：pod删除前的外部依赖清理，防止泄漏
  - 比如 pod 的 podIp 被写入了注册中心用于负载均衡，或者pod被分配了外部IP和外部DNS域名等，如果pod没有Finalizer，有可能被直接干掉。干掉后其他服务还会通过外部ip或域名请求到它，就发生了资源泄漏
  - 有了Finalizer，控制器在发现deletionTimestamp有值后，就知道该pod要被删除了，会先行把外部依赖都解决，分配的IP和域名进行清理，其他服务的请求就不会打到这台机器了，解决了资源泄漏问题

1.3.6.ResourceVersion：用于版本控制的分布式乐观锁

在这里插入图片描述

ResourceVersion：用于版本控制的分布式乐观锁
- 在分布式系统里，一般一个对象会被多个控制器管理，为了避免多个线程读写同一个对象所造成的资源冲突，就需要加锁。
- 可是加锁可能会带来一系列问题：线程饥饿、死锁等，因此就选择了版本控制的乐观锁方式。
- 当发生对象写操作时，apiserver会查看提交数据的ResourceVersion，如果<当前版本，说明该资源是根据较旧的版本更改的，拒绝本次更新，并返回一个409(“Conflict”)给写进程。写进程接收到后就知道发生了并发冲突，就需要根据最新数据处理后再提交

1.4.Spec和Status

在这里插入图片描述

Spec 和 Status 根据需要定义，比如 Namespace资源的Spec就是空的，因为它不需要定义什么，它只是一个目录。而Namespace的Status也只是表示其状态为 active 还是 terminating 等
- 不过我们查看Namespace时，会看到在spec中有个finalizers，这应该算是历史遗留问题。早期Namespace Controller通过.spec.finalizers保证在删除ns时，能够先把ns下所有的资源都清理掉
- 现在在通用属性Metadata中也包括finalizer了，其实可以重构一下

2.Kubernetes 常用API对象

这里只列举一些最常用的API对象，更详细的学习和深入，直接去看官方文档就好

2.1.Kubernetes常用API对象及其分组

在这里插入图片描述

核心对象core：基本上是能够满足一个应用的最小集合
随着一个对象的迭代和成熟度，可能会被划分到不同的group中，比如deployment以前就是属于extensions/v1beta1，现在划分到apps/v1了

2.2.Pod：Kubernetes调度的基本单位

2.2.1.Pod基本介绍

在这里插入图片描述

Pod是kubernetes调度的基本单位，一个pod可以包含多个容器，它们共享network、PID、IPC、UTS namespace。另外，一个Pod的volume默认也被多个容器间共享
- 一个pod中多个容器 network、volume 默认就是共享的，因此容器之间可以通过localhost去通信，多个容器的端口也不能冲突的。
- 而 PID、IPC 这些namespace是默认是不共享的，但是可以通过属性控制。比如使用 Pod .spec 中的 shareProcessNamespace 字段可以启用进程命名空间共享
```
apiVersion: v1
kind: Pod
metadata:name: nginx
spec:shareProcessNamespace: truecontainers:- name: nginximage: nginx- name: shellimage: busybox:1.28command: ["sleep", "3600"]securityContext:capabilities:add:- SYS_PTRACEstdin: truetty: true
```

2.2.2.Pod中配置来源

一个应用，配置一般要和代码进行分离，代码从容器镜像来，配置的来源就比较多了，比如作为环境变量写入，或者外挂一个存储卷，读取一个配置文件

2.2.2.1.Pod中的环境变量配置

pod中环境变量的数据来源，一般包括4种。
ConfigMap 和 Secret
- configmap是Kubernetes用于保存应用配置的对象，内容是明文保存。
- configmap的结构由 TypeMeta、Metadata、Data（map[string]string）等属性组成，它不包含Spec，或者说data就是它的spec。
- secret和configmap 结构一样，不过它是加密的

2.2.2.2.Pod中外挂存储卷配置

在这里插入图片描述

之前在讲Docker的时候，使用 docker run -v 命令时有挂载过外部存储到容器中。kubernetes中也是一样的，比如定义一个Pod，也可以为Pod中的容器挂载存储。
存储卷使用分为两部分：声明卷、挂载卷
- 声明卷Volume：卷名称、卷类型，表明卷的数据来源
- 挂载卷VolumeMount：卷名称、挂载到哪个目录

2.2.3.Pod网络

在这里插入图片描述

2.2.4.Pod资源限制

在这里插入图片描述

如何查看 Pod容器的资源限制
- 方法一：进入pod内部查看
  - 进入pod内部，在 /sys/fs/cgroup下面，可以看到当前pod的所有 cgroup设置
  - 比如 /sys/fs/cgroup/cpu 中，cpu.cfs_period_us、cpu.cfs_quota_us 就以绝对值的方式，设置了pod的 cpu limit
  - 再比如，在 /sys/fs/cgroup/memory 中，memory.limit_in_bytes 就设置了pod的 memory limit
- 方法二：在pod所在主机上查看
  - 进入主机的 /sys/fs/cgroup，每一个子系统中，都有一个kubepods的目录，里面存储着所有pod的cgroup
  - kubepods里面，还有一个burstable目录，这就是所有pod cgroup的存储位置
  - 比如，查看一个pod的cpu cgroup，就应该进入：/sys/fs/cgroup/cpu/kubepods/burstable/podxxxx-xxxx/
    - 其中 podxxxx-xxxx 表示pod的uid，可以使用kubectl get pods podxxx -oyaml找到

2.2.5.Pod健康检查

在这里插入图片描述

健康探针官方文档官方文档写的很通俗，建议这块直接看文档
Deployment 滚动升级配置 MaxUnavailable 和 MaxSurge
- MaxUnavailable：最大不可用pod数量，即无法正常提供服务的pod数量，如果达到了这个阈值，滚动升级是要暂停的
- MaxSurge：pod总数量可以超过 .spec.replicas 多少
Pod 字段 .status.ready
- Pod中有一个字段 .status.ready，代表这个pod是否完全准备好对外提供服务了
- service做负载均衡流量转发的时候，默认不会把没 Ready 的pod加入负载列表
Pod 的有3种健康探测方式
- LivenessProbe：存活探针，判断应用是否还存活，不存活则杀死
- ReadinessProbe：就绪探针，判断应用是否就绪，没有就绪则不应该接收流量，pod会表现为NotReady，但不会杀死或重启pod
- StartupProbe：启动探针，判断应用是否启动完成
  - 配置了StartupProbe时，LivenessProbe和ReadinessProbe 会在StartupProbe成功后才生效。
  - 我们可以为StartupProbe配置较低的探测频率，保证慢启动应用的数据库、端口、缓存预热等依赖加载的过程中，不会太频繁的探测造成应用压力，也不会在启动时就被LivenessProbe和ReadinessProbe判定为失败
健康探测的一些配置
- periodSeconds：每次探测的间隔时间。periodSeconds要合理，太短会加大应用压力，太长会较慢发现故障
Pod 的3种探活方式
- Exec：去这个容器里面执行一个命令，命令返回非0则失败，返回0则成功
  - 下面就是 cat一个文件，如果文件存在则探测成功，文件不存在肯定会报错
- TCP socket：由kubelet发起对指定host+port的端口连通性检查
- HTTP：由kubelet发起一条真正的http请求，容器化应用开发时一般都会预留一个端口用于http的健康检查

2.2.6.Pod的配置：ConfigMap、Secret

在这里插入图片描述

2.3.用户UserAccount 和服务账户ServiceAccount

在这里插入图片描述

当一个组件要跟 API Server 通信的时候，要做认证健全，就一定要有个身份，所以任何的 Kubernetes pod 都需要以一个 service account的身份运行
这个Service Account会以一个volume的形式，被mount到一个Pod里面，里面的应用就可以读取这个service account 所对应的 TOKEN 或 ca证书文件来跟API Server通信。

2.4.负载均衡Service

在这里插入图片描述

下面举例Service
- clusterIp：为service分配的集群内ip，集群外无法访问
- ipFamilies：定义service的ip协议栈是 IPv4
- ipFamilypolicy：协议栈类型为单栈
  - 详细的配置访问可以看官方文档：IPv4/IPv6 双协议栈
- ports：后端业务的访问信息
- selector：label选择器，选择service要管理哪些pod

2.5.副本集ReplicaSet

在这里插入图片描述

2.6.部署 Deployment

在这里插入图片描述

2.7.Deployment 和 Service 练习

在这里插入图片描述

2.8.有状态服务集 Statefulset

在这里插入图片描述

Statefulset 和 Deployment 的差异
- 名称规则不同：
  - Statefulset：创建的多副本，名称是固定的，按照数字序号递增
  - Deployment：创建的多副本，名字比较长：deployment名称-podTemplate哈希值-随机字符串
- 创建/更新顺序不同
  - Statefulset：创建是从小号–>大号，更新和删除是从大号–>小号。其中升级的时候支持滚动升级、分片升级、OnDelete升级
  - Deployment：创建/更新/删除都是随机的。
- Pod行为不同
  - Statefulset：因为名称是固定的，所以每个pod都是独立的个体，可以为它们声明不同的volume，当pod发生重建后可以关联旧的volume继承数据
  - Deployment：因为名称是随机的，所以每个pod无法做到独立个体，pod发生重建后名称就改变了，不太方便做到继承旧数据

2.9.任务 Job

在这里插入图片描述

Deployment、Statefulset都是 Running 长时任务，有时还有一些 Short 短时任务，Kuberenetes提供了Job资源类型用于短时任务，Job完成之后是completed状态，结束后不会再被拉起

2.10.后台支撑服务集 DaemonSet

在这里插入图片描述

2.11.存储PV和PVC

在这里插入图片描述

无论存储来自于本地还是网络，都可以通过PV和PVC去挂载

2.12.CRD：CustomResourceDefinition

在这里插入图片描述

CRD可以理解为数据库的开放式表，当基本对象没有办法支撑你的需求时，可以通过CRD的这种对象扩展一个当前业务。
比如：Calico，目前开源的最成熟的纯三层网络框架之一，它其实就依赖于一堆CRD
目前所有围绕着Kubernetes的大的生态项目基本都有自己的CRD和控制器，无论是运维还是开发最后都会涉及到有CRD

2.13.课后练习

在这里插入图片描述

2.13.1.启动一个envoy并查看进程及配置

apiVersion: v1
kind: PersistentVolume
metadata:name: envoy-pv
spec:storageClassName: local-storagecapacity:storage: 10GiaccessModes:- ReadWriteOncehostPath:path: /data---apiVersion: v1
kind: PersistentVolumeClaim
metadata:name: envoy-pvc
spec:storageClassName: local-storageaccessModes:- ReadWriteOnceresources:requests:storage: 10Gi---apiVersion: apps/v1
kind: Deployment
metadata:name: envoy-deployment
spec:replicas: 1selector:matchLabels:app: envoytemplate:metadata:labels:app: envoyspec:containers:- name: envoyimage: envoyproxy/envoy:v1.19.1ports:- containerPort: 8080volumeMounts:- name: envoy-datamountPath: /datavolumes:- name: envoy-datapersistentVolumeClaim:claimName: envoy-pvc

# 将上述文件保存为yaml文件，然后apply即可
[root@VM-226-235-tencentos ~/yamls]# kubectl apply -f envoy.yaml# 查看创建好的pv、pvc、deploy
[root@VM-226-235-tencentos ~/yamls]# kubectl get pvc
NAME                                           STATUS    VOLUME     CAPACITY   ACCESS MODES   STORAGECLASS    AGE
envoy-pvc                                      Bound     envoy-pv   10Gi       RWO            local-storage   12m
[root@VM-226-235-tencentos ~/yamls]# kubectl get pv
NAME       CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS   CLAIM               STORAGECLASS    REASON   AGE
envoy-pv   10Gi       RWO            Retain           Bound    default/envoy-pvc   local-storage            12m
[root@VM-226-235-tencentos ~/yamls]# kubectl get deploy
NAME               READY   UP-TO-DATE   AVAILABLE   AGE
envoy-deployment   1/1     1            1           22m# 进入pod内部
[root@VM-226-235-tencentos ~/yamls]# kubectl exec -it  envoy-deployment-68cd599779-4chjj -- /bin/bash# 可以看到1号进程即为envoy进程，命令中指定的了config文件路径
root@envoy-deployment-68cd599779-4chjj:/# ps -ef
UID        PID  PPID  C STIME TTY          TIME CMD
envoy        1     0  0 13:41 ?        00:00:01 envoy -c /etc/envoy/envoy.yaml
root       104     0  0 13:52 pts/0    00:00:00 /bin/bash
root       114   104  0 13:52 pts/0    00:00:00 ps -ef# 查看 envoy 的 config 文件
root@envoy-deployment-68cd599779-4chjj:/# cat /etc/envoy/envoy.yaml
admin:address:socket_address:protocol: TCPaddress: 0.0.0.0# envoy 的 监听端口port_value: 9901
static_resources:listeners:- name: listener_0address:socket_address:protocol: TCPaddress: 0.0.0.0port_value: 10000filter_chains:- filters:- name: envoy.filters.network.http_connection_managertyped_config:"@type": type.googleapis.com/envoy.extensions.filters.network.http_connection_manager.v3.HttpConnectionManagerscheme_header_transformation:scheme_to_overwrite: httpsstat_prefix: ingress_httproute_config:name: local_routevirtual_hosts:- name: local_servicedomains: ["*"]routes:- match:prefix: "/"route:host_rewrite_literal: www.envoyproxy.iocluster: service_envoyproxy_iohttp_filters:- name: envoy.filters.http.routerclusters:- name: service_envoyproxy_ioconnect_timeout: 30stype: LOGICAL_DNS# Comment out the following line to test on v6 networksdns_lookup_family: V4_ONLYlb_policy: ROUND_ROBINload_assignment:cluster_name: service_envoyproxy_ioendpoints:- lb_endpoints:- endpoint:address:socket_address:address: www.envoyproxy.ioport_value: 443transport_socket:name: envoy.transport_sockets.tlstyped_config:"@type": type.googleapis.com/envoy.extensions.transport_sockets.tls.v3.UpstreamTlsContextsni: www.envoyproxy.io

此时我们还没有从外部挂载配置到容器中，envoy使用默认配置，放在容器的/etc/envoy/envoy.yaml。所以待会我们从外部挂载配置的时候，要挂载到这个目录下

从配置中可以看出，虽然我们在 Pod 中容器containerPort写的是8080，但是envoy实际监听的端口是9901，curl一下试试

# 首先使用kubectl get pods -owide找到podIp
[root@VM-226-235-tencentos ~/zgy/yamls]# kubectl get pods -owide
NAME                               READY   STATUS         RESTARTS   AGE     IP             NODE                   NOMINATED NODE   READINESS GATES
envoy-deployment-555699d88-bmxxx   1/1     Running        0          13m     10.244.0.214   vm-226-235-tencentos   <none>           <none># 然后curl一下指定端口[root@VM-226-235-tencentos ~/zgy/yamls]# curl 10.244.0.214:8080
curl: (7) Failed connect to 10.244.0.214:8080; Connection refused# [root@VM-226-235-tencentos ~/zgy/yamls]# curl 10.244.0.214:9901<head><title>Envoy Admin</title><link rel='shortcut icon' type='image/png' href='data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAABgAAAAYCAYAAADgdz34AAAAAXNSR0IArs4c6QAAAARnQU1BAACxjwv8YQUAAAAJcEhZcwAAEnQAABJ0Ad5mH3gAAAH9SURBVEhL7ZRdTttAFIUrUFaAX5w9gIhgUfzshFRK+gIbaVbAzwaqCly1dSpKk5A485/YCdXpHTB4BsdgVe0bD0cZ3Xsm38yZ8byTUuJ/6g3wqqoBrBhPTzmmLfptMbAzttJTpTKAF2MWC7ADCdNIwXZpvMMwayiIwwS874CcOc9VuQPR1dBBChPMITpFXXU45hukIIH6kHhzVqkEYB8F5HYGvZ5B7EvwmHt9K/59CrU3QbY2RNYaQPYmJc+jPIBICNCcg20ZsAsCPfbcrFlRF+cJZpvXSJt9yMTxO/IAzJrCOfhJXiOgFEX/SbZmezTWxyNk4Q9anHMmjnzAhEyhAW8LCE6wl26J7ZFHH1FMYQxh567weQBOO1AW8D7P/UXAQySq/QvL8Fu9HfCEw4SKALm5BkC3bwjwhSKrA5hYAMXTJnPNiMyRBVzVjcgCyHiSm+8P+WGlnmwtP2RzbCMiQJ0d2KtmmmPorRHEhfMROVfTG5/fYrF5iWXzE80tfy9WPsCqx5Buj7FYH0LvDyHiqd+3otpsr4/fa5+xbEVQPfrYnntylQG5VGeMLBhgEfyE7o6e6qYzwHIjwl0QwXSvvTmrVAY4D5ddvT64wV0jRrr7FekO/XEjwuwwhuw7Ef7NY+dlfXpLb06EtHUJdVbsxvNUqBrwj/QGeEUSfwBAkmWHn5Bb/gAAAABJRU5'/><style>.home-table {........```

我们接下来外挂存储的时候正好测试一下把端口修改为8080，和pod的containerPort保持一致

2.13.2.挂载外部配置到Pod并测试访问

创建一个configMap

apiVersion: v1
kind: ConfigMap
metadata:name: envoy-config
data:envoy.yaml: |admin:address:socket_address:protocol: TCPaddress: 0.0.0.0port_value: 8080static_resources:listeners:- name: listener_0address:socket_address:protocol: TCPaddress: 0.0.0.0port_value: 10000filter_chains:- filters:- name: envoy.filters.network.http_connection_managertyped_config:"@type": type.googleapis.com/envoy.extensions.filters.network.http_connection_manager.v3.HttpConnectionManagerscheme_header_transformation:scheme_to_overwrite: httpsstat_prefix: ingress_httproute_config:name: local_routevirtual_hosts:- name: local_servicedomains: ["*"]routes:- match:prefix: "/"route:host_rewrite_literal: www.envoyproxy.iocluster: service_envoyproxy_iohttp_filters:- name: envoy.filters.http.routerclusters:- name: service_envoyproxy_ioconnect_timeout: 30stype: LOGICAL_DNSdns_lookup_family: V4_ONLYlb_policy: ROUND_ROBINload_assignment:cluster_name: service_envoyproxy_ioendpoints:- lb_endpoints:- endpoint:address:socket_address:address: www.envoyproxy.ioport_value: 443transport_socket:name: envoy.transport_sockets.tlstyped_config:"@type": type.googleapis.com/envoy.extensions.transport_sockets.tls.v3.UpstreamTlsContextsni: www.envoyproxy.io

将configmap mount到deploy中

apiVersion: apps/v1kind: Deploymentmetadata:name: envoy-deploymentspec:replicas: 1selector:matchLabels:app: envoytemplate:metadata:labels:app: envoyspec:containers:- name: envoyimage: envoyproxy/envoy:v1.19.1ports:- containerPort: 8080volumeMounts:- name: envoy-datamountPath: /data- name: envoy-config-volumemountPath: /etc/envoyvolumes:- name: envoy-datapersistentVolumeClaim:claimName: envoy-pvc- name: envoy-config-volumeconfigMap:name: envoy-config

yaml准备好后，apply到环境中

kubectl apply -f cm.yaml
kubectl apply -f deploy.yaml

进入pod内部，查看/etc/envoy/envoy.yaml，可以看到已经挂载上来了
```
root@envoy-deployment-555699d88-bmxxx:/# ls /etc/envoy
envoy.yaml
```

重新获取podip，然后curl一下8080，可以看到监听端口已经换成8080了

 # [root@VM-226-235-tencentos ~/zgy/yamls]# curl 10.244.0.214:8080<head><title>Envoy Admin</title><link rel='shortcut icon' type='image/png' href='data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAABgAAAAYCAYAAADgdz34AAAAAXNSR0IArs4c6QAAAARnQU1BAACxjwv8YQUAAAAJcEhZcwAAEnQAABJ0Ad5mH3gAAAH9SURBVEhL7ZRdTttAFIUrUFaAX5w9gIhgUfzshFRK+gIbaVbAzwaqCly1dSpKk5A485/YCdXpHTB4BsdgVe0bD0cZ3Xsm38yZ8byTUuJ/6g3wqqoBrBhPTzmmLfptMbAzttJTpTKAF2MWC7ADCdNIwXZpvMMwayiIwwS874CcOc9VuQPR1dBBChPMITpFXXU45hukIIH6kHhzVqkEYB8F5HYGvZ5B7EvwmHt9K/59CrU3QbY2RNYaQPYmJc+jPIBICNCcg20ZsAsCPfbcrFlRF+cJZpvXSJt9yMTxO/IAzJrCOfhJXiOgFEX/SbZmezTWxyNk4Q9anHMmjnzAhEyhAW8LCE6wl26J7ZFHH1FMYQxh567weQBOO1AW8D7P/UXAQySq/QvL8Fu9HfCEw4SKALm5BkC3bwjwhSKrA5hYAMXTJnPNiMyRBVzVjcgCyHiSm+8P+WGlnmwtP2RzbCMiQJ0d2KtmmmPorRHEhfMROVfTG5/fYrF5iWXzE80tfy9WPsCqx5Buj7FYH0LvDyHiqd+3otpsr4/fa5+xbEVQPfrYnntylQG5VGeMLBhgEfyE7o6e6qYzwHIjwl0QwXSvvTmrVAY4D5ddvT64wV0jRrr7FekO/XEjwuwwhuw7Ef7NY+dlfXpLb06EtHUJdVbsxvNUqBrwj/QGeEUSfwBAkmWHn5Bb/gAAAABJRU5'/><style>.home-table {........

2.13.3.级联删除和非级联删除

级联删除（Cascading Delete）是指在删除一个父资源对象时，Kubernetes会自动删除与之相关联的子资源对象。例如，如果删除一个命名空间（Namespace），级联删除将同时删除该命名空间中的所有Pod、Service、Deployment等子资源对象。
非级联删除（Non-Cascading Delete）是指在删除一个父资源对象时，Kubernetes只删除该父资源对象本身，而不会自动删除与之相关联的子资源对象。这意味着删除操作只影响到被删除的父资源对象，而不会影响到其他关联的子资源对象。

级联删除：删除deploy，默认会把replicaset和pod全部删除

[root@VM-226-235-tencentos ~/zgy/yamls]# kubectl delete deploy envoy-deployment
deployment.apps "envoy-deployment" deleted
[root@VM-226-235-tencentos ~/zgy/yamls]# kubectl get  pods| grep  envoy-deployment
[root@VM-226-235-tencentos ~/zgy/yamls]# kubectl get  replicaset| grep  envoy-deployment
No resources found in default namespace.

非级联删除：删除deploy，默认会保留replicaset和pod等子资源

[root@VM-226-235-tencentos ~/zgy/yamls]# kubectl delete deploy envoy-deployment --cascade=false
deployment.apps "envoy-deployment" deleted
[root@VM-226-235-tencentos ~/zgy/yamls]# kubectl get pods
NAME                               READY   STATUS             RESTARTS   AGE
clunky-serval-promtail-rcccj       0/1     ImagePullBackOff   0          6h2m
envoy-deployment-555699d88-gr9qq   1/1     Running            0          69s
[root@VM-226-235-tencentos ~/zgy/yamls]# kubectl get replicaset
NAME                         DESIRED   CURRENT   READY   AGE
envoy-deployment-555699d88   1         1         1       77s