你做了啥什么，对团队/项目贡献比较大的？ #

试点，给后续上生产起到好的示范作用，后续上生产比较顺利。

pv pvc storage-class之间的关系？ #

在 Kubernetes 中，PV（PersistentVolume）、PVC（PersistentVolumeClaim）和 StorageClass 共同用于管理持久化存储，它们的关系如下：

1. 关系概述 #

• StorageClass：定义存储的类型，决定如何动态创建 PV。
• PV（PersistentVolume）：代表集群中的实际存储，可以是静态预先创建的，也可以通过 StorageClass 动态创建。
• PVC（PersistentVolumeClaim）：Pod 申请存储时创建的存储请求，Kubernetes 根据 PVC 自动绑定合适的 PV。

2. 详细流程 #

1️⃣ Pod 申请存储（创建 PVC）

• 用户创建 PVC，声明需要多大的存储、读写权限等。
• Kubernetes 查找匹配的 PV，若存在符合要求的 PV，则直接绑定。
• 若 PV 不匹配，Kubernetes 使用 StorageClass 动态创建 PV（如果 PVC 指定了 StorageClass）。

2️⃣ PV 绑定 PVC

• 如果 PVC 申请的存储满足某个 PV 的要求，就会绑定该 PV。
• PVC 绑定 PV 后，Pod 只能使用该 PV，直到 PVC 释放。

3️⃣ Pod 使用 PVC

• Pod 在 volume 字段中引用 PVC，让应用可以挂载持久化存储。

4️⃣ PVC 释放 PV

• 当

  PVC
  

  被删除时，

  PV
  

  的回收策略（

  Retain
  

  、

  Recycle
  

  、

  Delete
  

  ）决定如何处理存储：

  • Retain：PV 保留，管理员需要手动回收数据。
  • Recycle（已废弃）：简单格式化 PV，重新变为可用状态。
  • Delete：自动删除 PV 及其后端存储。

3. 具体示例 #

1️⃣ StorageClass 定义 #

定义一个 StorageClass，用于动态创建 PV：

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: my-storage-class
provisioner: kubernetes.io/aws-ebs  # 存储供应商
parameters:
  type: gp2
reclaimPolicy: Delete  # PVC 删除后，PV 也删除

2️⃣ PVC 申请存储 #

用户创建 PVC 来申请存储：

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: my-pvc
spec:
  accessModes:
    - ReadWriteOnce  # 仅单个节点可挂载
  resources:
    requests:
      storage: 10Gi  # 申请 10Gi 存储
  storageClassName: my-storage-class  # 指定 StorageClass

• 如果集群有 StorageClass，则 Kubernetes 动态创建 PV 并绑定 PVC。

• 如果

  PVC
  

  不指定

  storageClassName
  

  ，则：

  • Kubernetes 绑定已有的静态 PV（如果匹配）。
  • 若 PV 不匹配，PVC 可能会一直 Pending。

3️⃣ PV 静态创建（可选） #

管理员可以预先创建 PV：

apiVersion: v1
kind: PersistentVolume
metadata:
  name: my-pv
spec:
  capacity:
    storage: 10Gi  # 存储大小
  accessModes:
    - ReadWriteOnce
  persistentVolumeReclaimPolicy: Retain  # PVC 删除后，PV 保留
  hostPath:
    path: "/mnt/data"

• 如果 PV 满足 PVC 申请的要求，Kubernetes 自动绑定。

4️⃣ Pod 挂载 PVC #

Pod 使用 PVC 来持久化存储：

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  containers:
    - name: my-container
      image: nginx
      volumeMounts:
        - mountPath: "/data"
          name: my-volume
  volumes:
    - name: my-volume
      persistentVolumeClaim:
        claimName: my-pvc  # 绑定 PVC

4. 总结 #

关键点 #

✅ PVC 申请存储 → PV 绑定 PVC ✅ StorageClass 支持动态创建 PV ✅ PV 的 reclaimPolicy 决定存储如何回收

这样，Kubernetes 能灵活管理存储，为 Pod 提供持久化存储支持！🚀

怎么优化网络的问题？ #

Kubernetes 网络优化涉及多个层面，包括 容器网络、CNI 插件、DNS 解析、Service 访问、负载均衡、网络安全 等。优化的重点一般是 降低延迟、提高吞吐量、减少丢包、优化服务发现。以下是一些常见的优化方案：

1. CNI 插件优化 #

选择合适的 CNI 插件

• Calico：支持 BGP，适用于大规模集群，适合高性能网络需求。
• Cilium：基于 eBPF 提供更高效的数据包处理，支持高并发。
• Flannel：轻量级，适合小规模集群，但不支持 NetworkPolicy。
• OVN-Kubernetes：支持高级网络策略，适合 OpenStack 等集成环境。

优化 CNI 配置

• 选择合适的后端（如 Calico 的 IP-in-IP vs VXLAN，或 Cilium 的 native-routing）。
• 开启 eBPF 加速（Cilium 支持 eBPF，减少 iptables 规则，提高网络性能）。
• 减少 NAT 转换（使用 DirectRouting 模式，避免 SNAT 影响性能）。

2. Pod 网络优化 #

(1) 调整 MTU #

• 降低 MTU 以减少分片

  ：默认

  1500
  

  ，如使用

  VXLAN
  

  或

  WireGuard
  

  ，可能需要

  1400
  

  或

  1450
  

  。

  ip link set dev eth0 mtu 1400
  

(2) 调整 TCP 参数 #

• 允许 TCP 快速重传，减少网络丢包影响：

  sysctl -w net.ipv4.tcp_fastopen=3
  sysctl -w net.core.rmem_max=16777216
  sysctl -w net.core.wmem_max=16777216
  

(3) 使用 IPv6 Dual Stack #

• 如果有 IPv6 需求，可以开启双栈支持：

  featureGates:
    IPv6DualStack: true
  

3. Service 网络优化 #

(1) 优化 kube-proxy #

