jiayu的博客

生产环境下更注重于集群的高可用，不同于测试环境的单主节点，在生产环境下需要配置至少两个主节点两个node节点，保证在主节点挂掉之后，node节点的kubelet还能访问到另一个主节点的apiserver等组件进行运作，这篇文章将部署一次k8s高可用集群

JumpServer-v2.20.0迁移K8S运行yaml: 相关链接：https://gitee.com/jiayu997/kubernetes/blob/master/Jumpserver-v2.20.0/Jumpserver.tar.gz测试环境主机k8s-master-1192.168.0.10MASTER节点k8s-node-1192.168.0.11WORK节点k8s-nfs192.168.0.55提供NFS存储实际效果jms_co

k8s-v1.20.10 1master&2node实验环境主机网络信息和组件信息K8S集群角色IP主机名安装的组件master192.168.0.10k8s-master-1apiserver、controller-manager、scheduler、etcd、docker、kubectl、kubelet、kube-proxy、calico、coredns、metric-servernode192.168.0.11k8s-node-1kubelet、

使用longhorn的backup/restore功能，但是随着数据量的增加，RTO时间具体需要多久待测试，且由于backup是定时或某个时刻手动触发的，RPO大小取决于备份完成后到发生故障这段时间具体产生了多少数据。且用户是否能容忍丢失这个数据量？将k8s-node-3/k8s-node-2节点关机(longhorn基础组件功能及其作用这里就不做介绍了。通过上述测试我们可以发现。

查看MAC地址信息，这个 MAC 地址应该是 Calico 硬塞进去的，而且还能响应 ARP。这个 IP 地址，拥有这个 IP 地址的设备会将自己的 MAC地址返回给对方。，而网关的 IP 地址不会出现在任何网络包头中。也就是说，没有人在乎这个 IP 地址究竟是什么，只要能找到对应的 MAC 地址，能响应 ARP 就行了。k8s-node-1 ens160物理抓包查看报文，可以发现和k8s-master-1 ens160发出来的数据报文一致。是容器的默认网关，但却找不到任何一张网卡对应这个 IP 地址。

​ 通过这个实验，我们可以很清晰地掌握 Calico 网络的数据转发流程，首先需要给所有的 ns 配置一条特殊的路由，并利用 veth 的代理 ARP 功能让 ns 出来的所有转发都变成三层路由转发，然后再利用主机的路由进行转发。这种方式不仅实现了同主机的二三层转发，也能实现跨主机的转发。

代理 ARP 是 ARP 协议的一个变种，当 ARP 请求目标跨网段时，网关设备收到此 ARP 请求，会用自己的 MAC 地址返回给请求者，这便是代理 ARP（Proxy ARP）。下面这张图中，电脑发送 ARP 请求服务器8.8.8.8 的 MAC 地址，路由器（网关）收到这个请求时会进行判断，由于目标 8.8.8.8 不属于本网段（即跨网段），此时便返回自己的接口 MAC 地址给 PC，后续电脑访问服务器时，目标 MAC 直接封装为 MAC25。当一个数据包的目的地址不是本机时，就会查询路由表

Calico切换网络模式无效问题解决

Metrics Server 是 Kubernetes 集群核心监控数据的聚合器（定时从Kubelet的Summary API 采集指标信息），可以通过 Metrics API 的形式获取 Metrics 数据，不过仅仅是获取指标的最新值，数据不做存储，且不负责将指标转发到第三方目标。Metrics Server 还可以与 Kubectl 工具结合使用，提供 Kubectl Top 命令来展示集群中的指标数据通俗地说，它存储了集群中各节点的监控数据，并且提供了API以供分析和使用。

但有些时候我们不得不启动多个进程，比如从传统部署迁移到 Kubernetes 的过渡期间，使用了富容器，即单个容器中需要启动多个业务进程，这时也只能通过 shell 启动，但无法使用上面的。如果我们父进程以bash/sh启动，能提供进程收割能力，防止容器出现僵尸进程，但是缺无法将终止信号传递给子进程，为此我们一般采用：dumb-init、tini作为父进程(提供进程接管能力、信号传递能力)简单而言，如果在容器中运行多个进程，PID1进程需要有能力接管“孤儿”进程并回收“僵尸”进程。：终止进程，杀死进程。

公司生产环境alpine基础基础镜像在解析类似``servicename、servicename.namespace.svc.cluster.local。时并未按照/etc/resolv.conf 中规则进行dns search，导致上述二种dns无法被解析

Istio Ingress-Gateway配置单双向TLS

基于Harbor管理helm仓库

挂载传播提供了共享卷挂载的能力, 它允许在同一个 Pod, 甚至同一个节点内, 在多个容器之间共享卷的挂载。kubernetes 中 卷的挂载传播由。kubernetes 的。

​ CA机构三套：apiserver一套，etcd一套，api聚合层一套(由于和apiserver共用一套CA会发生冲突这里单独使用一个CA)，颁发机构分别为：ca-apiserver，ca-etcd，front-proxy-ca。Github yaml部署链接：https://github.com/flannel-io/flannel/blob/master/Documentation/kube-flannel.yml。注：token.csv后边用于给kubelet自动颁发证书所使用的。

当K8S集群内生成大量被驱逐的pod时，在master负载较高时使用kubectl批量删除异常pod速度很慢，故使用原生的client-go库优化删除速度

kube-controller-manager的eviction机制是粗粒度的，即驱赶一个节点上的所有pod，而kubelet则是细粒度的，它驱赶的是节点上的某些Pod，驱赶哪些Pod与Pod的Qos机制有关。驱逐会考虑Pod的优先级，资源使用和资源申请。Eviction，即驱逐的意思，意思是当节点出现异常时，为了保证工作负载的可用性，kubernetes将有相应的机制驱逐该节点上的Pod。

K8S Docker数据目录迁移与扩容。

于 Kubernetes 集群中的 Pod，由于容器内不便于抓包，通常视情况在 Pod 数据包经过的 veth 设备，docker0 网桥，CNI 插件设备（如 cni0，flannel.1 etc..）及 Pod 所在节点的网卡设备上指定 Pod IP 进行抓包

默认docker运行程序下，如果未设置绑核，应用程序存在多个进程，且多个进程存在优先级，那么在这种情况下，可能会导致主进程工作效率降低单进程显然竞争不过多进程容器内如果存在多个进程，会存在低优先级抢占CPU的情况，导致主进程工作效率下降（解决办法：进行绑核处理）在宿主机资源不紧张的情况下，k8s可以保证每个pod分配request资源，且能将资源限制在limit之下在宿主机资源紧张的情况下，容器进程多的能抢占到更多的CPU，即使他们request与limit相同，且此时。...

Promethues operate blackbox(http/tcp/dns/icmp探测)部署参考

k8s内利用kong实现外部流量负载均衡

Kong是一个开源的网关，具有登录鉴权、熔断限流等功能，且其是基于Nginx和OpenResty开发的。同时，Kong也提供了和k8s高度融合的Kong Ingress Controller，可以直接作为k8s的原生网关使用

公司K8S集群内部某些节点安装了keepalived，但是在IPVS模式下，这些节点出现了VIP未创建ipvs 规则，导致无法通过VIP:PORT去访问服务

k8s部署flannel时报failed to find plugin "portmap" in path [/opt/cni/bin]]

