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

十念 · 2025-2-12 23:45:55

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

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 字段可以启用进程命名空间共享
  1. apiVersion: v1
  2. kind: Pod
  3. metadata:
  4. name: nginx
  5. spec:
  6. shareProcessNamespace: true
  7. containers:
  8. - name: nginx
  9. image: nginx
  10. - name: shell
  11. image: busybox:1.28
  12. command: ["sleep", "3600"]
  13. securityContext:
  14. capabilities:
  15. add:
  16. - SYS_PTRACE
  17. stdin: true
  18. 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一下试试
1. # 首先使用kubectl get pods -owide找到podIp
2. [root@VM-226-235-tencentos ~/zgy/yamls]# kubectl get pods -owide
3. NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
4. envoy-deployment-555699d88-bmxxx 1/1 Running 0 13m 10.244.0.214 vm-226-235-tencentos <none> <none>
6. # 然后curl一下指定端口
7. [root@VM-226-235-tencentos ~/zgy/yamls]# curl 10.244.0.214:8080
8. curl: (7) Failed connect to 10.244.0.214:8080; Connection refused
10. # [root@VM-226-235-tencentos ~/zgy/yamls]# curl 10.244.0.214:9901
12. <head>
13. <title>Envoy Admin</title>
14. <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'/>
15. <style>
16. .home-table {
17. ........
18. ```
复制代码
我们接下来外挂存储的时间正好测试一下把端口修改为8080，和pod的containerPort保持一致

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

创建一个configMap
1. apiVersion: v1
2. kind: ConfigMap
3. metadata:
4. name: envoy-config
5. data:
6. envoy.yaml: |
7. admin:
8. address:
9. socket_address:
10. protocol: TCP
11. address: 0.0.0.0
12. port_value: 8080
13. static_resources:
14. listeners:
15. - name: listener_0
16. address:
17. socket_address:
18. protocol: TCP
19. address: 0.0.0.0
20. port_value: 10000
21. filter_chains:
22. - filters:
23. - name: envoy.filters.network.http_connection_manager
24. typed_config:
25. "@type": type.googleapis.com/envoy.extensions.filters.network.http_connection_manager.v3.HttpConnectionManager
26. scheme_header_transformation:
27. scheme_to_overwrite: https
28. stat_prefix: ingress_http
29. route_config:
30. name: local_route
31. virtual_hosts:
32. - name: local_service
33. domains: ["*"]
34. routes:
35. - match:
36. prefix: "/"
37. route:
38. host_rewrite_literal: www.envoyproxy.io
39. cluster: service_envoyproxy_io
40. http_filters:
41. - name: envoy.filters.http.router
42. clusters:
43. - name: service_envoyproxy_io
44. connect_timeout: 30s
45. type: LOGICAL_DNS
46. dns_lookup_family: V4_ONLY
47. lb_policy: ROUND_ROBIN
48. load_assignment:
49. cluster_name: service_envoyproxy_io
50. endpoints:
51. - lb_endpoints:
52. - endpoint:
53. address:
54. socket_address:
55. address: www.envoyproxy.io
56. port_value: 443
57. transport_socket:
58. name: envoy.transport_sockets.tls
59. typed_config:
60. "@type": type.googleapis.com/envoy.extensions.transport_sockets.tls.v3.UpstreamTlsContext
61. sni: www.envoyproxy.io
复制代码
将configmap mount到deploy中
1. apiVersion: apps/v1
2. kind: Deployment
3. metadata:
4. name: envoy-deployment
5. spec:
6. replicas: 1
7. selector:
8. matchLabels:
9. app: envoy
10. template:
11. metadata:
12. labels:
13. app: envoy
14. spec:
15. containers:
16. - name: envoy
17. image: envoyproxy/envoy:v1.19.1
18. ports:
19. - containerPort: 8080
20. volumeMounts:
21. - name: envoy-data
22. mountPath: /data
23. - name: envoy-config-volume
24. mountPath: /etc/envoy
25. volumes:
26. - name: envoy-data
27. persistentVolumeClaim:
28. claimName: envoy-pvc
29. - name: envoy-config-volume
30. configMap:
31. name: envoy-config
复制代码
yaml准备好后，apply到环境中
1. kubectl apply -f cm.yaml
2. kubectl apply -f deploy.yaml
复制代码
进入pod内部，查看/etc/envoy/envoy.yaml，可以看到已经挂载上来了
1. root@envoy-deployment-555699d88-bmxxx:/# ls /etc/envoy
2. envoy.yaml
复制代码
重新获取podip，然后curl一下8080，可以看到监听端口已经换成8080了
1. # [root@VM-226-235-tencentos ~/zgy/yamls]# curl 10.244.0.214:8080
3. <head>
4. <title>Envoy Admin</title>
5. <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'/>
6. <style>
7. .home-table {
8. ........
复制代码

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

级联删除（Cascading Delete）是指在删除一个父资源对象时，Kubernetes会自动删除与之相关联的子资源对象。例如，假如删除一个命名空间（Namespace），级联删除将同时删除该命名空间中的全部Pod、Service、Deployment等子资源对象。
非级联删除（Non-Cascading Delete）是指在删除一个父资源对象时，Kubernetes只删除该父资源对象本身，而不会自动删除与之相关联的子资源对象。这意味着删除操纵只影响到被删除的父资源对象，而不会影响到其他关联的子资源对象。
级联删除：删除deploy，默认会把replicaset和pod全部删除
1. [root@VM-226-235-tencentos ~/zgy/yamls]# kubectl delete deploy envoy-deployment
2. deployment.apps "envoy-deployment" deleted
3. [root@VM-226-235-tencentos ~/zgy/yamls]# kubectl get pods| grep envoy-deployment
4. [root@VM-226-235-tencentos ~/zgy/yamls]# kubectl get replicaset| grep envoy-deployment
5. No resources found in default namespace.
复制代码
非级联删除：删除deploy，默认会保留replicaset和pod等子资源
1. [root@VM-226-235-tencentos ~/zgy/yamls]# kubectl delete deploy envoy-deployment --cascade=false
2. deployment.apps "envoy-deployment" deleted
3. [root@VM-226-235-tencentos ~/zgy/yamls]# kubectl get pods
4. NAME READY STATUS RESTARTS AGE
5. clunky-serval-promtail-rcccj 0/1 ImagePullBackOff 0 6h2m
6. envoy-deployment-555699d88-gr9qq 1/1 Running 0 69s
7. [root@VM-226-235-tencentos ~/zgy/yamls]# kubectl get replicaset
8. NAME DESIRED CURRENT READY AGE
9. envoy-deployment-555699d88 1 1 1 77s
复制代码

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。

		自动登录	找回密码
密码			立即注册

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

本帖子中包含更多资源

0 个回复

快速回复

楼主热帖

标签云