Kubernetes网络原理及方案

内容简介：Kubernetes网络原理及方案

大家好，说到容器、 Docker ，大家一定会想到 Kubernetes ，确实如此，在2016年ClusterHQ容器技术应用调查报告显示，Kubernetes的使用率已经达到了40%，成为最受欢迎的容器编排工具；那么Kubernetes到底是什么呢？它是一个用于容器集群的自动化部署、扩容以及运维的开源平台；那么通过Kubernetes能干什么呢？它能快速而有预期地部署你的应用，极速地扩展你的应用，无缝对接新的应用功能，节省资源，优化硬件资源的使用。

随着Kubernetes王者时代的到来，计算、网络、存储、安全是Kubernetes绕不开的话题，本次主要分享Kubernetes网络原理及方案，后续还会有Kubernetes其它方面的分享，另外有容云5.22发布了基于Kubernetes的容器云平台产品UFleet，想要获取新品试用，欢迎联系有容云。

一、Kubernetes网络模型

在Kubernetes网络中存在两种IP（Pod IP和Service Cluster IP），Pod IP 地址是实际存在于某个网卡(可以是虚拟设备)上的，Service Cluster IP它是一个虚拟IP，是由kube-proxy使用Iptables规则重新定向到其本地端口，再均衡到后端Pod的。下面讲讲Kubernetes Pod网络设计模型：

1、基本原则：

每个Pod都拥有一个独立的IP地址（IPper Pod），而且假定所有的pod都在一个可以直接连通的、扁平的网络空间中。

2、设计原因：

用户不需要额外考虑如何建立Pod之间的连接，也不需要考虑将容器端口映射到主机端口等问题。

3、网络要求：

所有的容器都可以在不用NAT的方式下同别的容器通讯；所有节点都可在不用NAT的方式下同所有容器通讯；容器的地址和别人看到的地址是同一个地址。

二、 Docker 网络基础

• Linux网络名词解释：

1、网络的命名空间：Linux在网络栈中引入网络命名空间，将独立的网络协议栈隔离到不同的命令空间中，彼此间无法通信；docker利用这一特性，实现不容器间的网络隔离。

2、Veth设备对：Veth设备对的引入是为了实现在不同网络命名空间的通信。

3、Iptables/Netfilter：Netfilter负责在内核中执行各种挂接的规则(过滤、修改、丢弃等)，运行在内核 模式中；Iptables模式是在用户模式下运行的进程，负责协助维护内核中Netfilter的各种规则表；通过二者的配合来实现整个 Linux 网络协议栈中灵活的数据包处理机制。

4、网桥：网桥是一个二层网络设备,通过网桥可以将linux支持的不同的端口连接起来,并实现类似交换机那样的多对多的通信。

5、路由：Linux系统包含一个完整的路由功能，当IP层在处理数据发送或转发的时候，会使用路由表来决定发往哪里。   

• Docker生态技术栈

下图展示了Docker网络在整个Docker生态技术栈中的位置：

• Docker网络实现

1、单机 网络模式： Bridge 、Host、Container、None，这里具体就不赘述了。

2、多机网络模 式： 一类是 Docker 在 1.9 版本中引入Libnetwork项目，对跨节点网络的原生支持；一类是通过插件（plugin）方式引入的第三方实现方案，比如 Flannel，Calico 等等。 

三、Kubernetes网络基础

1、容器间通信：

同一个Pod的容器共享同一个网络命名空间，它们之间的访问可以用localhost地址 + 容器端口就可以访问。

2、同一Node中Pod间通信：

同一Node中Pod的默认路由都是docker0的地址，由于它们关联在同一个docker0网桥上，地址网段相同，所有它们之间应当是能直接通信的。

3、不同Node中Pod间通信：

不同Node中Pod间通信要满足2个条件： Pod的IP不能冲突； 将Pod的IP和所在的Node的IP关联起来，通过这个关联让Pod可以互相访问。

4、Service介绍：

Service是一组Pod的服务抽象，相当于一组Pod的LB，负责将请求分发给对应的

Pod；Service会为这个LB提供一个IP，一般称为ClusterIP。

5、Kube-proxy介绍：

Kube-proxy是一个简单的网络代理和负载均衡器，它的作用主要是负责Service的实现，具体来说，就是实现了内部从Pod到Service和外部的从NodePort向Service的访问。

实现方式：

• userspace是在用户空间，通过kuber-proxy实现LB的代理服务，这个是kube-proxy的最初的版本，较为稳定，但是效率也自然不太高。

