achangleilei

 

k8s-网络

1.同一node上pod通讯:Kubernetes为每个Pod分配一个唯一的集群内部IP地址(Pod IP)

POD IP :Pod 的唯一网络标识,用于容器间直接通信。

  • 动态分配,Pod 删除后 IP 回收。​集群外无法直接访问​
  • 由 ​CNI 插件​(如 Flannel、Calico)分配,通常从节点所属的 podCIDR子网中分配

2.跨节点Pod通信:依赖网络插件(CNI),如Calico、Flannel、Weave Net等

Calico介绍:

Calico 为你的容器、虚拟机和物理机提供了一个可扩展的、安全的 IP 网络。

核心特性:

高性能:默认模式为纯三层网络,使用BGP协议,数据包在节点之间直接通过IP路由进行传输,无需额外的封包和解包,网络性能接近物理网络。

强策略:

  • 完全支持Kubernetes 网络策略​,可以定义基于 Pod 标签的入口和出口规则。
  • 提供比Kubernetes 原生策略更强大的Calico 网络策略,支持拒绝规则,支持更复杂的匹配规则,支持全局网络策略及网络日志。

灵活的数据平面。支持多种数据平面。如​Linux eBPF(沙盒程序),标准 Linux 网络​(iptables,ipvs),​Windows HNS​,​VXLAN/IP-in-IP​。

对网络边界的扩展。Calico 不仅管理集群内部网络,还通过其子项目 ​Calico Enterprise​ 和开源组件管理东西向流量(集群内)和南北向流量(进出集群)。

核心组件:

一个典型的 Calico 部署包含以下主要组件:

  • ​Felix​: 每个节点上运行的守护进程。负责编程路由规则、ACLs(访问控制列表),并报告节点的网络状态。

  • ​BIRD​: 一个开源的 BGP 客户端。负责在节点之间交换路由信息。每个节点上的 BIRD 从 Felix 获取路由并分发给其他 BGP 对等体(其他节点或物理路由器)。

  • ​confd​: 监控 Calico 的存储(如 etcd),并根据数据变化动态生成 BIRD 的配置文件。

  • ​Typha​: 一个可选的、用于扩展的组件。当集群规模很大时(成千上万个节点),Typha 作为 Felix 和数据存储之间的代理,减轻 etcd 的负载。

  • ​CNI 插件​: 被 kubelet 调用的二进制文件,负责将 Pod 加入到 Calico 网络中。

  • ​calicoctl​: 命令行管理工具,用于配置和管理 Calico 系统。

使用场景:

  • ​Kubernetes 集群网络​: 作为默认的 CNI 插件,为 Pod 提供网络互联。
  • ​网络安全与微服务隔离​: 在需要严格安全要求的生产环境中(如金融、政府),使用其网络策略实现服务间的访问控制。
  • 混合云与多集群网络​: 通过 BGP 将不同数据中心的 Kubernetes 集群网络打通。
  • ​需要高性能网络的场景​: 如 AI/ML 训练、大数据处理等,对网络延迟和吞吐量要求极高的应用。

3.动态Pod的稳定访问:Service资源

Service :一种抽象,定义了一组 Pod 的访问策略​(负载均衡和服务发现)

  • 提供稳定的虚拟 IP(ClusterIP),解耦前端访问与后端 Pod 实例的变化。
  • Service 资源通过 selector匹配 Pod 标签,动态维护端点列表(Endpoints)
  • 基于四层协议转发(端口转发)

Service类型:

  • ClusterIP 集群内部通过虚拟IP或DNS名称访问。

 Headless 直接通过Pod的DNS记录访问特定Pod,有状态应用(如Kafka、MySQL集群),需要直接与特定Pod通信,没有ClusterIP,DNS查询返回所有后端Pod的IP,如监控系统的数据库不需要用户直接对外访问,只需与监控系统web进行通信
有状态用Headless,无状态用ClusterIP

  • NodePort 通过 <任意节点IP>:<固定端口>从外部访问,在每个节点上开放端口,端口范围通常为30000-32767
  • LoadBalancer 通过云供应商提供的负载均衡器IP/域名访问

示例:

ClusterIP

apiVersion: v1
kind: Service
metadata:
  creationTimestamp: null
  labels:
    app: web-sports
  name: web-sports
spec:
  ports:
  - name: "80"
    nodePort: 30010
    port: 80
    protocol: TCP
    targetPort: 80
  selector:
    app: web-sport
  type: NodePort
status:
  loadBalancer: {}

Headless

apiVersion: v1
kind: Service
metadata:
  creationTimestamp: null
  labels:
    app: mydatabase
  name: mydatabase