Kubernetes 通过身份认证插件利用客户端证书、持有者令牌（Bearer Token）或身份认证代理（Proxy） 来认证 API 请求的身份，这篇博客将介绍如何基于用户、用户组进行授权

PushGateway简介Pushgateway 是 prometheus 的一个组件， prometheus server默认是通过exporter主动获取数据（默认采取 pull 拉取数据） pushgateway 则是通过被动方式推送数据到 prometheus server，用户可以写一些自定义的监控脚本把需要监控的数据发送给 pushgateway 然后pushgateway 再把数据发送给 Prometheus serverPrometheus默认采用定时 pull 模式拉取 target

告警效果Prometheus-server-configPrometheus-server规则参考链接(提供了不同exporter下各类常规指标告警规则)：https://awesome-prometheus-alerts.grep.to/rules注：由于监控etcd时需要使用相关证书，需要将etcd相关证书制作成secret，并挂载给prometheus-server使用 kubectl -n kube-prometheus create secret generic etcd-certs

Grafana 是一个开源的监控数据分析和可视化套件。最常用于对基础设施和应用数据分析的时间序列数据进行可视化分析，也可以用于其他需要数据可视化分析的领域，这边文章将基于k8s部署Grafana-v8.5.1

kube-state-metrics 通过监听 API Server 生成有关资源对象的状态指标，比如 Deployment 、Node 、 Pod ，`需要注意的是 kube-state-metrics 只是简单的提供一个 metrics 数据，并不会存储这些指标数据`，所以我们可以使用 Prometheus 来抓取这些数据然后存储，主要关注的是业务相关的一些元数据，比如 Deployment 、 Pod 、副本状态等；调度了多少个 replicas ？现在可用的有几个？多少个 Pod 是running

Prometheus-v2.35.0 k8s单节点部署

当prometheus配置node_exporter后，却发现node_exporter的状态是Down的

由于默认情况下，来自 Istio-enable Pod 的所有出站流量都会重定向到其 Sidecar 代理，集群外部 URL 的可访问性取决于代理的配置。默认情况下，Istio 将 Envoy 代理配置为允许传递未知服务的请求。尽管这为入门 Istio 带来了方便，但是，通常情况下，配置更严格的控制是更可取的

这篇文章将根据Istio官方案例实现Gateway的TLS或mTLS，以及HTTPS透传

流量镜像，也称为影子流量，是一个以尽可能低的风险为生产带来变化的强大的功能。镜像会将实时流量的副本发送到镜像服务。镜像流量发生在主服务的关键请求路径之外

Istio 在 Envoy 中设置请求超时示例

熔断，是创建弹性微服务应用程序的重要模式。熔断能够使您的应用程序具备应对来自故障、潜在峰值和其他未知网络因素影响的能力

灰度发布也叫金丝雀部署，是指通过控制流量的比例，实现新老版本的逐步更替。比如对于服务 A 有 version1 、 version2 两个版本 当前两个版本同时部署，但是 version1 比例90% version2 比例 10% ，看运行效果，如果效果好逐步调整流量占比 80 20 7030 ·····10 90 0 100 ，最终 version1 版本下线

在Prometheus的架构设计中，Prometheus Server并不直接服务监控特定的目标，其主要任务负责数据的收集，存储并且对外提供数据查询支持。因此为了能够能够监控到某些东西，如主机的CPU使用率，我们需要使用到Exporter。Prometheus周期性的从exporter暴露的HTTP服务地址（通常是/metrics）拉取监控样本数据

基于statefulset实现一主多从redis，动态扩缩容redis从库，并基于storageclass实现动态存储，保证数据的持久化存储