• iptables是纯采用iptables来实现LB，是目前kube-proxy默认的方式。

下面是iptables模式下Kube-proxy的实现方式：

• 在这种模式下，kube-proxy监视Kubernetes主服务器添加和删除服务和端点对象。对于每个服务，它安装iptables规则，捕获到服务的clusterIP（虚拟）和端口的流量，并将流量重定向到服务的后端集合之一。对于每个Endpoints对象，它安装选择后端Pod的iptables规则。

• 默认情况下，后端的选择是随机的。可以通过将service.spec.sessionAffinity设置为“ClientIP”（默认为“无”）来选择基于客户端IP的会话关联。

• 与用户空间代理一样，最终结果是绑定到服务的IP:端口的任何流量被代理到适当的后端，而客户端不知道关于Kubernetes或服务或Pod的任何信息。这应该比用户空间代理更快，更可靠。然而，与用户空间代理不同，如果最初选择的Pod不响应，则iptables代理不能自动重试另一个Pod，因此它取决于具有工作准备就绪探测。

6、Kube-dns介绍

Kube-dns用来为kubernetes service分配子域名，在集群中可以通过名称访问service；通常kube-dns会为service赋予一个名为“service名称.namespace.svc.cluster.local”的A记录，用来解析service的clusterip。

Kube-dns组件：

• 在Kubernetes v1.4版本之前由“Kube2sky、Etcd、Skydns、Exechealthz”四个组件组成。

• 在Kubernetes v1.4版本及之后由“Kubedns、dnsmasq、exechealthz”三个组件组成。

Kubedns

• 接入SkyDNS，为dnsmasq提供查询服务。

• 替换etcd容器，使用树形结构在内存中保存DNS记录。

• 通过K8S API监视Service资源变化并更新DNS记录。

• 服务10053端口。

Dnsmasq

• Dnsmasq是一款小巧的DNS配置工具。

• 在kube-dns插件中的作用是：

1. 通过kubedns容器获取DNS规则，在集群中提供DNS查询服务

2. 提供DNS缓存，提高查询性能

3. 降低kubedns容器的压力、提高稳定性

• Dockerfile在GitHub上Kubernetes组织的contrib仓库中，位于dnsmasq目录下。

• 在kube-dns插件的编排文件中可以看到，dnsmasq通过参数--server=127.0.0.1:10053指定upstream为kubedns。

Exechealthz

• 在kube-dns插件中提供健康检查功能。

• 源码同样在contrib仓库中，位于exec-healthz目录下。

• 新版中会对两个容器都进行健康检查，更加完善。

四、Kubernetes网络开源组件

1、技术术语：

IPAM：IP地址管理；这个IP地址管理并不是容器所特有的，传统的网络比如说DHCP其实也是一种IPAM，到了容器时代我们谈IPAM，主流的两种方法： 基于CIDR的IP地址段分配地或者精确为每一个容器分配IP。但总之一旦形成一个容器主机集群之后，上面的容器都要给它分配一个全局唯一的IP地址，这就涉及到IPAM的话题。

Overlay：在现有二层或三层网络之上再构建起来一个独立的网络，这个网络通常会有自己独立的IP地址空间、交换或者路由的实现。

IPSesc：一个点对点的一个加密通信协议，一般会用到Overlay网络的数据通道里。

vxLAN：由VMware、Cisco、RedHat等联合提出的这么一个解决方案，这个解决方案最主要是解决VLAN支持虚拟网络数量（4096）过少的问题。因为在公有云上每一个租户都有不同的VPC，4096明显不够用。就有了vxLAN，它可以支持1600万个虚拟网络，基本上公有云是够用的。

网桥Bridge： 连接两个对等网络之间的网络设备，但在今天的语境里指的是Linux Bridge，就是大名鼎鼎的Docker0这个网桥。

BGP：主干网自治网络的路由协议，今天有了互联网，互联网由很多小的自治网络构成的，自治网络之间的三层路由是由BGP实现的。

SDN、Openflow：软件定义网络里面的一个术语，比如说我们经常听到的流表、控制平面，或者转发平面都是Openflow里的术语。    

2、容器网络方案：

隧道方案（ Overlay Networking ）

隧道方案在IaaS层的网络中应用也比较多，大家共识是随着节点规模的增长复杂度会提升，而且出了网络问题跟踪起来比较麻烦，大规模集群情况下这是需要考虑的一个点。