默认 kube-proxy 使用 iptables，当 Service 多时会影响性能，推荐 使用 ipvs 提高性能：

kubectl edit configmap -n kube-system kube-proxy

修改：

mode: "ipvs"
ipvs:
  strictARP: true
  scheduler: "rr"

• strictARP: true 解决 arp flux 问题，避免流量分发错误。
• scheduler: "rr" 选择轮询调度，可优化流量分配。

(2) 开启 CoreDNS 缓存 #

DNS 解析慢会影响 Pod 访问 Service，可以优化 CoreDNS：

apiVersion: v1
kind: ConfigMap
metadata:
  name: coredns
  namespace: kube-system
data:
  Corefile: |
    .:53 {
        errors
        health
        ready
        cache 30  # 缓存 30 秒，减少 DNS 查询
        forward . 8.8.8.8  # 可替换为内网 DNS 服务器
    }

(3) 使用 headless Service #

• 对于 StatefulSet 等不需要

  ClusterIP
  

  的

  Service
  

  ，可使用

  headless service
  

  避免

  kube-proxy
  

  代理：

  apiVersion: v1
  kind: Service
  metadata:
    name: my-service
  spec:
    clusterIP: None  # 取消 ClusterIP，直接使用 Pod IP
  

4. 负载均衡优化 #

(1) 使用 ExternalTrafficPolicy #

• 默认情况下，LoadBalancer 会在 NodePort 层级进行 SNAT 转换，影响真实 IP 透传。

• externalTrafficPolicy: Local
  

  让流量直接到 Pod，减少一次 NAT 转换：

  apiVersion: v1
  kind: Service
  metadata:
    name: my-lb
  spec:
    type: LoadBalancer
    externalTrafficPolicy: Local
  

(2) 开启 KeepAlive #

如果 Service 后端是 Nginx、Envoy 之类的负载均衡器，建议启用 KeepAlive 以减少连接重建开销：

keepalive_timeout 75;
keepalive_requests 1000;

5. 网络安全优化 #

(1) 限制 IP 访问 #

如果集群暴露了外网 API Server，可以使用 iptables 限制访问：

iptables -A INPUT -p tcp --dport 6443 -s 192.168.1.0/24 -j ACCEPT
iptables -A INPUT -p tcp --dport 6443 -j DROP

(2) 使用 NetworkPolicy #

可以使用 NetworkPolicy 限制 Pod 之间的通信：

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-all
  namespace: default
spec:
  podSelector: {}
  policyTypes:
    - Ingress

• 这样 default 命名空间的 Pod 之间无法互相访问。

6. 使用 eBPF 提高性能 #

如果使用 Cilium，可以开启 eBPF 来优化：

cilium status
cilium config set enable-node-port true
cilium config set enable-bpf-masquerade true

• eBPF 取代 iptables，减少规则匹配开销，提高流量转发性能。

7. 监控和优化 #

(1) 使用 ping 和 iperf 监控网络 #

ping <pod-ip>
iperf3 -c <pod-ip>

可以用 iperf3 测试 Pod 之间的带宽：

iperf3 -s  # 服务器端
iperf3 -c <server-ip> -P 10  # 并发测试

(2) 使用 tcpdump 分析网络问题 #

tcpdump -i eth0 port 80 -nn -X

(3) 使用 Prometheus + Grafana 监控 #

可以部署 cAdvisor、node-exporter、Cilium Hubble 监控网络性能，及时发现异常情况。

总结 #

这些优化方案可以 降低 Kubernetes 网络延迟，提高吞吐量，减少丢包，从而提升整个集群的性能。🚀

iptables和ipvs的区别？ #

在 Kubernetes kube-proxy 中，iptables 和 IPVS 是两种不同的 Service 代理模式，它们的主要区别如下：

1. 基本概念 #

2. iptables 解析 #

iptables 工作原理 #

• iptables 是 Netfilter 的一部分，基于规则匹配来进行流量转发。
• kube-proxy 运行在每个节点上，通过 iptables 规则来 NAT 访问 ClusterIP。
• iptables 规则匹配是 线性查找（O(n)），规则越多，性能越低。

示例 #

使用 iptables -t nat -L -n --line-numbers 查看 KUBE-SERVICES 规则：

Chain KUBE-SERVICES (2 references)
num  target     prot opt source               destination
1    KUBE-MARK-MASQ  all  --  0.0.0.0/0      10.96.0.1    /* default/kubernetes:https cluster IP */
2    DNAT       tcp  --  0.0.0.0/0      10.96.0.1     to:192.168.1.100:6443

• 规则按顺序匹配（O(n)），当规则较多时会影响性能。
• iptables 适用于 小规模集群，但 大规模规则时性能下降。

3. IPVS 解析 #

IPVS 工作原理 #

• IPVS（IP Virtual Server） 是 Linux Kernel 提供的 四层负载均衡 方案，基于 Netfilter。
• kube-proxy 使用 IPVS 直接在 内核态 处理流量，支持 高并发和低延迟。
• IPVS 采用 哈希表（O(1)） 查找，提高了大规模 Service 的性能。

示例 #

使用 ipvsadm -L -n 查看 IPVS 规则：

IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port   Scheduler Flags
  -> RemoteAddress:Port  Forward Weight ActiveConn InActConn
TCP  10.96.0.1:443 rr
  -> 192.168.1.100:6443 Masq    1      3          5

• rr 表示轮询调度。
• IPVS 直接在内核处理转发，支持 TCP/UDP/SCTP 协议，吞吐量更高。

4. iptables vs IPVS 性能对比 #

当 Kubernetes Service 数量 较少（<100） 时，iptables 的性能足够；但当 Service 数量 超过 500+ 时，建议使用 IPVS。

5. 开启 IPVS 模式 #

(1) 检查内核模块 #

IPVS 依赖以下内核模块：

lsmod | grep ip_vs

如果没有加载，可以手动加载：

