kubernetes

前言 最近在使用 Kubernetes 查看 pod 日志时,发现 pod 日志显示的 ip 不是真实的请求者 ip, 而是 Node 节点的 ip。通过查阅资料发现可以通过设置 externalTrafficPolicy 来显示真实的 IP。 本文对 externaltrafficpolicy 进行一个简单的介绍。 简介 ExternalTrafficPolicy 是 Kubernetes Service 对象的一个属性，它决定了流量如何从集群外部访问 Service。有两个可选值：Cluster 和 Local。 Cluster 模式： 在 Cluster 模式下，流量将通过负载均衡器分发到 Service 的所有 Pod 上。这是传统的负载均衡方式，适用于需要水平扩展和容错的场景。负载均衡器会将流量平均分配给所有可用的 Pod，从而实现负载均衡。 Local 模式： 在 Local 模式下，流量将直接访问与请求最近的节点上运行的 Pod。这种方式避免了负载均衡器的介入，直接将流量定向到本地的 Pod 上。这样可以减少延迟，并且在负载均衡器发生故障时仍然保持可用性。 区别 两种模式有什么区别呢? Cluster 模式 Cluster 模式是默认的模式,Kube-proxy 不管容器在哪个节点上,会公平的转发到某一个节点上，在转发时会替换掉源ip，变成转发的上一个节点的ip.原因是Kube-proxy在做转发的时候，会做一次SNAT (source network address translation)，所以源ip变成了上一个节点的ip地址。 这个模式的优点是负载均衡比较好，缺点是由于转发,可能会有性能损耗。 Local 模式 Local 模式下,请求只转发给本机的容器,不会转发给其它节点的容器,保留了源ip。 这个模式的优缺点跟 Cluster 模式恰恰相反:性能好,负载均衡不好。所以如果想要负载均衡就需要一层 LB 来进行控制。 参考 https://github....

问题 最近在调用一个上传文件的接口时，发现接口调用响应状态码为413,并且控制台显示跨域错误信息。查找了相关信息，得知 413 状态码表示请求的包体过大导致的。 出现这种情况，我想到了2种解决方案: 1) 调整上传文件的方式 2) 调整网关的参数。 综合目前的现况，采取了第二种方式调整网关客户端请求体最大值的参数。 解决 通过查阅 nginx ingress 的文档, 得知可以添加 nginx.ingress.kubernetes.io/proxy-body-size 注解来设置请求体的最大值, 设置 nginx.ingress.kubernetes.io/proxy-body-size 值为合适的值后，再请求接口发现接口顺利响应。 小结 本文介绍了客户端请求接口时,由于 nginx 默认 proxy-body-size 参数太小, 导致请求413 的问题及相应的解决方案。 参考 https://opendocs.alipay.com/support/01rb44 https://nginx.org/en/docs/http/ngx_http_core_module.html#client_max_body_size https://github.com/kubernetes/ingress-nginx/blob/main/docs/user-guide/nginx-configuration/annotations.md#custom-max-body-size

本文我来讲解 Kubernetes 中的一个重要概念: 容器的健康检查。 介绍 在 Kubernetes 中，你可以为 Pod 里的容器定义一个健康检查“探针”（Probe）。 这样，kubelet 就会根据这个 Probe 的返回值决定这个容器的状态，而不是直接以容器镜像是否运行（来自 Docker 返回的信息）作为依据。 这种机制，是生产环境中保证应用健康存活的重要手段。 k8s 主要有三种健康检查的探针: 1) LivenessProbe 存活探针 2) ReadinessProbe 就绪探针 3) StartupProbe 启动探针 kubelet 使用存活探针来确定什么时候要重启容器。 例如，存活探针可以探测到应用死锁（应用程序在运行，但是无法继续执行后面的步骤）情况。 重启这种状态下的容器有助于提高应用的可用性，即使其中存在缺陷。 存活探针的常见模式是为就绪探针使用相同的低成本 HTTP 端点，但具有更高的 failureThreshold。 这样可以确保在硬性终止 Pod 之前，将观察到 Pod 在一段时间内处于非就绪状态。 kubelet 使用就绪探针可以知道容器何时准备好接受请求流量，当一个 Pod 内的所有容器都就绪时，才能认为该 Pod 就绪。 这种信号的一个用途就是控制哪个 Pod 作为 Service 的后端。 若 Pod 尚未就绪，会被从 Service 的负载均衡器中剔除。 kubelet 使用启动探针来了解应用容器何时启动。 如果配置了这类探针，你就可以控制容器在启动成功后再进行存活性和就绪态检查， 确保这些存活、就绪探针不会影响应用的启动。 启动探针可以用于对慢启动容器进行存活性检测，避免它们在启动运行之前就被杀掉。 probe 介绍 接下来我来讲解用的较多的2个探针: 1) LivenessProbe 存活探针 2) ReadinessProbe 就绪探针...

前言 最近看了 k8s 的书，学习了一些新的知识，将会分几篇来介绍学习到的知识，本文来先介绍k8s中如何修改 pod 的hosts文件。 我们知道当DNS出现问题时，可以向 Pod 的/etc/hosts文件添加条目来提供主机名解析Pod级别覆盖。该如何向hosts 文件中添加条目呢？ 可以使用PodSpec中的HostAliases字段添加自定义条目。 虽然我们也可以直接进入pod修改host文件来实现，但这样pod重建时会被覆盖，所以我们应该使用 HostAliases 来进行修改，因为该文件会由 Kubelet 管理，并且 可以在 Pod 创建/重启过程中被重写。 使用 我们该如何操作呢，接下来由我来介绍使用步骤: 1 先创建 Deployment YAML文件来创建后台运行的 busybox pod 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 apiVersion: apps/v1 kind: Deployment metadata: name: busybox-deployment spec: replicas: 1 selector: matchLabels: app: busybox template: metadata: labels: app: busybox spec: containers: - name: busybox image: busybox args: [ "sleep", "3600" ] resources: limits: memory: "128Mi" cpu: "500m" requests: memory: "64Mi" cpu: "250m" volumeMounts: - name: busybox-volume mountPath: /data volumes: - name: busybox-volume emptyDir: {} 查看 pod ip...

今天我来简单介绍 kubernetes 生态中一个重要一环-包管理工具 Helm。 介绍 Helm 是 Kubernetes 的开源包管理器。它提供了提供、共享和使用为 Kubernetes 构建的软件的能力。 Helm 于 2015 年在 Deis 创建，后来被微软收购。现在称为 Helm Classic 的是在当年 11 月的首届 KubeCon 上推出的。2016 年 1 月，Helm Classic 与谷歌的 Kubernetes 部署管理器合并到现在是 Helm 主要项目的存储库中。 该项目目前拥有超过 30,000 个 GitHub stars，每月从全球获得超过 200 万次下载。2020 年 4 月，Helm 在 CNCF 中获得毕业。 安装 Helm 二进制安装 1 打开 https://github.com/helm/helm/releases , 下载你需要的版本 2 解压安装包 3 将文件夹中的 helm 二进制文件移动到相应的位置 脚本安装 helm 官方提供了一个安装的脚本: 1 2 3 $ curl -fsSL -o get_helm....