【重识云原生】第六章容器基础6.4.10.5节——Statefulset原理剖析
《重识云原生系列》专题索引:
- 第一章——不谋全局不足以谋一域
- 第二章计算第1节——计算虚拟化技术总述
- 第二章计算第2节——主流虚拟化技术之VMare ESXi
- 第二章计算第3节——主流虚拟化技术之Xen
- 第二章计算第4节——主流虚拟化技术之KVM
- 第二章计算第5节——商用云主机方案
- 第二章计算第6节——裸金属方案
- 第三章云存储第1节——分布式云存储总述
- 第三章云存储第2节——SPDK方案综述
- 第三章云存储第3节——Ceph统一存储方案
- 第三章云存储第4节——OpenStack Swift 对象存储方案
- 第三章云存储第5节——商用分布式云存储方案
- 第四章云网络第一节——云网络技术发展简述
- 第四章云网络4.2节——相关基础知识准备
- 第四章云网络4.3节——重要网络协议
- 第四章云网络4.3.1节——路由技术简述
- 第四章云网络4.3.2节——VLAN技术
- 第四章云网络4.3.3节——RIP协议
- 第四章云网络4.3.4节——OSPF协议
- 第四章云网络4.3.5节——EIGRP协议
- 第四章云网络4.3.6节——IS-IS协议
- 第四章云网络4.3.7节——BGP协议
- 第四章云网络4.3.7.2节——BGP协议概述
- 第四章云网络4.3.7.3节——BGP协议实现原理
- 第四章云网络4.3.7.4节——高级特性
- 第四章云网络4.3.7.5节——实操
- 第四章云网络4.3.7.6节——MP-BGP协议
- 第四章云网络4.3.8节——策略路由
- 第四章云网络4.3.9节——Graceful Restart(平滑重启)技术
- 第四章云网络4.3.10节——VXLAN技术
- 第四章云网络4.3.10.2节——VXLAN Overlay网络方案设计
- 第四章云网络4.3.10.3节——VXLAN隧道机制
- 第四章云网络4.3.10.4节——VXLAN报文转发过程
- 第四章云网络4.3.10.5节——VXlan组网架构
- 第四章云网络4.3.10.6节——VXLAN应用部署方案
- 第四章云网络4.4节——Spine-Leaf网络架构
- 第四章云网络4.5节——大二层网络
- 第四章云网络4.6节——Underlay 和 Overlay概念
- 第四章云网络4.7.1节——网络虚拟化与卸载加速技术的演进简述
- 第四章云网络4.7.2节——virtio网络半虚拟化简介
- 第四章云网络4.7.3节——Vhost-net方案
- 第四章云网络4.7.4节vhost-user方案——virtio的DPDK卸载方案
- 第四章云网络4.7.5节vDPA方案——virtio的半硬件虚拟化实现
- 第四章云网络4.7.6节——virtio-blk存储虚拟化方案
- 第四章云网络4.7.8节——SR-IOV方案
- 第四章云网络4.7.9节——NFV
- 第四章云网络4.8.1节——SDN总述
- 第四章云网络4.8.2.1节——OpenFlow概述
- 第四章云网络4.8.2.2节——OpenFlow协议详解
- 第四章云网络4.8.2.3节——OpenFlow运行机制
- 第四章云网络4.8.3.1节——Open vSwitch简介
- 第四章云网络4.8.3.2节——Open vSwitch工作原理详解
- 第四章云网络4.8.4节——OpenStack与SDN的集成
- 第四章云网络4.8.5节——OpenDayLight
- 第四章云网络4.8.6节——Dragonflow
第四章云网络4.9.1节——网络卸载加速技术综述
第四章云网络4.9.2节——传统网络卸载技术
第四章云网络4.9.3.1节——DPDK技术综述
第四章云网络4.9.3.2节——DPDK原理详解
第四章云网络4.9.4.1节——智能网卡SmartNIC方案综述
第四章云网络4.9.4.2节——智能网卡实现
第六章容器6.1.1节——容器综述
第六章容器6.1.2节——容器安装部署
第六章容器6.1.3节——Docker常用命令
第六章容器6.1.4节——Docker核心技术LXC
第六章容器6.1.5节——Docker核心技术Namespace
第六章容器6.1.6节—— Docker核心技术Chroot
第六章容器6.1.7.1节——Docker核心技术cgroups综述
第六章容器6.1.7.2节——cgroups原理剖析
第六章容器6.1.7.3节——cgroups数据结构剖析
第六章容器6.1.7.4节——cgroups使用
第六章容器6.1.8节——Docker核心技术UnionFS
第六章容器6.1.9节——Docker镜像技术剖析
第六章容器6.1.10节——DockerFile解析
第六章容器6.1.11节——docker-compose容器编排
第六章容器6.1.12节——Docker网络模型设计
第六章容器6.2.1节——Kubernetes概述
第六章容器6.2.2节——K8S架构剖析
第六章容器6.3.1节——K8S核心组件总述
第六章容器6.3.2节——API Server组件
第六章容器6.3.3节——Kube-Scheduler使用篇
第六章容器6.3.4节——etcd组件
第六章容器6.3.5节——Controller Manager概述
第六章容器6.3.6节——kubelet组件
第六章容器6.3.7节——命令行工具kubectl
第六章容器6.3.8节——kube-proxy
第六章容器6.4.1节——K8S资源对象总览
第六章容器6.4.2.1节——pod详解
第六章容器6.4.2.2节——Pod使用(上)
第六章容器6.4.2.3节——Pod使用(下)
第六章容器6.4.3节——ReplicationController
第六章容器6.4.4节——ReplicaSet组件
第六章容器基础6.4.5.1节——Deployment概述
第六章容器基础6.4.5.2节——Deployment配置详细说明
第六章容器基础6.4.5.3节——Deployment实现原理解析
第六章容器基础6.4.6节——Daemonset
第六章容器基础6.4.7节——Job
第六章容器基础6.4.8节——CronJob
1 StatefulSet工作原理剖析
1.1 工作原理简述
首先,StatefulSet 的控制器直接管理的是 Pod。这是因为,StatefulSet 里的不同 Pod 实例,不再像 ReplicaSet 中那样都是完全一样的,而是有了细微区别的。比如,每个 Pod 的 hostname、名字等都是不同的、携带了编号的。而 StatefulSet 区分这些实例的方式,就是通过在 Pod 的名字里加上事先约定好的编号。
其次,Kubernetes 通过 Headless Service,为这些有编号的 Pod,在 DNS 服务器中生成带有同样编号的 DNS 记录。只要 StatefulSet 能够保证这些 Pod 名字里的编号不变,那么 Service 里类似于 web-0.nginx.default.svc.cluster.local 这样的 DNS 记录也就不会变,而这条记录解析出来的 Pod 的 IP 地址,则会随着后端 Pod 的删除和再创建而自动更新。这当然是 Service 机制本身的能力,不需要 StatefulSet 操心。
最后,StatefulSet 还为每一个 Pod 分配并创建一个同样编号的 PVC。这样,Kubernetes 就可以通过 Persistent Volume 机制为这个 PVC 绑定上对应的 PV,从而保证了每一个 Pod 都拥有一个独立的 Volume。在这种情况下,即使 Pod 被删除,它所对应的 PVC 和 PV 依然会保留下来。所以当这个 Pod 被重新创建出来之后,Kubernetes 会为它找到同样编号的 PVC,挂载这个 PVC 对应的 Volume,从而获取到以前保存在 Volume 里的数据。
从上面内容可以看出,管理有状态应用 Pod 的关键是提供稳定不变的 Pod 标识和稳定不变的存储。
1.2 拓扑状态实现
1.2.1 稳定不变的拓扑状态
StatefulSet 中Pod标识和 Pod是绑定的,不管 Pod 被调度到哪个节点上,每个 Pod 将被分配一个整数序号,从 0 到 N-1,该序号在 StatefulSet 上是唯一的。
每个 Pod 根据 StatefulSet 的名称和 Pod 的序号派生出它的主机名。组合主机名的格式为 (StatefulSet名称)(序号);例如StatefulSet 名称为 web,replicas 为 3,那么将会创建三个名称分别为 web-0、web-1、web-2 的 Pod。一旦每个 Pod 创建成功,就会得到一个匹配的 DNS 名称,格式为:. ..svc.cluster.local,其中 service-name 由 StatefulSet 的 serviceName 域来设定;并且这些 Pod 的创建,是严格按照编号顺序进行的。比如,在 web-0 进入到 Running 状态、并且 Conditions 成为 Ready 之前,web-1 会一直处于 Pending 状态。
当我们把这几个 Pod 删除之后,Kubernetes 会按照原先编号的顺序,创建出新的 Pod。并且,Kubernetes 依然为它们分配了与原来相同的“网络身份”;
通过这种严格的对应规则,StatefulSet 就保证了 Pod 网络标识的稳定性;
1.2.2 运用Headless Service实现Pod网络标识稳定不变
通过 Headless Service 的方式,StatefulSet 为每个 Pod 创建了一个固定并且稳定的 DNS 记录,来作为它的访问入口。
1.2.2.1 Service简介
Service 类型一般有如下的三种:
- VIP(Virtual IP,即:虚拟 IP)
Service提供一个 VIP,我们访问这个IP地址时,它会把请求转发到该 Service 所代理的某一个 Pod 上。
- DNS (Normal Service)
这种情况下,访问“my-svc.my-namespace.svc.cluster.local”解析到的,正是 my-svc 这个 Service 的 VIP,后面的流程就跟 VIP 方式一致。
- DNS (Headless Service)
这种情况下,访问“my-svc.my-namespace.svc.cluster.local”解析到的,直接就是 my-svc 代理的某一个 Pod 的 IP 地址。所以,Headless Service 不需要分配一个 VIP,而是可以直接以 DNS 记录的方式解析出被代理 Pod 的 IP 地址。
1.2.2.2 Headless Service
1.2.2.2.1 案例
参考如下的demo-service.yaml案例:
apiVersion: v1
kind: Service
metadata: name: demo-service labels: app: nginx
spec: ports: - port: 80 name: web clusterIP: None selector: app: demo-nginx
创建成功后可以查看到如下的内容:
demo-service
1.2.2.2.2 clusterIP
关于于上面的这行配置clusterIP: None。
clusterIP 是服务的IP地址,通常由主服务器随机分配还具有如下特点:
- 如果地址是手动指定的,并且未被其他人使用,则该地址将分配给服务;否则,服务创建将失败
- 无法通过更新更改此字段。
- 有效值为“ None”,空字符串(“”)或有效IP地址。
- 当不需要代理时,可以为无头服务指定“无”。
- 仅适用于ClusterIP,NodePort和LoadBalancer类型。
- 如果type为ExternalName,则忽略。
Headless Service 是一个标准 Service 的 YAML 文件。只不过,它的 clusterIP 字段的值是:None。这个 Service 被创建后并不会被分配一个 VIP,而是会以 DNS 记录的方式暴露出它所代理的 Pod。
1.2.2.2.3 DNS 记录
当按照这样的方式创建了一个 Headless Service 之后,它所代理的所有 Pod 的 IP 地址,都会被绑定一个这样格式的 DNS 记录,如下所示:
<pod-name>.<svc-name>.<namespace>.svc.cluster.local
这个 DNS 记录,正是 Kubernetes 项目为 Pod 分配的唯一的“可解析身份”(Resolvable Identity)。有了这个“可解析身份”,只需要知道了一个 Pod 的名字,以及它对应的 Service 的名字,就可以非常确定地通过这条 DNS 记录访问到 Pod 的 IP 地址。
1.2.2.3 StatefulSet实现Pod的拓扑状态
Stateful状态集在创建和扩展的时候有特殊的限制,如果一个有状态集期望的Pod数量是N,那么有StatefulSet会从0开始依次创建这些Pod在第一个Pod正常运行之前是不会创建第二个Pod。在删除Pod的时候,则是从第N个Pod开始反向依次删除。
StatefulSet的核心功能就是通过某种方式记录这些状态,然后在Pod被重新创建时能够为新Pod恢复这些状态。
只要知道一个Pod的名字以及它对应的Service的名字,就可以通过这条DNS记录访问到Pod的IP地址(pod的名称.service名称) -> Pod的IP。
定义Stateful的对象中有一个serviceName字段来告诉Stateful控制器使用具体的service来解析它所管理的Pod的IP地址。
Pod的名称由StatfulSet对象的名称+Pod创建时所在的索引组成 StatefulSet使用这个DNS记录解析规则来维持Pod的拓扑状态。
StatefulSet给它所管理的所有Pod的名字进行了编号,编号规则是: - .而且这些编号都是从0开始累加与StatefulSet的每个Pod实例一一对应、绝不重复。
这些Pod的创建也是严格按照编号顺序进行的,比如,在web-0进入到Running 状态、并且细分状态(Conditions)成为Ready之前,web-1会一直处于Pending状态。
把这两个Pod删除之后Kubernetes会按照原先编号的顺序,创建出了两个新的 Pod,并且Kubernetes依然为它们分配了与原来相同的“网络身份”:web-0.nginx和 web-1.nginx。
通过永远不改变Pod名称的方式StatefulSet保证了Pod网络标识的稳定性。不管Pod是被删除重启还是被调度到其他节点上都不会改变Pod的名称。
StatefulSet管理的pod使用的镜像是一样的,但是每个pod的命令和初始化流程可以完全不一样来实现主从Pod的拓扑部署。
尽管web-0.nginx这条DNS记录本身不会变但它解析到的Pod的IP地址并不是固定的。这就意味着,对于“有状态应用”实例的访问必须使用DNS记录或者hostname的方式而绝不应该直接访问这些Pod的IP地址。
1.3 “稳定不变的存储”的实现
1.3.1 稳定不变的存储概述
- 每个 Pod 都会绑定一个固定编号的 PVC,这些 PVC 的名字都是 -;
- 名叫 web-0 的 Pod,会声明使用名叫 www-web-0 的 PVC;
- PV/PVC 通过动态卷的方式存储于远程存储服务器;
- 当一个 Pod 被删除后,对应的 PVC 和 PV 并不会被删除,数据依然存在于远程服务器,Pod 被重建后,StatefulSet 会重新查找对应名称的 PVC 来进行绑定;
1.3.2 StatefulSet实现Pod的存储状态
通过PVC机制来实现存储状态管理。
在StatefulSet对象中除了定义PodTemplate还会定义一个volumeClaimTemplates凡是被这个StatefulSet管理的Pod都会声明一个对应的PVC,这个PVC的定义就来自于 volumeClaimTemplates这个模板字段。
这个PVC的名字,会被分配一个与这个Pod完全一致的编号。
把一个Pod比如web-0删除之后,这个Pod对应的PVC和PV并不会被删除,而这个Volume 里已经写入的数据,也依然会保存在远程存储服务里。
StatefulSet在重新创建web-0这个pod的时候.它声明使用的PVC的名字还是叫作:www-web-0 这个PVC的定义,还是来自于PVC模板(volumeClaimTemplates)这是StatefulSet创建 Pod的标准流程。
Kubernetes为它查找名叫www-web-0的PVC时,就会直接找到旧Pod遗留下来的同名的 PVC进而找到跟这个PVC绑定在一起的PV.这样新的Pod就可以挂载到旧Pod对应的那个Volume并且获取到保存在Volume里的数据.通过这种方式Kubernetes的StatefulSet就实现了对应用存储状态的管理。
StatefulSet其实就是一种特殊的Deployment,而其独特之处在于,它的每个Pod都被编号了.而且,这个编号会体现在Pod的名字和hostname等标识信息上,这不仅代表了Pod的创建顺序,也是Pod的重要网络标识(即:在整个集群里唯一的、可被的访问身份).有了这个编号后StatefulSet就使用Kubernetes里的两个标准功能:Headless Service 和 PV/PVC,实现了对 Pod 的拓扑状态和存储状态的维护。
1.4 核心逻辑实现
StatefulSet的实现机制整体流程相对简明,接下来按照Pod管理、状态计算、状态管理、更新策略这几部分来依次讲解。
1.4.1 Pod的release与adopt
statefulSet中的pod的名字都是按照一定规律来进行设置的, 名字本身也有含义, k8s在进行statefulset更新的时候,首先会过滤属于当前statefulset的pod,并做如下操作:
- K8s中控制器与Pod的关联主要通过两个部分:controllerRef和label, statefulset在进行Pod过滤的时候,如果发现对应的pod的controllerRef都是当前的statefulset但是其label或者名字并不匹配,则就会尝试release对应的Pod
- 反之如果发现对应Pod的label和名字都匹配,但是controllerRef并不是当前的statefulSet就会更新对应的controllerRef为当前的statefulset, 这个操作被称为adopt。
通过该流程可以确保当前statefulset关联的Pod要么与当前的对象关联,要么我就释放你,这样可以维护Pod的一致性,即时有人修改了对应的Pod则也会调整成最终一致性。
1.4.2 副本分类
在经过第一步的Pod状态的修正之后,statefulset会遍历所有属于自己的Pod,同时将Pod分为两个大类:有效副本和无效副本(condemned),前面提到过Pod的名字也是有序的即有N个副本的Pod则名字依次是{0...N-1}, 这里区分有效和无效也是依据对应的索引顺序,如果超过当前的副本即为无效副本
1.4.3 单调更新
单调更新主要是指的当对应的Pod管理策略不是并行管理的时候,只要当前Replicas(有效副本)中任一一个Pod发生创建、终止、未就绪的时候,都会等待对应的Pod就绪,即你要想更新一个statefulset的Pod的时候,对应的Pod必须已经RunningAndReady
func allowsBurst(set *apps.StatefulSet) bool {return set.Spec.PodManagementPolicy == apps.ParallelPodManagement}
1.4.4 基于计数器的滚动更新
滚动更新的实现相对隐晦一点,其主要是通过控制副本计数来实现,首先倒序检查对应的Pod的版本是否是最新版本,如果发现不是,则直接删除对应的Pod,同时将currentReplica计数减一,这样在检查对应的Pod的时候,就会发现对应的Pod的不存在,就需要为对应的Pod生成新的Pod信息,此时就会使用最新的副本去更新。
func newVersionedStatefulSetPod(currentSet, updateSet *apps.StatefulSet, currentRevision, updateRevision string, ordinal int) *v1.Pod {// 如果发现当前的Pod的索引小于当的副本计数,则表明当前Pod还没更新到,但实际上可能因为别的原因// 需要重新生成Pod模板,此时仍然使用旧的副本配置if currentSet.Spec.UpdateStrategy.Type == apps.RollingUpdateStatefulSetStrategyType &&(currentSet.Spec.UpdateStrategy.RollingUpdate == nil && ordinal < int(currentSet.Status.CurrentReplicas)) ||(currentSet.Spec.UpdateStrategy.RollingUpdate != nil && ordinal < int(*currentSet.Spec.UpdateStrategy.RollingUpdate.Partition)) {pod := newStatefulSetPod(currentSet, ordinal)setPodRevision(pod, currentRevision)return pod}// 使用新的配置生成新的Pod配置pod := newStatefulSetPod(updateSet, ordinal)setPodRevision(pod, updateRevision)return pod}
1.4.5 无效副本的清理
无效副本的清理应该主要是发生在对应的statefulset缩容的时候,如果发现对应的副本已经被遗弃,就会直接删除,此处默认也需要遵循单调性原则,即每次都只更新一个副本
1.4.6 基于删除的单调性更新
if getPodRevision(replicas[target]) != updateRevision.Name && !isTerminating(replicas[target]) {klog.V(2).Infof("StatefulSet %s/%s terminating Pod %s for update", set.Namespace, set.Name, replicas[target].Name)err := ssc.podControl.DeleteStatefulPod(set, replicas[target])status.CurrentReplicas--return &status, err}
Pod的版本检测位于对应一致性同步的最后,当代码走到当前位置,则证明当前的statefulSet在满足单调性的情况下,有效副本里面的所有Pod都是RunningAndReady状态了,此时就开始倒序进行版本检查,如果发现版本不一致,就根据当前的partition的数量来决定允许并行更新的数量,在这里删除后,就会触发对应的事件,从而触发下一个调度事件,触发下一轮一致性检查。
1.4.7 OnDelete策略
if set.Spec.UpdateStrategy.Type == apps.OnDeleteStatefulSetStrategyType {return &status, nil}
StatefulSet的更新策略除了RollingUpdate还有一种即OnDelete即必须人工删除对应的 Pod来触发一致性检查,所以针对那些如果想只更新指定索引的statefulset可以尝试该策略,每次只删除对应的索引,这样只有指定的索引会更新为最新的版本。
1.4.8 状态存储
状态存储其实就是我们常说的PVC,在Pod创建和更新的时候,如果发现对应的PVC的不存在则就会根据statefulset里面的配置创建对应的PVC,并更新对应Pod的配置。
1.5 有状态应用总结
从核心实现分析中可以看出来,有状态应用的实现,实际上核心是基于一致性状态、单调更新、持久化存储的组合,通过一致性状态、单调性更新,保证期望副本的数量的Pod处于RunningAndReady的状态并且保证有序性,同时通过持久化存储来进行数据的保存。
有序的重要性,在分布式系统中比较常见的两个设计就是分区和副本,其中副本主要是为了保证可用性,而分区主要是进行数据的平均分布,二者通常都是根据当前集群中的节点来进行分配的,如果我们节点短暂的离线升级,数据保存在对应的PVC中,在恢复后可以很快的进行节点的信息的恢复并重新加入集群,所以后面如果开发这种类似的分布式应用的时候,可以将底层的恢复和管理交给k8s,数据保存在PVC中,则应用更多的只需要关注系统的集群管理和数据分布问题即,这也是云原生带来的改变。
参考链接
Statefulset详细解析 - 不懂123 - 博客园
k8s中statefulset资源类型的深入理解
十,StatefulSet简介及简单使用 - 戴红领巾的少年 - 博客园
k8s之StatefulSet详解_最美dee时光的博客-CSDN博客_statefulset
Kubernetes学习笔记 —— 7. StatefulSet - 知乎
容器化部署实战(五)|控制器 StatefulSet 的原理
K8s StatefulSet
kubernetes——StatefulSet详解
Kubernetes 深入理解StatefulSet(一):拓扑状态_富士康质检员张全蛋的博客-CSDN博客
图解kubernetes控制器StatefulSet核心实现原理_8小时的博客-CSDN博客
详解 Kubernetes StatefulSet 实现原理_cbmljs的博客-CSDN博客_kubectl statefulset
Kubernetes:StatefulSet剖析
Kubernetes Deployments vs StatefulSets - Stack Overflow
StatefulSet: Run and Scale Stateful Applications Easily in Kubernetes | Kubernetes
Running ZooKeeper, A Distributed System Coordinator | Kubernetes
StatefulSets | Kubernetes
StatefulSet · Kubernetes Engine
【重识云原生】第六章容器基础6.4.10.5节——Statefulset原理剖析相关推荐
- 【重识云原生】第六章容器基础6.4.9.2节——使用 Service 连接到应用
<重识云原生系列>专题索引: 第一章--不谋全局不足以谋一域 第二章计算第1节--计算虚拟化技术总述 第二章计算第2节--主流虚拟化技术之VMare ESXi 第二章计算第3节--主流虚拟 ...
- 【重识云原生】第一章——不谋全局不足以谋一域
云原生体系知识地图大纲: 锲子 云原生概念这几年非常火爆,本人因有幸参与公司云原生转型项目调研,开始接触这一庞大技术体系,再通过与同业.各大头部云厂商超过150场的密集研讨交流,方得初窥全貌.同时 ...
- 【重识云原生】第二章计算第一节——计算虚拟化技术总述
云平台计算领域知识地图: 楔子:计算虚拟化技术算是云计算技术的擎天之柱,其前两代技术的演进一直引领着云计算的发展,即便到了云原生时代,其作用依然举足轻重. 一.计算虚拟化技术总述 1.1 虚拟化技 ...
- 【重识云原生】第六章容器基础6.4.7.1节——K8S Job组件
<重识云原生系列>专题索引: 第一章--不谋全局不足以谋一域 第二章计算第1节--计算虚拟化技术总述 第二章计算第2节--主流虚拟化技术之VMare ESXi 第二章计算第3节--主流虚拟 ...
- 【重识云原生】第六章容器基础6.4.5.2节——Deployment配置详细说明
<重识云原生系列>专题索引: 第一章--不谋全局不足以谋一域 第二章计算第1节--计算虚拟化技术总述 第二章计算第2节--主流虚拟化技术之VMare ESXi 第二章计算第3节--主流虚拟 ...
- 【重识云原生】第六章容器基础6.4.5.3节——Deployment实现原理解析
<重识云原生系列>专题索引: 第一章--不谋全局不足以谋一域 第二章计算第1节--计算虚拟化技术总述 第二章计算第2节--主流虚拟化技术之VMare ESXi 第二章计算第3节--主流虚拟 ...
- 【重识云原生】第六章容器基础6.4.5.1节——Deployment概述
<重识云原生系列>专题索引: 第一章--不谋全局不足以谋一域 第二章计算第1节--计算虚拟化技术总述 第二章计算第2节--主流虚拟化技术之VMare ESXi 第二章计算第3节--主流虚拟 ...
- 【重识云原生】第六章容器基础6.4.9.6节——Service 与 Pod 的DNS
1 Service 与 Pod 的 DNS Kubernetes 为 Service 和 Pod 创建 DNS 记录. 你可以使用一致的 DNS 名称而非 IP 地址访问 Service. Kuber ...
- 【重识云原生】第六章容器6.3.5节——Controller Manager概述
<重识云原生系列>专题索引: 第一章--不谋全局不足以谋一域 第二章计算第1节--计算虚拟化技术总述 第二章计算第2节--主流虚拟化技术之VMare ESXi 第二章计算第3节--主流虚拟 ...
- 【重识云原生】第三章云存储3.5节——商用分布式云存储方案
<重识云原生系列>专题索引: 第一章--不谋全局不足以谋一域 第二章计算第1节--计算虚拟化技术总述 第二章计算第2节--主流虚拟化技术之VMare ESXi 第二章计算第3节--主流虚拟 ...
最新文章
- 数字图像处理——第九章 形态学图像处理
- AdvFlow:一种基于标准化流的黑盒攻击新方法,产生更难被发觉的对抗样本 | NeurIPS‘20
- Windows -- cmd命令: ipconfig 和 nbtstat
- Spring 注入内部 Beans
- 福布斯中国2018年30位30岁以下精英榜单发布,为什么是他们?
- asp.net Page.Controls对象(找到所有服务器控件)
- typecho和wordpress模板了解、开发流程介绍、前台后台前端后端区分
- java单引号转义_Java基础入门——Java语言基础(上)
- 【web前端开发】介绍div+css的6个优点
- 南瓜电影将和腾讯合作 获海量视频版权授权
- 规划 SOA 参考架构
- python 代码命令大全-Linux命令大全
- 忆2015,迎2016(致敬自己)
- 一个漂亮的电子数字字体分享electronicFont
- ISO-IEC 27001 SOA适用性说明原文+个人理解
- 免费内网端口映射、内网穿透
- 用html设计logo,网页设计中的logo设计方法
- oracle数据库中汉字转化成拼音
- 当yum安装包时显示系统空间不足,求指教
- 利用github和hexo一步步生成个人博客(2)---基本配置和发表文章
热门文章
- mysql mtq_第十六节:Mysql中的关键字
- C++学习日记——头文件的编写
- 仙之侠道2玖章青门任务怎么做_仙之侠道Ⅱ攻略_仙之侠道Ⅱ柒章 任务全攻略 新手必看_牛游戏网魔兽地图专区...
- java 中文大写金额_金额数字转中文大写
- iov_iter操作
- echarts实现词云图表,及参数配置详解
- 荣耀笔记本pro linux版本,荣耀MagicBook Pro锐龙版发布:首发锐龙7 3750H、还有Linux版...
- e4a 安卓获取ROOT权限的方法思路 转载
- 解决 /lib64/libstdc++.so.6: version `GLIBCXX_3.4.20‘ not found (required by 问题
- 网页显示不正常怎么修复