baby sword‘s blog
xugaoyi
2023-09-15
目录

k8s中的网络(二)

# k8s 网络组件

#

# 一. 常见的网络组件

​ 1. Flannel：Flannel 是一个简单而高效的网络解决方案，用于在 Kubernetes 集群中提供网络通信。它使用了虚拟网络 overlay 网络模型，通过创建一个覆盖整个集群的子网，为每个 Pod 分配唯一的 IP 地址。Flannel 支持多种后端驱动程序，如 VxLAN、Host-Gateway、AWS VPC 等，可以根据实际需求选择合适的驱动程序。

​ 2. Calico：Calico 是一个强大的开源网络和网络安全解决方案，为 Kubernetes 提供高度可扩展的网络功能。它通过使用 BGP（Border Gateway Protocol）协议和路由器技术将 Pod 网络连接到集群外部网络。Calico 还提供了网络策略功能，允许管理员定义细粒度的网络访问控制规则。

# 二. k8s不安装网络组件会怎么样

​ 1. Pod 之间无法进行网络通信：网络组件负责为 Pod 分配唯一的 IP 地址，并设置网络路由，以便 Pod 之间可以相互通信。如果没有网络组件，Pod 将无法建立网络连接，无法通过 IP 地址进行通信。

​ 2. Pod 无法与集群外部进行通信：网络组件还负责将 Pod 与集群外部的网络连接起来，以便与其他服务或用户进行通信。如果没有网络组件，Pod 将无法与集群外部的网络进行通信，无法提供对外部的服务访问。

​ 3. 缺乏网络策略和安全性控制：网络组件通常还提供网络策略功能，允许管理员定义细粒度的网络访问控制规则。如果没有网络组件，将无法实施网络策略，无法控制 Pod 之间的网络流量和安全性。

​ 4. 缺乏网络功能扩展和性能优化：网络组件通常提供诸如负载均衡、网络隔离、网络拓扑优化等功能，以提高集群的性能和可扩展性。如果没有网络组件，将无法利用这些功能，可能会影响集群的性能和可靠性。

# k8s网络概述

节点网络

img

节点网络必须在物理上是可达的。在我们的k8s创建之前，机器之间应该是可以ping通过的，无论是L2还是L3层的通信（影响CNI的选择），所以k8s集群是不负责节点网络的，节点网络之间的通信应该在最开始就已经创建完成。

容器网络

img

​ ● pod在相同node上传达

​ ● pod跨node之间可达

​ ● CNI插件负责创建维护

同一个节点内，pod与pod之间通过虚拟网卡和交换机实现二层网络通信，不同节点的pod之间的通信通过虚拟网卡、交换机、隧道技术等实现。由谁来负责创建容器的网络呢？通过CNI插件来负责创建

集群网络

img

​ ● 提供服务的抽象

​ ● 服务到pod的动态映射

​ ● 提供负载均衡

​ ● 提供服务发现

通过容器网络我们知道，每一个pod都会分配一个ip地址，但是其实我们每一个pod中的容器访问不同的服务时，我们写的并不是ip地址，而是一个服务名，通过服务名来访问，一是ip地址变化时，我们容器中的服务名不需要变化，二是利用服务名的机制我们可以实现负载均衡。

所以集群网络将同一类pod的网络可以抽象为一个svc，这样不同的pod可以通过访问svc的方式去访问不同的pod。这个集群网络由k8s自己的组件进行维护

网络安全

​ ● 外部网络访问

​ ● 安全策略

例如我们有pod像前端、后端、数据库。那么，我们希望前端不能直接访问数据库pod，这就是一种安全策略。同时我们希望外部网络不能直接访问我们的pod，而是通过一个边缘节点提供公网后，进行访问，内部其他节点都是私有网络。

# 三. 网络基础

# TCP/IP网络模型

img

# 二层网络通信

img

ARP协议，广播

缓存表

# 三层网络通信

img

当我们的电脑（私网ip）想要访问公网时（公网ip）

这个时候依然会先进性arp协议的询问，路由器发现这个目的地址不在自己的网段内，就会把路由器的mac地址返回，并通过路由器逐渐路由到外部网络。同时外部网络访问我们的内部网络，会通过nat协议进行公网到内网的转化。

# 虚拟机和容器网络