modprobe ip_vs
modprobe ip_vs_rr
modprobe ip_vs_wrr
modprobe ip_vs_sh

(2) 修改 kube-proxy 配置 #

kubectl edit configmap -n kube-system kube-proxy

修改：

mode: "ipvs"
ipvs:
  scheduler: "rr"  # 轮询调度
  strictARP: true  # 避免流量转发错误

(3) 重启 kube-proxy #

kubectl delete pod -n kube-system -l k8s-app=kube-proxy

(4) 验证 IPVS 是否生效 #

ipvsadm -L -n

如果输出包含 IPVS 规则，说明配置成功。

6. 总结 #

• iptables 适合小规模集群，但当 Service 规则过多时，规则匹配会变慢。
• IPVS 适用于大规模集群，使用内核 O(1) 哈希查找，提高了 Service 性能。
• 如果 Service 数量超过 500+，建议切换到 IPVS，避免 iptables 规则过多导致的性能下降。 🚀

现在k8s默认的kube-proxy的模式是啥ipvs还是iptables，为啥？ #

Kubernetes 默认的 kube-proxy 模式是 iptables #

Kubernetes 目前默认使用 iptables 作为 kube-proxy 的模式，而不是 IPVS，主要原因如下：

1. iptables 是更通用的默认选择 #

• 广泛兼容性：iptables 在大多数 Linux 发行版上默认可用，无需额外的内核模块。
• 简单易用：基于 Netfilter，配置相对简单，易于维护和调试。
• 足够的性能：对于 中小规模集群（<500 个 Service），iptables 性能足够，不会成为瓶颈。

2. IPVS 依赖额外的内核模块 #

• IPVS
  

  需要加载

  ip_vs
  

  相关的内核模块：

  modprobe ip_vs
  modprobe ip_vs_rr
  modprobe ip_vs_wrr
  modprobe ip_vs_sh
  

• 部分精简版 Linux 发行版（如部分 Ubuntu 或 Alpine 变种）默认不包含 IPVS 相关模块，需要手动安装或编译。

• 这导致 IPVS 在所有环境下无法保证开箱即用，而 iptables 不受影响。

3. iptables 对中小规模集群足够 #

• iptables 在 少量 Service 场景下（<500 个 Service） 性能足够，不会明显影响集群。
• Kubernetes 目标是 开箱即用，默认使用 iptables 可以 避免 IPVS 的额外依赖问题，兼容性更好。

4. Kubernetes 并没有放弃 IPVS #

• 如果集群规模较大（>500 Service），建议手动切换

  kube-proxy
  

  到

  IPVS
  

  模式：

  mode: "ipvs"
  

• IPVS 在 大规模 Service 场景 下比 iptables 更优，特别是在高并发、高吞吐量的情况下。

5. 如何检查当前 kube-proxy 使用的模式？ #

你可以运行以下命令：

kubectl get configmap -n kube-system kube-proxy -o yaml | grep mode

如果返回：

mode: "iptables"

说明 kube-proxy 运行在 iptables 模式。

如果想切换到 IPVS，需要手动修改 kube-proxy 的 ConfigMap 并重启 kube-proxy Pod。

6. 结论 #

• 默认 kube-proxy 模式是 iptables，因为它兼容性更好，适用于大多数 Linux 发行版，并且在中小规模集群下足够稳定。
• 如果集群规模较大（>500 Services），推荐手动切换到 IPVS 模式，提升 kube-proxy 负载均衡性能。 🚀

#

最新版本的k8s，默认的kube-proxy的模式是啥ipvs还是iptables #

截至 Kubernetes 1.32 版本，kube-proxy 默认使用 iptables 模式。 citeturn0search7

在 Kubernetes 1.29 版本中，引入了 nftables 模式作为 Alpha 特性，旨在解决 iptables 模式下的性能问题。 目前，nftables 模式已进入 Beta 阶段，预计将在 1.33 版本中达到一般可用（GA）状态。 然而，出于兼容性考虑，即使 nftables 模式达到 GA，iptables 仍将作为默认模式。 citeturn0search0

需要注意的是，ipvs 模式在 Kubernetes 1.8 版本中引入，提供了更高效的负载均衡性能。 然而，ipvs 模式需要节点上预先安装 ipvs 内核模块。 如果这些模块未安装，kube-proxy 将回退到 iptables 模式。 citeturn0search1

因此，虽然 Kubernetes 提供了多种 kube-proxy 模式供用户选择，但默认情况下仍采用 iptables 模式。

Kubernetes 中 kube-proxy 的关键点总结 #

1. kube-proxy 的作用 #

• 运行在 Kubernetes 集群的每个节点上（除非使用了自定义替代组件）。
• 负责管理 Service 的虚拟 IP（ClusterIP），实现流量转发。
• 监听 Service 和 EndpointSlice 资源的变化，并据此调整网络规则。

2. kube-proxy 的工作机制 #

• 通过不同的代理模式（iptables、ipvs、nftables）配置节点，使流量能够正确地转发到后端 Pod 或其他端点。
• 规则与 Kubernetes API 服务器状态同步，确保 Service 和 EndpointSlice 变更时网络规则及时更新。

3. 为什么 Kubernetes 需要代理转发流量？ #

• DNS 解析受 TTL 影响，部分实现不会严格遵守 TTL，可能导致缓存问题。
• 某些应用仅在启动时解析 DNS，导致后端 Pod 变更时无法正确更新。
• 频繁解析 DNS 可能会增加负载，不易管理。

4. 代理模式 #

(1) iptables 模式 #

• 适用于 Linux 节点。
• 通过 iptables 规则实现 Service 虚拟 IP 到后端 Pod 的转发。
• 规则由 kube-proxy 监听 Service 变更并动态更新。
• 在拥有大量 Pod 和 Service 的大规模集群中，可能导致规则更新较慢。

(2) IPVS 模式 #

