Kubernetes架构原则和对象计划（三）
云原生学习路线导航页（持续更新中）[*]kubernetes学习系列快捷链接
[*]Kubernetes架构原则和对象计划（一）
[*]Kubernetes架构原则和对象计划（二）
[*]Kubernetes常见问题解答
本文主要对kubernetes的核心技术概念和核心API进行先容，深入理解kubernetes对象计划原则
1.Kubernetes核心技术概念
1.1.Kubernetes API对象属性
https://i-blog.csdnimg.cn/direct/1313c0e3decb420bae171057174f0e7b.png
[*]kubernetes对象，是其计划最牛的地方。kubernetes诞生时，要和openStack、docker等技术争取天下，项目是很难推进的，因此谷歌做了两件事：
[*]基于强大的borg系统
[*]通过界说API规范，将自己做成业界规范。因此kubernetes将云盘算领域全部的对象 ，都纳入其管控范围
[*]kubernetes为什么要界说规范？
[*]kubernetes把 盘算节点应该如何、作业应该如何、服务应该如何、入栈流量应该如何、防火墙规则应该如何 等等，都定成标准和规范，自己专注于API层，就把自己的行业地位固化住了。
[*]其他公司可以 对kubernetes的API进行各种实现，这就相称于加入了kubernetes生态，拉着全世界全部的云盘算公司站队kubernetes。
[*]规范强大起来后，其他公司在自己另起炉灶的意义就不大了，就逐渐都复用这个完善的规范了。
[*]一个kubernetes对象，一般包含4个部门：
[*]TypeMeta：界说对象是什么
[*]Metadata：界说对象元数据，如 名字、标签、基本属性等
[*]Spec：对象的盼望终态
[*]Status：对象的实时状态
1.2.TypeMeta
https://i-blog.csdnimg.cn/direct/452cefbb66de49029a718614e887de77.png
[*]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
https://i-blog.csdnimg.cn/direct/9243932690f74638a190983695ec0eab.png
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：标签
https://i-blog.csdnimg.cn/direct/93bae748be3a4f9c9fdbaab954374a00.png
[*]label：标签，mapstring，一般用于filter查询过滤
[*]好比 kubectl get ns -l a=b
https://i-blog.csdnimg.cn/direct/9e03888a312b4a6c90a918223fe71bac.png
[*]label的使用场景
[*]好比说现在做资本控制，每个 作业或应用 都要规定好属于哪个业务部门，这叫资本分配，最终要去统计资源使用率的时间，就知道 a部门到底产生了哪些 作业或应用，最后公司财务再去review，审查每一个应用的财务开销。
[*]这个例子中，作业或应用就可以打上 特定的label，用于标识 属于哪个业务部门
1.3.4.annotation：注解
https://i-blog.csdnimg.cn/direct/67397119405444f994a069236b9f36fe.png
[*]annotation，mapstring，一般用于扩展对象功能
[*]当你以为kubernetes对象里面的属性不太够用，但是改动CRD的动作太大（涉及到CRD升级回滚各种风险），此时就可以做一些附加属性写到annotation
[*]annotation的key命名有一些不成文的规范：项目域名/功能名。好比：flannel.alpha.coreos.com/backend-type
1.3.5.Finalizer：对象终止器，资源锁
https://i-blog.csdnimg.cn/direct/b9d818d0d0cb49978f8756dcfa85028a.png
[*]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：用于版本控制的 分布式乐观锁
https://i-blog.csdnimg.cn/direct/7dd700f70f774f368ee5a8c6e39c82ad.png
[*]ResourceVersion：用于版本控制的 分布式乐观锁
[*]在分布式系统里，一般一个对象会被多个控制器管理，为了制止多个线程读写同一个对象所造成的资源冲突，就必要加锁。
[*]可是加锁可能会带来一系列问题：线程饥饿、死锁等，因此就选择了版本控制的乐观锁方式。
[*]当发生对象写操纵时，apiserver会查看提交数据的ResourceVersion，假如<当前版本，阐明该资源是根据较旧的版本更改的，拒绝本次更新，并返回一个409(“Conflict”)给写进程。写进程吸收到后就知道发生了并发冲突，就必要根据最新数据处理后再提交
1.4.Spec和Status
https://i-blog.csdnimg.cn/direct/286d211d45ce433ab5bb14edb2a7fb82.png
[*]Spec 和 Status 根据必要界说，好比 Namespace资源 的Spec就是空的，因为它不必要界说什么，它只是一个目次。而Namespace的Status也只是表示其状态为 active 还是 terminating 等
[*]不过我们查看Namespace时，会看到在spec中有个finalizers，这应该算是历史遗留问题。早期Namespace Controller通过.spec.finalizers包管在删除ns时，能够先把ns下全部的资源都清理掉
[*]现在 在通用属性Metadata中也包括finalizer了，实在可以重构一下
https://i-blog.csdnimg.cn/direct/848e30f4954a4d01a015ec063a4ea70e.png
2.Kubernetes 常用API对象
这里只枚举一些最常用的API对象，更详细的学习和深入，直接去看官方文档就好
2.1.Kubernetes常用API对象及其分组
https://i-blog.csdnimg.cn/direct/76c9020467364ea29d4676c8026bf7e7.png
[*]核心对象core：基本上是能够满足一个应用的最小聚集
[*]随着一个对象的迭代和成熟度，可能会被分别到差别的group中，好比deployment以前就是属于extensions/v1beta1，现在分别到apps/v1了
2.2.Pod：Kubernetes调度的基本单位
2.2.1.Pod基本先容
https://i-blog.csdnimg.cn/direct/2c13414ee64749c68062d3db94ca29de.png
[*]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种。
https://i-blog.csdnimg.cn/direct/37cd04f8119a4a06b259345bdd5b21cf.png
[*]ConfigMap 和 Secret
[*]configmap是Kubernetes用于保存应用设置的对象，内容是明文保存。
[*]configmap的布局由 TypeMeta、Metadata、Data（mapstring） 等属性组成，它不包含Spec，或者说data就是它的spec。
[*]secret和configmap 布局一样，不过它是加密的
2.2.2.2.Pod中外挂存储卷设置
https://i-blog.csdnimg.cn/direct/5f2a4ef835a04b5f88d2636d1a6019f9.png
[*]之前在讲Docker的时间，使用 docker run -v 命令时有挂载过外部存储到容器中。kubernetes中也是一样的，好比界说一个Pod，也可以为Pod中的容器挂载存储。
[*]存储卷使用分为两部门：声明卷、挂载卷
[*]声明卷Volume：卷名称、卷范例，表明卷的数据来源
[*]挂载卷VolumeMount：卷名称、挂载到哪个目次
2.2.3.Pod网络
https://i-blog.csdnimg.cn/direct/260bc9f043184056aa6e4cb0834e6628.png
2.2.4.Pod资源限定
https://i-blog.csdnimg.cn/direct/1cdfae39f1e644dc86c8d0710befffe8.png
[*]如何查看 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康健查抄
https://i-blog.csdnimg.cn/direct/908b45c8396146f2be99110e6b94e9be.png
[*] 康健探针官方文档 官方文档写的很普通，建议这块直接看文档
https://i-blog.csdnimg.cn/direct/b2009982085743a6a69ad3e671519b53.png
[*] Deployment 滚动升级设置 MaxUnavailable 和 MaxSurge
[*]MaxUnavailable：最大不可用pod数目，即无法正常提供服务的pod数目，假如达到了这个阈值，滚动升级是要停息的
[*]MaxSurge：pod总数目可以超过 .spec.replicas 多少
[*] Pod 字段 .status.ready
[*]Pod中有一个字段 .status.ready，代表这个pod是否完全准备好对外提供服务了
[*]service做负载均衡 流量转发的时间，默认不会把没 Ready 的pod加入负载列表
https://i-blog.csdnimg.cn/direct/47601ea0688744eeb6a92774e885699f.png
[*] Pod 的有3种康健探测方式
[*]LivenessProbe：存活探针，判断应用是否还存活，不存活则杀死
[*]ReadinessProbe：就绪探针，判断应用是否就绪，没有就绪则不应该吸收流量，pod会体现为NotReady，但不会杀死或重启pod
[*]StartupProbe：启动探针，判断应用是否启动完成
[*]设置了StartupProbe时，LivenessProbe和ReadinessProbe 会在StartupProbe乐成后才生效。
[*]我们可以为StartupProbe设置较低的探测频率，包管慢启动应用的 数据库、端口、缓存预热 等依赖加载的过程中，不会太频仍的探测造成应用压力，也不会在启动时就被LivenessProbe和ReadinessProbe判断为失败
[*] 康健探测的一些设置
https://i-blog.csdnimg.cn/direct/425676232d334b56860e44b807718c8e.png
[*]periodSeconds：每次探测的隔断时间。periodSeconds要合理，太短会加大应用压力，太长会较慢发现故障
[*] Pod 的3种探活方式
[*]Exec：去这个容器里面实验一个命令，命令返回非0则失败，返回0则乐成
[*]下面就是 cat一个文件，假如文件存在则探测乐成，文件不存在肯定会报错
https://i-blog.csdnimg.cn/direct/55bd4e9a88e74575af31d2cabd98a8fb.png
[*]TCP socket：由kubelet发起对 指定host+port的端口连通性查抄
[*]HTTP：由kubelet发起一条真正的http请求，容器化应用开发时一般都会预留一个端口用于http的康健查抄
2.2.6.Pod的设置：ConfigMap、Secret
https://i-blog.csdnimg.cn/direct/ee7be70a1b6641b1a823db849e96dba8.png
https://i-blog.csdnimg.cn/direct/12fe14deda914c3dac8e3f0c3020b89a.png
2.3.用户UserAccount 和 服务账户ServiceAccount
https://i-blog.csdnimg.cn/direct/a90ad5c67534491596876a5916be8306.png
[*]当一个组件要跟 API Server 通信的时间，要做认证健全，就一定要有个身份，以是任何的 Kubernetes pod 都必要以一个 service account的身份运行
[*]这个Service Account会以一个volume的形式，被mount到一个Pod里面，里面的应用就可以读取这个service account 所对应的 TOKEN 或 ca证书文件 来跟API Server通信。
2.4.负载均衡Service
https://i-blog.csdnimg.cn/direct/bee8a7cccee14929a0838bd5d39320df.png
[*]下面举例Service
[*]clusterIp：为service分配的集群内ip，集群外无法访问
[*]ipFamilies：界说service的ip协议栈是 IPv4
[*]ipFamilypolicy：协议栈范例为单栈
[*]详细的设置访问可以看官方文档：IPv4/IPv6 双协议栈
[*]ports：后端业务的访问信息
[*]selector：label选择器，选择service要管理哪些pod
https://i-blog.csdnimg.cn/direct/00a4d45434d346cc82f2442acb33bd8d.png
2.5.副本集ReplicaSet
https://i-blog.csdnimg.cn/direct/bf33aefa446349a890ac95dc318f5d8e.png
2.6.摆设 Deployment
https://i-blog.csdnimg.cn/direct/794ba9fcd0e64c968dae18f16a95f47d.png
2.7.Deployment 和 Service 练习
https://i-blog.csdnimg.cn/direct/030b84194ed4453f8feb4809db1ac73d.png
2.8.有状态服务集 Statefulset
https://i-blog.csdnimg.cn/direct/5a399d8de20743ebba45ec565423dafd.png
[*] Statefulset 和 Deployment 的差异
https://i-blog.csdnimg.cn/direct/a7a3d9c242914a85ad4ea80cc6f7b118.png
[*]名称规则差别：
[*]Statefulset：创建的多副本，名称是固定的，按照数字序号递增
[*]Deployment：创建的多副本，名字比力长：deployment名称-podTemplate哈希值-随机字符串
[*]创建/更新次序差别
[*]Statefulset：创建是从小号–>大号，更新和删除是从大号–>小号。此中升级的时间支持滚动升级、分片升级、OnDelete升级
[*]Deployment：创建/更新/删除 都是随机的。
[*]Pod举动差别
[*]Statefulset：因为名称是固定的，以是每个pod都是独立的个体，可以为它们声明差别的volume，当pod发生重建后可以关联旧的volume继承数据
[*]Deployment：因为名称是随机的，以是每个pod无法做到独立个体，pod发生重建后名称就改变了，不太方便做到继承旧数据
2.9.任务 Job
https://i-blog.csdnimg.cn/direct/c9071fe0572746b49919d76eddcf650d.png
[*]Deployment、Statefulset都是 Running 长时任务，偶然另有一些 Short 短时任务，Kuberenetes提供了Job资源范例用于短时任务，Job完成之后是completed状态，结束后不会再被拉起
2.10.背景支撑服务集 DaemonSet
https://i-blog.csdnimg.cn/direct/e8fb67def102420c9692d78d40fe7f32.png
2.11.存储PV和PVC
https://i-blog.csdnimg.cn/direct/dc2e31996d6442979a3f1651b2405aa2.png
[*]无论存储来自于本地还是网络，都可以通过PV和PVC去挂载
2.12.CRD：CustomResourceDefinition
https://i-blog.csdnimg.cn/direct/a23c4a32200c428eba56b5ccc8e3ff94.png
[*]CRD可以理解为数据库的开放式表，当基本对象没有办法支撑你的需求时，可以通过CRD的这种对象扩展一个当前业务。
[*]好比：Calico，现在开源的最成熟的纯三层网络框架之一，它实在就依赖于一堆CRD
[*]现在全部围绕着Kubernetes的大的生态项目基本都有自己的CRD和控制器，无论是运维还是开发最后都会涉及到有CRD
2.13.课后练习
https://i-blog.csdnimg.cn/direct/639aa885c13741b7b20e867d2697de5c.png
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即可
# kubectl apply -f envoy.yaml
# 查看创建好的pv、pvc、deploy
# kubectl get pvc
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE
envoy-pvc Bound envoy-pv 10Gi RWO local-storage 12m
# 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
# kubectl get deploy
NAME READY UP-TO-DATE AVAILABLE AGE
envoy-deployment 1/1 1 1 22m
# 进入pod内部
# kubectl exec -itenvoy-deployment-68cd599779-4chjj -- /bin/bash
# 可以看到1号进程即为envoy进程，命令中指定的了config文件路径
root@envoy-deployment-68cd599779-4chjj:/# ps -ef
UID PIDPPIDC STIME TTY TIME CMD
envoy 1 00 13:41 ? 00:00:01 envoy -c /etc/envoy/envoy.yaml
root 104 00 13:52 pts/0 00:00:00 /bin/bash
root 114 1040 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
# 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一下指定端口
# curl 10.244.0.214:8080
curl: (7) Failed connect to 10.244.0.214:8080; Connection refused
# # 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了
# # 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全部删除
# kubectl delete deploy envoy-deployment
deployment.apps "envoy-deployment" deleted
# kubectl getpods| grepenvoy-deployment
# kubectl getreplicaset| grepenvoy-deployment
No resources found in default namespace.
[*] 非级联删除：删除deploy，默认会保留replicaset和pod等子资源
# kubectl delete deploy envoy-deployment --cascade=false
deployment.apps "envoy-deployment" deleted
# 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
# kubectl get replicaset
NAME DESIRED CURRENT READY AGE
envoy-deployment-555699d88 1 1 1 77s
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。
页:
[1]