07 Kubernetes 网络与服务管理

课件

Kubernetes Service是一个抽象层，用于定义一组Pod的访问方式和访问策略，其作用是将一组Pod封装成一个服务，提供一个稳定的虚拟IP地址和端口号，以便于其他应用程序或服务进行访问。

以下是Kubernetes Service YAML配置文件的一些重要字段及其解释：

apiVersion: v1
kind: Service
metadata:name: my-servicenamespace: my-namespace
spec:selector:app: my-appports:- name: httpport: 80targetPort: 8080type: ClusterIP

• apiVersion: 指定使用的Kubernetes API版本。
• kind: 指定对象类型，这里是Service。
• metadata: 指定Service的元数据，包括名称、命名空间等信息。
• selector: 指定Service所关联的Pod的标签选择器，用于将Pod与Service关联起来。
• ports: 指定Service所监听的端口，包括端口名称、端口号和目标端口号。其中，端口名称是可选的，目标端口号是Pod中实际监听的端口号。
• type: 指定Service的类型，包括ClusterIP、NodePort、LoadBalancer和ExternalName等。ClusterIP是默认类型，用于将Service暴露到集群内部。NodePort将Service暴露到每个Node的IP地址和端口上。LoadBalancer用于将Service暴露到外部负载均衡器上。ExternalName用于将Service与外部服务关联起来。

除了上述字段外，还可以配置一些高级选项，例如：

apiVersion: v1
kind: Service
metadata:name: my-service
spec:selector:app: my-appports:- name: httpport: 80targetPort: 8080type: ClusterIPsessionAffinity: ClientIPexternalTrafficPolicy: Local

• sessionAffinity: 指定会话亲和性类型，包括None和ClientIP。ClientIP将请求发送到相同的Pod，以保持会话一致性。
• externalTrafficPolicy: 指定外部流量策略，包括Cluster和Local。Cluster将流量分配给所有节点，Local将流量分配给与请求最近的节点。
  
  Kubernetes Endpoints是一种资源对象，用于将Service与其实现的Pod的IP地址和端口号匹配。Endpoints资源通常由Kubernetes API服务器自动创建和更新，以确保Service可以正确地路由到其后端Pod。

Endpoints资源的YAML定义如下：

apiVersion: v1
kind: Endpoints
metadata:name: my-service
subsets:- addresses:- ip: 10.0.0.1- ip: 10.0.0.2ports:- name: httpport: 80protocol: TCP

其中：

• apiVersion：指定Kubernetes API版本。
• kind：指定资源类型，这里是Endpoints。
• metadata：指定资源的元数据，包括名称等。
• subsets：指定一组后端Pod的IP地址和端口。

在subsets中，addresses字段列出了后端Pod的IP地址，ports字段列出了后端Pod的端口号和协议。在上面的示例中，我们定义了一个名为my-service的Endpoints资源，它包含了两个IP地址（10.0.0.1和10.0.0.2）和一个端口号（80）。

这个Endpoints资源的作用是将名为my-service的Service路由到这两个IP地址和端口号所代表的Pod上。如果有更多的Pod加入了这个Service，Kubernetes API服务器会自动更新这个Endpoints资源。

无头服务（Headless Service）是 Kubernetes 中的一种特殊类型的服务。与普通的服务不同，无头服务并不会为 Pod 提供一个稳定的访问 IP，它的 Cluster IP 为 None。这意味着，无头服务并不会进行负载均衡，而是直接将请求转发给后端 Pod，这些 Pod 的 IP 地址将会被暴露出来。

无头服务通常用于需要访问单个 Pod 的场景，例如 StatefulSet 中的每个 Pod 都具有唯一的标识符和状态，需要直接对每个 Pod 进行访问。无头服务可以将所有后端 Pod 的 IP 地址公开出来，以便直接访问每个 Pod。

在创建无头服务时，需要将 spec.clusterIP 设置为 None，并且需要设置 spec.selector 以选择后端 Pod。这样就可以创建一个无头服务了。

无头服务（Headless Service）的好处有以下几点：

1. 直接访问后端 Pod：无头服务不会对请求进行负载均衡，而是直接将请求转发给后端 Pod，这样可以直接访问每个 Pod。

2. 每个 Pod 有唯一的标识符和状态：在某些情况下，每个 Pod 都具有唯一的标识符和状态，需要直接对每个 Pod 进行访问。无头服务可以将所有后端 Pod 的 IP 地址公开出来，以便直接访问每个 Pod。

3. 避免网络代理：在某些情况下，需要直接访问后端 Pod，而不是通过 Service 进行代理。无头服务可以避免网络代理，直接访问后端 Pod。

4. 避免 Service IP 变化：普通的服务会为 Pod 提供一个稳定的访问 IP，但是 Service IP 可能会发生变化，这可能会导致一些问题。无头服务的 Cluster IP 为 None，避免了 Service IP 变化的问题。

综上所述，无头服务可以直接访问后端 Pod，避免了网络代理和 Service IP 变化的问题，适用于一些需要直接访问每个 Pod 的场景。

$ nslookup example.com

$ dig example.com +short

