搜索

第 5 章 网络

download PDF

5.1. 网络

5.1.1. 概述

Kubernetes 可确保 pod 能够相互联网,并从内部网络为每个 pod 分配一个 IP 地址。这样可保证 pod 中所有容器的行为如同它们在同一主机上一样。为每个 pod 指定专属的 IP 地址,意味着在端口分配、联网、命名、服务发现、负载均衡、应用程序配置和迁移方面,可以像物理主机或虚拟机一样来对待 pod。

不需要在 pod 间创建链接,我们不推荐使用 IP 地址直接与 pod 进行通信。相反,建议您创建一个服务(service),然后使用服务进行交互。

5.1.2. OpenShift Container Platform DNS

如果您 运行多个服务 (如用于多个 pod 的前端和后端服务),以使 frontend pod 与后端服务通信,则要为用户名、服务 IP 等创建环境变量。如果删除并重新创建服务,可以为该服务分配一个新的 IP 地址,并且需要重新创建 frontend pod 来获取服务 IP 环境变量的更新值。另外,必须在任何 frontend pod 之前创建后端服务,以确保正确生成服务 IP,并将它作为环境变量提供给 frontend pod。

因此,OpenShift Container Platform 具有一个内置 DNS,以便服务 DNS 以及服务 IP/端口能够访问这些服务。OpenShift Container Platform 支持在回答服务的 DNS 查询的 master 上运行 SkyDNS 来拆分 DNS。默认情况下,主设备侦听端口 53。

当节点启动时,以下消息表示 Kubelet 被正确地解析到 master:

0308 19:51:03.118430    4484 node.go:197] Started Kubelet for node
openshiftdev.local, server at 0.0.0.0:10250
I0308 19:51:03.118459    4484 node.go:199]   Kubelet is setting 10.0.2.15 as a
DNS nameserver for domain "local"

如果没有显示第二条消息,则 Kubernetes 服务可能不可用。

在节点主机上,每个容器的名称服务器都有添加到前端的 master 名称,容器的默认搜索域将是 . < pod_namespace& gt; .cluster.local。容器随后会在节点上的任何其他名称服务器之前将任何名称服务器查询定向到主名称服务器,这是 Docker 格式的容器的默认行为。主控机将在具有以下格式的 .cluster.local 域中应答查询:

表 5.1. DNS 示例名称
对象类型示例

默认

<pod_namespace>.cluster.local

服务

<service>.<pod_namespace>.svc.cluster.local

Endpoints

<name>.<namespace>.endpoints.cluster.local

这可以防止重启 frontend pod 以便获取新服务,这将为服务创建新 IP。这也无需使用环境变量,因为 pod 可以使用服务 DNS。另外,由于 DNS 不会改变,您也可以将数据库服务引用为 db.local。也支持通配符查找,因为查找会解析到服务 IP,并且无需在任何 frontend pod 之前创建后端服务,因为服务名称(以及 DNS)已提前建立。

此 DNS 结构还包括无头服务,其中门户 IP 没有分配给服务,kube-proxy 不会为其端点提供负载均衡或提供路由。服务 DNS 仍可被使用,并响应多个 A 记录,一个用于服务的每个 pod,允许客户端在每个 Pod 间进行循环。

Red Hat logoGithubRedditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

通过我们的产品和服务,以及可以信赖的内容,帮助红帽用户创新并实现他们的目标。

让开源更具包容性

红帽致力于替换我们的代码、文档和 Web 属性中存在问题的语言。欲了解更多详情,请参阅红帽博客.

關於紅帽

我们提供强化的解决方案,使企业能够更轻松地跨平台和环境(从核心数据中心到网络边缘)工作。

© 2024 Red Hat, Inc.