kubernetes - 无法 ping 一个服务到 Kubernetes 集群中的另一个服务?
问题描述
我创建了一个本地 ubuntu Kubernetes 集群,有 1 个主节点和 2 个从节点。
我在 2 个 pod 中部署了 2 个应用程序并为这两个 pod 创建了服务,它工作正常。我通过键入此命令进入 pod 内部,
$ kubectl exec -it firstpod /bin/bash
# apt-get update
无法进行更新,我收到一个错误:
Err http://security.debian.org jessie/updates InRelease
Err http://deb.debian.org jessie InRelease
Err http://deb.debian.org jessie-updates InRelease
Err http://security.debian.org jessie/updates Release.gpg Temporary failure resolving 'security.debian.org' Err http://deb.debian.org jessie-backports InRelease
Err http://deb.debian.org jessie Release.gpg Temporary failure resolving 'deb.debian.org' Err http://deb.debian.org jessie-updates Release.gpg Temporary failure resolving 'deb.debian.org' Err http://deb.debian.org jessie-backports Release.gpg Temporary failure resolving 'deb.debian.org' Reading package lists... Done W: Failed to fetch http://deb.debian.org/debian/dists/jessie/InRelease
W: Failed to fetch http://deb.debian.org/debian/dists/jessie-updates/InRelease
W: Failed to fetch http://security.debian.org/dists/jessie/updates/InRelease
W: Failed to fetch http://deb.debian.org/debian/dists/jessie-backports/InRelease
W: Failed to fetch http://security.debian.org/dists/jessie/updates/Release.gpg Temporary failure resolving 'security.debian.org'
W: Failed to fetch http://deb.debian.org/debian/dists/jessie/Release.gpg Temporary failure resolving 'deb.debian.org'
W: Failed to fetch http://deb.debian.org/debian/dists/jessie-updates/Release.gpg Temporary failure resolving 'deb.debian.org'
W: Failed to fetch http://deb.debian.org/debian/dists/jessie-backports/Release.gpg Temporary failure resolving 'deb.debian.org'
W: Some index files failed to download. They have been ignored, or old ones used instead.
我正在尝试 ping 我的第二个 pod 服务:
# ping secondservice (This is the service name of secondpod)
PING secondservice.default.svc.cluster.local (10.100.190.196): 56 data bytes
unable to ping.
如何从第一个节点 ping/调用第二个服务?
解决方案
我在那里看到两个(不相关的)问题。我将专注于第二个,因为第一个对我来说不清楚(问的是什么?)。
因此,您想知道为什么以下内容不起作用:
# ping secondservice
这不是错误或意外(实际上,我在这里写过)。简而言之:FQDNsecondservice.default.svc.cluster.local
通过 DNS 插件解析为一个虚拟 IP(VIP),这个 VIP 的本质是它是虚拟的,也就是说,它不连接到网络接口,它只是一堆 iptables 规则。因此,基于 ICMP 的 ping 没有什么可对付的,因为它不是“真正的”IP。不过,您可以curl
使用该服务。假设服务在端口 9876 上运行,以下应该可以工作:
# curl secondservice:9876
推荐阅读
- azure - 为什么持久功能需要太多时间才能“完成”?
- express - 服务器没有运行
- r - R tidyverse 工作流程中的逐步模型选择
- python - float64 在 netcdf4 中写入 nan
- php - 如何在 jQuery 包含之后放置 jQuery 代码?
- c# - 反序列化 DateTime 格式不适用于周二缩写
- machine-learning - 为什么每个时代之后损失突然下降?
- authentication - IdentityServer4 用户范围/权利/声明?
- css - :not(:has(td[rowspan])) 的 CSS 选择器?
- python - 散景:为什么 factor_cmap 可以在 vbar 中工作,但不能在行中工作?