• 适用于 Linux 节点。
• 基于 Linux 内核的 IPVS 机制，性能优于 iptables 模式。
• 通过哈希表管理转发表，查询效率高，适用于大规模集群。
• 支持多种流量调度算法，如轮询（rr）、最少连接（lc）、源哈希（sh）等。
• 需要 IPVS 内核模块支持，kube-proxy 启动前需确保 IPVS 可用。

(3) nftables 模式 #

• 适用于 Linux 节点。
• 使用 nftables 替代 iptables 来管理流量转发规则。
• 目前较少使用，主要适用于不支持 iptables 或 ipvs 的场景。

(4) Windows Kernelspace 模式 #

• 适用于 Windows 节点。
• 直接在 Windows 内核空间配置转发规则。

5. iptables 模式的优化 #

• minSyncPeriod
  

  控制规则最短同步间隔，默认值

  1s
  

  。

  • 值越小，规则同步越及时，但会增加 CPU 负担。
  • 适当增大可减少频繁更新，提高大规模集群的效率。

• syncPeriod
  

  控制定期同步时间，默认

  30s
  

  。

  • 影响外部干预 iptables 规则后的自动恢复速度。
  • 过去有些集群设为 1h 以减少更新负载，但现在不推荐。

6. IPVS 代理模式的优势 #

• 相比 iptables，IPVS 具有更低的转发延迟和更高的吞吐量。
• 提供更丰富的负载均衡调度算法，如轮询、最少连接、哈希等。
• 适合大规模 Kubernetes 集群。

7. 使用 IPVS 模式的注意事项 #

• 需要在节点上启用 IPVS 内核模块，否则 kube-proxy 启动失败。
• 默认调度算法是 rr（轮询），可通过 kube-proxy 配置修改。
• 需要 ipvsadm 命令行工具来查看和管理 IPVS 规则。

这就是 Kubernetes 中 kube-proxy 的核心要点，你可以根据自己的需求选择合适的代理模式。 🚀

ingress和ingress-controller区别？ #

Ingress 和 Ingress Controller 的区别 #

1. 什么是 Ingress？ #

• Ingress 是 Kubernetes 的 API 资源，用于定义集群内服务的外部访问规则。
• 提供基于 HTTP/HTTPS 的路由，允许将外部流量引导到集群内部的 Service。
• 可以配置主机名、路径、TLS 证书、重定向、流量规则等。

示例 Ingress 资源：

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: example-ingress
spec:
  rules:
  - host: example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: my-service
            port:
              number: 80

作用：

• 访问 http://example.com 时，流量会被转发到 my-service 的 80 端口。

2. 什么是 Ingress Controller？ #

• Ingress Controller 是实际执行流量管理的组件。
• 它监听 Kubernetes 中的 Ingress 资源，并根据规则配置负载均衡器（如 Nginx、Traefik、HAProxy 等）。
• Ingress 本身只是规则定义，Ingress Controller 负责将规则转化为实际的流量转发行为。

常见的 Ingress Controller：

• Nginx Ingress Controller（最常用）
• Traefik
• HAProxy Ingress
• Istio Gateway（结合 Service Mesh 使用）
• Contour
• Kong Ingress Controller（支持 API 网关功能）

示例：使用 Nginx 作为 Ingress Controller

kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/main/deploy/static/provider/cloud/deploy.yaml

3. 核心区别 #

4. 总结 #

• Ingress 是规则，定义如何让外部访问集群内部服务。
• Ingress Controller 是执行者，它根据 Ingress 规则配置负载均衡器，使流量正确转发。
• Ingress 需要 Ingress Controller 才能生效，否则不会生效。

🚀 记住：Ingress 只是规则，Ingress Controller 才是真正实现流量转发的组件！

目前用的ingress-controller有哪几种？ #

目前主流的 Ingress Controller 主要有以下几种：

1. Nginx Ingress Controller（最常见） #

• 特点：基于 Nginx，功能丰富，支持 HTTPS、重定向、Rewrite、负载均衡等。

• 适用场景：适合大多数 Kubernetes 集群，官方 Kubernetes 推荐。

• 安装方式

  ：

  kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/main/deploy/static/provider/cloud/deploy.yaml
  

• GitHub：kubernetes/ingress-nginx

2. Traefik Ingress Controller（云原生友好） #

• 特点：支持动态配置、自动发现、支持 TCP/UDP、多协议负载均衡，默认自带可视化 Web UI。

• 适用场景：适用于微服务架构，特别是使用 Kubernetes CRD 进行高级路由管理的场景。

• 安装方式

  ：

  helm install traefik traefik/traefik
  

• GitHub：traefik/traefik

3. HAProxy Ingress Controller（高性能） #

• 特点：性能极高，支持高级负载均衡策略，原生支持 TCP、gRPC 和 WebSocket。

• 适用场景：对高吞吐、高性能要求较高的场景，如银行、电信、游戏等行业。

• 安装方式

  ：

  helm install haproxy-ingress haproxy-ingress/haproxy-ingress
  

• GitHub：jcmoraisjr/haproxy-ingress

4. Kong Ingress Controller（API 网关） #

• 特点：不仅是 Ingress Controller，还是 API Gateway，支持身份认证、速率限制、日志管理等功能。

• 适用场景：API 管理、微服务架构、需要 API 级别控制的企业级应用。

• 安装方式

  ：

  helm install kong kong/kong
  

• GitHub：Kong/kubernetes-ingress-controller

5. Istio Gateway（Service Mesh 方案） #

• 特点：依赖 Istio Service Mesh，提供更强的流量控制能力，如流量镜像、熔断、流量拆分等。

• 适用场景：微服务架构、需要强大流量控制能力的企业级应用。

• 安装方式

  ：

  istioctl install --set profile=demo
  

• GitHub：Istio Gateway

6. Contour Ingress Controller（Envoy 代理） #

• 特点：基于 Envoy 代理，支持 HTTP/2、gRPC 代理，性能优秀。

• 适用场景：Envoy 生态的 Kubernetes 负载均衡方案。

