有两种基于 NGINX 的 Ingress 控制器实现:一种是nginxinc/kubernetes-ingress,另一种是kubernetes/ingress-nginx。
Grafana Image Renderer
是一个 Grafana 后端插件,它使用无头浏览器 (Chromium) 将面板和仪表板渲染为 PNG。比如下面的邮件通知,Include image
功能则需要这个插件。
本文中的Grafana在Docker容器中运行,用的Grafana7和Grafana8.5的镜像都实验了,如果是二进制本地化安装可能很多经验不适用。
本文将在Grafana的邮件报警通知
,Grafana容器中安装grafana-image-renderer插件
,独立运行grafana-image-renderer插件镜像作为远程服务
,遇到的坑
这几个方便做个记录。
我们都知道在k8s中,NameSpace是资源隔离的,那如何在命名空间A中调用B中的服务呢?
先说答案:第一种方式:在NameSpace A中创建无Selecter选择运算符的Service,然后手动创建EndPoints指向NameSpace B中的Service IP。或者第二种方式使用ExternalName 类型的Service
其实原理很简单,和我们创建平时创建普通Service一样:创建Service时一般会使用selecter选择Pod,会创建一个与Serivce同名EndPoints去调用Pod,使用kubectl get endpoints -n ns xxx -o yaml
可以看到在EndPoints中指定了Pod Ip和端口。
K8s中flexvolume插件驱动的安装只需要将对应驱动文件放到对应宿主机目录下,k8s 1.17及其之前需要重启kubelet组件生效
二进制集群环境默认路径:/usr/libexec/kubernetes/kubelet-plugins/volume/exec/<vendor~driver>/
Rancher集群环境默认路径:/var/lib/kubelet/volumeplugins/<vendor~driver>/
Install the vendor driver on all nodes (also on master nodes if "--enable-controller-attach-detach" Kubelet option is enabled) in the plugin path. Path for installing the plugin:
<plugindir>/<vendor~driver>/<driver>
. The default plugin directory is/usr/libexec/kubernetes/kubelet-plugins/volume/exec/
. It can be changed in kubelet via the--volume-plugin-dir
flag, and in controller manager via the--flex-volume-plugin-dir
flag.For example to add a
cifs
driver, by vendorfoo
install the driver at:/usr/libexec/kubernetes/kubelet-plugins/volume/exec/foo~cifs/cifs
The vendor and driver names must match flexVolume.driver in the volume spec, with '~' replaced with '/'. For example, if
flexVolume.driver
is set tofoo/cifs
, then the vendor isfoo
, and driver iscifs
.
我们知道k8s中可以通过服务名进行调用,初次部署coredns后正常运行但无法解析服务名,导致各pod之间通信不能通过svc,排查后发现kube-proxy报如下错误:
[root@k8s-node2 ~]# systemctl status kube-proxy -l
● kube-proxy.service - Kubernetes Proxy
Loaded: loaded (/usr/lib/systemd/system/kube-proxy.service; enabled; vendor preset: disabled)
Active: active (running) since Sun 2022-04-24 22:46:27 EDT; 6h ago
Main PID: 3134 (kube-proxy)
CGroup: /system.slice/kube-proxy.service
└─3134 /opt/kubernetes/bin/kube-proxy --logtostderr=false --v=2 --log-dir=/opt/kubernetes/logs --config=/opt/kubernetes/cfg/kube-proxy-config.yml
Apr 24 22:46:27 k8s-node2 systemd[1]: Started Kubernetes Proxy.
Apr 24 22:46:31 k8s-node2 kube-proxy[3134]: E0424 22:46:31.258995 3134 node.go:161] Failed to retrieve node info: Get "https://192.168.88.113:6443/api/v1/nodes/k8s-node2": dial tcp 192.168.88.113:6443: connect: no route to host
Apr 24 22:46:45 k8s-node2 kube-proxy[3134]: E0424 22:46:45.979680 3134 node.go:161] Failed to retrieve node info: Get "https://192.168.88.113:6443/api/v1/nodes/k8s-node2": net/http: TLS handshake timeout
Apr 24 22:46:56 k8s-node2 kube-proxy[3134]: E0424 22:46:56.589155 3134 proxier.go:1644] Failed to delete stale service IP 10.0.0.2 connections, error: error deleting connection tracking state for UDP service IP: 10.0.0.2, error: error looking for path of conntrack: exec: "conntrack": executable file not found in $PATH
Apr 24 22:47:25 k8s-node2 kube-proxy[3134]: E0424 22:47:25.572468 3134 proxier.go:778] Failed to delete kube-system/kube-dns:dns endpoint connections, error: error deleting conntrack entries for udp peer {10.0.0.2, 10.244.1.27}, error: error looking for path of conntrack: exec: "conntrack": executable file not found in $PATH
Apr 25 05:06:00 k8s-node2 kube-proxy[3134]: E0425 05:06:00.578223 3134 proxier.go:778] Failed to delete kube-system/kube-dns:dns endpoint connections, error: error deleting conntrack entries for udp peer {10.0.0.2, 10.244.1.31}, error: error looking for path of conntrack: exec: "conntrack": executable file not found in $PATH
Apr 25 05:06:08 k8s-node2 kube-proxy[3134]: E0425 05:06:08.888616 3134 proxier.go:1644] Failed to delete stale service IP 10.0.0.2 connections, error: error deleting connection tracking state for UDP service IP: 10.0.0.2, error: error looking for path of conntrack: exec: "conntrack": executable file not found in $PATH
在k8s中使用了ingress-nginx-controller作为Ingress控制器,默认bodysize最大限制为1M,在类似文件上传下载比较大的请求中就会出现失败返回413状态码的情况。如果是nginx-ingress-controller注解是不一样的,它们两的区别可以查看我另一篇文章K8s中的两种nginx-ingress-controller及其区别
解决:在Ingress的metadata中添加如下annotations
在K8s中我们知道可以使用Exec或TCP或HTTP对应用进行就绪探针检测和存活检测、以便K8s可以对应用进行平滑更新、升级、关停等。最近在K8s中部署SpringBoot应用,使用TCP 8080(应用端口)进行就绪探针检测,在更新应用时发现了一个问题。
由于该应用启动时间比较长,大概60s,K8s设定每15秒进行一次TCP就绪探针检测,发现进行应用更新过程中,新版本还未完全启动时便kill掉了老版本,导致应用出现大概35秒的时间不可用,使用kubectl get pod -w
观察过程如下:
使用TCP Socket进行就绪探测:
前言
需求:需要在k8s的部署文件(Kind:Deployment)中定义变量,在应用程序中要能够接收变量值。
最终通过设置环境变量(ENV)来给应用程序传递参数。下面来简单分析一下。
SpringBoot中如何接收运行参数的
首先我们先了解SpringBoot中如何接收运行参数。
通常我们以一个jar的方式运行程序,比如我们的命令为java -jar -DDATE=20220616 /opt/app/app.jar ycyin 20220617
在程序中我们尝试读取值:
修改k8s节点主机名并重新加入集群
k8s版本:v1.20.15
部署方式:二进制
目的:将节点名称为k8s-node01
修改为k8s-node1
,修改后需要删除节点重新加入k8s集群。
删除Node01节点
kubectl delete node k8s-node01
前言
Kubernetes 卷(Volume)有很多的类型,hostPath方式只是其中一个,关于hostPath,它的定位可能还是一个比较简单的应用设计,例如demo,测试等,因为它需要在每一个node节点都要有对应的挂载目录/文件。比如在k8s集群中,Master调用nginx服务,他可能会分配到多个节点,例如有2个node节点,这次nginx服务被分配到了node2节点,如果node2节点没有建立相应的目录以及配置文件,就会映射失败,那么怎么解决这个问题?