跳到主要内容

service

apiVersion: v1
kind: Service
metadata:
  creationTimestamp: null
  labels:
    app: mynginx
  name: mynginx-service
  namespace: dev
spec:
  ports:
  - port: 80
    protocol: TCP
    targetPort: 80
  selector:
    app: mynginx
  type: NodePort
status:
  loadBalancer: {}

获取服务 ip 通过 dns backend database.default svc cluster. l ocal

backend-database 对应于服务名称， default 表示服务在其中定义的名称 空 间，而 svc.cluster.local 是在 所有集群本地服 务名称 中使用的可配置 集群 域后缀。

获取服务 ip 通过 环境变量 KUBIA SERVICE HOST=l0.111.249.153 KUB工A SERVICE PORT=80

BACKENDDATABASESERVICEHOST和BACKENDDATABASE SERVICE PORT去获得IP地址和端口信息。

获取服务 ip 通过 ExternalName type: ExternalName externalName: someapi.somecompany.com ports:

  • port: 80

几种方式可以在外部访问服务: • 将服务的类型设置成NodePort-每个集群节点都会在节点上打开一 个端口， 对于NodePort服务， 每个集群节点在节点本身(因此得名叫 NodePort)上打开一 个端口，并将在该端口上接收到的流量重定向到基础服务。 该服务仅在内部集群 IP 和端口上才可访间， 但也可通过所有节点上的专用端 口访问。 • 将服务的类型设置成LoadBalance, NodePort类型的一种扩展一—这使得 服务可以通过一个专用的负载均衡器来访问， 这是由Kubernetes中正在运行 的云基础设施提供的。 负载均衡器将流量重定向到跨所有节点的节点端口。 客户端通过负载均衡器的 IP 连接到服务。 • 创建一个Ingress资源， 这是一个完全不同的机制， 通过一个IP地址公开多 个服务——它运行在HTTP层(网络协议第7层)上， 因此可以提供比工作 在第4层的服务更多的功能。 我们将在5.4节介绍Ingress资源。

![dc717c4c4d4a403d5f4c4f77bf206415.png] (dc717c4c4d4a403d5f4c4f77bf206415.png)

使用JSONPath获取所有节点的IP

kubecl get nodes -o jsonpath='{.items[*l.etatus. addresses[?(@.type=="ExternalIP")] .address}'



![9ab8a086b070741681eb40294c0d6cac.png](9ab8a086b070741681eb40294c0d6cac.png)

![8fa4fc0c648b0361dd5bce82bae1335e.png](8fa4fc0c648b0361dd5bce82bae1335e.png)

创建证书 openssl genrsa -out tls . key 2048

openssl req -new -x509 -key tls.key -out tls.cert -days 360 -subj /CN=kubia.example.com

kubectl create secret tls tls-secret --cert=tls.cert - -key=tls .key

![fe49e181a963412eb5373061f8b89f09.png] (fe49e181a963412eb5373061f8b89f09.png)

就绪探针的类型 • Exec 探针，执行进程的地方 。容器 的状态由进程的退出状态代码确定 。 •HTTP GET探针，向容器发送 HTTP GET 请求，通过响应的 HTTP 状态代码 判断容器是否准备好 。 • TCP socket 探针，它打开 一 个 TCP 连接到容器的指定端口。如果连接己建立， 则认为容器己准备就绪 。

存活探针通过杀死异常的容器并用新的正常 容器替代它 们来保持 pod 正常工作，而就 绪探针确保只有准备好处理请求的 pod 才可以接收它们(请求)。 这在容器启动时最为必要， 当然在容器运行一 段时间后也 是有用的。

就绪探针确 保客户端只与正常的pod交互， 并且永远不会知道系统存在问题。

![e521d159cb2d7535c8cabc62f04c880b.png] (e521d159cb2d7535c8cabc62f04c880b.png)

![35041e1b06691d06dbe0a477f4424c3e.png] (35041e1b06691d06dbe0a477f4424c3e.png)

如果无法通过服务访问pod, 应该根据下面的列表进行排查: • 首先， 确保从集群内连接到服务的集群IP, 而不是从外部。 • 不要通过ping服务IP 来判断服务是否可 访问(请记住， 服务的集群IP 是虚 拟IP, 是无法ping通的)。 • 如果已经定义了就绪探针， 请确保 它返回成功;否则该pod不会成为服务的 一部分 。 • 要确认某个容器是服务的 一部分， 请使用kubectl get endpoints来检 查相应的端点对象。 • 如果尝试通过FQDN或其中一部分来访问服务(例如， myservice. mynamespace.svc.cluster.local或 myservice.mynamespace), 但 并不起作用， 请查看是否可以使用其集群IP而不是FQDN来访问服务 。 • 检查是否连接到服务公开的端口，而不是目标端口。 • 尝试直接连接到podIP以确认pod正在接收正确端口上的 连接。 • 如果甚至无法通过pod的IP 访问应用， 请确保应用不是仅绑定 到本地主机。

在 Kubernetes 中，Service 与 Pod 的关联是通过标签选择器（Label Selector）来实现的。Service 使用标签选择器来选择一组具有特定标签的 Pod，并为这些 Pod 提供一个稳定的网络终点。

下面是一个示例，展示了如何将 Service 与 Pod 关联起来：

首先，在 Pod 配置中为 Pod 添加一个标签。例如，可以为 Pod 添加一个名为 “app” 的标签，值为 “my-app”：

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
  labels:
    app: my-app
spec:
  containers:
    - name: my-container
      image: my-image
      # 容器配置...

然后，在 Service 的配置中使用相同的标签选择器来选择具有该标签的 Pod。例如，可以创建一个名为 “my-service” 的 Service，并使用标签选择器选择具有 “app=my-app” 的 Pod：

apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  selector:
    app: my-app
  ports:
    - protocol: TCP
      port: 80
      targetPort: 8080

在上面的示例中，Service 的 spec.selector 部分指定了一个标签选择器，即选择具有 “app=my-app” 标签的 Pod。这样，Service 将会与拥有该标签的 Pod 关联起来。

请注意，Service 还定义了一个或多个端口，并将流量转发到这些端口上的 Pod。在上面的示例中，Service 将 TCP 流量转发到 Pod 的端口 8080。

通过这种方式，Service 可以动态地根据标签选择器选择与其关联的 Pod，并将流量转发到这些 Pod 上，提供了一种抽象的方式来访问 Pod。这样，即使 Pod 的 IP 地址或运行位置发生变化，Service 仍然可以提供稳定的网络终点，确保应用程序能够可靠地与后端的 Pod 通信