服务发现

K8s 服务发现是K8s 集群中的核心功能，用于实现 Pod 之间的服务发现和通信。主要有两种实现方式：service 和 ingress。

Service

Service 是一种抽象，用来定义一组 Pod 的访问方式。
它提供了一种稳定的访问方式，可以通过 Service 的 ClusterIP、NodePort 或者 LoadBalancer 类型来访问后端 Pod。
Service 通常用于在应用内部进行服务发现和通信，或者对外暴露服务。

Service访问结构

yaml

apiVersion: v1
kind: Service
metadata:
  name: nginx-svc
spec:
  type: NodePort
  selector:
    app: nginx-deploy
  ports:
  - protocol: TCP
    port: 80
    targetPort: 80

type

ClusterIP（集群内部IP）：这是默认的 Service 类型。它将为服务分配一个集群内部的虚拟 IP 地址，并且仅在集群内部可访问。其他 Pod 可以通过该 IP 地址访问服务，但是该 IP 地址对集群外部不可见。
NodePort（节点端口）：NodePort 类型的 Service 会在每个节点上选择一个端口，并将此端口映射到 Service 的后端 Pod。此外，还会在集群的所有节点上公开此端口，使得集群外部可以通过 <NodeIP>:NodePort 访问该服务。
LoadBalancer（负载均衡器）：LoadBalancer 类型的 Service 会使用云服务提供商（如 AWS、Azure、GCP 等）提供的负载均衡器来公开服务。负载均衡器会为 Service 提供一个唯一的外部 IP 地址，并通过此 IP 地址将流量路由到 Service 的后端 Pod。这样，您可以通过负载均衡器的 IP 地址访问服务。
ExternalName（外部名称）：ExternalName 类型的 Service 并不会分配 ClusterIP 或 NodePort。它只会为服务分配一个外部名称，并将此外部名称映射到外部服务的 DNS 记录。这个外部服务可以是集群外部的任何服务，例如外部数据库或者其他外部服务。

负载均衡

一个四层负载均衡器。

自动发现 Pod
- 你只要给Pod打上label，Service的selector匹配上它们，就会自动把这些Pod IP加到自己的Endpoint列表里。
- Pod增减副本时，Service会实时更新，不需要手动改配置。
天然负载均衡
- kube-proxy（在每个节点上跑）会给每个Service端口生成一套iptables/ipvs规则，随机/轮询分发到Endpoint列表里的Pod。
- 这是在集群内部透明实现的，应用层根本不用知道背后有多少Pod。
多端口也能均衡
- 每个端口都维护一份独立的负载均衡规则，但都是针对同一批Pod。
- 你访问哪一个端口，就会在对应targetPort的Pod列表里负载均衡。
零运维切换
- Pod挂了 → kubelet汇报给API Server → Service Endpoint自动剔除 → 新Pod起起来自动加入。

Ingress

官方文档
注意和k8s集群的版本对应关系
https如果是自签的，需要单独信任
Ingress属于七层应用，端口属于四层，非七层协议，还是用NodePort

Ingress 是 Kubernetes 中用于管理 HTTP 和 HTTPS 流量的 API 对象。
它允许外部流量进入 Kubernetes 集群，并在集群内部的 Service 之间进行路由和负载均衡。
Ingress 可以定义域名、路径和其他规则，根据这些规则将流量转发到不同的后端 Service。

shell

helm repo add ingress-nginx https://kubernetes.github.io/ingress-nginx
helm repo update
# 指定版本号
# see https://github.com/kubernetes/ingress-nginx?tab=readme-ov-file#supported-versions-table

helm install ingress-nginx ingress-nginx/ingress-nginx \
  --namespace ingress-nginx --create-namespace \
  --version 4.3.0 \
  --set controller.image.tag="v1.6.4" \
  -f ingress-values.yaml

helm upgrade ingress-nginx ingress-nginx/ingress-nginx \
  -n ingress-nginx \
  -f ingress-values.yaml \

yaml

controller:
  extraVolumes:
    - name: ingress-ca-cert
      configMap:
        name: ingress-ca-cert
  extraVolumeMounts:
    - name: ingress-ca-cert
      mountPath: /etc/ingress-ca-cert
      readOnly: true
  tcp:
    enabled: true  # 如果 chart 支持此开关，可以加上
  tcpServicesConfigMapNamespace: ingress-nginx
  tcpServicesConfigMapName: tcp-services

局域网

MetalLB：解决私有云测试部署验证问题

授权管理