img

img

关键点：网络命名空间、网桥、虚拟网卡对

# 四. 容器网络

# pod网络创建过程

什么是CRI k8s中什么是CRI (opens new window)

CRI 是容器运行时接口（Container Runtime Interface）的缩写。它是 Kubernetes 中定义容器运行时与容器管理器（如 kubelet）之间通信的标准接口。

在 Kubernetes 中，容器运行时负责管理和执行容器的生命周期，包括创建、启动、停止和销毁容器。而容器管理器（kubelet）负责与容器运行时进行交互，并协调容器在集群中的部署和调度。

为了实现容器运行时与容器管理器之间的解耦和可扩展性，Kubernetes 引入了 CRI。CRI 定义了一组标准化的 gRPC 接口和协议，用于容器运行时和容器管理器之间的通信。

通过 CRI，容器管理器（kubelet）可以与任何符合 CRI 接口规范的容器运行时进行通信，而无需直接依赖于特定的容器运行时实现。这使得 Kubernetes 可以支持多种容器运行时，如 Docker、Containerd、CRI-O 等，而无需修改容器管理器的代码。

CRI 接口包括一些核心功能，如创建和销毁容器、容器状态查询、日志获取、端口转发等。通过 CRI，容器管理器可以以统一的方式与不同的容器运行时进行交互，从而提供对容器的一致管理和操作。

总的来说，CRI（容器运行时接口）定义了容器运行时与容器管理器之间的标准化接口，使得 Kubernetes 能够与不同的容器运行时进行交互和管理容器。这种解耦和可扩展性为 Kubernetes 提供了更大的灵活性和可选性。

什么是CNI K8s中什么是CNI (opens new window)

CRI 是容器运行时接口（Container Runtime Interface）的缩写。它是 Kubernetes 中定义容器运行时与容器管理器（如 kubelet）之间通信的标准接口。

在 Kubernetes 中，容器运行时负责管理和执行容器的生命周期，包括创建、启动、停止和销毁容器。而容器管理器（kubelet）负责与容器运行时进行交互，并协调容器在集群中的部署和调度。

为了实现容器运行时与容器管理器之间的解耦和可扩展性，Kubernetes 引入了 CRI。CRI 定义了一组标准化的 gRPC 接口和协议，用于容器运行时和容器管理器之间的通信。

通过 CRI，容器管理器（kubelet）可以与任何符合 CRI 接口规范的容器运行时进行通信，而无需直接依赖于特定的容器运行时实现。这使得 Kubernetes 可以支持多种容器运行时，如 Docker、Containerd、CRI-O 等，而无需修改容器管理器的代码。

CRI 接口包括一些核心功能，如创建和销毁容器、容器状态查询、日志获取、端口转发等。通过 CRI，容器管理器可以以统一的方式与不同的容器运行时进行交互，从而提供对容器的一致管理和操作。

总的来说，CRI（容器运行时接口）定义了容器运行时与容器管理器之间的标准化接口，使得 Kubernetes 能够与不同的容器运行时进行交互和管理容器。这种解耦和可扩展性为 Kubernetes 提供了更大的灵活性和可选性。

什么是pause sandbox k8s中什么是pause sandbox (opens new window)

在 Kubernetes 中，"Pause Sandbox" 是一种特殊的容器，用于创建 Pod。Pod 是 Kubernetes 中的最小部署单位，它可以包含一个或多个容器。

当创建一个 Pod 时，Kubernetes 创建一个额外的容器，称为 "Pause Sandbox" 或 "Pause Container"。这个容器是一个非常轻量级的容器，它没有实际的应用程序运行在内部。它的主要目的是为了管理 Pod 的网络和命名空间。

Pause Sandbox 容器在创建 Pod 时被添加到 Pod 中，并与其他容器共享相同的网络命名空间和存储卷。它会创建一个网络命名空间，并为 Pod 中的其他容器提供网络隔离。Pause Sandbox 容器会自动分配一个 IP 地址，并为 Pod 中的其他容器设置网络路由和通信规则。

通过将所有容器共享相同的网络命名空间，Pod 中的容器可以通过 localhost 进行相互通信，就好像它们运行在同一个主机上一样。Pause Sandbox 容器还负责在 Pod 中的所有容器之间转发网络流量，以实现容器之间的通信。

