可以做软件的网站有哪些功能,亚马逊怎么做网站推广,可以做设计兼职的网站有哪些工作室,wordpress调用文章内容图片前言
Kubernetes 可以理解成一个对计算、网络、存储等云计算资源的抽象后的标准 API 服务。几乎所有对 Kubernetes 的操作#xff0c;不管是用 kubectl 命令行工具#xff0c;还是在UI或者CD Pipeline 中#xff0c;都相当于在调用其 REST API。很多人说 Kubernetes 复杂不管是用 kubectl 命令行工具还是在UI或者CD Pipeline 中都相当于在调用其 REST API。很多人说 Kubernetes 复杂除了其本身实现架构复杂以外还有一个原因就是里面有二十多种原生资源的 API 学起来曲线比较陡。但不用担心我们只要抓住本质 – 提供容器计算能力的平台就能纲举目张很容易快速理解。在 K8S 中最重要也最基础的资源是 Pod翻译一下就是“豆荚”我们用下面这个最最基础的 Nginx 容器为例搞清楚豆荚的一生K8S 就懂了一半。大家也不需要研究 Kubernetes 怎么搭建推荐用 OrbStack 在本地一键安装一套 Docker K8S 环境出来快速开始实验。首先写一段这样的 Yaml 文件出来。
# nginx.yaml
apiVersion: v1
kind: Pod
metadata:name: nginxlabels:app: nginx
spec:containers:- name: webimage: nginxports:- name: webcontainerPort: 80protocol: TCP
然后用 kubectl 将 nginx 的 Pod 进行创建命令后面加 -v8 是详细日志模式可以看出来 kubectl 到底做了什么事情。
kubectl create pod -f nginx.yaml -v8kubectl get pod -v8
在 OpenLens 或 K9S 等可视化工具中我们可以看到一个叫 Nginx 的 Pod 就被”生“出来了从 kubectl 的详细日志中也可以看到 POST/GET 等请求的信息。
I1127 14:55:06.886901 83798 round_trippers.go:463] GET http://127.0.0.1:60649/77046cfbc5f80b52d9a1501954ee0672/api/v1/namespaces/default/pods?limit500
I1127 14:55:06.886916 83798 round_trippers.go:469] Request Headers:
I1127 14:55:06.886921 83798 round_trippers.go:473] User-Agent: kubectl...
I1127 14:55:07.166333 83798 round_trippers.go:580] Cache-Control: no-cache, private
可以看到在创建完成 Pod 之后实际的 Pod 比我们在 Yaml 中声明的字段更多这些多出来的字段就是 Pod 从出生后的经历证明由调度器调度到集群可用节点、交给 kubelet 管理 Pod 生命周期、分配网络IP、挂载临时存储、容器运行时拉取镜像启动容器、控制器协调校正运行状态等等。
apiVersion: v1
kind: Pod
metadata:name: nginxnamespace: default
status:phase: RunninghostIP: 10.....podIP: 10.....conditions:- type: Initializedstatus: TruelastProbeTime: nulllastTransitionTime: 2023-11-27T06:59:13Z- type: Readystatus: TruelastProbeTime: null.....
spec:volumes:- name: kube-api-access-72rkq......containers:- name: webimage: nginxports:- name: webcontainerPort: 80protocol: TCPresources: {}volumeMounts:- name: kube-api-access-72rkqreadOnly: truemountPath: /var/run/secrets/kubernetes.io/serviceaccountterminationMessagePath: /dev/termination-logterminationMessagePolicy: FileimagePullPolicy: AlwaysrestartPolicy: AlwaysterminationGracePeriodSeconds: 30dnsPolicy: ClusterFirstserviceAccountName: defaultserviceAccount: defaultsecurityContext: {}schedulerName: default-schedulertolerations:- key: node.kubernetes.io/not-readyoperator: Existseffect: NoExecutetolerationSeconds: 300- key: node.kubernetes.io/unreachableoperator: Existseffect: NoExecutetolerationSeconds: 300priority: 0enableServiceLinks: truepreemptionPolicy: PreemptLowerPriority
展开来看运行一个容器必要的就是3大件计算、网络、存储。 计算资源就是 CPU/Mem/GPU是在 spec 的 container 部分声明这个案例中没有设置到底需要多少 resourcesrequests 和 resources.limits 为空也就是说可能占满整个宿主机这种情况一般叫 Best-Effort QoS 级别调度优先级是比较低的。 实际情况下一般会设置合理的 requests/limits达到 Burstable QoS 级别或者设置 requests、limits 一模一样达到 Guarantee 级别。这个 Pod 经过调度器调度到某个节点之后就会交给一个叫 CRIContainer Runtime Interface的接口让 CRI 的实现来把容器真正建出来通常是 containerdcri-opodman docker 等等。 网络方面可以看到在 status 里面多出了 PodIP 字段这个是调用底层一个叫 CNIContainer Network Interface的接口让 CNI 的实现层给出的IP这个过程比较复杂涉及到一个叫 pause 容器的东西入门的时候可以忽略这些细节。 存储方面可以看到自动挂载了一个 volume/volumeMounts这是对 Pod 挂载的额外存储可能是配置文件或密钥也可能是挂载一些云厂商提供的持久化存储比如 EBS、EFS 盘则会涉及到 K8S 第三类底层接口CSIContainer Storage Interface我们用的云厂商的 Kubernetes 发行版本一般都已经内置了CSI的实现。 有了计算网络存储Pod 就运行起来了如果我们要更新 Pod可以用 Update Patch 接口但是Pod是一个 Kubernetes 的原子资源只能更新极少数字段比如 image 和 readinessGate。如果想结束掉这个 Pod可以用 Delete 接口来让 Pod 进入 Terminating 状态最终被控制器删除回收掉计算资源容器镜像文件最终也会被 GC 掉。 这里只是讲了最浅显的流程详细的 Pod 生命周期可以参考这里https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/尤其是一些和业务强相关的生命周期活动比如 postStart 并行的启动 hookpreStop 串行的停止 hook发送 SIGTERM 尝试结束进程过了 Graceful Period 后发送 SIGKILL 信号等等对业务很有用。 Kubernetes 集群视角的计算、网络、存储
至此我们明白了计算网络存储资源如何赋予到 Pod 这个载体上。那么计算、网络、存储的资源池本身在 Kubernetes 里叫什么Kubernetes 集群的计算节点叫 Node和传统云平台对硬件机器的定义不同Node 也是抽象的资源可以长出来也可以死掉不和运行哪个容器直接绑定而是通过 label/selectoraffinity 等调度相关的机制关联到 Pod。Kubernetes 集群的块存储资源叫 PersistentVolume实际使用场景下一般是用分布式文件系统来实现根据业务的磁盘请求自动创建 PersistentVolume 的东西叫 StorageClass。 Kubernetes 的网络是分好几层的让整个集群变成一个大内网的 Pod 网络让集群内服务互相访问自带 L4 负载均衡的 Service 网络以及做精细流量治理的 L7 Ingress/GatewayAPI/ServiceMesh 网络。还有控制网络访问策略的 NetworkPolicy 资源。首先我们看 Pod 网络虽然不同 CNI 实现的网络原理差别巨大但目的都是一样的给每个 Pod 分配IP并打通和其他 Pod 之间的路由。比如 AWS 就用了一个很讨巧的方式实现直接给 Pod 分配当前 VPC-Subnet 的二级IPDHCP和路由表都是复用的Pod 之间和现有 EC2 节点之间的通信方式完全一样。再来看作为内部L4负载均衡器的 Service 网络给每个 K8S services 资源分配一个虚拟 IPClusterIP。ClusterIP 分配后kube-proxy 组件负责来实现这个虚拟IP的路由的创建和 Pod Endpoint 变化的实时校正。 还是以 AWS EKS 为例EKS 默认使用的 iptables 模式kube-proxy 会在每个节点上把每个 ClusterIP Service 的 IP 写入 iptables用 iptables 命令可以看到实现细节。 由于每次变更导致的 iptables 修改大规模集群用 K8S 内置的 Service 负载均衡是存在性能问题的切换到 ipvs 模式可以解决 还有一种没有 ClusterIP 的 Headless Service借助 DNS 实现了端点自动发现不是常规的 L4 负载均衡 如果需要直接把某个 Service 暴露到公网去还有 NodePort/LoadBalancer 类型的 Servicekube-proxy 会在集群每个节点 listen NodePort 端口iptables写入 NodePort 对应的 DNAT 规则 LoadBalancer / NodePort类型的Service还有一个关键字段“externalTrafficPolicy”简单理解是跨节点负载均衡模式还是本地节点直连模式跨节点负载均衡还会引起外部 LB 的健康检查失效问题以及内部服务无法获取 Client IP 问题这些都是平台方需要处理好的不需要业务方关心业务团队记住一个原则永远不要用 NodePort Service 就行。 # https://zhuanlan.zhihu.com/p/196393839
iptables -L -n
# Chain OUTPUT (policy ACCEPT)
# target prot opt source destination
# KUBE-PROXY-FIREWALL all -- anywhere anywhere ctstate NEW /* kubernetes load balancer firewall */
# KUBE-SERVICES all -- anywhere anywhere ctstate NEW /* kubernetes service portals */
# KUBE-FIREWALL all -- anywhere anywhere iptables -L -t nat
#Chain KUBE-SVC-TCOU7JCQXEZGVUNU (1 references)
#target prot opt source destination
#KUBE-SEP-HI2KQBDGYW5OVKWN all -- anywhere anywhere /* kube-system/kube-dns:dns - 10.52.xx.xx:53 */ statistic mode random probability 0.50000000000#KUBE-SEP-XQT5TF2PMBOMEGDC all -- anywhere anywhere /* kube-system/kube-dns:dns - 10.52.xx.xx:53 */
最后了解一下L7服务网络一般由类似 Nginx Ingress/Envoy 之类的应用流量负载均衡器提供对于业务来说就当把 nginx conf 拆成一个一个 yaml 片段就好。Ingress 直管南北向流量而 Service Mesh 把东西南边向流量全托管了也能实现一些比 Nginx conf 里面更复杂的行为比如流量加密、鉴权、故障注入、熔断降级、重试等等。
其他原生资源要么是对 Pod 套娃、要么是打辅助的
Kubernetes 的 API 设计非常符合单一职责原则SRPPod 就是一个包容器的单纯的豆荚delete 了就没了。但是你要跑服务怎么办没关系单一职责原则下实现新功能就是一个套娃Kubernetes 抽象了一个叫 Deployment 套住一个叫 ReplicaSet的东西ReplicaSet 再来套住 Pod。这样Deployment 只管变更处理轮换 RSRS 只管保证有 n 个 pod 在跑Pod 没了再生死了重启这里也体现了 Erlang 典型的 let it crash 思维。哪天你说要训练一个AI模型干掉 OpenAIKubernetes 给你提供了一个叫 CronJob和 Job 的抽象CronJob 套住了 JobJob 又套住了 Pod。Job 只管一次性 run 的东西要重试几次跑完多久删 Pod 这些事Cronjob则是一个天然的分布式cron只管定时把 job 这个东西生出来。CronJob 和 Job 广泛用在大数据处理管线、CICD管线AI训练这些领域。OpenAI 也是一个包含 8000 多个节点的巨大Kubernetes 集群训练出来的。哪天你又想用 Kubernetes 运行一个数据库恭喜头铁的你学到了最复杂的一种原生资源StatefulSetdeployment是把豆荚当牲畜想杀就杀StatefulSet 是把Pod 当宠物宠物不好养的每个 Pod 都不能随便动更新的时候只能按序一个一个更新。除了这些对 Pod 套娃的资源剩下的可以理解成打辅助的比如把流量引入集群的Ingress内部流量负载均衡的 Service给每个Pod提供的分布式配置ConfigMap、分布式密钥存储 Secret。还有一些策略控制和资源限额的辅助类这里不一一展开了。
重新思考 Kubernetes 是什么
到这里我们大概搞清楚了 Kubernetes 对于使用者来说意味着什么。从Kubernetes 自身的组件视图来看包括这些东西 每个机器装一个叫 kubelet 的 Agent控制这台机器运行什么 每个机器装一个 kube proxy 的东西用来托管网络防火墙规则并装一个 CNI 的实现控制集群内部的 Pod IP 分配和网络路由 可选的装一个CSI的实现接管持久化存储盘的创建和挂载 这些东西都听 API Server Controller Manager Scheduler 组成的控制中心这套控制中心暴露一套标准的可扩展的 REST API数据全部存到了 ETCD 元数据集群里。让我们操作分布式集群再也不用撸 shell 命令一切命令都 API 化一切资源都变成了 ETCD 的数据记录。 了解了这些也就明白了 Kubernetes 本质上是对现有技术的封装形成了一套云资源操作系统真正干活的还是服务器上的进程而已真正对资源做隔离的还是 cgroup 和 namespace 这些 linux 内核原有的东西。了解了这些也就明白了为什么 Kubernetes 挂了不影响正在跑的服务为什么在Kubernetes 集群做应用性能调优还是去看 EC2 用什么 instance typePV存储是哪一代的 EBS、EFS还是去看 Subnet 内核 VPC 之间怎么优化 RTT 延迟和提升带宽Kubernetes 包含了分布式集群的一切Kubernetes 又一无所有。
Kubernetes 的 A/B 面 Kubernetes 带来的最大的几个好处分别是标准化、弹性、可扩展。REST API 带来的管理界面完全标准化存个 ETCD 记录就创建或校正资源状态带来了极致弹性扩缩容就在弹指之间。开发一个自定义资源就实现任意功能带来了丰富的可扩展性演化出庞大的 CloudNative 生态系统。既要又要还要标准弹性可扩展都有了看起来很完美但任何事物都有两面Kubernetes 的这些好处也是坏处的根源。标准化的暗面是复杂化。标准要考虑到所有情况所以这个标准不可能简单仅仅是一个Pod的spec就有几十个字段可能一小半字段大部分人都没有见过。Kubernetes 学透的难度和自建运维难度从培训考证机构可见一斑。即使是大公司也最好不要有自建 Kubernetes 的念头Kubernetes 自己的几个组件每个都有上百个启动参数要么是不懂坑有多大的年轻人要么是假装整明白的人要么是身在云厂商里面真正懂的人。弹性的暗面是易失性连集群的 Node 能随时长出、随时消逝带来了对应用架构的侵入在 Kubernetes 中运行的有状态服务必须具备动态发现的能力想在代码中配置静态IP的时代结束了。我还发现一个 Kubernetes 带来的效应”日志丢失焦虑“在VM上大概没有人会担心日志没采集到Kubernetes上Pod飘来飘去总有人问服务挂掉前的最后一行日志怎么采的采不到怎么办可扩展的暗面是良莠不齐在CNCF Landscape和开源社区的并不是都是优秀的产品甚至有些问题很大的东西也流行起来。比如之前团队有位同事仔细读过 Clickhouse operator 代码这个1.5K star的项目代码质量可能在及格线以下。4年前和另一位同事尝试用 ES Operator 和 Kafka Helm Chart 来运维 ES/Kafka当时成熟度还远没有达到生产可用的水平。另外Helm 这个 Kubernetes 最流行的包管理工具也是”worse is better“的典型代表Helm 作者哲学家 Matt Butcher 提出 OAM 思想后自己去搞”下一代云计算”WASM生态去了