• Weave：UDP广播，本机建立新的BR，通过PCAP互通

• Open vSwitch（OVS）：基于VxLan和GRE协议，但是性能方面损失比较严重

• Flannel：UDP广播，VxLan

• Racher：IPsec

路由方案

路由方案一般是从3层或者2层实现隔离和跨主机容器互通的，出了问题也很容易排查。

• Calico：基于BGP协议的路由方案，支持很细致的ACL控制，对混合云亲和度比较高。

• Macvlan：从逻辑和Kernel层来看隔离性和性能最优的方案，基于二层隔离，所以需要二层路由器支持，大多数云服务商不支持，所以混合云上比较难以实现。

3、CNM & CNI阵营：

容器网络发展到现在，形成了两大阵营，就是Docker的CNM和Google、CoreOS、Kuberenetes主导的CNI。首先明确一点，CNM和CNI并不是网络实现，他们是网络规范和网络体系，从研发的角度他们就是一堆接口，你底层是用Flannel也好、用Calico也好，他们并不关心，CNM和CNI关心的是网络管理的问题。

CNM（Docker LibnetworkContainer Network Model）:

Docker Libnetwork的优势就是原生，而且和Docker容器生命周期结合紧密；缺点也可以理解为是原生，被Docker“绑架”。

• Docker Swarm overlay

• Macvlan & IP networkdrivers

• Calico

• Contiv

• Weave

CNI（Container NetworkInterface）：

CNI的优势是兼容其他容器技术（e.g. rkt）及上层编排系统（Kubernetes & Mesos)，而且社区活跃势头迅猛，Kubernetes加上CoreOS主推；缺点是非Docker原生。

• Kubernetes

• Weave

• Macvlan

• Calico

• Flannel

• Contiv

• Mesos CNI

4 、Flannel容器网络：

Flannel之所以可以搭建kubernets依赖的底层网络，是因为它可以实现以下两点：

• 它给每个node上的docker容器分配相互不想冲突的IP地址；

• 它能给这些IP地址之间建立一个覆盖网络，同过覆盖网络，将数据包原封不动的传递到目标容器内。

Flannel介绍

• Flannel是CoreOS团队针对Kubernetes设计的一个网络规划服务，简单来说，它的功能是让集群中的不同节点主机创建的Docker容器都具有全集群唯一的虚拟IP地址。

• 在默认的Docker配置中，每个节点上的Docker服务会分别负责所在节点容器的IP分配。这样导致的一个问题是，不同节点上容器可能获得相同的内外IP地址。并使这些容器之间能够之间通过IP地址相互找到，也就是相互ping通。

• Flannel的设计目的就是为集群中的所有节点重新规划IP地址的使用规则，从而使得不同节点上的容器能够获得“同属一个内网”且”不重复的”IP地址，并让属于不同节点上的容器能够直接通过内网IP通信。

• Flannel实质上是一种“覆盖网络(overlaynetwork)”，也就是将TCP数据包装在另一种网络包里面进行路由转发和通信，目前已经支持udp、vxlan、host-gw、aws-vpc、gce和alloc路由等数据转发方式，默认的节点间数据通信方式是UDP转发。

5、Calico容器网络：

Calico介绍

• Calico是一个纯3层的数据中心网络方案，而且无缝集成像OpenStack这种IaaS云架构，能够提供可控的VM、容器、裸机之间的IP通信。Calico不使用重叠网络比如flannel和libnetwork重叠网络驱动，它是一个纯三层的方法，使用虚拟路由代替虚拟交换，每一台虚拟路由通过BGP协议传播可达信息（路由）到剩余数据中心。

• Calico在每一个计算节点利用Linux Kernel实现了一个高效的vRouter来负责数据转发，而每个vRouter通过BGP协议负责把自己上运行的workload的路由信息像整个Calico网络内传播——小规模部署可以直接互联，大规模下可通过指定的BGP route reflector来完成。

• Calico节点组网可以直接利用数据中心的网络结构（无论是L2或者L3），不需要额外的NAT，隧道或者Overlay Network。

• Calico基于iptables还提供了丰富而灵活的网络Policy，保证通过各个节点上的ACLs来提供Workload的多租户隔离、安全组以及其他可达性限制等功能。

Calico架构图

五、网络开源组件性能对比分析

性能对比分析：

性能对比总结：

CalicoBGP 方案最好，不能用 BGP 也可以考虑 Calico ipip tunnel 方案；如果是 Coreos 系又能开 udp offload，flannel 是不错的选择；Docker 原生Overlay还有很多需要改进的地方。