yaml

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-ingress
  namespace: ai-flow
  resourceVersion: '41949573'
  generation: 3
  creationTimestamp: '2025-07-01T02:51:30Z'
  labels:
    k8slens-edit-resource-version: v1
  annotations:
    kubectl.kubernetes.io/last-applied-configuration: >
      {"apiVersion":"networking.k8s.io/v1","kind":"Ingress","metadata":{"annotations":{},"name":"my-ingress","namespace":"ai-flow"},"spec":{"ingressClassName":"nginx","rules":[{"host":"dfdf.com","http":{"paths":[{"backend":{"service":{"name":"animal-pose-3-2","port":{"number":8080}}},"path":"/","pathType":"Prefix"}]}},{"host":"dsds.com","http":{"paths":[{"backend":{"service":{"name":"animal-pose-3-2","port":{"number":8888}}},"path":"/","pathType":"Prefix"}]}}]}}
    nginx.ingress.kubernetes.io/auth-response-headers: X-Auth-Request-User, X-Auth-Request-Email
    nginx.ingress.kubernetes.io/auth-signin: >-
      http://oauth.abc.com:9003/oauth2/start?rd=$scheme://$host$request_uri
    nginx.ingress.kubernetes.io/auth-url: http://oauth.abc.com:9003/oauth2/auth
  selfLink: /apis/networking.k8s.io/v1/namespaces/ai-flow/ingresses/my-ingress
status:
  loadBalancer:  # 
    ingress:
      - ip: 10.1.72.2  # 私有云通过MetalLB解决
spec:
  ingressClassName: nginx
  rules:
    - host: 8080.abc.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: ffddsssss-1-1270
                port:
                  number: 8080
    - host: 8888.abc.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: ffddsssss-1-1270
                port:
                  number: 8888

CoreDNS

提供集群内部的本地域名映射解析能力

集群内自定义域名

修改coredns配置

shell

kubectl -n kube-system edit configmap coredns

yaml

apiVersion: v1
data:
  Corefile: |
    .:53 {
        errors
        health {
           lameduck 5s
        }
        ready
        kubernetes cluster.local in-addr.arpa ip6.arpa {
           pods insecure
           fallthrough in-addr.arpa ip6.arpa
           ttl 30
        }
        # look 
        hosts {
           10.1.72.80 oauth.abc.com
           fallthrough
        }
        prometheus :9153
        # 注意这里是解析的主机的 dns 服务，如果这个 /etc/resolv.conf 配置文件有问题 CoreDNS 无法启动
        forward . /etc/resolv.conf {
           max_concurrent 1000
        }
        cache 30
        loop
        reload
        loadbalance
    }
kind: ConfigMap
metadata:
  name: coredns
  namespace: kube-system

给需要绑定自定义域名的 pod / deploy 添加

shell

kubectl rollout restart deployment coredns -n kube-system

yaml

spec:
  template:
    spec:
      hostAliases:
        - ip: "10.1.72.80"
          hostnames:
            - "oauth.abc.com"

容器生命周期与健康检查

探针（Probes）

Kubernetes 提供三种探针用于检测容器的运行状态，从而保障容器的健康运行和服务的高可用性：

Liveness Probe（存活探针）

作用：检测容器是否处于“存活”状态。如果探针失败，Kubernetes 会认为容器已经“死掉”，自动重启该容器。
用途：发现死循环或死锁的容器，确保容器自愈。
典型场景：
- 应用卡死但进程未退出。
- 程序死循环。
配置示例：

yaml

livenessProbe:
  httpGet:
    path: /healthz
    port: 8080
  initialDelaySeconds: 30
  periodSeconds: 10
  failureThreshold: 3

Readiness Probe（就绪探针）

作用：判断容器是否已经准备好接受请求。只有当探针通过时，Pod 才会被 Service 发送流量。
用途：防止流量发送到还没准备好的容器（如启动慢的服务、初始化未完成）。
典型场景：
- 应用初始化加载配置或依赖服务。
- 需要先完成某些预处理操作。
配置示例：

yaml

readinessProbe:
  tcpSocket:
    port: 3306
  initialDelaySeconds: 5
  periodSeconds: 10

Startup Probe（启动探针）

作用：专门用于判断容器是否完成启动。启动探针失败前，不会执行存活和就绪探针。
用途：适合启动非常慢的应用，避免被存活探针误判重启。
典型场景：
- 启动时间较长的 Java 应用、数据库等。
配置示例：

yaml

startupProbe:
  exec:
    command:
      - cat
      - /tmp/healthy
  failureThreshold: 30
  periodSeconds: 10

探针关系总结

探针类型	作用	触发动作	适用场景
Liveness Probe	判断容器是否活着	失败后重启容器	容器死锁、死循环
Readiness Probe	判断容器是否准备好接流量	失败时从 Service 端点中剔除	启动慢、依赖初始化
Startup Probe	判断容器是否启动完成	启动未完成时禁用其他探针	启动时间长的容器，防止误重启

服务发现 ​

Service ​

type ​

负载均衡 ​

Ingress ​

局域网 ​

授权管理 ​

CoreDNS ​

集群内自定义域名 ​

容器生命周期与健康检查 ​

探针（Probes） ​

Liveness Probe（存活探针） ​

Readiness Probe（就绪探针） ​

Startup Probe（启动探针） ​

探针关系总结 ​

服务发现

Service

type

负载均衡

Ingress

局域网

授权管理

CoreDNS

集群内自定义域名

容器生命周期与健康检查

探针（Probes）

Liveness Probe（存活探针）

Readiness Probe（就绪探针）

Startup Probe（启动探针）

探针关系总结