• 安装方式

  ：

  kubectl apply -f https://projectcontour.io/quickstart/contour.yaml
  

• GitHub：projectcontour/contour

7. GCE Ingress Controller（适用于 GCP） #

• 特点：Google Cloud 官方提供，依赖 Google Load Balancer。
• 适用场景：Kubernetes 部署在 Google Kubernetes Engine（GKE）时使用。
• GitHub：kubernetes/ingress-gce

8. AWS ALB Ingress Controller（适用于 AWS） #

• 特点：基于 AWS Application Load Balancer（ALB），深度集成 AWS 生态。
• 适用场景：Kubernetes 部署在 AWS EKS 上时使用。
• GitHub：kubernetes-sigs/aws-load-balancer-controller

9. F5 BIG-IP Ingress Controller（企业级） #

• 特点：支持 F5 BIG-IP 设备，适用于企业级网络安全和高可用需求。
• 适用场景：使用 F5 硬件设备的大型企业。
• GitHub：F5Networks/k8s-bigip-ctlr

总结：不同 Ingress Controller 适用场景 #

🚀 选择建议：

• 普通 Kubernetes 方案 → Nginx Ingress
• 需要 API 网关功能 → Kong Ingress
• 服务网格（Service Mesh） → Istio Gateway
• 高性能、低延迟需求 → HAProxy
• 动态发现、可视化 UI → Traefik
• 使用 Google Cloud / AWS → GCE / ALB Ingress

上传文件，提示上传文件过大怎么处理？nginx配置，ingress-controller的注解。 #

如果上传文件时提示文件过大，可以从 Nginx 配置 和 Ingress Controller 注解 两个方面处理。

1. Nginx 配置（适用于独立 Nginx 部署） #

修改 Nginx 配置文件 nginx.conf 或者相应的 server 块，增加 client_max_body_size 参数：

http {
    client_max_body_size 100M;
}

或者：

server {
    location /upload {
        client_max_body_size 100M;
    }
}

然后重启 Nginx：

systemctl restart nginx

2. Nginx Ingress Controller 配置 #

Nginx Ingress Controller 支持 自定义注解（annotations） 进行配置，常见方法有两种：

方法 1：在 Ingress 资源中增加 Annotation #

如果使用 ingress-nginx 控制器，可以在 Ingress 资源中添加以下注解：

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-ingress
  annotations:
    nginx.ingress.kubernetes.io/proxy-body-size: "100m"
spec:
  rules:
    - host: example.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: my-service
                port:
                  number: 80

解释：

• nginx.ingress.kubernetes.io/proxy-body-size：设置最大上传文件大小，默认 1M，这里改为 100M。

方法 2：修改 ConfigMap 配置 #

如果需要全局修改 Nginx Ingress Controller 的上传限制，可以编辑 Ingress Controller 的 ConfigMap：

kubectl edit configmap -n ingress-nginx nginx-ingress-controller

添加或修改：

data:
  proxy-body-size: "100m"

然后重启 Ingress Controller：

kubectl rollout restart deployment -n ingress-nginx ingress-nginx-controller

3. Helm 安装 Nginx Ingress 时修改 #

如果是使用 Helm 安装的 ingress-nginx，可以在 values.yaml 里配置：

controller:
  config:
    proxy-body-size: "100m"

然后执行升级：

helm upgrade --install ingress-nginx ingress-nginx/ingress-nginx -f values.yaml

总结 #

如果只是 单个 Ingress 资源 需要调整，推荐 方法 1（添加 Annotation）。 如果要 全局修改，推荐 方法 2 或 3。

流量经过ingress-controller后获取不到真实ip，说下原因及怎么解决？ #

流量经过 Ingress Controller 后获取不到 真实 IP，通常是因为 Nginx Ingress Controller 作为 反向代理，默认会使用自身的 IP 进行转发，导致后端 Pod 无法直接获取客户端的真实 IP。以下是常见原因及解决方案：

1. 常见原因 #

(1) Ingress Controller 作为反向代理 #

• Ingress Controller 默认使用代理模式，后端 Pod 看到的 IP 是 Ingress Controller 的 IP，而不是客户端的真实 IP。
• 解决方案：使用 X-Forwarded-For 头传递真实 IP，并在后端读取。

(2) Kubernetes 运行模式（LoadBalancer / NodePort / HostNetwork） #

不同的部署方式会影响真实 IP 的获取：

• LoadBalancer 模式（ELB/ALB 等云负载均衡）
  • 如果前面有 云厂商的负载均衡，Ingress Controller 可能只接收到 LB 的 IP，而非客户端 IP。
  • 解决方案：检查 云负载均衡 是否支持 直接传递真实 IP（比如开启 Proxy Protocol）。
• NodePort 模式
  • 如果 Service 类型是 NodePort，流量会经过 Kube-Proxy 转发，可能丢失真实 IP。
  • 解决方案：使用 externalTrafficPolicy: Local 避免 SNAT。
• HostNetwork 模式
  • 直接使用 宿主机网络 的 Ingress Controller 可以获取真实 IP。

(3) SNAT（源地址网络转换） #

• 如果 Kubernetes 集群使用了 SNAT（Source NAT），客户端 IP 可能会被替换为 Ingress Controller 的 IP。
• 解决方案：调整 externalTrafficPolicy，避免 SNAT。

2. 解决方案 #

方法 1：使用 X-Forwarded-For 传递真实 IP #

Nginx Ingress Controller 默认支持 X-Forwarded-For 头，我们可以在后端应用中读取该头：

nginx.ingress.kubernetes.io/use-forwarded-headers: "true"

示例：

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-ingress
  annotations:
    nginx.ingress.kubernetes.io/use-forwarded-headers: "true"
spec:
  rules:
    - host: example.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: my-service
                port:
                  number: 80