最后，再提下我们有容云5.22发布了基于Kubernetes的容器云平台产品UFleet，UFleet采用的是Flannel网络，后续我们将支持Calico网络，如需试用，欢迎联系有容云。

Q&A

Q1：目前 有容云 用的是哪种网络，有什么优缺点？容器规模在500内，在网络选择上有什么建议？

A：目前有容云 UFleet 产品用的是flannel网络；flannel网络优势就是部署简单，性能还不错，劣势就是不能进行多子网隔离，也没法固定容器IP，每台主机都划分一个24网段，严重造成IP浪费；有关容器规模在500内，在选择网络上的建议，这个还需要看容器是部署的几台主机上，是否需要子网隔离，性能要求等，综合部署网络的要求及各网络的优劣来选择最适合自己的网络方案（有关各网络的优劣，可以参考分享中的“网络开源组件性能对比分析”）。

Q2：A的pod如何连接B的pod？ kube-dns起到什么作用？ kube-dns如果调用kube-proxy？

A：这里说的A和B应当是指service，A service中pod与B service pod之间的通信，可以在其容器的环境变量中定义service IP或是service name来实现；由于service IP提前不知道，使用引入kube-dns做服务发现，它的作用就是监听service变化并更新DNS，即pod通过服务名称可以查询DNS；kube-proxy是一个简单的网络代理和负载均衡器，它的作用主要是负责service的实现，具体来说，就是实现了内部从Pod到Service和外部的从NodePort向Service的访问，可以说kube-dns和kube-proxy都是为Service服务的。

Q3：网络问题 docker default 是网桥模式（NAT） 如果用路由的模式，所以pod的网关都会是 docker 0 IP ？ 那pod 1与pod 2 之间也走路由 ，这会使路由表很大？ Flannel 网络是不是可以把所有的node上，相当于一个分布式交换机？

A：Docker实现跨主机通信可以通过桥接和路由的方式，桥接的方式是将docker0桥接在主机的网卡上，而路由直接通过主机网口转发出去；kubernetes网络有pod和server，pod网络实现的方式很多，可以参考CNI网络模型，flannel实质上是一种“覆盖网络(overlay network)”，也就是将TCP数据包装在另一种网络包里面进行路由转发和通信。

Q4：大规模容器集群如何保证安全? 主要从几个方面考虑?

A：一个大规模容器集群从安全性考虑来讲，可以分为几个方面：1、集群安全，包括集群高可用；2、访问安全，包括认证、授权、访问控制等；3、资源隔离，包括多租户等；4、网络安全，包括网络隔离、流量控制等；5、 镜像 安全，包括容器漏洞等；6、容器安全，包括端口暴露、privileged权限等。

Q5：svc 如何进行客户端分流，A网段的访问Pod1 ，B网段的访问Pod2，C网段的访问Pod3 .3个PoD都在svc的endpoint中？

A： 内部从Pod到Service的实现是由kube-proxy（简单的网络代理和负载均衡器）来完成，kube-proxy默认采用轮询方法进行分配，也可以通过将service.spec.sessionAffinity设置为“ClientIP”（默认为“无”）来选择基于客户端IP的会话关联，目前还不能进行网段的指定。

Q6：对于ingress+haproxy这种实现service负载均衡的方式，ingress controller轮询service后面的pods状态，并重新生成haproxy配置文件，然后重启haproxy，从而达到服务发现的目的。这种原理对于haproxy来讲是不是服务会暂时间断。有没有好的替代方案？之前看到golang实现的traefik，可无缝对接k8s，同时不需要ingress了。方案可行么？

A：由于微服务架构以及 Docker 技术和 kubernetes 编排 工具 最近几年才开始逐渐流行，所以一开始的反向代理服务器比如nginx/haproxy 并未提供其支持，毕竟他们也不是先知，所以才会出现 IngressController 这种东西来做 kubernetes 和前端负载均衡器如 nginx/haproxy之间做衔接，即 Ingress Controller 的存在就是为了能跟 kubernetes 交互，又能写 nginx/haproxy 配置，还能 reload 它，这是一种折中方案；而最近开始出现的 traefik 天生就是提供了对 kubernetes 的支持，也就是说 traefik 本身就能跟 kubernetes API 交互，感知后端变化，因此在使用traefik时就不需要Ingress Controller，此方案当然可行。 