因此，Pause Sandbox 容器在 Kubernetes 中起到了重要的角色，它提供了 Pod 级别的网络隔离和网络管理功能。它使得 Pod 内的多个容器可以共享网络资源，并通过共享的网络命名空间进行通信。

什么是route table k8s中route table是什么 (opens new window)

在 Kubernetes (K8s) 中，"Route Table"（路由表）是网络路由的管理机制，用于定义和控制 Pod 和 Service 之间的网络通信。

路由表是一个包含路由规则的数据结构，它决定了网络数据包在网络中的传输路径。每个节点（Node）上都有一个路由表，用于确定如何将数据包从一个网络接口转发到另一个网络接口。

在 Kubernetes 集群中，每个节点都有一个网络路由表，用于处理 Pod 和 Service 的网络流量。路由表中的规则定义了如何将数据包转发到正确的目标，以实现跨节点的网络通信。

以下是一些与路由表相关的概念和组件：

​ 1. Pod 网络路由：在 Kubernetes 中，每个 Pod 都有一个唯一的 IP 地址。路由表规则将流量从节点的网络接口转发到正确的 Pod IP 地址，以实现容器之间的通信。

​ 2. Service 网络路由：Kubernetes 的 Service 提供了一种抽象层，允许将多个 Pod 组合成一个逻辑单元，并通过负载均衡器将流量分发到这些 Pod。路由表规则将 Service 的流量转发到相应的 Pod IP 地址，以实现 Service 的访问。

​ 3. 跨节点通信：当 Pod 或 Service 跨越多个节点时，路由表规则将决定数据包在网络中的传输路径，确保数据包能够正确地到达目标节点。

通过管理路由表，Kubernetes 可以实现 Pod 和 Service 之间的网络隔离、负载均衡和跨节点通信。路由表规则由 Kubernetes 系统自动管理，根据 Pod 和 Service 的创建、删除和调度等操作动态更新。

需要注意的是，具体的路由表实现和配置可能会根据使用的网络插件、操作系统和网络设备而有所不同。因此，对于特定的 Kubernetes 部署，路由表的细节和配置可能会有所差异。

img

大概过程，当我们通过kubectl创建一个pod时，首先会将相应的请求打到我们的apiServer当中，在由master Schedule决定该pod会被调用到哪一个node中，之后将命令通过apiServer传输到对应的kubelet，kubelet调用CRI接口来创建对应的pod，pod创建过程中还会启动一个pause sandbox用于统一pod内的容器的网络环境、存储环境等。pause sandbox创建完成后，kubelet会调用CNI接口建立pod间的网络通信，如下:

img

CNI插件会在对应的pod上创建对应的路由表，并创建网络接口并分配网络地址。同时会在主机node上创建对应的网桥，路由表，虚拟网卡接口等。这样，就可以实现pod到主机之间的网络通信，多个pod都与主机建立了通信，那么pod之间也就可以间接的通信。

​ ● CNI 插件定义规范和功能

img

# calico 组件

什么是mesh网络 什么是mesh网络 (opens new window)

Mesh 网络是一种网络拓扑结构，其中每个节点都直接连接到其他节点，形成一个完全互联的网络。在 Mesh 网络中，数据包可以通过多个路径从源节点传输到目标节点，而不需要经过中心路由器或交换机。

Mesh 网络可以分为两种类型：物理 Mesh 网络和逻辑 Mesh 网络。

​ 1. 物理 Mesh 网络：在物理 Mesh 网络中，每个节点都直接通过物理链接连接到其他节点。这种拓扑结构可以提供高度的冗余性和可靠性，因为如果一个节点或链接发生故障，数据包仍然可以通过其他路径传输。

​ 2. 逻辑 Mesh 网络：在逻辑 Mesh 网络中，节点之间的连接是通过软件定义的方式建立的，而不是物理链接。这种拓扑结构通常通过使用网络协议和技术来实现，例如虚拟专用网络（VPN）、隧道协议和网络编程。

Mesh 网络在现代应用和服务的部署中扮演着重要的角色。它提供了以下优势：

​ 1. 可扩展性：由于每个节点都直接连接到其他节点，Mesh 网络可以轻松地扩展到大规模的节点数量，而无需依赖中心化的设备或路由器。

