Strive to become a dream architect.
2023-12-15 myluzh Kubernetes
0x00 前言 最近在管理Rancher2.5部署的K8S集群发现一个问题，一旦Rancher Server不可用，直接在K8S master通过kubectl管理集群也会提示连接不到api提示不可用。 分析Rancher UI生成的kubeconfig文件可以发现，当kubectl访问K8S API SERVER的时候，请求是先发送到Rancher，然后再通过cluster agent转发给 K8S API SERVER。 所以需要开启“授权集群访问地址”，这样就算Rancher不可用，也可以通过kubectl --context 切换上下文，直接对集群直接进行管理。 0x01 启用Rancher授权集群访问地址 在rancher web面板中，找到集群，编辑，授权集群访问地址，启用，保存。 0x02 复制kubecfg配置 1、进入rancher面板，选择集群，在右上角打开“Kubeconfig文件”，复制kubeconfig文件内容。 可以看到kubecfg文件里面有两个上下文，第一个上下文就是先到rancher，再通过cluster agent转发到k8s api server的。 第二个上下文就...2023-12-7 myluzh Kubernetes
0x00 前言 在新版K8S中，即便 Service 使用 nodeport 暴露，在 node 中使用netstat -anp 或者ss -nlt命令上也看不到 kube-proxy 监听的端口了，但是 nodeport 访问是正常的。 Kubernetes服务不是作为侦听特定端口的进程来实现的。取而代之的是使用iptables (或IPVS)，服务基本上是iptables规则。这就是为什么它们不会出现在你的netstat中。 详细查看：https://kubernetes.io/docs/concepts/services-networking/service/#proxy-mode-iptables 0x01 你需要先了解kube-proxy的三种工作模式 1、userspace userspace模式是 kube-proxy 使用的第一代模式，该模式在 kubernetes v1.0 版本开始支持使用，该模式kube-proxy会为每一个Service创建一个监听端口，发向Cluster IP的请求被Iptables规则重定向到kube-proxy监听的端口上，kube-proxy根据LB算法选择一个...标签: k8s kube-porxy iptables ipvs
2023-12-4 myluzh Kubernetes
1、滚动更新之健康检查重要性 spec: containers: - name: my-container readinessProbe: tcpSocket: port: 9999 initialDelaySeconds: 60 periodSeconds: 10 livenessProbe: tcpSocket: port: 9999 initialDelaySeconds: 60 periodSeconds: 10 2、滚动更新之流量丢失解决方法（pod优雅退出） 这个操作的目的可能是为了在容器终止之前进行一些清理或收尾工作，例如保存临时数据或发送终止信号给其他进程。 spec: containers: - name: my-container lifecycle: preStop: exec: command: ...2023-11-23 myluzh Kubernetes
0x00 前置条件 1、开启K8S API聚合。关于API聚合：https://kubernetes.io/zh-cn/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/ 2、集群中安装Metrics Server。 0x01 开启Kubernetes API Aggregation 在 Kubernetes 1.7 版本引入了聚合层，允许第三方应用程序通过将自己注册到kube-apiserver上，仍然通过 API Server 的 HTTP URL 对新的 API 进行访问和操作。为了实现这个机制，Kubernetes 在 kube-apiserver 服务中引入了一个 API 聚合层（API Aggregation Layer），用于将扩展 API 的访问请求转发到用户服务的功能。  当你访问 apis/metrics.k8s.io/v1beta1 的时候，实际上访问到...2023-11-23 myluzh Kubernetes
0x00 HPA基本介绍 Kubernetes 中的 Metrics Server 持续采集所有 Pod 副本的指标数据。HPA 控制器通过 Metrics Server 的 API（Heapster 的 API 或聚合 API）获取这些数据，基于用户定义的扩缩容规则进行计算，得到目标 Pod 副本数量。当目标 Pod 副本数量与当前副本数量不同时，HPA 控制器就向 Pod 的副本控制器（Deployment、RC 或 ReplicaSet）发起 scale 操作，调整 Pod 的副本数量，完成扩缩容操作。 在弹性伸缩中，冷却周期是不能逃避的一个话题， 由于评估的度量标准是动态特性，副本的数量可能会不断波动。有时被称为颠簸， 所以在每次做出扩容缩容后，冷却时间是多少。 HPA（Horizontal Pod Autoscaler）：Pod个数自动扩/缩容。在 HPA 中，默认的扩容冷却周期是 3 分钟，缩容冷却周期是 5 分钟。可以通过调整kube-controller-manager组件启动参数设置冷却时间： - --horizontal-pod-autoscaler-downscale-delay ：扩容冷却 - --...2023-11-20 myluzh Kubernetes
0x00 Ingress金丝雀发布介绍 Nginx Annotations 支持以下 4 种 Canary 规则： （1）nginx.ingress.kubernetes.io/canary-by-header： 基于 Request Header 的流量切分，适用于灰度发布以及 A/B 测试。当 Request Header 设置为 always时，请求将会被一直发送到 Canary 版本；当 Request Header 设置为 never时，请求不会被发送到 Canary 入口；对于任何其他 Header 值，将忽略 Header，并通过优先级将请求与其他金丝雀规则进行优先级的比较。 （2）nginx.ingress.kubernetes.io/canary-by-header-value： 要匹配的 Request Header 的值，用于通知 Ingress 将请求路由到 Canary Ingress 中指定的服务。当 Request Header 设置为此值时，它将被路由到 Canary 入口。该规则允许用户自定义 Request Header 的值，必须与上一个 annotation (即：canar...