Q7：一个 POD里面的 多个 container ,是同一个 service的？还是由不同的service 的组成？ 是啥样的分配逻辑？ 2、Flannel 是实现 多个宿主机上的N多的service以及pod里面的各个container的IP的唯一性么？ 3、k8s 具备负载均衡的效果 。那是否就不用在考虑nigix？

A：Pod 是Kubernetes的基本操作单元，Pod包含一个或者多个相关的容器，Pod可以认为是容器的一种延伸扩展，一个Pod也是一个隔离体，而Pod内部包含的一组容器又是共享的（包括PID、Network、IPC、UTS）；service是pod的路由代理抽象，能解决pod之间的服务发现问题；Flannel的设计目的就是为集群中的所有节点重新规划IP地址的使用规则，从而使得不同节点上的容器能够获得“同属一个内网”且”不重复的”IP地址，并让属于不同节点上的容器能够直接通过内网IP通信；k8s kube-proxy实现的是内部L4层轮询机制的负载均衡，要支持L4、L7负载均衡，k8s也提供了Ingress组件，通过反向代理负载均衡器（nginx/haproxy）+Ingress Controller+Ingress可以实现对外服务暴露，另外使用traefik方案来实现service的负载均衡也是一种不错的选择。

Q8：据我所知有容云之前的产品是基于rancher开发的，而最新的UFleet是基于k8s。这两个产品有什么区别？为什么从Rancher转向k8s? 有容云的新旧产品以后是同时存在么，市场定位是怎样的？

A：有容云AppSoar和UFleet都是容器云管理平台， AppSoar 是基于rancher， UFleet 是基于k8s，这两个产品区别有2大部分，一部分是rancher和k8s的区别，另一部分是UFleet的优势，比如集成了 CICD 功能，详情请关注有容云UFleet产品；从Rancher转向K8s也是顺应市场的需求变化，AppSoar和UFleet在很长一段时间内应当会并存，因为它们的市场定位也是不一样的。

Q9：kube-proxy是怎样进行负载？ service虚拟ip存在哪里？

A：kube-proxy有2个模式实现负载均衡，一种是userspace，通过iptables重定向到kube-proxy对应的端口上，然后由kube-proxy进一步把数据发送到其中的一个pod上，另一种是iptables，纯采用iptables来实现负载均衡，kube-proxy默认采用轮询方法进行分配，也可以通过将service.spec.sessionAffinity设置为“ClientIP”（默认为“无”）来选择基于客户端IP的会话关联；Service Cluster IP它是一个虚拟IP，是由kube-proxy使用Iptables规则重新定向到其本地端口，再均衡到后端Pod的，通过 apiserver的启动参数--service-cluster-ip-range来设置，由kubernetes集群内部维护。

Q10：请问有没有具体的不同网络方案的测试数据？

A：有，包括flannel、calico等，有需要的可以联系有容云。

Q11：有容目前的产品都支持那些网络类型？这些网络类型分别针对那些应用场景？

A：有容云AppSoar产品网络这块目前支持Overlay Vxlan、IPsec、MacVlan，UFleet产品网络这块支持Flannel、Calico；不同的场景，不同的需求对网络这块的要求也不一样，比如不需要网络隔离，单台主机容器数不超过254个，就可以选用Flannel网络，毕竟它部署简单，性能也还不错。

Q12：kubernetes网络复杂，如果要实现远程调试，该怎么做，端口映射的方式会有什么样的隐患？

A： kubernetes网络这块采用的是CNI规范，网络插件化，非常灵活，不同的网络插件调试的方法也是不一样的；端口映射方式的最大隐患就是很容易造成端口冲突。

Q13：rpc的服务注册，把本机ip注册到注册中心，如果在容器里面会注册那个虚拟ip，集群外面没法调用，有什么好的解决方案吗？

A：kubernetes service到pod的通信是由kube-proxy代理分发，而pod中容器的通信是通过端口，不同service间通信可以通过dns，不一定要使用虚拟IP。

Q14：我现在才用的是coreos作为底层，所以网络采用的是flannel 但是上层用calico作为network policy，最近有一个canal的结构和这个比较类似，能介绍一下么，可以的话，能详细介绍一下CNI原理和callico的policy实现么？

A：canal不是很了解；CNI并不是网络实现，它是网络规范和网络体系，从研发的角度它就是一堆接口，关心的是网络管理的问题，CNI的实现依赖于两种plugin，一种是CNI Plugin负责将容器connect/disconnect到host中的vbridge/vswitch，另一种是IPAM Plugin负责配置容器namespace中的网络参数；Calico 的policy是基于iptables, 保证通过各个节点上的 ACLs 来提供workload 的多租户隔离、安全组以及其他可达性限制等功能。