• 后端应用需要读取

  X-Forwarded-For
  

  头，获取

  客户端真实 IP

  ：

  X-Forwarded-For: 1.2.3.4, 10.0.0.1
  

  客户端 IP = 1.2.3.4

  （第一个 IP）。

方法 2：修改 externalTrafficPolicy 避免 SNAT #

如果 Ingress Controller 通过 NodePort 或 LoadBalancer 方式暴露服务，Kubernetes 可能会进行 SNAT，丢失客户端 IP。可以修改 Service 使其直接透传流量：

apiVersion: v1
kind: Service
metadata:
  name: ingress-nginx-controller
  namespace: ingress-nginx
spec:
  type: LoadBalancer
  externalTrafficPolicy: Local

• externalTrafficPolicy: Local：保持客户端原始 IP，不进行 SNAT。
• 适用于 NodePort 和 LoadBalancer 类型的 Service。

方法 3：使用 proxy-protocol（适用于云负载均衡） #

如果 Kubernetes 部署在 云环境，并使用云厂商的 LoadBalancer，需要启用 proxy-protocol 透传真实 IP：

apiVersion: v1
kind: ConfigMap
metadata:
  name: nginx-configuration
  namespace: ingress-nginx
data:
  use-proxy-protocol: "true"

然后，在 Ingress Controller Service 里添加：

metadata:
  annotations:
    service.beta.kubernetes.io/aws-load-balancer-proxy-protocol: '*'

• 适用于 AWS ALB、GCP LB 等云负载均衡，保证传递 真实 IP。

3. 总结 #

最佳实践：

• K8s 云环境（AWS/GCP/阿里云） → 开启 proxy-protocol
• 本地 K8s 集群（NodePort） → 设置 externalTrafficPolicy: Local
• 应用层（Nginx/Flask/Go/PHP） → 读取 X-Forwarded-For 头

这样就可以正确获取 客户端真实 IP！

git，ssh形式拉去代码，怎么配置？ #

要通过 SSH 方式拉取 Git 仓库的代码，需要配置 SSH 密钥并将公钥添加到 Git 服务（例如 GitHub、GitLab 或其他 Git 服务器）中。以下是配置步骤：

1. 生成 SSH 密钥对 #

如果你还没有 SSH 密钥对，可以通过以下步骤生成一个。

在本地机器上生成 SSH 密钥： #

1. 打开终端。

2. 输入以下命令生成 SSH 密钥对：

   ssh-keygen -t rsa -b 4096 -C "your_email@example.com"
   

   • -t rsa 表示使用 RSA 算法。
   • -b 4096 表示生成一个 4096 位的密钥。
   • -C 后面是一个注释，一般填写你的邮箱。

3. 生成密钥对时，会提示选择文件保存路径，默认会保存在 ~/.ssh/id_rsa，按 Enter 键选择默认路径。

4. 输入一个 密码短语（可选），如果不想设置密码短语，直接按 Enter 键跳过。

生成的密钥对包括：

• 私钥：~/.ssh/id_rsa
• 公钥：~/.ssh/id_rsa.pub

2. 将公钥添加到 Git 服务 #

将生成的公钥添加到你使用的 Git 服务账户中（如 GitHub、GitLab 或 Bitbucket）。

GitHub： #

1. 登录到 GitHub。

2. 点击右上角的 头像 → Settings（设置）。

3. 在左侧栏点击 SSH and GPG keys。

4. 点击 New SSH key 按钮。

5. 打开终端，查看公钥内容：

   cat ~/.ssh/id_rsa.pub
   

6. 将显示的公钥内容复制粘贴到 GitHub 的 SSH 密钥配置页，点击 Add SSH key。

GitLab： #

1. 登录到 GitLab。
2. 点击右上角的 头像 → Settings。
3. 在左侧栏点击 SSH Keys。
4. 将公钥内容粘贴到 SSH 密钥框中，点击 Add key。

Bitbucket： #

1. 登录到 Bitbucket。
2. 点击右上角的 头像 → Personal settings（个人设置）。
3. 在左侧栏点击 SSH keys。
4. 粘贴公钥内容，点击 Add key。

3. 配置 SSH 客户端 #

如果你想确保 SSH 客户端始终使用正确的密钥，可以配置 ~/.ssh/config 文件。

编辑或创建 ~/.ssh/config 文件，添加如下配置：

Host github.com
  User git
  HostName github.com
  IdentityFile ~/.ssh/id_rsa
  IdentitiesOnly yes

• Host github.com：指定对 github.com 使用此配置。
• IdentityFile ~/.ssh/id_rsa：指定使用的私钥文件路径。

4. 使用 SSH 拉取代码 #

通过 SSH 拉取 Git 仓库时，使用 SSH URL 进行克隆。例如，GitHub 仓库的 SSH URL 形式是：

git clone git@github.com:username/repository.git

对于其他 Git 服务，URL 形式也类似，例如：

• GitLab：git@gitlab.com:username/repository.git
• Bitbucket：git@bitbucket.org:username/repository.git

5. 测试 SSH 连接 #

可以通过以下命令测试是否配置正确：

ssh -T git@github.com

如果配置正确，应该看到类似下面的消息：

Hi username! You've successfully authenticated, but GitHub does not provide shell access.

6. 配置 Git 使用 SSH #

如果你的 Git 配置默认使用 HTTPS，可以通过以下命令将远程仓库 URL 更新为 SSH 格式：

git remote set-url origin git@github.com:username/repository.git

总结： #

1. 生成 SSH 密钥对：使用 ssh-keygen 生成私钥和公钥。
2. 将公钥添加到 Git 服务：将公钥上传到 GitHub、GitLab 或 Bitbucket。
3. 配置 SSH 客户端：通过 ~/.ssh/config 配置 SSH 客户端，以确保使用正确的密钥。
4. 使用 SSH 拉取代码：使用 git@github.com:username/repository.git 格式的 URL 克隆代码。

配置好 SSH 后，你就可以使用 SSH 拉取和推送代码了！