​ 2. 冗余和可靠性：Mesh 网络具有高度的冗余性，即使某个节点或链接发生故障，数据包仍然可以通过其他路径传输，从而提供更高的可靠性和容错能力。

​ 3. 灵活性：Mesh 网络允许任意节点之间的直接通信，这为实现复杂的网络拓扑和策略提供了灵活性。它可以支持多种通信模式，如点对点通信、多对多通信等。

​ 4. 安全性：Mesh 网络可以通过加密和认证等技术提供更高的安全性。逻辑 Mesh 网络中的节点可以通过 VPN 或其他安全隧道协议进行安全通信。

Mesh 网络在容器编排平台（如 Kubernetes）和服务网格（如 Istio）等现代应用和基础设施中得到广泛应用。它提供了强大的网络架构和通信模式，以支持复杂的微服务架构和应用程序交互。

什么是BGP网络 什么是BGP (opens new window)

BGP（Border Gateway Protocol）是一种用于在互联网中交换路由信息的协议。它是一种自治系统（AS）之间的外部网关协议，用于实现不同自治系统之间的路由选择和交换。

BGP 是一种路径矢量协议，其主要功能是在自治系统之间交换网络可达性信息。每个自治系统都可以通过 BGP 向其他自治系统宣告自己的路由信息，并学习其他自治系统宣告的路由信息。BGP 基于各自治系统之间的策略和路由策略来决定最佳的路由路径。

BGP 具有以下主要特点：

​ 1. 可靠性：BGP 支持可靠的路由选择和路径决策机制。它会考虑多个因素，如网络距离、自治系统的策略和策略属性等，来选择最佳的路径。

​ 2. 有向无环图（DAG）：BGP 的路由信息交换形成了一个有向无环图结构，其中自治系统之间的路由关系形成了多个路径。这种结构确保了网络的冗余性和可靠性。

​ 3. 策略控制：BGP 允许自治系统在路由选择时应用各种策略。自治系统可以根据自身需求和政策来选择和控制路由流量，以实现网络流量优化和管理。

​ 4. 扩展性：BGP 具有良好的扩展性，可以应对互联网规模的增长和复杂性。它支持分层、聚合和汇总等技术，以减少路由信息的传输和存储开销。

BGP 在互联网中起着关键的作用，它连接了全球的自治系统，使得不同网络之间能够互相通信和交换数据。BGP 的使用使得互联网具备了分布式、自治和可扩展的特性，为网络的稳定运行和全球互联提供了基础。

img

calico就是通过BGP协议来进行网络通信的

k8s中calico的相关组件

calico-kube-controllers: 与apiServer通信，用于监听calico想要监听的事件

calicoCtl ：用户用来操作的命令行工具（需要单独安装）

calicoctl get nodes -o wide
1

img

etcd: 用户存储服务

以上的服务都运行在主机节点或者其他地方。

剩下的服务是每个node当中都会运行一套：Felix、confd、BIRD

这个三个服务在一个pod当中，每个node都会运行这么一个守护pod

img

当我们新创建一个pod时，对应calico会分配对应的ip地址并记录到etcd中，这个时候，Felix会监听到etcd的变化，并把对应的iptable数据项进行更新，而且会通过BIRD这种BGP协议在多个节点之间更新路由表信息

当创建一个pod时，calico是如何分配ip地址的？

可以使用host-local和calico-ipam方式，默认方式是calico-ipam。

host-local是会为当前node分配一个网段，里面的pod在该网段分配的子网中进行划分地址。简单，但是缺点是无法提现calico的管理网络功能。

配置文件地址 /etc/cni/net.d/10-calico.conflist