Q15：您好，想问下不同网络方案的性能对比测试有什么工具吗？

A：工具有很多，比如sysbench测试CPU/内存/文件，iperf测试网络带宽，qperf测试网络带宽及延时。

Q16：Calico依赖了尚不稳定的(Alpha Feature)CNI，生产环境中应用的风险贵司是怎么考虑的？

A：目前Calico最新的cni-plugin版本是v1.8.3，已经比较稳定了，至于生成环境是否使用Calico网络还得看具体业务对网络的要求而定。

Q17：cni是怎么管理网络的？或者说它跟网络方案之间是怎么配合的？

A：CNI并不是网络实现，它是网络规范和网络体系，从研发的角度它就是一堆接口，你底层是用Flannel也好、用Calico也好，它并不关心，它关心的是网络管理的问题，CNI的实现依赖于两种plugin，一种是CNI Plugin负责将容器connect/disconnect到host中的vbridge/vswitch，另一种是IPAM Plugin负责配置容器namespace中的网络参数。

Q18：service是个实体组件么？那些个service配置文件，什么部件来执行呢？

A：Services是Kubernetes的基本操作单元，是真实应用服务的抽象，service ip范围在配置kube-apiserver服务的时候通过--service-cluster-ip-range参数指定，由Kubernetes集群自身维护。

Q19：关于集群多节点共同写入日志到存储，有没有好的跨节点共享存储写入方案？

A：这种有很多方案，比如NFS，另外有容云也有自己的存储产品，有兴趣可以联系有容云详细了解。

Q20：service cluster ip后端的选择是随机的。可以通过将service.spec.sessionAffinity设置为“ClientIP”来选择基于客户端IP的会话关联。这个的实现原理是什么?还有没有类似轮询等其它策略?

A：设置了这个参数后，相当于将会话与客户端关联起来了，实现会话保持，设置后就没有轮询机制了。

Q21：市面上是否有扫描容器网络安全性的工具呢？

A：有关容器网络方面的扫描，据我了解，国外有2家，TwistLock和Aqua，国内除了有容云的 AppSafe ，还没有其他公司有容器网络安全方面的产品，有兴趣可以联系有容云详细了解。

Q22：k8s可以跨资源整合调度吗？比如我有两个机器，分别四块gpu，这时有人提交了一个8gpu的yaml，k8s会把两个机器的4块gpu整合到一起共同提供计算吗？

A：Kubernetes namespace是一个逻辑资源的划分，pod是运行在主机上的，首先要保证主机上的可使用资源要大于pod的请求资源，pod才能运行。

Q23：多个容器被分配的ip，都是内网ip么？是不是宿主机上的ip才是外部可访问的ip呢？客户机->宿主机->loadbalancer->docker内部路由（iptables或者其他机制）-> 目标服务容器，是这样子么？

A：从Docker层面讲，容器分配的IP是基于docker0网桥的内网IP，外部只能访问容器所在宿主机的IP，要想访问容器，可以将容器暴露给主机端口，外部可以通过宿主机IP+端口来访问容器。

Q24：您好，请问批量更新容器内的服务有没有自动化的好的方式?

A：Kubernetes可以通过kube-dns来自动发现服务。

Q25：假设有一个运行在docker中的mysql，在宿主机运行一个 java 服务端程序，可以访问docker中的数据库么？这时通信使用的是local的iptables映射直接通信，还是经过了docker0这个网桥进行的通信？

A：将 mysql 容器端口暴露给宿主机端口，宿主机的java程序可以通过local+端口直接和mysql容器直接通信。

Q26：k8s可以跨资源整合调度吗？比如我有两个机器，分别四块gpu，这时有人提交了一个8gpu的yaml，k8s会把两个机器的4块gpu整合到一起共同提供计算吗？

A：Kubernetes namespace是一个逻辑资源的划分，pod是运行在主机上的，首先要保证主机上的可使用资源要大于pod的请求资源，pod才能运行。

以上就是本文的全部内容，希望对大家的学习有所帮助，也希望大家多多支持 码农网

查看所有标签

本站部分资源来源于网络，本站转载出于传递更多信息之目的，版权归原作者或者来源机构所有，如转载稿涉及版权问题，请联系我们。