spec:
  clusterIP: None   ##clusterIP为None
  ports:
  - name: "3306"
    port: 3306
    protocol: TCP
    targetPort: 3306
  selector:
    app: mysql
  type: ClusterIP
status:
  loadBalancer: {}

有状态和无状态pod的区别

  • 无状态应用(Deployment)

pod身份:无固定身份,随机名称
网络标识:共享同一个Service,无固定网络地址
存储:共享存储或临时存储
部署/更新策略:滚动更新时,新pod先创建,旧pod销毁,顺序不固定
扩缩容:扩缩容时随机增减pod,顺序不固定
适用场景:无状态应用(web服务,api服务,前端应用)

  • 有状态应用(StatefuleSets)

pod身份:有固定身份,名称格式固定(StatefulSet名称-序号)
网络标识:每个Pod有唯一的DNS名称(通过Headless Service实现)(格式为:pod名称.service名称.命名空间.svc.cluster.local)
存储:每个pod有专属的PVC,名称格式为pvc模板名称-pod名称,存储与pod身份绑定
部署/更新策略:严格按序号升序部署/更新,删除时按序号降序
扩缩容:扩缩容严格按序号顺序,保证身份连续性
适用场景:有状态应用(数据库,分布式系统、消息队列)

4.集群内服务的智能路由入口:ingress
Ingress 就是为了更优雅地解决外部访问问题而生的。​​ 它不是一种 Service 类型,而是一个 ​API 对象,其核心功能是:
对外提供一个统一的、基于 HTTP/HTTPS 的访问端点,并按照定义的规则将流量分发到不同的后端服务。​

四层负载均衡与七层负载均衡

  • 四层是通过传输层实现,通过转发端口来负载
  • 七层是通过业务层实现,通过url来实现负载

ingress可以基于七层的http和https协议转发,可以通过域名和路径做到更细粒度的划分

Ingress 的核心组成部分

  • Ingress 资源 (Ingress Resource)

它本身不处理任何流量,它只是一份 ​​“交通规则说明书”​。

示例:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-website-ingress
  annotations:
    kubernetes.io/ingress.class: "nginx" # 注解:指定由哪个控制器处理
spec:
  tls: # TLS/HTTPS 配置
  - hosts:
      - mywebsite.com
    secretName: my-website-tls-secret
  rules: # 核心路由规则
  - host: mywebsite.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: frontend-service
            port:
              number: 80
  - host: api.mywebsite.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: backend-api-service
            port:
              number: 8080

这个规则声明:

访问 https://mywebsite.com的流量应被路由到 frontend-service

访问 https://api.mywebsite.com的流量应被路由到 backend-api-service

  • Ingress 控制器 (Ingress Controller)

这是 ​Ingress 规则的“执行者”​。它是一个实际运行在集群中的 Pod,监听 Kubernetes API 的 Ingress 资源变化,并根据规则动态配置一个真正的负载均衡器/反向代理服务器​(如 Nginx、Envoy、Traefik 等)。
必须先安装一个 Ingress 控制器,你定义的 Ingress 资源才能生效!​​ Kubernetes 本身不提供默认的控制器,你需要自行选择并部署。

常见的 Ingress 控制器
社区有非常多优秀的 Ingress 控制器可供选择:
​​Nginx Ingress Controller​​: 最流行的控制器之一,基于 Nginx,由 Kubernetes 社区和维护 Nginx 的公司 F5 共同管理。
​​Ingress-NGINX Controller​​: Nginx 官方提供的控制器,功能更丰富。
​​Traefik​​: 一个现代化的、云原生的 HTTP 反向代理和负载均衡器,以动态配置和易用性著称。
​​HAProxy Ingress​​: 基于高性能的 HAProxy 软件。
​云厂商提供的控制器​: 如 AWS ALB Ingress Controller(与 AWS 负载均衡器集成)、GCE Ingress(与 Google Cloud 负载均衡器集成)等。

Ingress 的核心功能与优势
​基于域名和路径的路由​: 这是最基本的功能,可以将不同域名或同一域名的不同 URL 路径路由到不同的后端服务。
​TLS/HTTPS 终止​: 可以在 Ingress 层面统一处理 SSL/TLS 加密和解密,后端服务只需处理明文的 HTTP 流量,简化了后端应用的配置。证书通常通过 Kubernetes 的 ​Secret​ 资源来管理。
​负载均衡​: 自动将流量负载均衡到后端 Service 的多个 Pod 实例上。
​虚拟主机​: 在同一个 IP 地址上托管多个基于域名的网站或服务。
​统一访问入口​: 为整个集群提供一个稳定、统一的入口 IP 或域名,外部用户无需关心后端服务的具体部署细节。

posted on 2025-10-12 12:44  achangleilei  阅读(0)  评论(0)    收藏  举报

导航