jenkins在不同平台做编译，agent在不同平台如何操作？对jenkins集群有了解吗？ #

Jenkins 在多平台编译和使用不同平台的 agent 操作时，通常会涉及到 Jenkins 集群 和 Jenkins Agent 的配置。Jenkins 集群是指由多个 Jenkins 节点组成的系统，其中包括 主节点（Master） 和 代理节点（Agent）。代理节点是用于执行 Jenkins 作业的独立计算机。以下是相关的操作步骤和配置。

1. Jenkins 集群架构 #

Jenkins 集群由一个主节点和多个代理节点组成：

• Master（主节点）：Jenkins 主节点负责调度任务、分配作业并提供 Web 界面。主节点并不执行所有的构建工作，主节点主要负责管理任务和协调代理节点的工作。
• Agent（代理节点）：代理节点用于实际执行 Jenkins 的作业（如构建、测试、部署等）。可以有多个代理节点，支持不同操作系统和平台，保证跨平台的构建需求。

Jenkins 集群的优势：

• 负载均衡：作业可以根据需要分配到不同的代理节点，减轻主节点的负担。
• 跨平台支持：在不同操作系统的代理节点上构建支持多平台的项目。

2. 配置 Jenkins Agent 在不同平台上执行任务 #

在 Jenkins 中，代理节点可以是不同操作系统（如 Linux、Windows 或 macOS）上的机器，每个代理节点可以运行特定操作系统上需要的构建任务。以下是配置过程：

步骤一：安装 Jenkins 主节点 #

1. 安装 Jenkins 主节点，并启动 Jenkins 服务。
2. 配置 Jenkins 主节点并访问 Web 控制台，通常可以通过 http://localhost:8080 访问。

步骤二：配置 Agent 节点 #

在 Jenkins 中配置 Agent 节点时，可以选择通过以下几种方式连接代理节点：

• SSH 连接（Linux/Mac）：对于 Linux 或 macOS 系统的代理节点，可以通过 SSH 连接进行配置。
• Windows 代理（Jenkins agent）：对于 Windows 系统，可以使用 Jenkins Windows Agent。

1. 配置 Linux/macOS Agent #

• 在 Jenkins Web 界面中，点击 Manage Jenkins → Manage Nodes and Clouds → New Node，然后输入节点名称和选择节点类型。

• 选择

  Permanent Agent

  ，并输入该节点的详细信息：

  • Remote root directory：代理节点上 Jenkins 工作目录的路径。

  • Labels：标签，用于标识该代理节点，方便调度作业到此节点。

  • Launch method

    ：选择

    Launch agents via SSH
    

    ，然后提供代理节点的 SSH 配置信息，如：

    • 主机名或 IP 地址
    • 用户名
    • SSH 密钥或密码

• 配置完成后，点击 Save。

2. 配置 Windows Agent #

Windows 代理节点配置略有不同，通常使用 Jenkins Agent 可执行文件进行连接：

• 在 Jenkins Web 界面中，选择 Manage Jenkins → Manage Nodes and Clouds → New Node，并创建一个新的节点。
• 在 Launch method 中选择 Launch agent via Java Web Start，然后下载代理程序。
• 运行下载的代理程序，Jenkins 会自动连接并启动代理。

步骤三：验证 Agent 节点 #

配置完成后，在 Jenkins 控制台页面中，代理节点会显示为在线状态，并可以开始接收任务。

3. 配置多平台编译 #

在 Jenkins 中进行跨平台编译时，通常会涉及到平台特定的构建工具或环境配置。你可以通过以下方式配置多平台编译：

使用 Labels #

• 在 Jenkins 作业中，可以通过 Labels 来指定该作业需要在哪些节点上运行。例如，你可以为 Windows 系统的代理节点设置 windows 标签，为 Linux 系统的代理节点设置 linux 标签。
• 在作业配置中，通过设置构建节点的标签来确保作业在指定的代理节点上运行。

使用环境变量 #

• 在不同平台的代理节点中，设置不同的环境变量。例如，Windows 节点上可能需要设置 JAVA_HOME、MAVEN_HOME 等环境变量，而 Linux 节点上可能有不同的路径配置。
• 你可以在 Jenkins 中通过 Build Environment 配置环境变量，或者直接在每个平台的代理节点上设置合适的环境变量。

使用 Platform-Specific 构建工具 #

如果在不同平台上需要使用特定的构建工具，可以在 Jenkins 作业中设置不同的构建命令，或者在各个代理节点上安装平台相关的工具。例如：

• 在 Windows 节点上使用 MSBuild 构建项目。
• 在 Linux 节点上使用 mvn 或 make 命令进行构建。

4. Jenkins 集群的负载均衡和优化 #

• 负载均衡：Jenkins 会根据每个节点的资源情况和标签配置将任务分配到适当的代理节点。你可以根据资源使用情况设置节点的负载均衡策略。
• 节点管理：可以设置代理节点的 Idle time，以便节点在空闲时自动断开连接，节省资源。
• 节点标签：根据标签将不同类型的构建任务调度到特定的节点，保证构建任务在正确的环境下运行。

5. 通过 Pipeline 实现跨平台构建 #

通过 Jenkins Pipeline，可以在同一流水线中对多个平台进行构建。例如，你可以在 Jenkins Pipeline 中配置多平台构建，如：

pipeline {
    agent none
    stages {
        stage('Build Linux') {
            agent { label 'linux' }
            steps {
                sh './build-linux.sh'
            }
        }
        stage('Build Windows') {
            agent { label 'windows' }
            steps {
                bat 'build-windows.bat'
            }
        }
    }
}

在上述示例中，label 用来指定在不同的代理节点上运行不同的构建任务。

总结 #

1. Jenkins 集群：由主节点和多个代理节点组成，可以实现负载均衡和跨平台支持。
2. Agent 配置：根据操作系统类型（Windows、Linux、macOS）选择不同的连接方法，使用 SSH 或 Java Web Start。
3. 多平台编译：通过标签（Labels）、环境变量、平台特定构建工具和流水线配置，实现跨平台构建。
4. 负载均衡：Jenkins 会根据节点的资源和标签配置分配任务，保证不同平台的构建任务可以在适当的节点上执行。

