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: true
      containers:
      - name: nginx
        image: nginx
      - name: shell
        image: busybox:1.28
        command: ["sleep", "3600"]
        securityContext:
          capabilities:
            add:
            - SYS_PTRACE
        stdin: true
        tty: 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-storage
  capacity:
    storage: 10Gi
  accessModes:
    - ReadWriteOnce
  hostPath:
    path: /data

---

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: envoy-pvc
spec:
  storageClassName: local-storage
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 10Gi

---

apiVersion: apps/v1
kind: Deployment
metadata:
  name: envoy-deployment
spec:
  replicas: 1
  selector:
    matchLabels:
      app: envoy
  template:
    metadata:
      labels:
        app: envoy
    spec:
      containers:
        - name: envoy
          image: envoyproxy/envoy:v1.19.1
          ports:
            - containerPort: 8080
          volumeMounts:
            - name: envoy-data
              mountPath: /data
      volumes:
        - name: envoy-data
          persistentVolumeClaim:
            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: TCP
      address: 0.0.0.0
      # envoy 的 监听端口
      port_value: 9901
static_resources:
  listeners:
  - name: listener_0
    address:
      socket_address:
        protocol: TCP
        address: 0.0.0.0
        port_value: 10000
    filter_chains:
    - filters:
      - name: envoy.filters.network.http_connection_manager
        typed_config:
          "@type": type.googleapis.com/envoy.extensions.filters.network.http_connection_manager.v3.HttpConnectionManager
          scheme_header_transformation:
            scheme_to_overwrite: https
          stat_prefix: ingress_http
          route_config:
            name: local_route
            virtual_hosts:
            - name: local_service
              domains: ["*"]
              routes:
              - match:
                  prefix: "/"
                route:
                  host_rewrite_literal: www.envoyproxy.io
                  cluster: service_envoyproxy_io
          http_filters:
          - name: envoy.filters.http.router
  clusters:
  - name: service_envoyproxy_io
    connect_timeout: 30s
    type: LOGICAL_DNS
    # Comment out the following line to test on v6 networks
    dns_lookup_family: V4_ONLY
    lb_policy: ROUND_ROBIN
    load_assignment:
      cluster_name: service_envoyproxy_io
      endpoints:
      - lb_endpoints:
        - endpoint:
            address:
              socket_address:
                address: www.envoyproxy.io
                port_value: 443
    transport_socket:
      name: envoy.transport_sockets.tls
      typed_config:
        "@type": type.googleapis.com/envoy.extensions.transport_sockets.tls.v3.UpstreamTlsContext
        sni: 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: TCP
            address: 0.0.0.0
            port_value: 8080
      static_resources:
        listeners:
        - name: listener_0
          address:
            socket_address:
              protocol: TCP
              address: 0.0.0.0
              port_value: 10000
          filter_chains:
          - filters:
            - name: envoy.filters.network.http_connection_manager
              typed_config:
                "@type": type.googleapis.com/envoy.extensions.filters.network.http_connection_manager.v3.HttpConnectionManager
                scheme_header_transformation:
                  scheme_to_overwrite: https
                stat_prefix: ingress_http
                route_config:
                  name: local_route
                  virtual_hosts:
                  - name: local_service
                    domains: ["*"]
                    routes:
                    - match:
                        prefix: "/"
                      route:
                        host_rewrite_literal: www.envoyproxy.io
                        cluster: service_envoyproxy_io
                http_filters:
                - name: envoy.filters.http.router
        clusters:
        - name: service_envoyproxy_io
          connect_timeout: 30s
          type: LOGICAL_DNS
          dns_lookup_family: V4_ONLY
          lb_policy: ROUND_ROBIN
          load_assignment:
            cluster_name: service_envoyproxy_io
            endpoints:
            - lb_endpoints:
              - endpoint:
                  address:
                    socket_address:
                      address: www.envoyproxy.io
                      port_value: 443
          transport_socket:
            name: envoy.transport_sockets.tls
            typed_config:
              "@type": type.googleapis.com/envoy.extensions.transport_sockets.tls.v3.UpstreamTlsContext
              sni: www.envoyproxy.io
  

• 将configmap mount到deploy中

  apiVersion: apps/v1
    kind: Deployment
    metadata:
      name: envoy-deployment
    spec:
      replicas: 1
      selector:
        matchLabels:
          app: envoy
      template:
        metadata:
          labels:
            app: envoy
        spec:
          containers:
            - name: envoy
              image: envoyproxy/envoy:v1.19.1
              ports:
                - containerPort: 8080
              volumeMounts:
                - name: envoy-data
                  mountPath: /data
                - name: envoy-config-volume
                  mountPath: /etc/envoy
          volumes:
            - name: envoy-data
              persistentVolumeClaim:
                claimName: envoy-pvc
            - name: envoy-config-volume
              configMap:
                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