root@k1:/etc/cni/net.d# cat /etc/cni/net.d/10-calico.conflist
{
  "name": "k8s-pod-network",
  "cniVersion": "0.3.1",
  "plugins": [
    {
      "type": "calico",
      "log_level": "info",
      "log_file_path": "/var/log/calico/cni/cni.log",
      "datastore_type": "kubernetes",
      "nodename": "k1",
      "mtu": 0,
      "ipam": {
          "type": "calico-ipam"
      },
      "policy": {
          "type": "k8s"
      },
      "kubernetes": {
          "kubeconfig": "/etc/cni/net.d/calico-kubeconfig"
      }
    },
    {
      "type": "portmap",
      "snat": true,
      "capabilities": {"portMappings": true}
    },
    {
      "type": "bandwidth",
      "capabilities": {"bandwidth": true}
    }
  ]
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33

几个重要命令：

ip link 查看当前节点的网卡信息

ifconfig 查看网卡对应的ip地址

route -n 查看当前节点的路由表 route -n (opens new window)

kubectl get pod -o wide -A 查看对应pod的ip地址

不同node的pod之间如何通信，案例：不同node之间的pod是如何进行通信d (opens new window)

# 多网络场景

一个pod存在多个网卡的情况

img

可以使用Multus插件来使用多场景、多网卡

img

如图所示，这个插件下可以使用更多的其他CNI插件

# 五.集群网络

当一个node中的某一个pod宕机了后，会创建一个新的pod，那么这个新的pod就会分配新的ip地址。

将一组pod抽象成一个类型service，其他服务想要调用时直接调用这个service，然后由这个service去决定流量分发到什么地方

# servcice工作机制

声明式系统工作原理：什么是声明式系统 (opens new window)

是的，Kubernetes（K8s）可以被认为是一个声明式系统。

在Kubernetes中，您通过定义所需的状态（状态声明）来描述您希望系统达到的目标状态，而不需要指定实现这个状态所需的具体步骤和操作。您可以使用Kubernetes对象的声明式配置文件（例如YAML）来定义这些状态，例如定义Pod、Deployment、Service等。

Kubernetes的控制器和调度器负责将实际状态与所需状态进行比较，并根据需要采取适当的操作来使系统达到所需状态。这意味着Kubernetes会自动处理资源的创建、调度、伸缩和故障恢复等任务，以使集群中的实际状态与您声明的状态保持一致。

通过声明式的方式，您可以通过更新声明文件来指定所需的更改，而不是手动执行一系列命令或脚本来达到目标状态。Kubernetes将负责处理这些更改，确保系统按照您的期望进行配置和管理。

声明式系统的优势在于简化了管理和维护复杂的分布式系统，提供了可预测性和一致性。Kubernetes中的声明式方式使得应用程序的部署和管理更加可靠和可扩展。

Kubernetes（K8s）是一个基于声明式系统原理的容器编排平台。下面是Kubernetes声明式系统的原理概述：

​ 1. 状态声明：在Kubernetes中，您使用声明式配置文件（如YAML）来定义所需的系统状态。这些配置文件描述了您希望集群中的资源（如Pod、Deployment、Service等）处于的状态。

​ 2. 控制循环：Kubernetes控制循环是Kubernetes系统的核心组件，负责将实际状态与声明的状态进行比较，并采取适当的操作来使系统达到所需状态。控制循环包括以下步骤：

​ a. 观察（Observe）：控制循环观察集群中的实际状态，包括当前运行的Pod、节点状态等。

​ b. 比较（Compare）：将实际状态与声明的状态进行比较，确定是否存在差异。

​ c. 调谐（Reconcile）：根据比较结果，采取适当的操作来使实际状态与声明的状态保持一致。这可能涉及创建、更新或删除资源。

​ 3. 控制器：Kubernetes的控制器是控制循环的实现者。每个资源类型（如Pod、Deployment等）都有一个关联的控制器，负责管理该资源的实际状态。控制器监视该资源的状态变化，并根据需要执行相应的操作。

​ 4. 自愈性：Kubernetes的声明式系统具有自愈性的能力。当集群中的资源状态与声明的状态不一致时，控制器会自动采取恢复操作，例如重新创建失败的Pod、调度到健康的节点等。

通过声明式系统，Kubernetes提供了一种高级抽象的方式来管理和编排复杂的分布式系统。您只需关注所需的状态，并使用适当的配置文件进行声明，而不需要关心实现这些状态所需的具体步骤。Kubernetes负责管理和协调底层资源，以确保系统按照您的期望工作。这种声明式的方式提供了可预测性、一致性和可伸缩性，使得应用程序的部署和管理更加可靠和高效。

controller的重要作用：可以看下CRD里面的controller 什么是CRD (opens new window)

kubectl中每个资源可以看做CRD，每个 CRD 都有一个搭配的controller，这个controller 用于监控资源是否有变动，并做出进一步的动作。

那么我们的service资源按理来说也有对应的controller。

下面说一下一个service的创建过程

img

当我们定义好了一个yaml文件后，通过kubectl命令将对应的请求发送到我们的apiserver，apiServer再转发到controller，controller根据yaml文件中service名字，并自动为service分配一个ip地址【取决于service分配到哪个pod】组成键值对放在etcd中，同时还会创建一个与servcie同名的endpoint，endpoint用于表示该service关联了哪些pod【通过yaml的Selector进行选择】。这样当一条流量打到service后，service可以找到对应的endpoint，并通过一定的负载均衡将流量导入到其中的一个pod

ipvs和iptable是什么

同时每个节点的kube_proxy会订阅etcd的变化，当感知到变化后，kube_proxy会更新本地的iptables，对应的数据还会再NAT映射，映射到我们实际的pod当中。

因为k8s是一个声明式的系统，如果我们某一个pod挂掉了后，kube-controller会感知到，然后会到etcd中奖对应的endpoint的ip地址删除掉。同事proxy也感知到了etcd变化，proxy会将本地的iptable进行修改。当我们的pod创建成功后，controller感知并在etcd中新增endpoint，proxy感知并在iptable中创建新数据。

这里我们访问也可以通过DNS来进行访问。

深入：需要了解iptables相关概念

iptables -n -t nat -L KUBE-SERVICES

service的几种类型

img

ClusterIP

ClusterIP 是默认的 Service 类型。它将 Service 暴露在集群内部，只能在集群内部访问。通过 ClusterIP，可以为 Service 分配一个虚拟 IP 地址，其他 Pod 或 Service 可以使用该 IP 地址来访问该 Service。这种类型适用于内部服务，不需要从集群外部访问。

NodePort

​ NodePort 类型的 Service 通过在每个节点上暴露一个静态端口，将 Service 的访问暴露到集群外部。外部客户端可以通过节点的 IP 地址和静态端口来访问 Service。NodePort Service 会将流量转发到后端 Pod。这种类型适用于需要从外部访问 Service 的场景，但不适合生产环境，因为端口范围受限。

LoadBalancer

​ LoadBalancer 类型的 Service 通过云服务提供商提供的负载均衡器（Load Balancer）将 Service 暴露到外部。负载均衡器会分配一个唯一的外部 IP 地址，并将流量转发到 Service 的后端 Pod。这种类型适用于需要在外部暴露 Service，并且需要使用负载均衡器来处理流量分发的场景。

ExternalName

​ ExternalName 类型的 Service 是一种简单的映射服务，它将 Service 的访问重定向到集群外部的其他 DNS 记录。它不会分配 ClusterIP 或将流量转发到任何 Pod，而是通过返回给定的外部 DNS 名称的 CNAME 记录来提供别名访问。

# k8s中的服务发现和DNS

img

DNS服务本身也是在pod中，所以在master节点上会有几个DNS pod服务，同时还有有一个service选中了这几个coredns，当外面的pod请求dns service时，就会将流量负载均衡到dns pod。我们看看实际pod和service:

对应的dns pod分配在master节点当中：

img

我们再来看看对应的service：

img

所以当我们访问这个dns service时，流量就会打到我们的dns pod上。

我们每个pod如果没有特殊的配置的话，其域名的地址都将是这个service，我们随便进入一个pod当中，使用命令cat /etc/rsolv.conf来进行查看

resolv.conf (opens new window)

img

在Linux系统中，/etc/resolv.conf 是一个配置文件，用于配置系统的域名解析设置。它包含了用于解析域名的域名服务器（DNS服务器）的配置信息。

具体来说，/etc/resolv.conf 文件通常包含以下配置项：

  1. nameserver：指定 DNS 服务器的 IP 地址。可以配置多个 nameserver 条目，按优先级顺序进行尝试。例如：

    ```

    nameserver 8.8.8.8

    nameserver 8.8.4.4

    ```

  2. search：指定默认的搜索域名。当进行主机名解析时，如果没有指定完整的域名，系统会自动在搜索域名列表中进行搜索。例如：

    ````

    search example.com

    ```

  3. domain：指定默认的域名。如果没有指定完整的域名，系统会将主机名与默认域名拼接在一起进行解析。例如：

    ````

    domain example.com

    ```

  4. options：指定其他的解析选项，如超时时间、是否启用递归解析等。例如：

    ````

    options timeout:2 attempts:3

    ```

这些配置项可以根据需要进行配置，以满足特定的网络环境和需求。当系统需要进行域名解析时，会根据 /etc/resolv.conf 中的配置来选择合适的 DNS 服务器进行查询。

需要注意的是，/etc/resolv.conf 是一个常见的配置文件，但具体位置和名称可能因不同的 Linux 发行版或网络配置管理工具而异。因此，在特定的系统中，可能会有其他位置和名称的配置文件来管理域名解析设置。

这里看到这个pod默认使用的DNS就是我们k8s集群中的系统dns。

那么这个可以配置吗？是可以的，每个pod都可以配置其dns策略。

​ ● Default：该配置只能解析注册到互联网上的外部域名，无法解析集群内部域名，表示 Pod 里面的 DNS 配置继承了宿主机上的 DNS 配置。简单来说，就是该 Pod 的 DNS 配置会跟宿主机完全一致，也就是和node上的dns配置是一样的。

​ ● ClusterFirst：应用对接Kube-DNS/CoreDNS。这种场景下，容器既能够解析service注册的集群内部域名，也能够解析发布到互联网上的外部域名。不过ClusterFirst 还有一个特例，如果你的 Pod 设置了 HostNetwork=true，则 ClusterFirst 就会被强制转换成 Default。

​ ● ClusterFirstWithHostNet：如果pod是桥接的模式， dnsPolicy 将设置为ClusterFirstWithHostNet，他将同时继承default和ClusterFirst的DNS解析。

​ ● None：表示会清除 Pod 预设的 DNS 配置，当 dnsPolicy 设置成这个值之后，Kubernetes 不会为 Pod 预先载入任何自身逻辑判断得到的 DNS 配置。因此若要将 dnsPolicy 的值设为 None，为了避免 Pod 里面没有配置任何 DNS，最好再添加 dnsConfig 来描述自定义的 DNS 参数。

img

nslookup ip地址 DNS服务 nslookup (opens new window)

nslookup 是一个常用的网络工具，用于查询域名系统（DNS）信息。它在大多数操作系统中都可用，包括 Windows、Linux 和 macOS。

通过使用 nslookup 命令，可以执行以下操作：

  1. 域名解析：通过提供主机名或域名作为参数，nslookup 可以查询与之关联的 IP 地址。例如，使用以下命令查询 example.com 的 IP 地址：

    ````

    nslookup example.com

    ```

  2. 反向解析：通过提供 IP 地址作为参数，nslookup 可以查询与之关联的主机名。例如，使用以下命令查询 IP 地址 192.0.2.1 的主机名：

    ````

    nslookup 192.0.2.1

    ```

  3. 查询特定类型的 DNS 记录：使用 -type 参数，可以指定要查询的 DNS 记录类型。常见的记录类型包括 A 记录（主机地址记录）、CNAME 记录（别名记录）、MX 记录（邮件交换记录）等。例如，使用以下命令查询 example.com 的 MX 记录：

    ````

    nslookup -type=MX example.com

    ```

  4. 指定 DNS 服务器：通过使用 server 命令，可以指定要使用的 DNS 服务器地址。例如，使用以下命令将 DNS 服务器设置为 8.8.8.8，然后查询 example.com：

    ````

    nslookup

    > server 8.8.8.8

    > example.com

    ```

nslookup 提供了一种交互式的命令行界面，允许用户在命令提示符下进行多个查询，并查看详细的 DNS 解析结果。它在网络故障排除、调试和了解域名解析配置方面非常有用。

# ingress

//TODO

https://www.bilibili.com/video/BV1ve4y1W7o8/?p=5&spm_id_from=pageDriver

编辑 (opens new window)
上次更新: 2024/02/22, 14:03:19
k8s中的网络(一)
扣丁狼k8s（三）存储与配置

← 扣丁狼k8s（三）存储与配置→

最近更新
01
spark基础
02-22
02
mysql读写分离和分库分表
02-22
03
数据库迁移
02-22
更多文章>
Theme by Vdoing | Copyright © 2019-2024 Evan Xu | MIT License