通过这种方式，你可以在 Jenkins 集群中跨平台执行编译和构建任务，提高 CI/CD 流程的灵活性和可扩展性。

docker的几种不同的网络类型？ #

Docker 提供了几种不同的网络模式，用于容器之间的通信、容器与宿主机的通信等。以下是常见的 Docker 网络类型：

1. bridge 网络（桥接网络） #

• 默认网络模式：如果没有指定其他网络，Docker 会将容器连接到 bridge 网络。

• 特点

  ：

  • 容器之间可以通过 IP 地址或容器名称互相通信，但默认情况下，容器不能直接访问宿主机的网络。
  • 容器与外部网络之间的通信通过 Docker 主机的网络栈来实现，通常需要使用端口映射。
  • 容器通过 docker network bridge 默认创建的虚拟网桥进行通信。

• 适用场景

  ：

  • 单机部署或开发环境中，适合小规模容器部署。

docker run --name mycontainer --network bridge myimage

2. host 网络 #

• 特点

  ：

  • 容器共享宿主机的网络命名空间。容器不会获得自己的 IP 地址，而是直接使用宿主机的 IP 地址。
  • 容器与宿主机之间的网络通信是直接的，没有隔离。容器暴露的端口会直接映射到宿主机上。

• 适用场景

  ：

  • 当容器需要访问宿主机网络的高性能通信时，适合使用 host 网络。
  • 适用于需要极低延迟的场景，如高性能网络服务。

docker run --name mycontainer --network host myimage

3. none 网络 #

• 特点

  ：

  • 容器不会连接到任何网络。
  • 容器没有网络接口，因此容器无法与外部进行通信。只有容器内部的进程可以使用 localhost 进行通信。
  • 用于对网络要求极为严格的场景，或者测试需要完全隔离的环境。

• 适用场景

  ：

  • 当需要完全隔离网络的容器时，或者希望手动配置容器的网络接口。

docker run --name mycontainer --network none myimage

4. overlay 网络 #

• 特点

  ：

  • 用于多主机容器网络，允许跨宿主机的容器之间进行通信。
  • Docker Swarm 或 Kubernetes 等容器编排平台使用 overlay 网络来进行容器集群内的通信。
  • 基于 VXLAN 技术，提供了一种在多宿主机上创建虚拟网络的方式。

• 适用场景

  ：

  • 多宿主机容器之间的通信，通常用于微服务架构中。
  • 用于 Docker Swarm 集群或 Kubernetes 集群中的容器通信。

docker network create -d overlay my_overlay_network

5. macvlan 网络 #

• 特点

  ：

  • 容器获取自己的 MAC 地址，并通过宿主机的网络接口直接访问网络。
  • 容器表现得像独立的物理主机，可以在同一物理网络上进行通信。
  • 可用于要求容器像物理设备一样直接接入物理网络的场景。

• 适用场景

  ：

  • 容器需要直接接入物理网络或需要被物理网络中的其他设备直接访问。
  • 适用于需要更高级网络隔离的环境，例如某些企业级应用场景。

docker network create -d macvlan --subnet=192.168.1.0/24 --gateway=192.168.1.1 my_macvlan_network

6. host-gateway 网络（Docker 20.10 及以上版本） #

• 特点

  ：

  • 容器能够通过 host-gateway 地址访问宿主机的网络。
  • 通常在容器需要访问宿主机或宿主机访问容器时使用，便于容器与宿主机之间的网络交互。

• 适用场景

  ：

  • 在 Docker 20.10 或更高版本中，能够方便地通过容器访问宿主机网络。

docker network create --driver bridge --gateway host-gateway my_network

总结： #

• bridge：默认的容器网络，适用于单机部署。
• host：容器共享宿主机的网络栈，适用于高性能网络需求。
• none：容器没有网络连接，完全隔离。
• overlay：适用于跨主机容器通信，常用于集群部署。
• macvlan：容器获取独立的 MAC 地址，适用于需要直接访问物理网络的场景。
• host-gateway：容器与宿主机直接交互，便于容器访问宿主机。

选择适合的网络类型可以根据具体应用场景和网络需求来决定。

有container网络吗 #

在 Docker 中，并没有明确叫做 “container” 的网络类型，但 Docker 确实有一个名为 container 的网络模式，它允许容器之间共享网络命名空间。这意味着一个容器可以直接访问另一个容器的网络接口。

container 网络模式 #

• 特点

  ：

  • 在 container 网络模式下，容器将直接共享与指定容器相同的网络命名空间（包括 IP 地址、端口等网络信息）。
  • 容器间会通过容器名或 IP 地址直接进行通信，无需额外的网络隔离。
  • 当两个容器都使用 --network container:<container_name_or_id> 配置时，它们就共享一个网络栈。

• 适用场景

  ：

  • 容器需要共享网络栈，通常用于需要共享 IP 地址的场景。
  • 比如在容器内运行某些需要共享主机网络接口的应用，或者容器与其他容器需要直接进行低延迟、高效的网络通信。

使用示例： #

假设你有两个容器，一个是数据库容器，另一个是应用容器。你希望应用容器共享数据库容器的网络栈，可以使用如下命令：

docker run --name db_container --network bridge mysql
docker run --name app_container --network container:db_container myapp

在这个例子中，app_container 会使用与 db_container 相同的网络栈，直接访问数据库容器的 IP 地址和端口。

总结： #

• container 网络模式是 Docker 的一种特殊网络模式，允许容器共享网络栈。虽然没有单独的容器网络类型叫做 “container”，但这是一种非常特殊且有效的容器间通信方式，通常用于容器之间高度耦合的场景。

#

反问 #

运维团队大概有几个人，管理机器规模？ #

日常工作？ #