dig example.com +short 是一个在命令行中使用 dig 工具的简单命令。它的作用是查询 example.com 域名的 IP 地址，并以简短的格式输出结果。

具体来说，命令中的参数含义如下：

• dig：命令名，用于查询 DNS 信息。
• example.com：要查询的域名。
• +short：输出简短格式的结果，只显示 IP 地址，不包含其他信息。

$ dig @localhost -t AXFR example.com

该命令表示在本地主机上使用 DNS 协议的 AXFR（Zone Transfer）方式获取 example.com 域名的所有 DNS 记录。

• @localhost：指定 DNS 服务器为本地主机。
• -t AXFR：指定使用 AXFR 方式进行 DNS 记录的传输。
• example.com：指定要获取 DNS 记录的域名。
  
  
  
  
  
  
  是的，Cilium Endpoints 和 Kubernetes Endpoints 之间存在关系。

Kubernetes Endpoints 是 Kubernetes 中的一种资源，用于表示服务的后端。它包含了一组 IP 地址和端口号，代表了服务的所有可用实例。当一个 Pod 加入或离开一个服务时，Kubernetes 会自动更新相应的 Endpoints。

Cilium Endpoints 是 Cilium 的一个概念，它是一个具有特定标识符的网络终端，代表了一个容器或一个 Pod。Cilium 使用 Endpoints 来实现网络安全和服务发现等功能，通过监控 Kubernetes Endpoints 的变化来更新 Cilium Endpoints。

因此，Cilium Endpoints 和 Kubernetes Endpoints 是密切相关的，它们共同组成了 Kubernetes 集群中的网络拓扑，并共同支持了 Kubernetes 中的服务发现和网络安全功能。

Kubernetes Ingress工作在应用层（Layer 7）协议，因为它是一个HTTP(S)负载均衡器。Ingress提供了一种将外部HTTP(S)流量路由到Kubernetes集群内部的机制，通过将请求路由到不同的服务和端点，从而实现负载均衡和流量管理。Ingress控制器使用HTTP请求中的主机名和路径来路由请求到不同的服务，可以根据需要添加SSL/TLS加密和身份验证，提供更高级别的访问控制和安全性。因此，Ingress是在应用层（Layer 7）上工作的，提供了更高级别的网络功能和控制。

Ingress是Kubernetes中的一种资源对象，它定义了如何将外部流量路由到Kubernetes集群中的服务。Ingress YAML配置文件通常包含以下几个部分：

1. metadata：包含Ingress对象的名称、命名空间、标签等元数据信息。

2. spec：定义了Ingress的规则和配置。

   • rules：定义了Ingress的路由规则，包含了host、http、paths等配置。

   • tls：定义了Ingress的TLS配置，可以配置证书、私钥等信息。

   • backend：定义了Ingress的默认后端服务，当没有匹配到任何规则时，请求将被路由到该后端服务。

3. status：包含了Ingress对象的当前状态信息。

一个完整的Ingress YAML配置示例：

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:name: example-ingressnamespace: defaultannotations:nginx.ingress.kubernetes.io/rewrite-target: /
spec:rules:- host: example.comhttp:paths:- path: /app1pathType: Prefixbackend:service:name: app1-serviceport:name: http- path: /app2pathType: Prefixbackend:service:name: app2-serviceport:name: httptls:- hosts:- example.comsecretName: example-tls

上述配置文件定义了一个名为example-ingress的Ingress对象，它包含了两个路由规则，每个规则都定义了一个host和多个路径。当请求的host和路径匹配到规则时，请求将被路由到相应的后端服务。此外，配置文件还定义了TLS配置，使用了名为example-tls的证书。

在Ingress中，host、http和paths是三个不同的配置块，它们的作用如下：

1. host：定义了Ingress的域名或IP地址，用于将请求路由到相应的服务。

2. http：定义了Ingress的HTTP配置，包括了路由规则和TLS配置等。

3. paths：定义了Ingress的路径规则，用于将请求路由到相应的服务。

具体而言，host配置用于指定Ingress的域名或IP地址，可以将不同的域名或IP地址映射到不同的服务上。例如，可以将example.com映射到一个服务，将api.example.com映射到另一个服务。

http配置用于定义Ingress的HTTP配置，包括了路由规则和TLS配置等。在http配置中，可以定义多个路由规则，每个路由规则可以指定一个或多个路径。当请求匹配到某个路由规则时，Ingress会将请求路由到相应的服务上。

paths配置用于定义Ingress的路径规则，用于将请求路由到相应的服务。在paths配置中，可以定义多个路径规则，每个路径规则可以指定一个路径和相应的服务。当请求的路径匹配到某个路径规则时，Ingress会将请求路由到相应的服务上。

总的来说，host用于指定Ingress的域名或IP地址，http用于定义Ingress的HTTP配置，包括了路由规则和TLS配置等，而paths用于定义Ingress的路径规则，用于将请求路由到相应的服务。

自测题

Kubernetes Service 对象的 selector 字段是必须指定的，它定义了 Service 所要选择的 Pod 的标签。如果没有指定 selector 字段，Service 就无法确定它所要代理的 Pod，因此无法工作。在创建 Service 对象时，必须指定 selector 字段，否则会出现错误。