Kubernetes on SRE运维博客

多云搭建 K3S 集群

Wenlong — Fri, 19 Nov 2021 11:32:53 +0800

作者：SRE运维博客
博客地址： https://www.cnsre.cn/
文章地址：https://www.cnsre.cn/posts/211119132529/
相关话题：https://www.cnsre.cn/tags/k3s/

双十一薅了几个云厂商的羊毛，一开始搭建了k3s的单机版，后面就想着能不能搭建一个k3s集群，然后参考了这位大佬的文章，就试着用 WireGuard 来进行组网。它轻量、便捷、高效，而且数据全程加密传输，是依托公网组建虚拟局域网的优秀选择。

环境介绍

服务器介绍

云厂商	公网IP地址	内网IP地址	虚拟网络IP地址	操作系统	内核版本
腾讯云1	42.xx.xx.12	10.0.16.8	192.168.1.1	CentOS Linux release 7.9.2009 (Core)	5.15.2-1
腾讯云2	122.xx.xxx.111	10.0.0.6	192.168.1.2	CentOS Linux release 7.9.2009 (Core)	5.15.2-1
阿里云	122.xx.xx.155	172.17.0.3	192.168.1.3	CentOS Linux release 7.9.2009 (Core)	5.15.2-1

搭建前准备

在搭建跨云的 k3s 集群前，我们需要把 WireGuard 安装好，WireGuard 对内核是有要求的，所以内核已经要升级到 5.15.2-1.el7.elrepo.x86_64

在所有节点开启 IP 地址转发

1
2
3

echo "net.ipv4.ip_forward = 1" >> /etc/sysctl.conf
echo "net.ipv4.conf.all.proxy_arp = 1" >> /etc/sysctl.conf
sysctl -p /etc/sysctl.conf

所有节点开启修改主机名称

# 腾讯云1执行
hostnamectl  set-hostname k3s-master
# 腾讯云2执行
hostnamectl  set-hostname k3s-node1
# 阿里云执行
hostnamectl  set-hostname k3s-node2

升级内核

几个服务器默认的内核都是 3.10 的，安装WireGuard 需要吧内核升级到比较高的版本。

升级内核前

先升级软件包（非必要）

`1`	`yum update -y`

添加 iptables 规则，允许本机的 NAT 转换：

所有节点都要执行

iptables -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
iptables -A FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
iptables -A FORWARD -i wg0 -o wg0 -m conntrack --ctstate NEW -j ACCEPT
iptables -t nat -A POSTROUTING -s 192.168.1.1/24 -o eth0 -j MASQUERADE

wg0:为你定义的虚拟网卡

192.168.1.1: 为你的虚拟IP地址段

eth0:为你的物理网卡

升级内核

所有节点都要执行

方法1：

直接下载RPM包进行安装。

如果你想安装其他内核，你也可以在这里下载

1
2

wget https://pan.cnsre.cn/d/Package/Linux/kernel/kernel-ml-5.15.2-1.el7.elrepo.x86_64.rpm
rpm -ivh kernel-ml-5.15.2-1.el7.elrepo.x86_64.rpm

方法 2：

利用包管理工具更新

# 载入公钥
rpm --import https://www.elrepo.org/RPM-GPG-KEY-elrepo.org
# 升级安装 elrepo
rpm -Uvh http://www.elrepo.org/elrepo-release-7.0-5.el7.elrepo.noarch.rpm
# 载入 elrepo-kernel 元数据
yum --disablerepo=\* --enablerepo=elrepo-kernel repolist
# 安装最新版本的内核
yum --disablerepo=\* --enablerepo=elrepo-kernel install  kernel-ml.x86_64  -y
# 删除旧版本工具包
yum remove kernel-tools-libs.x86_64 kernel-tools.x86_64  -y

方法3：

通过源码包编译安装.

这种方式可定制性强，但也比较复杂，有需要的可自行查找资料安装，下面只给出各系统版本内核源码包的下载地址

修改默认内核版本

# 查看当前实际启动顺序
grub2-editenv list
# 查看内核插入顺序
grep "^menuentry" /boot/grub2/grub.cfg | cut -d "'" -f2
# 设置默认启动
grub2-set-default 'CentOS Linux (5.15.2-1.el7.elrepo.x86_64) 7 (Core)'
# 重新创建内核配置
grub2-mkconfig -o /boot/grub2/grub.cfg
# 重启服务器
reboot
# 验证当前内核版本
uname -r

内核版本一定要是比较高的，不然启动WireGuard会有如下报错。

[#] ip link add wg0 type wireguard
RTNETLINK answers: Operation not supported
Unable to access interface: Protocol not supported
[#] ip link delete dev wg0
Cannot find device "wg0"

安装 WireGuard

所有节点执行

安装流程非常简单，我这里是直接将 CentOS 内核更新到目前最新的 5.15.2 版本，其中就已经包含了 WireGuard 的内核模块，只需要安装 wireguard-tools 这个 yum 包就行了。

1
2

yum install epel-release https://www.elrepo.org/elrepo-release-7.el7.elrepo.noarch.rpm
yum install yum-plugin-elrepo kmod-wireguard wireguard-tools -y

配置 WireGuard

wireguard-tools 包提供了我们所需的工具 wg 和 wg-quick，可以使用它们来分别完成手动部署和自动部署。

先按照官方文档描述的形式，生成腾讯云1用于加密解密的密钥

`1`	`wg genkey \| tee privatekey \| wg pubkey > publickey`

然后在当前目录下就生成了 privatekey 和 publickey 两个文件

密钥是配置到本机的，而公钥是配置到其它机器里的。

1
2
3

cat privatekey publickey
EMWcI01iqM4zkb7xfbaaxxxxxxxxDo2GJUA=
0ay8WfGOIHndWklSIVBqrsp5LDWxxxxxxxxxxxxxxQ=

现在我们需要与上述主机对等联网的 腾讯云2 阿里云 ，其公网IP（这边需要填写的是能与主机通信的IP）是 122.xx.xxx.111，122.xx.xx.155

我们首先依照上面的流程安装 WireGuard 并生成好 腾讯云2 阿里云 的密钥。

然后编写 腾讯云1 完整的配置文件，以供 wg-quick 使用，在主机A的 /etc/wireguard/wg0.conf 中写入

[Interface]
PrivateKey = EMWcI01iqM4zkb7xfbaaxxxxxxxxDo2GJUA=
Address = 192.168.1.1
ListenPort = 5418

[Peer]
PublicKey = 腾讯云2 publickey
EndPoint = 122.xx.xxx.111:5418
AllowedIPs = 192.168.1.2/32

[Peer]
PublicKey = 阿里云publickey
EndPoint = 122.xx.xx.155:5418
AllowedIPs = 192.168.1.3/32

配置说明

Interface: 小节是属于腾讯云1（也就是本机）的配置.

Address: 是分配给 腾讯云1 虚拟IP，

ListenPort: 是主机之间通讯使用的端口，是 UDP 协议的。

Peer: 是属于需要通信的 腾讯云2 、阿里云 的信息，有多少需要通信的主机，就添加多少个 Peer 小节。

EndPoint: 是 腾讯云2 、阿里云的公网IP与 WireGuard 监听的 UDP 端口，这个 IP 不一定是公网，

如果你的机器通过内网也能通信，直接用内网 IP 也可以，当然要注意这个IP需要所有加入局域网的主机都能通信才行。

AllowedIPs: 是指本机发起连接的哪些IP应该将流量转发到这个节点去，比如我们给主机B分配了内网IP 192.168.1.2，那么在主机A上发送到 192.168.1.2 的数据包，都应该转发到这个 EndPoint 上，它其实起的是一个过滤作用。而且多个 Peer 时，这里配置的IP地址不能有冲突。

各个节点生产的 privatekey 和publickey 分别如下

# master 节点
[root@k3s-master ~]# cat privatekey publickey
EMWcI01iqM4zkb7xfbaaxxxxxxxxDo2GJUA=
0ay8WfGOIHndWklSIVBqrsp5LDWxxxxxxxxxxxxxxQ=
# node1 节点
[root@k3s-node1 ~]# cat privatekey publickey
QGdNkzpnIkuvUU+00C6XYxxxxxxxxxK0D82qJVc=
3izpVbZgPhlM+S5szOogTDTxxxxxxxxxuKuDGn4=
# node2 节点
[root@k3s-node2 ~]# cat privatekey publickey
WOOObkWINkW/hqaAME9r+xxxxxxxxxm+r2Q=
0f0dn60+tBUfYgzw7rIihKbqxxxxxxxxa6Wo=

各节点配置

# master 节点
cat /etc/wireguard/wg0.conf
[Interface]
PrivateKey = EMWcI01iqM4zkb7xfbaaxxxxxxxxDo2GJUA=
Address = 192.168.1.1
ListenPort = 5418

[Peer]
PublicKey = 3izpVbZgPhlM+S5szOogTDTxxxxxxxxxuKuDGn4=
EndPoint = 122.xx.xxx.111:5418
AllowedIPs = 192.168.1.2/32

[Peer]
PublicKey = 0f0dn60+tBUfYgzw7rIihKbqxxxxxxxxa6Wo=
EndPoint = 122.xx.xx.155:5418
AllowedIPs = 192.168.1.3/32

# node1 节点
cat /etc/wireguard/wg0.conf
[Interface]
PrivateKey = QGdNkzpnIkuvUU+00C6XYxxxxxxxxxK0D82qJVc=
Address = 192.168.1.2
ListenPort = 5418

[Peer]
PublicKey = 0ay8WfGOIHndWklSIVBqrsp5LDWxxxxxxxxxxxxxxQ=
EndPoint = 42.xxx.xx.16:5418
AllowedIPs = 192.168.1.1/32

[Peer]
PublicKey = 0f0dn60+tBUfYgzw7rIihKbqxxxxxxxxa6Wo=
EndPoint = 122.xx.xx.155:5418
AllowedIPs = 192.168.1.3/32

# node2 节点
cat /etc/wireguard/wg0.conf
[Interface]
PrivateKey = WOOObkWINkW/hqaAME9r+xxxxxxxxxm+r2Q=
Address = 192.168.1.3
ListenPort = 5418

[Peer]
PublicKey = 0ay8WfGOIHndWklSIVBqrsp5LDWxxxxxxxxxxxxxxQ=
EndPoint = 42.xxx.xx.16:5418
AllowedIPs = 192.168.1.1/32

[Peer]
PublicKey = 3izpVbZgPhlM+S5szOogTDTxxxxxxxxxuKuDGn4=
EndPoint = 122.xx.xx.155:5418
AllowedIPs = 192.168.1.2/32

启动 WireGuard

配置文件写好后，使用 wg-quick 工具来创建虚拟网卡，

`1`	`wg-quick up wg0`

上面命令中的 wg0 对应的是 /etc/wireguard/wg0.conf 这个配置文件，其自动创建的网卡设备，名字就是 wg0，这对应关系自不必多言。

将腾讯云2 、阿里云 的网卡设备都安装配置好后，就能使用 wg 命令来观察组网情况了

[root@k3s-master ~]# wg
interface: wg0
  public key: 0ay8WfGOIHndWklSIVBqrsp5LDWxxxxxxxxxxxxxxQ=
  private key: (hidden)
  listening port: 5418

peer: 0f0dn60+tBUfYgzw7rIihKbqxxxxxxxxa6Wo=
  endpoint: 122.xx.xx.155:5418
  allowed ips: 192.168.1.3/32
  latest handshake: 3 minutes, 3 seconds ago
  transfer: 35.40 KiB received, 47.46 KiB sent

peer: 3izpVbZgPhlM+S5szOogTDTxxxxxxxxxuKuDGn4=
  endpoint: 122.xx.xxx.111:5418
  allowed ips: 192.168.1.2/32
  latest handshake: 5 minutes, 6 seconds ago
  transfer: 24.84 KiB received, 35.21 KiB sent

可以看到列出了对等联网的节点信息，还有通信测量数据。然后可以通过 ping 其他主机的虚拟IP或者 ssh 其他主机的IP地址，来检查网络通信是否正常。

自动化

系统重启后，WireGuard 创建的网卡设备就会丢失，有自动化的脚本

`1`	`systemctl enable wg-quick@wg0`

使用上述命令生成systemd守护脚本，开机会自动运行up指令。

配置热重载

wg-quick并未提供重载相关的指令，但是提供了 strip 指令，可以将 conf 文件转换为 wg 指令可以识别的格式。

`1`	`wg syncconf wg0 <(wg-quick strip wg0)`

即可实现热重载。

完成 WireGuard 的安装配置以后，我们就可以接下来安装 k3s 的集群了。

安装 K3S 集群

master节点安装

curl -sfL http://rancher-mirror.cnrancher.com/k3s/k3s-install.sh | INSTALL_K3S_MIRROR=cn sh  -s -  --node-external-ip 42.xx.xx.12--advertise-address 42.xx.xx.12--node-ip 192.168.1.1 --flannel-iface wg0

参数说明：

--node-external-ip 42.xxx.xx.16 为节点设置外部IP，阿里云VPC的外网IP并未直接绑定到虚拟机网卡上，所以我要设置这个参数，避免k3s组件在设置loadbalance时，将内网IP当作公网IP使用。
--advertise-address 42.xxx.xx.16 用于设置kubectl工具以及子节点进行通讯使用的地址，可以是IP，也可以是域名，在创建apiserver证书时会将此设置到有效域中。
--node-ip 10.20.30.1 如果不设置这个参数，那么第一张网卡设备上的IP就会被选中，所以这个IP常是内网IP。但我自行组建了虚拟局域网，所以需要指定虚拟局域网的IP（也就是WireGuard的IP）。
--flannel-iface wg0 wg0是WireGuard创建的网卡设备，我需要使用虚拟局域网来进行节点间的通信，所以这里需要指定为wg0。

另外就是，由于WireGuard的所有流量都是加密传输的，通过它来进行节点间的通信，就已经能够保证通信安全，也就没有必要改用其它的CNI驱动，使用默认的就可以了。

在主节点执行上述命令后，一分钟不到就可以看到脚本提示安装完成。通过命令查看下主控端的运行情况

`1`	`systemctl status k3s`

如果运行正常，那么就看看容器的运行状态是否正常

`1`	`kubectl get pods -A`

-A 参数用于查看所有命名空间，如果容器都处于 running 状态，那么安装就成功了，接下来要可以添加被控节点。

Agent 安装

有了上述安装主控的经验，安装work节点更加简单，参数需要一定的调整

腾讯云2执行

curl -sfL http://rancher-mirror.cnrancher.com/k3s/k3s-install.sh | INSTALL_K3S_MIRROR=cn K3S_URL=https://192.168.1.1:6443 K3S_TOKEN=K107xxxxxxxxxxxxxxxx2cf95048d6a3cd85f15717edfbe5::server:xxxxxxxxxxxxxxxxxxxx4da1b7e701f67e sh -s - --node-external-ip 122.xx.xxx.111 --node-ip 192.168.1.2 --flannel-iface wg0

阿里云执行

curl -sfL http://rancher-mirror.cnrancher.com/k3s/k3s-install.sh | INSTALL_K3S_MIRROR=cn K3S_URL=https://192.168.1.1:6443 K3S_TOKEN=K10720eda8a278bdc7b9b6d787c9676a92119bb2cf95048d6a3cd85f15717edfbe5::server:e98b986e8202885cb54da1b7e701f67e sh -s - --node-external-ip 122.xx.xx.155 --node-ip 192.168.1.3 --flannel-iface wg0

参数不必过多解释

K3S_Token 去 cat /var/lib/rancher/k3s/server/node-token 获取即可。
K3S_URL 需要设置master的通信地址端口，端口默认是6443，IP地址就是虚拟网域的IP，这样流量就会通过WireGuard加密传输。
node-external-ip 为节点公网地址
node-ip 节点虚拟IP地址
执行完稍等一会，安装成功后，查看服务运行状态。

`1`	`systemctl status k3s-agent`

如果有报错就根据报错查找解决方案。

都安装好以后在master节点检查。

`1`	`kubectl get nodes -o wide`

至此多云 K3S 集群已经搭建完毕。

作者：SRE运维博客
博客地址： https://www.cnsre.cn/
文章地址：https://www.cnsre.cn/posts/211119132529/
相关话题：https://www.cnsre.cn/tags/k3s/

如何解决 Amazon EKS 中 Fargate 无法访问公网的问题

Wenlong — Mon, 09 Sep 2024 09:28:27 +0800

作者：SRE运维博客
博客地址：https://www.cnsre.cn/
文章地址：https://www.cnsre.cn/posts/240909092827/
相关话题：https://www.cnsre.cn/tags/eks/

如何解决 Amazon EKS 中 Fargate 无法访问公网的问题

背景介绍

在使用 EKS + Fargate 创建服务的测试过程中，遇到了 Fargate 中的 Pod 无法访问公网的问题。该案例中，Fargate 和 EC2 实例使用了相同的子网配置，然而 Fargate Pod 无法访问公网，而 EC2 Pod 可以正常访问。本文将深入分析该问题的原因，并提供相应的解决方案。

案例描述

我们在 AWS 环境中配置了一个 EKS 集群，其中既包含 EC2 节点的 Pod，也包含 Fargate 节点的 Pod。EC2 节点的 Pod 可以正常访问公网，但 Fargate 节点的 Pod 却出现了无法解析域名、访问超时的情况。

关键问题

在我们尝试使用 Fargate Pod 访问公网时，使用 kubectl exec 进入 Fargate Pod 后，尝试执行 apt-get update 以更新系统包，但出现了如下错误：

`1`	`0% [Connecting to archive.ubuntu.com] [Connecting to security.ubuntu.com] ^C`

这表明 Fargate Pod 无法访问外部网络，而 EC2 节点的 Pod 则可以正常执行命令、连接公网。

分析与调查

经过 AWS 技术支持的深入分析，问题的根源在于 安全组配置。Fargate 使用的 Pod 默认通过 CoreDNS 解析域名，当我们使用 dig 命令解析域名时，返回了超时错误。这说明 Fargate Pod 的 DNS 请求未能正确处理。

在检查我们的 EC2 节点时，发现该节点的安全组仅放行了来自 Fargate 的 TCP 请求。然而，DNS 请求通常使用 UDP 协议，因此在 Fargate Pod 尝试进行 DNS 解析时，由于安全组未放行 UDP 流量，导致了超时。

解决方案

为了解决这一问题，AWS 技术支持建议修改 EC2 节点的安全组配置。通过放行来自 集群安全组 的所有流量，包括 TCP 和 UDP 请求，确保 Fargate Pod 能够正常进行 DNS 解析和公网访问。

步骤如下：

登录 AWS 控制台，进入 EC2 管理页面。
选择对应的 EC2 实例，并查看其附加的安全组。
修改安全组规则，确保放行来自 Fargate 的所有流量，特别是 UDP 53 端口，用于 DNS 请求。
保存更改后，重新测试 Fargate Pod 的公网访问能力。

结果验证

在修改安全组后，我们的 Fargate Pod 可以正常访问公网，使用 apt-get update 命令成功连接到外部源。这说明问题已彻底解决。

Fargate Pod 成功连接公网输出

root@awslinux-fargate-pod:/# apt-get update
Hit:1 http://archive.ubuntu.com/ubuntu focal InRelease
Get:2 http://security.ubuntu.com/ubuntu focal-security InRelease [114 kB]
Fetched 114 kB in 1s (150 kB/s)
Reading package lists... Done

通过这些配置修改，Fargate Pod 的网络访问问题得到了彻底解决，我们的生产环境也恢复了正常运行。

常见问题与预防

为什么 Fargate 和 EC2 的网络行为不同？

Fargate 和 EC2 节点虽然可以共享同一个子网，但它们在网络层面的实现存在差异。Fargate 使用 AWS 提供的托管网络，因此其默认行为与 EC2 节点有所不同。在配置安全组时，特别需要注意两者的网络规则是否兼容。

如何避免类似问题？

为了避免类似的网络问题，建议在配置 EKS 集群时，仔细检查所有节点（包括 Fargate 和 EC2）的 安全组配置 和 网络规则。确保放行集群内部所需的所有流量，尤其是 UDP 53 端口，以支持 DNS 请求的正常运行。

注意：
为了能够保证Fargate 和EC2 node 的通信，尽量打通集群安全组，和 EC2 node 的安全组的通讯问题。即 EC2 node 安全组全部放行可以访问集群安全组，集群安全组全部放行可以访问EC2 node。

结论

通过本文，我们深入探讨了 Amazon EKS 环境中 Fargate Pod 无法访问公网的问题及其解决方案。这一问题主要是由于 安全组未放行 UDP 流量 导致的，通过适当的安全组配置调整，问题得以顺利解决。如果您在使用 AWS EKS 时遇到类似的网络问题，建议从安全组配置入手，确保所有必要的流量得到了正确放行。

作者：SRE运维博客
博客地址：https://www.cnsre.cn/
文章地址：https://www.cnsre.cn/posts/240909092827/
相关话题：https://www.cnsre.cn/tags/eks/

实现Kubernetes跨Namespace Service访问的最佳实践

Wenlong — Fri, 06 Sep 2024 08:57:14 +0800

作者：SRE运维博客
博客地址：https://www.cnsre.cn/
文章地址：https://www.cnsre.cn/posts/240906085714/
相关话题：https://www.cnsre.cn/tags/kubernetes/

实现Kubernetes跨Namespace Service访问的最佳实践

在Kubernetes运维场景中，经常会遇到跨Namespace（名称空间）的Service访问需求。为了实现不同Namespace下的Pod能够通过Service名称进行跨Namespace访问，我们可以利用Kubernetes的ExternalName类型Service来解决这个问题。

在本文中，我将展示如何配置和实现这种跨Namespace的通信。我们将通过一个完整的示例来详细说明配置过程和关键步骤。

1. 场景需求

假设我们有两个不同Namespace下的两个Service和Pod：

Namespace A：ServiceA (PodA)
Namespace B：ServiceB (PodB)

我们希望实现PodA通过ServiceB的名称进行通信，而不是通过Service的IP地址。由于Service的IP地址可能会在重启时发生变化，而Service的名称则保持不变，这样可以确保通信的稳定性。

2. 创建Service和Pod

首先，我们需要为两个Namespace分别创建对应的Pod和Service。

在`myns` Namespace中创建Pod和Service

apiVersion: v1
kind: Namespace
metadata:
  name: myns
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp-deploy1
  namespace: myns
spec:
  replicas: 2
  selector:
    matchLabels:
      app: myapp
      release: v1
  template:
    metadata:
      labels:
        app: myapp
        release: v1
    spec:
      containers:
      - name: myapp
        image: registry.cn-beijing.aliyuncs.com/google_registry/myapp:v1
        ports:
        - name: http
          containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
  name: myapp-clusterip1
  namespace: myns
spec:
  type: ClusterIP
  selector:
    app: myapp
    release: v1
  ports:
  - name: http
    port: 80
    targetPort: 80

在`mytest` Namespace中创建Pod和Service

apiVersion: v1
kind: Namespace
metadata:
  name: mytest
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp-deploy2
  namespace: mytest
spec:
  replicas: 2
  selector:
    matchLabels:
      app: myapp
      release: v2
  template:
    metadata:
      labels:
        app: myapp
        release: v2
    spec:
      containers:
      - name: myapp
        image: registry.cn-beijing.aliyuncs.com/google_registry/myapp:v2
        ports:
        - name: http
          containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
  name: myapp-clusterip2
  namespace: mytest
spec:
  type: ClusterIP
  selector:
    app: myapp
    release: v2
  ports:
  - name: http
    port: 80
    targetPort: 80

3. 检查创建结果

运行以下命令来应用这些YAML文件并检查Service和Pod的状态：

kubectl apply -f deply_service_myns.yaml
kubectl apply -f deply_service_mytest.yaml

kubectl get svc -n myns -o wide
kubectl get svc -n mytest -o wide
kubectl get pod -A -o wide

4. 跨Namespace Service通信问题

在默认情况下，PodA无法通过Service名称直接访问Namespace B中的Service。下面是PodA尝试访问PodB的日志输出：

1
2
3

# kubectl exec -it -n myns myapp-deploy1-36ds6g873r8-asy2us sh
/ # ping myapp-clusterip2
ping: bad address 'myapp-clusterip2'

这是因为默认的Kubernetes DNS解析只支持在同一Namespace内解析Service名称。

5. 解决方案：使用`ExternalName`类型的Service

为了解决这个问题，我们可以在每个Namespace中创建一个ExternalName类型的Service。ExternalName允许通过指定的FQDN（完全限定域名）来指向其他Namespace中的Service。

以下是实现跨Namespace通信的Service配置：

在`myns` Namespace中创建`ExternalName` Service

apiVersion: v1
kind: Service
metadata:
  name: myapp-clusterip1-externalname
  namespace: myns
spec:
  type: ExternalName
  externalName: myapp-clusterip2.mytest.svc.cluster.local
  ports:
  - name: http
    port: 80
    targetPort: 80

在`mytest` Namespace中创建`ExternalName` Service

apiVersion: v1
kind: Service
metadata:
  name: myapp-clusterip2-externalname
  namespace: mytest
spec:
  type: ExternalName
  externalName: myapp-clusterip1.myns.svc.cluster.local
  ports:
  - name: http
    port: 80
    targetPort: 80

运行以下命令来应用这些新的Service配置：

`1`	`kubectl apply -f svc_ExternalName_visit.yaml`

6. 验证跨Namespace通信

现在我们可以再次尝试从PodA访问PodB，应该可以成功解析并进行通信：

1
2

kubectl exec -it -n myns myapp-deploy1-36ds6g873r8-asy2us sh
/ # ping myapp-clusterip2.mytest.svc.cluster.local

这样，PodA就可以通过Service名称访问不同Namespace中的PodB了。

7. 总结

通过使用Kubernetes的ExternalName类型Service，我们成功实现了跨Namespace的Service名称解析和通信。此方法避免了直接使用IP地址通信的局限性，确保了即使Service的IP地址发生变化，通信依然可以通过名称进行。

这种跨Namespace通信的场景在多租户、多环境隔离的Kubernetes集群中尤为常见。如果你的集群架构中需要不同Namespace之间的Service互访，ExternalName是一个有效的解决方案。

作者：SRE运维博客
博客地址：https://www.cnsre.cn/
文章地址：https://www.cnsre.cn/posts/240906085714/
相关话题：https://www.cnsre.cn/tags/kubernetes/

Amazon EKS 中 EFS 持久性存储

Wenlong — Mon, 10 Jan 2022 08:50:57 +0800

作者：SRE运维博客
博客地址：https://www.cnsre.cn/
文章地址：https://www.cnsre.cn/posts/220110850573/
相关话题：https://www.cnsre.cn/tags/eks/

学习目标

在 EKS 中部署 Amazon EFS CSI 驱动程序到
验证 EFS 并验证它是否正常工作
创建基于 EFS 的静态、动态存储

前提条件

EKS 集群
AWS CLI 如果你没有安装请查看安装、更新和卸载 AWS CLI。在安装 AWS CLI 后，还要对其进行配置。
kubectl 如果没有安装请查看安装 kubectl。

创建 IAM 策略

创建 IAM 策略并将其分配给 IAM 角色。该策略将允许 Amazon EFS 驱动程序与文件系统交互。

1.从查看下方 IAM 策略文档或者查看策略文档。

推荐使用查看策略文档。获取策略文档。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "elasticfilesystem:DescribeAccessPoints",
        "elasticfilesystem:DescribeFileSystems"
      ],
      "Resource": "*"
    },
    {
      "Effect": "Allow",
      "Action": [
        "elasticfilesystem:CreateAccessPoint"
      ],
      "Resource": "*",
      "Condition": {
        "StringLike": {
          "aws:RequestTag/efs.csi.aws.com/cluster": "true"
        }
      }
    },
    {
      "Effect": "Allow",
      "Action": "elasticfilesystem:DeleteAccessPoint",
      "Resource": "*",
      "Condition": {
        "StringEquals": {
          "aws:ResourceTag/efs.csi.aws.com/cluster": "true"
        }
      }
    }
  ]
}

2.在IAM-策略中创建策略

在Identity and Access Management (IAM)中点击 策略 然后在下一步中点击 创建策略

点击 json 然后将 IAM 策略 填入，然后点击 下一步:标签

在下一步的标签中，可以根据自己的情况自行填写,然后点击 下一步:审核

名称中填写 AmazonEKS_EFS_CSI_Driver_Policy

你可以将 AmazonEKS_EFS_CSI_Driver_Policy 更改为其他名称，但如果更改，请确保在后续步骤中也做出相应更改。

将 efs 策略附件到 eks node 角色中

将我们刚才创建的 efs 策略 AmazonEKS_EFS_CSI_Driver_Policy 附加在 eks_node 的角色中，确保eks node拥有efs的权限。

如果你之前创建了 eks 那么在你的角色中会有一个名为 eksctl-<eks-name>-nodegrou-NodeInstanceRole-xxxxxxxxx 的角色。

在角色中搜索 node 然后点击 eksctl-<eks-name>-nodegrou-NodeInstanceRole-xxxxxxxxx

在角色中点击 附加策略

搜索之前创建的 EFS 策略也就是 AmazonEKS_EFS_CSI_Driver_Policy 然后选中，点击最下方的附加策略。

安装 Amazon EFS 驱动程序

使用 Helm 或 yaml 清单安装 Amazon EFS CSI 驱动程序。
这边不详细说 helm 部署方式主要介绍 yaml 清单部署

一定要修改镜像地址为你所在的地区 Amazon EKS 附加组件容器镜像地址

yaml 清单部署

因为github网络的问题。如果再执行的时候部署没有反应，请终止运行，多运行几次尝试部署

`1`	`kubectl apply -k "github.com/kubernetes-sigs/aws-efs-csi-driver/deploy/kubernetes/overlays/stable/?ref=release-1.3"`

输出如下：

serviceaccount/efs-csi-controller-sa created
serviceaccount/efs-csi-node-sa created
clusterrole.rbac.authorization.k8s.io/efs-csi-external-provisioner-role created
clusterrolebinding.rbac.authorization.k8s.io/efs-csi-provisioner-binding created
deployment.apps/efs-csi-controller created
daemonset.apps/efs-csi-node created
csidriver.storage.k8s.io/efs.csi.aws.com created

检查驱动运行是否正常

kubectl  get  pods -A|grep  efs
kube-system                    efs-csi-controller-56f6dc4c76-2lvqf               3/3     Running     0          3m32s
kube-system                    efs-csi-controller-56f6dc4c76-dxkwl               3/3     Running     0          3m32s
kube-system                    efs-csi-node-9ttxp                                3/3     Running     0          3m32s
kube-system                    efs-csi-node-hsn94                                3/3     Running     0          3m32s

虽然这边显示运行正常，但是还是要修改镜像地址。不然在创建pv，pvc以后在pod中挂载会出现错误。（后面会单独记录这个错误）

修改 efs-csi-node 驱动

`1`	`kubectl edit daemonsets.apps -n kube-system efs-csi-node`

找到 aws-efs-csi-driver 驱动所在的位置

然后将镜像修改为 918309763551.dkr.ecr.cn-north-1.amazonaws.com.cn/eks/aws-efs-csi-driver:v1.3.3

具体如下

创建 Amazon EFS 文件系统

为 Amazon EKS 集群创建 Amazon EFS 文件系统

在控制台中搜索 efs 点击确认然后进入 EFS 控制台

在控制台中点击 创建文件系统

名称：根据自己的情况填写
vpc：一定要创建在跟 eks 同一 VPC 下
可用性和持久性: 根据提示说明创建自己所需要的
如果有更多需求可以点击 自定义来设置更多 如：吞吐量、加密、备份等策略
最后点击 创建

创建入站规则

允许来自 EKS 集群 VPC 的 CIDR 的入站 NFS 流量
在刚刚创建的 EFS 中选择 网络 –> 安全组 然后复制安全组的ID sg-152XXX

在 EC2 中找到 网络与安全 选择 安全组 然后在搜索框中搜索 sg-152XXX 选中安全组。并选择 入站规则

在入站规则中允许来 EKS 集群来访问 NFS(2049)端口流量。

部署示例应用程序

部署静态供给

部署使用你创建的持久性卷的示例应用程序

此过程利用来自 Amazon EFS Container Storage Interface (CSI) 驱动程序 GitHub 存储库的多个 Pod 读写许多示例来使用静态预置的 Amazon EFS 持久性卷，并使用 ReadWriteMany 访问模式从多个 Pod 访问它。

将 Amazon EFS Container Storage Interface (CSI) 驱动程序 GitHub 存储库克隆到你的本地系统。
```
git clone https://github.com/kubernetes-sigs/aws-efs-csi-driver.git
```

导航到 multiple_pods 示例目录。

cd aws-efs-csi-driver/examples/kubernetes/multiple_pods/

检索你的 Amazon EFS 文件系统 ID。你可以在 Amazon EFS 控制台中查找此信息，或者使用以下 AWS CLI 命令。
```
aws efs describe-file-systems --query "FileSystems[*].FileSystemId" --output text
```
输出：
```
fs-<582a03f3>
```
编辑 specs/pv.yaml 文件并将 volumeHandle 值替换为你的 Amazon EFS 文件系统 ID。
```
apiVersion: v1
kind: PersistentVolume
metadata:
  name: efs-pv
spec:
  capacity:
    storage: 5Gi
  volumeMode: Filesystem
  accessModes:
    - ReadWriteMany
  persistentVolumeReclaimPolicy: Retain
  storageClassName: efs-sc
  csi:
    driver: efs.csi.aws.com
    volumeHandle: fs-<582a03f3>
```
注意

由于 Amazon EFS 是弹性文件系统，因此它不会强制实施任何文件系统容量限制。在创建系统时，不使用持久性卷和持久性卷声明中的实际存储容量值。但是，由于存储容量是 Kubernetes 中的必需字段，你必须指定有效值，例如，在此示例中为 5Gi。此值不会限制 Amazon EFS 文件系统的大小。

从 specs 目录部署 efs-sc 存储类、efs-claim 持久性卷声明以及 efs-pv 持久性卷。

kubectl apply -f specs/pv.yaml
kubectl apply -f specs/claim.yaml
kubectl apply -f specs/storageclass.yaml

列出默认命名空间中的持久性卷。查找具有 default/efs-claim 声明的持久性卷。

kubectl get pv -w

输出：

NAME     CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS   CLAIM               STORAGECLASS   REASON   AGE
efs-pv   5Gi        RWX            Retain           Bound    default/efs-claim   efs-sc                  2m50s

在 STATUS 变为 Bound 之前，请勿继续执行下一步。

从 specs 目录部署 app1 和 app2 示例应用程序。

kubectl apply -f specs/pod1.yaml
kubectl apply -f specs/pod2.yaml

查看默认命名空间中的 Pod 并等待 app1 和 app2 Pod 的 STATUS 变为 Running 状态。
```
kubectl get pods --watch
```
注意

可能需要几分钟 Pod 才能达到 Running 状态。

描述持久性卷。

kubectl describe pv efs-pv

输出：

Name:            efs-pv
Labels:          none
Annotations:     kubectl.kubernetes.io/last-applied-configuration:
                   {"apiVersion":"v1","kind":"PersistentVolume","metadata":{"annotations":{},"name":"efs-pv"},"spec":{"accessModes":["ReadWriteMany"],"capaci...
                 pv.kubernetes.io/bound-by-controller: yes
Finalizers:      [kubernetes.io/pv-protection]
StorageClass:    efs-sc
Status:          Bound
Claim:           default/efs-claim
Reclaim Policy:  Retain
Access Modes:    RWX
VolumeMode:      Filesystem
Capacity:        5Gi
Node Affinity:   none
Message:
Source:
    Type:              CSI (a Container Storage Interface (CSI) volume source)
    Driver:            efs.csi.aws.com
    VolumeHandle:      fs-582a03f3
    ReadOnly:          false
    VolumeAttributes:  none
Events:                none

Amazon EFS 文件系统 ID 将作为 VolumeHandle 列出。

验证 app1 Pod 是否成功将数据写入卷。

kubectl exec -ti app1 -- tail /data/out1.txt

输出：

...
Mon Mar 22 18:18:22 UTC 2021
Mon Mar 22 18:18:27 UTC 2021
Mon Mar 22 18:18:32 UTC 2021
Mon Mar 22 18:18:37 UTC 2021
...

验证 app2 Pod 在卷中显示的数据与 app1 写入卷的数据相同。

kubectl exec -ti app2 -- tail /data/out1.txt

输出：

...
Mon Mar 22 18:18:22 UTC 2021
Mon Mar 22 18:18:27 UTC 2021
Mon Mar 22 18:18:32 UTC 2021
Mon Mar 22 18:18:37 UTC 2021
...

完成试验时，请删除此示例应用程序的资源以进行清理。
```
kubectl delete -f specs/
```
你还可以手动删除你创建的文件系统和安全组。

部署动态供给

Prerequisite

您必须使用 1.2x 版或更高版本的 Amazon EFS CSI 驱动程序，该驱动程序需要 1.17 或更高版本的集群。要更新集群，请参阅更新集群。

部署使用控制器所创建的持久性卷的示例应用程序

此过程利用来自 Amazon EFS Container Storage Interface (CSI) 驱动程序 GitHub 存储库的动态预置示例。它通过 Amazon EFS 接入点和 Pod 使用的持久性卷申领 (PVC) 动态创建一个持久性卷。

为 EFS 创建存储类。有关所有参数和配置选项，请参阅 GitHub 上的 Amazon EFS CSI 驱动程序。
1. 下载 Amazon EFS 的 StorageClass 清单。
```
curl -o storageclass.yaml https://raw.githubusercontent.com/kubernetes-sigs/aws-efs-csi-driver/master/examples/kubernetes/dynamic_provisioning/specs/storageclass.yaml
```
2. 编辑相应文件，将 fileSystemId 的值替换为您的文件系统 ID。
3. 部署存储类。
```
kubectl apply -f storageclass.yaml
```
通过部署利用 PersistentVolumeClaim 的 Pod 来测试自动预置：
1. 下载一个清单，该清单将部署一个 Pod 和一个 PersistentVolumeClaim。
```
curl -o pod.yaml https://raw.githubusercontent.com/kubernetes-sigs/aws-efs-csi-driver/master/examples/kubernetes/dynamic_provisioning/specs/pod.yaml
```
2. 使用示例应用程序和 Pod 使用的 PersistentVolumeClaim 来部署 Pod。
```
kubectl apply -f pod.yaml
```

确定运行控制器的 Pod 的名称。

kubectl get pods -n kube-system | grep efs-csi-controller

输出

efs-csi-controller-74ccf9f566-q5989   3/3     Running   0          40m
efs-csi-controller-74ccf9f566-wswg9   3/3     Running   0          40m

几秒钟后，您可以观察到控制器开始接受更改（已编辑，旨在提高可读性）。将 74ccf9f566-q5989 替换成来自上一个命令输出中的一个 Pod 的值。
```
kubectl logs efs-csi-controller-74ccf9f566-q5989 \
    -n kube-system \
    -c csi-provisioner \
    --tail 10
```
输出
```
...
1 controller.go:737] successfully created PV pvc-5983ffec-96cf-40c1-9cd6-e5686ca84eca for PVC efs-claim and csi volume name fs-95bcec92::fsap-02a88145b865d3a87
```
如果未看到上一个输出，请使用其他控制器 Pod 之一运行上一个命令。

确认已创建状态为 Bound 至 PersistentVolumeClaim 的持久性卷：

kubectl get pv

输出

NAME                                       CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS   CLAIM               STORAGECLASS   REASON   AGE
pvc-5983ffec-96cf-40c1-9cd6-e5686ca84eca   20Gi       RWX            Delete           Bound    default/efs-claim   efs-sc                  7m57s

查看有关所创建的 PersistentVolumeClaim 的详细信息。

kubectl get pvc

输出

NAME        STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS   AGE
efs-claim   Bound    pvc-5983ffec-96cf-40c1-9cd6-e5686ca84eca   20Gi       RWX            efs-sc         9m7s

查看示例应用程序 Pod 的状态。

kubectl get pods -o wide

输出

NAME          READY   STATUS    RESTARTS   AGE   IP               NODE                                           NOMINATED NODE   READINESS GATES
efs-example   1/1     Running   0          10m   192.168.78.156   ip-192-168-73-191.us-west-2.compute.internal   <none>           <none>

确认数据已写入到卷。

kubectl exec efs-app -- bash -c "cat data/out"

输出

...
Tue Mar 23 14:29:16 UTC 2021
Tue Mar 23 14:29:21 UTC 2021
Tue Mar 23 14:29:26 UTC 2021
Tue Mar 23 14:29:31 UTC 2021
...

（可选）终止运行 Pod 的 Amazon EKS 节点并等待重新安排运行 Pod。或者，您也可以删除 Pod 并重新部署它。再次完成步骤 7，确认输出包含先前的输出。

作者：SRE运维博客
博客地址：https://www.cnsre.cn/
文章地址：https://www.cnsre.cn/posts/220110850573/
相关话题：https://www.cnsre.cn/tags/eks/

如何彻底删除EKS中一直卡在Terminating的Namespace

Wenlong — Fri, 07 Jan 2022 09:06:44 +0800

作者：SRE运维博客
博客地址：https://www.cnsre.cn/
文章地址：https://www.cnsre.cn/posts/220107906441/
相关话题：https://www.cnsre.cn/tags/eks/

介绍

最近一直在玩EKS（Elastic Kubernetes Service – Amazon EKS）和 kubesphere。因为之前没有使用过EKS 和 kubesphere 所以这个过程也是一个试错的过程，在我使用 kubesphere 的时候发现有一个日志服务，在好奇心的驱使下，我创建了它。

在我创建了日志服务（KubeSphere Logging System）以后，我发现我并不想使用它。（可能我只是想看看它到底是什么吧。）强迫症我的，就想把它给删除掉。于是我在我的 EKS 中对他进行了强制删除 kubectl delete ns kubesphere-logging-system --force --grace-period=0

让人尴尬的是，这个 Namespace 并没有立马删除，我自我安慰到，可能 Namespace 下边有其他没有删除的资源在等待删除，我在等等。。。

过了半个小时，我去查看的时候

[root@ip-10-0-100-206 ~]# kubectl get  ns  kubesphere-logging-system
NAME                              STATUS        AGE
kubesphere-logging-system         Terminating   6d19h

它好像这地卡在了 Terminating 的状态。
我试着寻找解决方法，http://github.com/kubernetes/kubernetes/issues/60807 但是这中方法要通过 API 才可以实现。EKS 是托管在 AWS 中的，我根本没有办法去操作eks的后台。

我开始后悔我为什么要去安装它，我本可以不折腾的。但是回想如果我不去安装它的话，我肯定会像想在这样难过，因为我无法了解它（KubeSphere Logging System）到底是什么样的。

终于我找到了 commented https://github.com/kubernetes/kubernetes/issues/60807#issuecomment-663853215

如何彻底删除 namespace

获取namespace的详情信息并转为json

`1`	`kubectl get namespace kubesphere-logging-system -o json > kubesphere-logging-system.json`

打开 json 文件编辑

{
    "apiVersion": "v1",
    "kind": "Namespace",
    "metadata": {
        "creationTimestamp": "2021-12-31T05:03:58Z",
        "deletionTimestamp": "2022-01-05T08:05:40Z",
        "labels": {
            "kubesphere.io/namespace": "kubesphere-logging-system",
            "kubesphere.io/workspace": "system-workspace"
        },
        "managedFields": [
            {
                "apiVersion": "v1",
                "fieldsType": "FieldsV1",
                "fieldsV1": {
                    "f:metadata": {
                        "f:labels": {
                            ".": {},
                            "f:kubesphere.io/namespace": {}
                        },
                        "f:ownerReferences": {
                            ".": {},
                            "k:{\"uid\":\"6d535470-2592-4f3c-a155-eabc362c339d\"}": {
                                ".": {},
                                "f:apiVersion": {},
                                "f:blockOwnerDeletion": {},
                                "f:controller": {},
                                "f:kind": {},
                                "f:name": {},
                                "f:uid": {}
                            }
                        }
                    }
                },
                "manager": "controller-manager",
                "operation": "Update",
                "time": "2021-12-31T05:04:01Z"
            },
            {
                "apiVersion": "v1",
                "fieldsType": "FieldsV1",
                "fieldsV1": {
                    "f:metadata": {
                        "f:labels": {
                            "f:kubesphere.io/workspace": {}
                        }
                    },
                    "f:status": {
                        "f:phase": {}
                    }
                },
                "manager": "kubectl",
                "operation": "Update",
                "time": "2021-12-31T05:04:01Z"
            },
            {
                "apiVersion": "v1",
                "fieldsType": "FieldsV1",
                "fieldsV1": {
                    "f:status": {
                        "f:conditions": {
                            ".": {},
                            "k:{\"type\":\"NamespaceContentRemaining\"}": {
                                ".": {},
                                "f:lastTransitionTime": {},
                                "f:message": {},
                                "f:reason": {},
                                "f:status": {},
                                "f:type": {}
                            },
                            "k:{\"type\":\"NamespaceDeletionContentFailure\"}": {
                                ".": {},
                                "f:lastTransitionTime": {},
                                "f:message": {},
                                "f:reason": {},
                                "f:status": {},
                                "f:type": {}
                            },
                            "k:{\"type\":\"NamespaceDeletionDiscoveryFailure\"}": {
                                ".": {},
                                "f:lastTransitionTime": {},
                                "f:message": {},
                                "f:reason": {},
                                "f:status": {},
                                "f:type": {}
                            },
                            "k:{\"type\":\"NamespaceDeletionGroupVersionParsingFailure\"}": {
                                ".": {},
                                "f:lastTransitionTime": {},
                                "f:message": {},
                                "f:reason": {},
                                "f:status": {},
                                "f:type": {}
                            },
                            "k:{\"type\":\"NamespaceFinalizersRemaining\"}": {
                                ".": {},
                                "f:lastTransitionTime": {},
                                "f:message": {},
                                "f:reason": {},
                                "f:status": {},
                                "f:type": {}
                            }
                        }
                    }
                },
                "manager": "kube-controller-manager",
                "operation": "Update",
                "time": "2022-01-05T08:05:47Z"
            }
        ],
        "name": "kubesphere-logging-system",
        "ownerReferences": [
            {
                "apiVersion": "tenant.kubesphere.io/v1alpha1",
                "blockOwnerDeletion": true,
                "controller": true,
                "kind": "Workspace",
                "name": "system-workspace",
                "uid": "6d535470-2592-4f3c-a155-eabc362c339d"
            }
        ],
        "resourceVersion": "7376520",
        "uid": "2b76e9b1-75f2-4a2e-a819-73b36aea188e"
    },
    "spec": {
        "finalizers": [
            "kubernetes" # 将此行删除
        ]
    },
    "status": {
        "conditions": [
            {
                "lastTransitionTime": "2022-01-05T08:05:47Z",
                "message": "All resources successfully discovered",
                "reason": "ResourcesDiscovered",
                "status": "False",
                "type": "NamespaceDeletionDiscoveryFailure"
            },
            {
                "lastTransitionTime": "2022-01-05T08:05:47Z",
                "message": "All legacy kube types successfully parsed",
                "reason": "ParsedGroupVersions",
                "status": "False",
                "type": "NamespaceDeletionGroupVersionParsingFailure"
            },
            {
                "lastTransitionTime": "2022-01-05T08:05:47Z",
                "message": "All content successfully deleted, may be waiting on finalization",
                "reason": "ContentDeleted",
                "status": "False",
                "type": "NamespaceDeletionContentFailure"
            },
            {
                "lastTransitionTime": "2022-01-05T08:05:47Z",
                "message": "Some resources are remaining: fluentbits.logging.kubesphere.io has 1 resource instances",
                "reason": "SomeResourcesRemain",
                "status": "True",
                "type": "NamespaceContentRemaining"
            },
            {
                "lastTransitionTime": "2022-01-05T08:05:47Z",
                "message": "Some content in the namespace has finalizers remaining: fluentbit.logging.kubesphere.io in 1 resource instances",
                "reason": "SomeFinalizersRemain",
                "status": "True",
                "type": "NamespaceFinalizersRemaining"
            }
        ],
        "phase": "Terminating"
    }
}

找到 spec 将 finalizers 下的 kubernetes 删除
具体如下

{
    "apiVersion": "v1",
    "kind": "Namespace",
    "metadata": {
        "creationTimestamp": "2021-12-31T05:03:58Z",
        "deletionTimestamp": "2022-01-05T08:05:40Z",
        "labels": {
            "kubesphere.io/namespace": "kubesphere-logging-system",
            "kubesphere.io/workspace": "system-workspace"
        },
        "managedFields": [
            {
                "apiVersion": "v1",
                "fieldsType": "FieldsV1",
                "fieldsV1": {
                    "f:metadata": {
                        "f:labels": {
                            ".": {},
                            "f:kubesphere.io/namespace": {}
                        },
                        "f:ownerReferences": {
                            ".": {},
                            "k:{\"uid\":\"6d535470-2592-4f3c-a155-eabc362c339d\"}": {
                                ".": {},
                                "f:apiVersion": {},
                                "f:blockOwnerDeletion": {},
                                "f:controller": {},
                                "f:kind": {},
                                "f:name": {},
                                "f:uid": {}
                            }
                        }
                    }
                },
                "manager": "controller-manager",
                "operation": "Update",
                "time": "2021-12-31T05:04:01Z"
            },
            {
                "apiVersion": "v1",
                "fieldsType": "FieldsV1",
                "fieldsV1": {
                    "f:metadata": {
                        "f:labels": {
                            "f:kubesphere.io/workspace": {}
                        }
                    },
                    "f:status": {
                        "f:phase": {}
                    }
                },
                "manager": "kubectl",
                "operation": "Update",
                "time": "2021-12-31T05:04:01Z"
            },
            {
                "apiVersion": "v1",
                "fieldsType": "FieldsV1",
                "fieldsV1": {
                    "f:status": {
                        "f:conditions": {
                            ".": {},
                            "k:{\"type\":\"NamespaceContentRemaining\"}": {
                                ".": {},
                                "f:lastTransitionTime": {},
                                "f:message": {},
                                "f:reason": {},
                                "f:status": {},
                                "f:type": {}
                            },
                            "k:{\"type\":\"NamespaceDeletionContentFailure\"}": {
                                ".": {},
                                "f:lastTransitionTime": {},
                                "f:message": {},
                                "f:reason": {},
                                "f:status": {},
                                "f:type": {}
                            },
                            "k:{\"type\":\"NamespaceDeletionDiscoveryFailure\"}": {
                                ".": {},
                                "f:lastTransitionTime": {},
                                "f:message": {},
                                "f:reason": {},
                                "f:status": {},
                                "f:type": {}
                            },
                            "k:{\"type\":\"NamespaceDeletionGroupVersionParsingFailure\"}": {
                                ".": {},
                                "f:lastTransitionTime": {},
                                "f:message": {},
                                "f:reason": {},
                                "f:status": {},
                                "f:type": {}
                            },
                            "k:{\"type\":\"NamespaceFinalizersRemaining\"}": {
                                ".": {},
                                "f:lastTransitionTime": {},
                                "f:message": {},
                                "f:reason": {},
                                "f:status": {},
                                "f:type": {}
                            }
                        }
                    }
                },
                "manager": "kube-controller-manager",
                "operation": "Update",
                "time": "2022-01-05T08:05:47Z"
            }
        ],
        "name": "kubesphere-logging-system",
        "ownerReferences": [
            {
                "apiVersion": "tenant.kubesphere.io/v1alpha1",
                "blockOwnerDeletion": true,
                "controller": true,
                "kind": "Workspace",
                "name": "system-workspace",
                "uid": "6d535470-2592-4f3c-a155-eabc362c339d"
            }
        ],
        "resourceVersion": "7376520",
        "uid": "2b76e9b1-75f2-4a2e-a819-73b36aea188e"
    },
    "spec": {
        "finalizers": [
        ]
    },
    "status": {
        "conditions": [
            {
                "lastTransitionTime": "2022-01-05T08:05:47Z",
                "message": "All resources successfully discovered",
                "reason": "ResourcesDiscovered",
                "status": "False",
                "type": "NamespaceDeletionDiscoveryFailure"
            },
            {
                "lastTransitionTime": "2022-01-05T08:05:47Z",
                "message": "All legacy kube types successfully parsed",
                "reason": "ParsedGroupVersions",
                "status": "False",
                "type": "NamespaceDeletionGroupVersionParsingFailure"
            },
            {
                "lastTransitionTime": "2022-01-05T08:05:47Z",
                "message": "All content successfully deleted, may be waiting on finalization",
                "reason": "ContentDeleted",
                "status": "False",
                "type": "NamespaceDeletionContentFailure"
            },
            {
                "lastTransitionTime": "2022-01-05T08:05:47Z",
                "message": "Some resources are remaining: fluentbits.logging.kubesphere.io has 1 resource instances",
                "reason": "SomeResourcesRemain",
                "status": "True",
                "type": "NamespaceContentRemaining"
            },
            {
                "lastTransitionTime": "2022-01-05T08:05:47Z",
                "message": "Some content in the namespace has finalizers remaining: fluentbit.logging.kubesphere.io in 1 resource instances",
                "reason": "SomeFinalizersRemain",
                "status": "True",
                "type": "NamespaceFinalizersRemaining"
            }
        ],
        "phase": "Terminating"
    }
}

执行清理命令

现在我们只需要一条命令就可以彻底删除这个 Namespace

`1`	`kubectl replace --raw "/api/v1/namespaces/kubesphere-logging-system/finalize" -f ./kubesphere-logging-system.json`

执行完以后，你需要等待一会
再次执行命令检查 namespaces

`1`	`kubectl replace --raw "/api/v1/namespaces/kubesphere-logging-system/finalize" -f ./kubesphere-logging-system.json`

最后的检查

kubectl get  ns  kubesphere-logging-system
Error from server (NotFound): namespaces "kubesphere-logging-system" not found

[root@ip-10-0-100-206 ~]# kubectl get  ns 
NAME                              STATUS   AGE
default                           Active   23d
kubesphere-controls-system        Active   9d
kubesphere-devops-system          Active   9d
kubesphere-devops-worker          Active   16h
kubesphere-monitoring-federated   Active   9d
kubesphere-monitoring-system      Active   9d
kubesphere-sample-dev             Active   8d
kubesphere-system                 Active   9d

在此查看的时候，它已经不存在了。

作者：SRE运维博客
博客地址：https://www.cnsre.cn/
文章地址：https://www.cnsre.cn/posts/220107906441/
相关话题：https://www.cnsre.cn/tags/eks/

AWS eks绑定alb 使用aws-load-balancer-controller(Ingress Controller)提供服务

Wenlong — Fri, 17 Dec 2021 14:31:13 +0800

作者：SRE运维博客
博客地址：https://www.cnsre.cn/
文章地址：https://www.cnsre.cn/posts/211217431135/
相关话题：https://www.cnsre.cn/tags/aws/

最近在AWS 平台创建了EKS 用于测试环境项目，EKS 创建完以后我打算使用 Ingress 控制器来暴露服务，ingress 前在添加一个ALB 负载均衡器，这样就可以实现完全的高可用了。但是在创建好 ingress 却发现无法调通服务，查看 aws 官方文档 Amazon EKS 上的应用程序负载均衡发现需要使用 aws-load-balancer-controller.

本文档的目标：

创建 EKS ALB 所需要的角色。
创建 EKS aws-load-balancer-controller
创建 EKS pod 服务
使用 ALB 将 pod 服务暴露出去

AWS Load Balancer Controller 介绍

AWS Load Balancer Controller 的工作原理

AWS Load Balancer Controller 是帮助管理 Kubernetes 集群的弹性负载均衡器的控制器。

它通过供应应用程序负载均衡器来满足 Kubernetes Ingress 资源。
它通过提供网络负载均衡器来满足 Kubernetes Service 资源。

下图详细说明了此控制器创建的 AWS 组件。它还演示了从 ALB 到 Kubernetes 集群的路由入口流量。

[1]：控制器监视来自 API 服务器的入口事件。当它找到满足其要求的入口资源时，它开始创建 AWS 资源。

[2]：在 AWS 中为新的入口资源创建了一个 ALB (ELBv2)。此 ALB 可以面向 Internet 或内部。您还可以使用注释指定它在其中创建的子网。

[3]：在 AWS 中为入口资源中描述的每个独特的 Kubernetes 服务创建目标组。

[4]：为入口资源注释中详述的每个端口创建侦听器。如果未指定端口，则使用合理的默认值 (80或443)。证书也可以通过注释附加。

[5]：为入口资源中指定的每个路径创建规则。这可确保将特定路径的流量路由到正确的 Kubernetes 服务。

安装前的准备

EKS 已经创建完毕
准备两个 Public 子网
能够创建 IAM 策略的账户

关于子网的说明：

根据EKS 最佳实践。EKS 的 worker node，它们只需要接收来自 alb ingress（通过内网转发）的流量，安全起见就需要把他们放在私有子网。但是它们又需要去公网上拉一些镜像，所以它们本身也需要放问公网的能力，这个时候它们的子网里配置个 nat，访问外网的时候由 NAT 做一个出向的转发，就可以实现了，但是因为 nat 是单向的，外界是无法通过NAT访问到eks的节点的，所以我就需要将ALB 放在 public 子网里。最后就是 ALB 放在 public 来接受流量，worker node 在私有子网处理业务。

创建AWS Load Balancer Controller 的 IAM 策略

打开策略点击 创建策略 打开 IAM_Policy.json 复制内容粘贴到 json

点击下一步:标签

然后一直下一步在下图中名称填写 AWSLoadBalancerControllerIAMPolicy 你也可以自定义名称。然后创建策略。

如果以官方提供的 IAM_Policy.json 保存有错的话你可以使用一下策略（权限会大一些）

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "iam:CreateServiceLinkedRole",
                "ec2:DescribeAccountAttributes",
                "ec2:DescribeAddresses",
                "ec2:DescribeAvailabilityZones",
                "ec2:DescribeInternetGateways",
                "ec2:DescribeVpcs",
                "ec2:DescribeSubnets",
                "ec2:DescribeSecurityGroups",
                "ec2:DescribeInstances",
                "ec2:DescribeNetworkInterfaces",
                "ec2:DescribeTags",
                "ec2:GetCoipPoolUsage",
                "ec2:DescribeCoipPools",
                "elasticloadbalancing:DescribeLoadBalancers",
                "elasticloadbalancing:DescribeLoadBalancerAttributes",
                "elasticloadbalancing:DescribeListeners",
                "elasticloadbalancing:DescribeListenerCertificates",
                "elasticloadbalancing:DescribeSSLPolicies",
                "elasticloadbalancing:DescribeRules",
                "elasticloadbalancing:DescribeTargetGroups",
                "elasticloadbalancing:DescribeTargetGroupAttributes",
                "elasticloadbalancing:DescribeTargetHealth",
                "elasticloadbalancing:DescribeTags"
            ],
            "Resource": "*"
        },
        {
            "Effect": "Allow",
            "Action": [
                "cognito-idp:DescribeUserPoolClient",
                "acm:ListCertificates",
                "acm:DescribeCertificate",
                "iam:ListServerCertificates",
                "iam:GetServerCertificate",
                "waf-regional:GetWebACL",
                "waf-regional:GetWebACLForResource",
                "waf-regional:AssociateWebACL",
                "waf-regional:DisassociateWebACL",
                "wafv2:GetWebACL",
                "wafv2:GetWebACLForResource",
                "wafv2:AssociateWebACL",
                "wafv2:DisassociateWebACL",
                "shield:GetSubscriptionState",
                "shield:DescribeProtection",
                "shield:CreateProtection",
                "shield:DeleteProtection"
            ],
            "Resource": "*"
        },
        {
            "Effect": "Allow",
            "Action": [
                "ec2:AuthorizeSecurityGroupIngress",
                "ec2:RevokeSecurityGroupIngress"
            ],
            "Resource": "*"
        },
        {
            "Effect": "Allow",
            "Action": [
                "ec2:CreateSecurityGroup"
            ],
            "Resource": "*"
        },
        {
            "Effect": "Allow",
            "Action": [
                "ec2:CreateTags"
            ],
            "Resource": "arn:aws-cn:ec2:*:*:security-group/*",
            "Condition": {
                "StringEquals": {
                    "ec2:CreateAction": "CreateSecurityGroup"
                },
                "Null": {
                    "aws:RequestTag/elbv2.k8s.aws/cluster": "false"
                }
            }
        },
        {
            "Effect": "Allow",
            "Action": [
                "ec2:CreateTags",
                "ec2:DeleteTags"
            ],
            "Resource": "arn:aws-cn:ec2:*:*:security-group/*",
            "Condition": {
                "Null": {
                    "aws:RequestTag/elbv2.k8s.aws/cluster": "true",
                    "aws:ResourceTag/elbv2.k8s.aws/cluster": "false"
                }
            }
        },
        {
            "Effect": "Allow",
            "Action": [
                "ec2:AuthorizeSecurityGroupIngress",
                "ec2:RevokeSecurityGroupIngress",
                "ec2:DeleteSecurityGroup"
            ],
            "Resource": "*",
            "Condition": {
                "Null": {
                    "aws:ResourceTag/elbv2.k8s.aws/cluster": "false"
                }
            }
        },
        {
            "Effect": "Allow",
            "Action": [
                "elasticloadbalancing:CreateLoadBalancer",
                "elasticloadbalancing:CreateTargetGroup"
            ],
            "Resource": "*",
            "Condition": {
                "Null": {
                    "aws:RequestTag/elbv2.k8s.aws/cluster": "false"
                }
            }
        },
        {
            "Effect": "Allow",
            "Action": [
                "elasticloadbalancing:CreateListener",
                "elasticloadbalancing:DeleteListener",
                "elasticloadbalancing:CreateRule",
                "elasticloadbalancing:DeleteRule"
            ],
            "Resource": "*"
        },
        {
            "Effect": "Allow",
            "Action": [
                "elasticloadbalancing:AddTags",
                "elasticloadbalancing:RemoveTags"
            ],
            "Resource": [
                "arn:aws-cn:elasticloadbalancing:*:*:targetgroup/*/*",
                "arn:aws-cn:elasticloadbalancing:*:*:loadbalancer/net/*/*",
                "arn:aws-cn:elasticloadbalancing:*:*:loadbalancer/app/*/*"
            ],
            "Condition": {
                "Null": {
                    "aws:RequestTag/elbv2.k8s.aws/cluster": "true",
                    "aws:ResourceTag/elbv2.k8s.aws/cluster": "false"
                }
            }
        },
        {
            "Effect": "Allow",
            "Action": [
                "elasticloadbalancing:AddTags",
                "elasticloadbalancing:RemoveTags"
            ],
            "Resource": [
                "arn:aws-cn:elasticloadbalancing:*:*:listener/net/*/*/*",
                "arn:aws-cn:elasticloadbalancing:*:*:listener/app/*/*/*",
                "arn:aws-cn:elasticloadbalancing:*:*:listener-rule/net/*/*/*",
                "arn:aws-cn:elasticloadbalancing:*:*:listener-rule/app/*/*/*"
            ]
        },
        {
            "Effect": "Allow",
            "Action": [
                "elasticloadbalancing:ModifyLoadBalancerAttributes",
                "elasticloadbalancing:SetIpAddressType",
                "elasticloadbalancing:SetSecurityGroups",
                "elasticloadbalancing:SetSubnets",
                "elasticloadbalancing:DeleteLoadBalancer",
                "elasticloadbalancing:ModifyTargetGroup",
                "elasticloadbalancing:ModifyTargetGroupAttributes",
                "elasticloadbalancing:DeleteTargetGroup"
            ],
            "Resource": "*",
            "Condition": {
                "Null": {
                    "aws:ResourceTag/elbv2.k8s.aws/cluster": "false"
                }
            }
        },
        {
            "Effect": "Allow",
            "Action": [
                "elasticloadbalancing:RegisterTargets",
                "elasticloadbalancing:DeregisterTargets"
            ],
            "Resource": "arn:aws-cn:elasticloadbalancing:*:*:targetgroup/*/*"
        },
        {
            "Effect": "Allow",
            "Action": [
                "elasticloadbalancing:SetWebAcl",
                "elasticloadbalancing:ModifyListener",
                "elasticloadbalancing:AddListenerCertificates",
                "elasticloadbalancing:RemoveListenerCertificates",
                "elasticloadbalancing:ModifyRule"
            ],
            "Resource": "*"
        }
    ]
}

赋予 EKS node 权限

在角色中搜索 nodegrou-NodeInstanceRole 找到你对应的 EKS 集群如下图

然后点击该角色– 点击附加策略

在搜索框内输入刚才创建的策略名称然后选中，点击最下边的附加策略。

我的策略名称为：AWSLoadBalancerControllerIAMPolicy

在 EKS 中安装 AWS Load Balancer Controller

安装证书管理器

`1`	`kubectl apply --validate=false -f https://github.com/jetstack/cert-manager/releases/download/v1.5.3/cert-manager.yaml`

部署 YAML

下载负载平衡器控制器的规范。

`1`	`wget https://github.com/kubernetes-sigs/aws-load-balancer-controller/releases/download/v2.3.1/v2_3_1_full.yaml`

编辑保存的 yaml 文件，转到部署规范，并将控制器 –cluster-name arg 值设置为您的 EKS 集群名称

apiVersion: apps/v1
kind: Deployment
. . .
name: aws-load-balancer-controller
namespace: kube-system
spec:
    . . .
    template:
        spec:
            containers:
                - args:
                    - --cluster-name=<INSERT_CLUSTER_NAME>

如果您为服务账户使用 IAM 角色，我们建议您从 yaml 规范中删除 ServiceAccount。如果您从 yaml 规范中删除安装部分，这将保留 eksctl 创建的 iamserviceaccount。

1
2

apiVersion: v1
kind: ServiceAccount

应用 yaml 文件

`1`	`kubectl apply -f v2_3_1_full.yaml`

部署示例应用程序

将游戏 2048 部署为示例应用程序，以确认作为入口对象的结果，Amazon负载均衡器控制器是否会创建 Amazon ALB。

`1`	`kubectl apply -f https://raw.githubusercontent.com/kubernetes-sigs/aws-load-balancer-controller/v2.2.0/docs/examples/2048/2048_full.yaml`

几分钟后，验证是否已使用以下命令创建入口资源。

`1`	`kubectl get ingress/ingress-2048 -n game-2048`

输出：

1
2

NAME           CLASS    HOSTS   ADDRESS                                                                       PORTS   AGE
ingress-2048   <none>   *       k8s-game2048-ingress2-xxxxxxxxxx-yyyyyyyyyy.cn-north-1.elb.amazonaws.com.cn   80      3h42m

如果在几分钟后尚未创建入口，请运行以下命令以查看负载均衡器控制器日志。这些日志包含可帮助您诊断部署中任何问题的错误消息。

`1`	`kubectl logs -n kube-system deployment.apps/aws-load-balancer-controller`

打开浏览器并从上一命令输出导航到 ADDRESS URL 以查看示例应用程序。如果您没有看到任何内容，请等待几分钟，并刷新您的浏览器。

作者：SRE运维博客
博客地址：https://www.cnsre.cn/
文章地址：https://www.cnsre.cn/posts/211217431135/
相关话题：https://www.cnsre.cn/tags/aws/

kubectl 彩色输出 -- kubecolor

Wenlong — Fri, 10 Dec 2021 09:52:58 +0800

作者：SRE运维博客
博客地址： https://www.cnsre.cn/
文章地址：https://www.cnsre.cn/posts/211210952578/
相关话题：https://www.cnsre.cn/tags/kubernetes/

kubecolor 是什么？

kubecolor 为您的kubectl命令输出着色，不执行任何其他操作。kubecolor 在内部调用kubectlcommand 并尝试对输出进行着色，以便你可以使用 kubecolor 作为 kubectl 的完整替代方案。

kubecolor项目地址

安装

通过 GitHub 发布下载

git clone https://github.com/dty1er/kubecolor.git

通过 go 命令手动构建

cd kubecolor/
go build -o kubecolor cmd/kubecolor/main.go

构建后，得到一个 kubecolor 的文件

设置默认 kubectl 使用 kubecolor

echo "alias kubectl='/root/kubecolor/kubecolor" >> ~/.bashrc
# 使配置生效
source .bashrc

效果展示

kubectl get pods

kubectl describe

作者：SRE运维博客
博客地址： https://www.cnsre.cn/
文章地址：https://www.cnsre.cn/posts/211210952578/
相关话题：https://www.cnsre.cn/tags/kubernetes/

kubernetes架构图

Wenlong — Wed, 08 Dec 2021 10:38:35 +0800

作者：SRE运维博客
博客地址： https://www.cnsre.cn/
文章地址：https://www.cnsre.cn/posts/211208038353/
相关话题：https://www.cnsre.cn/tags/kubernetes/

一、kubernetes 集群架构图

二、Openshift or Kubernetes 集群架构图

三、常见的 CI/CD 架构图

1、Gitlab Webhook + Jenkins SharedLibraries/Kubernetes + SonarScanner Maven Plugin

2、Gitlab CI/CD Workflow

3、Logging

4、Logging与Metrics

原文出处

作者：SRE运维博客
博客地址： https://www.cnsre.cn/
文章地址：https://www.cnsre.cn/posts/211208038353/
相关话题：https://www.cnsre.cn/tags/kubernetes/

AWS EKS 添加IAM用户角色

Wenlong — Fri, 03 Dec 2021 09:31:50 +0800

作者：SRE运维博客
博客地址： https://www.cnsre.cn/
文章地址：https://www.cnsre.cn/posts/211203931498/
相关话题：https://www.cnsre.cn/tags/aws/

因为创建 Amazon EKS 集群时，IAM 用户或角色会自动在集群的 RBAC 配置中被授予 system:masters 权限。例如，IAM 用户或角色可以是创建集群的联合身份用户。如果使用不属于 aws-auth ConfigMap 的 IAM 用户或角色访问 Amazon EKS 控制台，则无法看到 Kubernetes 工作负载。也不会看到集群的概览详细信息。所以要向其他 AWS 用户或角色授予与集群交互的能力，您必须在 Kubernetes 中编辑 aws-auth ConfigMap。

因为部门有不通的角色，所以想基于不通的角色分配不同的权限，下面是记录添加一个对 EKS 只有只读权限的 AIM 用户。

如果您在运行 AWS 命令行界面 (AWS CLI) 命令时遇到错误，请确保您使用的是最新版的 AWS CLI。

为 IAM 用户或角色配置权限

要查找具有主要集群配置权限的集群创建者或管理员角色，请在 AWS CloudTrail 中搜索 CreateCluster API 调用。然后，检查此 API 调用的 UserIdentity 部分。
识别需要权限的 IAM 用户或角色。
确认已识别的 IAM 用户或角色有权在 AWS 管理控制台中查看所有集群的节点和工作负载。

使用 aws-auth ConfigMap 将 IAM 用户或角色映射到 RBAC 角色和组

在连接 Amazon EKS API 服务器之前，安装并配置最新版本的 AWS CLI。

获取 AWS CLI 用户或角色的配置：

 aws sts get-caller-identity

输出将返回 IAM 用户或角色的 Amazon 资源名称 (ARN)。例如：

{
    "UserId": "XXXXXXXXXXXXXXXXXXXXX",
    "Account": "XXXXXXXXXXXX",
    "Arn": "arn:aws:iam::XXXXXXXXXXXX:user/testuser"
}

确认 ARN 与具有主要集群配置访问权限的集群创建者或管理员相匹配。如果 ARN 与集群创建者或管理员不匹配，请联系集群创建者 aws-auth ConfigMap。

添加对 EKS 集群具有只读访问权限的 IAM 用户

要允许超级用户访问权限以对任何资源执行任何操作，请添加 system:masters 而非 system:bootstrappers 和 system:nodes。有关更多信息，请参阅 Kubernetes 网站上的默认角色和角色绑定。

创建 rbac.yaml

---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: reader
rules:
- apiGroups: ["*"]
  resources: ["deployments", "configmaps", "pods", "secrets", "services"]
  verbs: ["get", "list", "watch"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: reader
subjects:
- kind: Group
  name: reader
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: reader
  apiGroup: rbac.authorization.k8s.io

要添加 IAM 用户或角色，请完成以下步骤之一。

添加 IAM 用户到 mapUsers。

...
  mapUsers: |
    - userarn: arn:aws:iam::424432388155:user/developer
      username: developer
      groups: 
      - reader
...

创建 RBAC

kubectl apply -f rbac.yaml

在AWS 中创建 AmazonEKSDeveloperPolicy 策略以让用户在 AWS 管理控制台中查看所有集群的节点和工作负载

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "eks:DescribeNodegroup",
                "eks:ListNodegroups",
                "eks:DescribeCluster",
                "eks:ListClusters",
                "eks:AccessKubernetesApi",
                "ssm:GetParameter",
                "eks:ListUpdates",
                "eks:ListFargateProfiles"
            ],
            "Resource": "*"
        }
    ]
}

创建eks-developerIAM 组并附加AmazonEKSDeveloperPolicy策略
创建developer用户
添加developer个人资料aws configure --profile developer
添加到aws-authconfigmapdeveloper用户 ARN。

kubectl edit -n kube-system configmap/aws-auth
...
  mapUsers: |
    - userarn: arn:aws:iam::424432388155:user/developer
      username: developer
      groups: 
      - reader
...

为developer用户配置 kubectl 上下文

`1`	`aws eks --region us-east-1 update-kubeconfig --name eks --profile developer`

检查 kubeconfig

`1`	`kubectl config view --minify`

检查权限

1
2
3

kubectl auth can-i get pods
kubectl auth can-i create pods
kubectl run nginx --image=nginx

创建具有管理员访问权限的 IAM 角色并由 IAM 用户代入此角色。

创建AmazonEKSAdminPolicy策略

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "eks:*"
            ],
            "Resource": "*"
        },
        {
            "Effect": "Allow",
            "Action": "iam:PassRole",
            "Resource": "*",
            "Condition": {
                "StringEquals": {
                    "iam:PassedToService": "eks.amazonaws.com"
                }
            }
        }
    ]
}

创建eks-admin角色并附加AmazonEKSAdminPolicy策略
描述eks-admin角色

`1`	`aws iam get-role --profile terraform --role-name eks-admin`

创建AmazonEKSAssumePolicy允许承担角色的策略

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "sts:AssumeRole"
            ],
            "Resource": "arn:aws:iam::424432388155:role/eks-admin"
        }
    ]
}

创建manager用户以使用eks-admin角色
添加manager个人资料aws configure --profile manager
检查manager用户是否可以承担eks-admin角色

`1`	`aws sts assume-role --role-arn arn:aws:iam::424432388155:role/eks-admin --role-session-name manager-session --profile manager`

为创建 EKS 集群的用户更新 kubeconfig

`1`	`aws eks --region us-east-1 update-kubeconfig --name eks --profile terraform`

添加到aws-authconfigmapeks-admin角色 ARN。

 kubectl edit -n kube-system configmap/aws-auth
...
- rolearn: arn:aws:iam::424432388155:role/eks-admin
  username: eks-admin
  groups:
  - system:masters
...

创建eks-admin配置文件以承担角色vim ~/.aws/config

[profile eks-admin]
role_arn = arn:aws:iam::424432388155:role/eks-admin
source_profile = manager

为manager用户配置 kubectl 上下文以自动承担eks-admin角色

`1`	`aws eks --region us-east-1 update-kubeconfig --name eks --profile eks-admin`

检查 kubeconfig

`1`	`kubectl config view --minify`

检查经理是否具有 EKS 集群的管理员访问权限

`1`	`kubectl auth can-i "" ""`

作者：SRE运维博客
博客地址： https://www.cnsre.cn/
文章地址：https://www.cnsre.cn/posts/211203931498/
相关话题：https://www.cnsre.cn/tags/aws/

Kubernetes 的 Taint 和 Toleration（污点和容忍）

Wenlong — Mon, 29 Nov 2021 09:46:48 +0800

作者：SRE运维博客
博客地址： https://www.cnsre.cn/
文章地址：https://www.cnsre.cn/posts/211129946481/
相关话题：https://www.cnsre.cn/kubernetes/

Taint 和 Toleration（污点和容忍）

在 k8s 集群中，节点亲和性 NodeAffinity 是一种 Pod 上定义的属性，能够让 Pod 可以按找我们的需求调度到指定节点上，而 Taints (污点) 则于NodeAffinity (节点亲和性)是相反的，它是一种 Node 上定义的属性，可以让 Pod 不被调度到带污点的节点上，甚至会对带污点节点上已有的 Pod 进行驱逐。对应的 k8s 可以给 Pod 设置 Tolerations(容忍) 让 Pod 能够对有污点的节点设置容忍，将 Pod 调度到该节点。 Taints 一般是配合 Tolerations 使用的。

为 node 设置污点和容忍

NoSchedule: 一定不能被调度
PreferNoSchedule: 尽量不要调度
NoExecute: 不仅不会调度, 还会驱逐Node上已有的Pod

为 node1 设置 taint：

1
2
3

kubectl taint nodes k8s-node1 key1=value1:NoSchedule
kubectl taint nodes k8s-node1 key1=value1:NoExecute
kubectl taint nodes k8s-node1 key2=value2:NoSchedule

查看 node1 上的 taint：

`1`	`kubectl describe nodes k8s-node1 \|grep Taint`

删除上面的 taint：

kubectl taint nodes k8s-node1 key1:NoSchedule-
kubectl taint nodes k8s-node1 key1:NoExecute-
kubectl taint nodes k8s-node1 key2:NoSchedule-
kubectl taint nodes k8s-node1 key1-     # 删除指定key所有的effect

为 pod 设置 toleration

只要在 pod 的 spec 中设置 tolerations 字段即可，可以有多个 key，如下所示：

tolerations:            
- key: "key1"          
  operator: "Equal"     
  value: "value1"       
  effect: "NoSchedule"  
- key: "key1"
  operator: "Equal"
  value: "value1"
  effect: "NoExecute"
- key: "node.alpha.kubernetes.io/unreachable"
  operator: "Exists"
  effect: "NoExecute"
  tolerationSeconds: 4000

tolerations 和 containers 同级。
key 能容忍的污点 key。
operator Equal 等于表示 key=value ， Exists 不等于，表示当值不等于下面 value 正常
value 可以设置为 NoSchedule、PreferNoSchedule 或 NoExecute。
effect effect 策略
tolerationSeconds 是当 pod 需要被驱逐时，可以继续在 node 上运行的时间。

具体的使用方法请参考官方文档。

作者：SRE运维博客
博客地址： https://www.cnsre.cn/
文章地址：https://www.cnsre.cn/posts/211129946481/
相关话题：https://www.cnsre.cn/tags/kubernetes/

k3s单机版安装部署附一键安装脚本

Wenlong — Tue, 09 Nov 2021 09:07:03 +0800

作者：SRE运维博客
博客地址： https://www.cnsre.cn/
文章地址：https://www.cnsre.cn/posts/211109907029/
相关话题：https://www.cnsre.cn/tags/k3s/

双十一各大云厂商纷纷撒种子种韭菜（抢用户），良心云 也是一如既往的良心，新用户更是通过某宝 148 就可以买到三年 2C4G8M 的轻量应用服务器。于是我也出售薅了羊毛入手了一台。
但是对于各种组件本身就对资源消耗比较大的 k8s 来说，跑起来还是有点费力的，于是我打算将这台实例部署一台轻量级的 Kubernetes: k3s

k8s VS k3s

k3s 是 Rancher 推出的轻量级 k8s。k3s 本身包含了 k8s 的源码，而二进制包却只有 60M 但是本质上和 k8s 没有区别。但为了降低资源占用，k3s 和 k8s 还是有一些区别的，主要是：

使用了相比 Docker 更轻量的 containerd 作为容器运行时（Docker 并不是唯一的容器选择）。
去掉了 k8s 的 Legacy, alpha, non-default features。
用 sqlite3 作为默认的存储，而不是 etcd。
其他的一些优化，最终 k3s 只是一个 binary 文件，非常易于部署。、

所以 k3s 适用于边缘计算，IoT 等资源紧张的场景。同时 k3s 也是非常容易部署的，官网上提供了一键部署的脚本。

k3s的优点

k3s将安装Kubernetes所需的一切打包进仅有60MB大小的二进制文件中，并且完全实现了Kubernetes API。为了减少运行Kubernetes所需的内存，Rancher删除了很多不必要的驱动程序，并用附加组件对其进行替换。
k3s是一款完全通过CNCF认证的Kubernetes发行版，这意味着你可以编写YAML来对完整版的Kubernetes进行操作，并且它们也将适用于k3s集群。
由于它只需要极低的资源就可以运行，因此它能够在任何512MB RAM以上的设备上运行集群，换言之，我们可以让pod在master和节点上运行。

k3s的缺点

首先，当前k3s的版本（k3s v0.8.1）仅能运行单个master，这意味着如果你的master宕机，那么你就无法管理你的集群，即便已有集群要继续运行。但是在k3s v0.10的版本中，多主模式已经是实验性功能，也许在下一个版本中能够GA。
其次，在单个master的k3s中，默认的数据存储是SQLite，这对于小型数据库十分友好，但是如果遭受重击，那么SQLite将成为主要痛点。但是，Kubernetes控制平面中发生的更改更多是与频繁更新部署、调度Pod等有关，因此对于小型开发/测试集群而言，数据库不会造成太大负载。

结论

K8s和k3s各有优劣，使用场景也有所区别，因此不能一概而论。如果你要进行大型的集群部署，那么我建议你选择使用K8s；

如果你像我一样只是为了开发或者测试，那么选择k3s则是性价比更高的选择。

安装 k3s

确保你是一台干净的 CentOS7 服务器。
按照惯例先更新,更新前顺便把源换为国内的yum源。

# 改国内yum源
curl -o /etc/yum.repos.d/CentOS-Base.repo http://mirrors.aliyun.com/repo/Centos-7.repo
curl -o /etc/yum.repos.d/epel.repo http://mirrors.aliyun.com/repo/epel-7.repo
# 更新
yum update -y

修改主机名

`1`	`hostnamectl set-hostname k3s-master`

修改完毕后，断开重连一下。

⚠️ 注意
K3s 默认将使用 containerd 作为容器环境，请在下边选择 使用Docker安装 或者使用Containerd安装。

使用 docker 安装

# 安装 docker-ce
yum remove -y docker docker-client docker-client-latest docker-common docker-latest docker-latest-logrotate docker-logrotate docker-engine
yum install -y yum-utils
yum-config-manager --add-repo  https://download.docker.com/linux/centos/docker-ce.repo
yum install -y docker-ce docker-ce-cli containerd.io
# 解决内核检查问题 重启生效
grubby --args="user_namespace.enable=1" --update-kernel="$(grubby --default-kernel)"
systemctl enable docker
systemctl start docker
# 修改 docker 源
cat << EOF > /etc/docker/daemon.json
{
    "registry-mirrors":["https://3laho3y3.mirror.aliyuncs.com"]
}
EOF
systemctl daemon-reload
systemctl restart docker
# 安装 docker 结束
# 关 firewalld 防火墙
systemctl stop firewalld
systemctl disable firewalld
# 安装 k3s
curl -sfL http://rancher-mirror.cnrancher.com/k3s/k3s-install.sh | INSTALL_K3S_MIRROR=cn sh -s - --docker

使用 containerd 安装

`1`	`curl -sfL http://rancher-mirror.cnrancher.com/k3s/k3s-install.sh \| INSTALL_K3S_MIRROR=cn sh -`

安装完检查

安装完成后，可以执行以下命令进行主机检查。

# 运行配置检查
k3s check-config
# 查看节点状态以及 k3s 版本
[root@k3s-master ~]# kubectl get node
NAME             STATUS   ROLES                  AGE   VERSION
vm-16-8-centos   Ready    control-plane,master   52m   v1.21.5+k3s2
# 查看所有 pod 信息
[root@k3s-master ~]# kubectl get pods -A
NAMESPACE     NAME                                      READY   STATUS      RESTARTS   AGE
kube-system   local-path-provisioner-5ff76fc89d-bbps4   1/1     Running     0          52m
kube-system   coredns-7448499f4d-42v9x                  1/1     Running     0          52m
kube-system   metrics-server-86cbb8457f-xqlrg           1/1     Running     0          52m
kube-system   helm-install-traefik-crd-9wk9v            0/1     Completed   0          52m
kube-system   helm-install-traefik-d8llf                0/1     Completed   3          52m
kube-system   svclb-traefik-jqxvf                       2/2     Running     0          49m
kube-system   traefik-97b44b794-wv6zv                   1/1     Running     0          49m

截止到这里 k3s 已经安装完毕。

安装 nfs

安装 nfs 服务

1
2

yum -y install nfs-utils
systemctl start nfs && systemctl enable nfs

创建nfs目录

`1`	`mkdir -p /home/k8s/nfs`

修改权限

`1`	`chmod -R 755 /home/k8s/nfs`

编辑export文件

1
2
3

cat >>/etc/exports << EOF
/home/k8s/nfs *(rw,no_root_squash,sync)
EOF

配置生效

`1`	`exportfs -r`

启动rpcbind、nfs服务

1
2

systemctl restart rpcbind && systemctl enable rpcbind
systemctl restart nfs && systemctl enable nfs

到这里 k3s 以及 nfs 已经安装完成，下面就可以去体验了。
如果想以上都比较麻烦，你可以用下面的一键安装脚本来执行

一键安装 k3s 脚本

#!/bin/bash
PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin:~/bin
export PATH
LANG=en_US.UTF-8

RD="\033[31m"      # 错误消息
GR="\033[32m"      # 成功消息
YL="\033[33m"      # 告警消息
BL="\033[36m"      # 日志消息
PL='\033[0m'

clear
echo -e "${YL}##################################################${PL}"
echo -e "${YL}#${PL} ${GR}脚本名称${PL}: 一键安装 k3s 脚本                    ${YL}#${PL}"
echo -e "${YL}#${PL} ${GR}作    者${PL}: sre运维博客                          ${YL}#${PL}"
echo -e "${YL}#${PL} ${GR}网    址${PL}: https:www.cnsre.cn                   ${YL}#${PL}"
echo -e "${YL}#${PL} ${GR}文章地址${PL}: https://cnsre.cn/posts/211109907029/ ${YL}#${PL}"
echo -e "${YL}##################################################${PL}"
sleep 0.5

set -e
echo  
echo 
echo
echo -e "${RD}是否确定安装 dockerb版本的 k3s? ${PL}"
read -r -p "确定请按 y 任意键则退出！请选择：[y/n]" input
    if [[ $input != "y" ]]; then
        exit 1
    else 
        echo -e "$GR正在开始安装 dockerb版本的 k3s$PL"
    fi

if [ `command -v docker` ];then
    echo -e "${YL}docker 已经安装,正在添加docker加速源${PL}"
else
    echo -e "${GR}install docker${PL}"
    curl https://download.daocloud.io/docker/linux/centos/docker-ce.repo -o /etc/yum.repos.d/docker-ce.repo
    yum -y install https://download.daocloud.io/docker/linux/centos/7/x86_64/stable/Packages/containerd.io-1.2.6-3.3.el7.x86_64.rpm
    curl -fsSL https://get.daocloud.io/docker | bash -s docker --mirror Aliyun
fi

sudo mkdir -p /etc/docker
tee /etc/docker/daemon.json <<-'EOF'
{
  "registry-mirrors": ["http://f1361db2.m.daocloud.io"]
}
EOF
grubby --args="user_namespace.enable=1" --update-kernel="$(grubby --default-kernel)"

sudo systemctl daemon-reload
sudo systemctl restart docker
sudo systemctl enable docker


if [ `command -v k3s` ];then
    echo -e "${YL}k3s 已经安装${PL}"
	exit 1
else
    export K3S_NODE_NAME=${HOSTNAME//_/-}
    export INSTALL_K3S_EXEC="--docker --kube-apiserver-arg service-node-port-range=1-65000 --no-deploy traefik --write-kubeconfig ~/.kube/config --write-kubeconfig-mode 666"
    curl -sfL http://rancher-mirror.cnrancher.com/k3s/k3s-install.sh | INSTALL_K3S_MIRROR=cn sh -
fi

echo -e "${GR}export K3S_TOKEN=$(cat /var/lib/rancher/k3s/server/node-token)${PL}"
echo -e "${GR}export K3S_URL=https://$(ip addr | grep -E -o '[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}' | grep -E -v "^127\.|^255\.|^0\." | head -n 1):6443${PL}"
echo -e "${GR}安装结束，请重启服务器${PL}"
read -r -p "确定请按 y 任意键则退出！请选择：[y/n]" input
    if [[ $input != "y" ]]; then
        reboot
    else 
        exit 1
    fi

作者：SRE运维博客
博客地址： https://www.cnsre.cn/
文章地址：https://www.cnsre.cn/posts/211109907029/
相关话题：https://www.cnsre.cn/tags/k3s/

国外镜像拉取到docker hub

Wenlong — Fri, 24 Sep 2021 09:25:54 +0800

作者：SRE运维博客
博客地址：https://www.cnsre.cn
文章地址：https://www.cnsre.cn/posts/210924925541/
相关话题：https://www.cnsre.cn/tags/docker/

文章链接
在学习K8S 的过程中总，部分镜像需要从 k8s.grc.io 仓库中拉拉取。但是因为网络的问题导致无法拉取狗歌的镜像，也就导致了创建 pod 拉取镜像失败。
今天就跟大家分享下我从国外拉到国内的镜像。

替换规则

同理，其他镜像地址也可以用该 dockerhub 的地址。
具体替换规则：
k8s.gcr.io 替换为 cnsre
ingress-nginx/controller 替换为 ingress-nginx-controller

1
2
3

k8s.gcr.io/ingress-nginx/controller:v1.0.0
# 等同于 
cnsre/ingress-nginx-controller:v1.0.0

举例

比如 ingress 中的镜像地址为 k8s.gcr.io/ingress-nginx/controller:v1.0.0
需要将镜像地址更改为：cnsre/ingress-nginx-controller:v1.0.0

docker pull k8s.gcr.io/ingress-nginx/controller:v1.0.0
# 等同于
docker pull cnsre/ingress-nginx-controller:v1.0.0

dockerhub 中没有的镜像

如果 cnsre 仓库中没有的一些国外镜像需要下载的话，你可以在地址留言(最好在留言中补充邮箱信息，这样你就可以收到通知。)

作者：SRE运维博客
博客地址：https://www.cnsre.cn
文章地址：https://www.cnsre.cn/posts/210924925541/
相关话题：https://www.cnsre.cn/tags/docker/

kubernetes 部署 metric-server

Wenlong — Wed, 22 Sep 2021 10:13:36 +0800

作者：SRE运维博客
博客地址：https://www.cnsre.cn
文章地址：https://www.cnsre.cn/posts/210922013357/
相关话题：https://www.cnsre.cn/tags/kubernetes/

K8S 使用 kubectl top 看K8S监控
kubectl top 是基础命令，但是需要部署配套的组件才能获取到监控值
部署 metric-server

Kubernetes Metrics Server 是 Cluster 的核心监控数据的聚合器，kubeadm 默认是不部署的。
Metrics Server 供 Dashboard 等其他组件使用，是一个扩展的 APIServer，依赖于 API Aggregator。所以，在安装 Metrics Server 之前需要先在 kube-apiserver 中开启 API Aggregator。
Metrics API 只可以查询当前的度量数据，并不保存历史数据。
Metrics API URI 为 /apis/metrics.k8s.io/，在 k8s.io/metrics 下维护。
必须部署 metrics-server 才能使用该 API，metrics-server 通过调用 kubelet Summary API 获取数据.
不指定pod 名称，则显示命名空间下所有 pod，–containers可以显示 pod 内所有的container
指标含义：
和k8s中的request、limit一致，CPU单位100m=0.1 内存单位1Mi=1024Ki
pod的内存值是其实际使用量，也是做limit限制时判断oom的依据。pod的使用量等于其所有业务容器的总和，不包括 pause 容器，值等于cadvisr中的container_memory_working_set_bytes指标
node的值并不等于该node 上所有 pod 值的总和，也不等于直接在机器上运行 top 或 free 看到的值

要求

注意：使用 Metrics Server 有必备两个条件：

API Server 启用 Aggregator Routing 支持
API Server 能访问 Metrics Server Pod IP
启用API Aggregator

安装 metric-server

下载yaml文件

可以通过运行以下命令下载最新的 Metrics Server 版本：

`1`	`wget https://github.com/kubernetes-sigs/metrics-server/releases/latest/download/components.yaml`

兼容性：

指标服务器	指标 API 组/版本	支持的 Kubernetes 版本
0.6.x	metrics.k8s.io/v1beta1	*1.19+
0.5.x	metrics.k8s.io/v1beta1	*1.8+
0.4.x	metrics.k8s.io/v1beta1	*1.8+
0.3.x	metrics.k8s.io/v1beta1	1.8-1.21

对于 <1.16 需要--authorization-always-allow-paths=/livez,/readyz

修改镜像地址

国内无法下载 k8s.gcr.io/metrics-server/metrics-server:v0.4.1镜像
需要修改为一下镜像地址

`1`	`cnsre/metrics-server-metrics-server:v0.4.1`

添加 –kubelet-insecure-tls参数

    spec:
      containers:
      - args:
        - --cert-dir=/tmp
        - --secure-port=4443
        - --kubelet-preferred-address-types=InternalIP,ExternalIP,Hostname
        - --kubelet-use-node-status-port
        - --kubelet-insecure-tls  # 新增内容

部署metrics-server服务

`1`	`kubectl apply -f components.yaml`

查看状态

1
2
3

[root@master ~]# kubectl -n kube-system get deploy metrics-server
NAME             READY   UP-TO-DATE   AVAILABLE   AGE
metrics-server   1/1     1            1           9m39s

测试

[root@master ~]# kubectl  top  node
NAME     CPU(cores)   CPU%   MEMORY(bytes)   MEMORY%   
master   294m         8%     5971Mi          41%       
node1    198m         5%     3800Mi          26%       
[root@master ~]# kubectl  top  pods 
NAME                                     CPU(cores)   MEMORY(bytes)   
cnsre-deployment-cf6fddb9f-bvfdk         1m           1Mi             
cnsre-deployment-cf6fddb9f-d8spc         1m           1Mi             
cnsre-deployment-cf6fddb9f-nrrhz         1m           1Mi             
nfs-client-provisioner-fd74f99b4-gk8l4   4m           8Mi             
tomcat-deployment-66dc86bb8f-6xj28       2m           974Mi           
tomcat-deployment-66dc86bb8f-db66l       2m           884Mi

作者：SRE运维博客
博客地址：https://www.cnsre.cn
文章地址：https://www.cnsre.cn/posts/210922013357/
相关话题：https://www.cnsre.cn/tags/kubernetes/

kube-eventer事件监控

Wenlong — Fri, 17 Sep 2021 11:28:05 +0800

作者：SRE运维博客
博客地址：https://www.cnsre.cn
文章地址：https://www.cnsre.cn/posts/210917128049/
相关话题：https://www.cnsre.cn/tags/kubernetes/

下载deployment

我这里保存成kube-event.yaml

# cat kube-event.yaml
---
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    name: kube-eventer
  name: kube-eventer
  namespace: kube-system
spec:
  replicas: 1
  selector:
    matchLabels:
      app: kube-eventer
  template:
    metadata:
      labels:
        app: kube-eventer
      annotations:
        scheduler.alpha.kubernetes.io/critical-pod: ''
    spec:
      dnsPolicy: ClusterFirstWithHostNet
      serviceAccount: kube-eventer
      containers:
        - image: registry.aliyuncs.com/acs/kube-eventer-amd64:v1.2.0-484d9cd-aliyun
          name: kube-eventer
          command:
            - "/kube-eventer"
            - "--source=kubernetes:https://kubernetes.default"
            ## .e.g,dingtalk sink demo
            #- --sink=dingtalk:[your_webhook_url]&label=[your_cluster_id]&level=[Normal or Warning(default)]
            - --sink=dingtalk:https://oapi.dingtalk.com/robot/send?access_token=355cf0156xxxxxxxxxxxxxxxxxx&level=Warning
          env:
          # If TZ is assigned, set the TZ value as the time zone
          - name: TZ
            value: "Asia/Shanghai"
          volumeMounts:
            - name: localtime
              mountPath: /etc/localtime
              readOnly: true
            - name: zoneinfo
              mountPath: /usr/share/zoneinfo
              readOnly: true
          resources:
            requests:
              cpu: 100m
              memory: 100Mi
            limits:
              cpu: 500m
              memory: 250Mi
      volumes:
        - name: localtime
          hostPath:
            path: /etc/localtime
        - name: zoneinfo
          hostPath:
            path: /usr/share/zoneinfo
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: kube-eventer
rules:
  - apiGroups:
      - ""
    resources:
      - configmaps
      - events
    verbs:
      - get
      - list
      - watch
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: kube-eventer
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: kube-eventer
subjects:
  - kind: ServiceAccount
    name: kube-eventer
    namespace: kube-system
---
apiVersion: v1
kind: ServiceAccount
metadata:
  name: kube-eventer
  namespace: kube-system

钉钉群里创建自定义webhook

设置–智能群助手–添加机器人–选择WeebHook。定义机器人名称和安全设置

安全设置这里我定义了关键字，Waring。创建后复制webhook地址。然后更改上面deployment中的sink处。

我把上面的label删掉了，只留下了level=Waring，刚好对应了我关键字的Waring。只有带有关键字的才会触发告警。

测试告警

然后创建一个测试的Tomcat的deployment，故意把image镜像的tag写错，让他无法拉取镜像

[root@master allenjol]# kubectl apply -f deploy-tomcat-test.yaml
deployment.apps/tomcat-deployment-allenjol created
service/tomcat-service-allenjol created

[root@master allenjol]# kubectl get po
NAME                                        READY   STATUS             RESTARTS   AGE
tomcat-deployment-allenjol-b6687f99-l5vj9   0/1     ImagePullBackOff   0          45s

部署kube-event.yaml并查看日志。可以看到隔30s去检测一次

]# kubectl apply -f kube-event.yaml
]# kubectl get po -n kube-system | grep kube-event


[root@master allenjol]# kubectl logs -f kube-eventer-648f64c985-zfkkg -n kube-system
I0708 09:26:36.409034       1 eventer.go:67] /kube-eventer --source=kubernetes:https://kubernetes.default --sink=dingtalk:https://oapi.dingtalk.com/robot/send?access_token=355cf01569aef206dc6c05681aaf3ed0ea19ed3597db4c26c565dbeb69ce1303&level=Warning
I0708 09:26:36.409191       1 eventer.go:68] kube-eventer version: v1.2.0 commit: 484d9cd
I0708 09:26:36.411557       1 eventer.go:94] Starting with DingTalkSink sink
I0708 09:26:36.411596       1 eventer.go:108] Starting eventer
I0708 09:26:36.411678       1 eventer.go:116] Starting eventer http service
I0708 09:27:00.000163       1 manager.go:102] Exporting 5 events
I0708 09:27:30.000130       1 manager.go:102] Exporting 9 events
I0708 09:28:00.000147       1 manager.go:102] Exporting 1 events
I0708 09:28:30.000150       1 manager.go:102] Exporting 4 events
I0708 09:29:00.000138       1 manager.go:102] Exporting 1 events
...

可以看到这里已经看到了钉钉的webhook地址了，并且还收集到了events。
查看钉钉群，就会看到已经出现了告警了。

其实这个告警当前还存在点问题。个人认为不应该这么频繁发送，应该像prometheus一样可以配置抑制和静默。然后监控时间可以更改。当然熟悉go语言可以自己改源码然后构建成镜像。

作者：SRE运维博客
博客地址：https://www.cnsre.cn
文章地址：https://www.cnsre.cn/posts/210917128049/
相关话题：https://www.cnsre.cn/tags/kubernetes/

Kubernetes 持久化数据存储 StorageClass

Wenlong — Wed, 08 Sep 2021 10:23:01 +0800

作者：SRE运维博客
博客地址：https://www.cnsre.cn
文章地址：https://www.cnsre.cn/posts/210908023010/
相关话题：https://www.cnsre.cn/tags/kubernetes/

PV 和 PVC 模式要先创建好 PV，然后再定义好 PVC 进行一对一的绑定。那么如果遇到大集群，也一一的创建吗？这样来说维护成本很高，工作量大。这个时候就有了 Kubernetes 提供一种自动创建 PV 的机制，叫 StorageClass ，它的作用就是创建 PV 的模板。

** StorageClass 会定义两部分：**

PV的属性：
比如存储的大小、类型等
PV需要使用到的存储插件
比如Ceph等；

有了这两部分信息，Kubernetes 就能够根据用户提交的 PVC ，找到对应的 StorageClass ，然后 Kubernetes 就会调用 StorageClass 声明的存储插件，自动创建 PV 。

不过要使用 NFS ，我们就需要一个 nfs-client 的插件。这个插件会使 NFS 服务自动帮我们创建 PV 。

自动创建的 PV 会以 ${namespace}-${pvcName}-${pvName} 的格式存储
如果 PV 被回收，则会以 archieved-${namespace}-${pvcName}-${pvName} 的格式存储
详细可以参考 Github
PV、PVC、NFS不再介绍,没有完成的请查看 kubernetes使用PV和PVC管理数据存储

创建ServiceAccount

创建 ServiceAccount 的目的是为了给 nfs-client 授权。

1
2

# 下载 rbac.yaml
wget https://github.com/kubernetes-retired/external-storage/blob/201f40d78a9d3fd57d8a441cfc326988d88f35ec/nfs-client/deploy/rbac.yaml

部署 rbac.yaml

kubectl  apply  -f   rbac.yaml 
# 输出如下
serviceaccount/nfs-client-provisioner created
clusterrole.rbac.authorization.k8s.io/nfs-client-provisioner-runner created
clusterrolebinding.rbac.authorization.k8s.io/run-nfs-client-provisioner created
role.rbac.authorization.k8s.io/leader-locking-nfs-client-provisioner created
rolebinding.rbac.authorization.k8s.io/leader-locking-nfs-client-provisioner created

创建 nfs-client

使用 Deployment 来创建 nfs-client

1
2

# 下载 deployment.yaml
wget https://github.com/kubernetes-retired/external-storage/blob/201f40d78a9d3fd57d8a441cfc326988d88f35ec/nfs-client/deploy/deployment.yaml

修改 yaml 如下

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nfs-client-provisioner
  labels:
    app: nfs-client-provisioner
  # replace with namespace where provisioner is deployed
  namespace: default
spec:
  replicas: 1
  strategy:
    type: Recreate
  selector:
    matchLabels:
      app: nfs-client-provisioner
  template:
    metadata:
      labels:
        app: nfs-client-provisioner
    spec:
      serviceAccountName: nfs-client-provisioner
      containers:
        - name: nfs-client-provisioner
          image: quay.io/external_storage/nfs-client-provisioner:latest
          volumeMounts:
            - name: nfs-client-root
              mountPath: /persistentvolumes
          env:
            - name: PROVISIONER_NAME
              value: fuseim.pri/ifs      # 这里的供应者名称必须和class.yaml中的provisioner的名称一致，否则部署不成功
            - name: NFS_SERVER
              value: 10.0.10.51          # 这里写NFS服务器的IP地址或者能解析到的主机名
            - name: NFS_PATH
              value: /home/bsh/nfs       # 这里写NFS服务器中的共享挂载目录（强调：这里的路径必须是目录中最后一层的文件夹，否则部署的应用将无权限创建目录导致Pending）
      volumes:
        - name: nfs-client-root
          nfs:
            server: 10.0.10.51          # NFS服务器的IP或可解析到的主机名 
            path: /home/bsh/nfs        # NFS服务器中的共享挂载目录（强调：这里的路径必须是目录中最后一层的文件夹，否则部署的应用将无权限创建目录导致Pending）

⚠️ 注意
value: fuseim.pri/ifs # 这里的供应者名称必须和 class.yaml 中的 provisioner 的名称一致，否则部署不成功

创建检查

# 部署 nfs-client
kubectl  apply  -f   deployment.yaml
# 输出如下
deployment.apps/nfs-client-provisioner created

查看pod

kubectl get pod
# 输出如下
NAME                                     READY   STATUS    RESTARTS   AGE
nfs-client-provisioner-fd74f99b4-wr58j   1/1     Running   1          30s

创建 StorageClass

class.yaml 内容比较少，可以不用下载,具体内容如下
class.yaml 下载地址

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: managed-nfs-storage
provisioner: fuseim.pri/ifs # or choose another name, must match deployment's env PROVISIONER_NAME'
parameters:
  archiveOnDelete: "false"

⚠️ 注意
provisioner 必须和上面得 Deployment 的 YAML 文件中 PROVISIONER_NAME 的值保持一致。

创建 storageclass

# 创建 
kubectl  apply  -f  class.yaml 
# 输出如下
storageclass.storage.k8s.io/managed-nfs-storage created

查看状态

kubectl get storageclass
# 输出如下
NAME                  PROVISIONER      RECLAIMPOLICY   VOLUMEBINDINGMODE   ALLOWVOLUMEEXPANSION   AGE
managed-nfs-storage   fuseim.pri/ifs   Delete          Immediate           false                  53s

创建 PVC

创建 tomcat-storageclass-pvc.yaml

kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: tomcat
  annotations:
    volume.beta.kubernetes.io/storage-class: "managed-nfs-storage"
spec:
  accessModes:
    - ReadWriteMany
  resources:
    requests:
      storage: 500Mi

部署 yaml

1
2
3

kubectl  apply  -f tomcat-storageclass-pvc.yaml
# 输出如下
persistentvolumeclaim/tomcat created

查看状态

kubectl get pvc
# 输出如下
NAME         STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS          AGE
tomcat       Bound    pvc-d35c82e3-29f3-4f6d-b25d-3ccdd365d1ec   500Mi      RWX            managed-nfs-storage   48s

pod 使用添加 pvc

还拿之前的 tomcat 做实验，我们把 tomcat 目录下的 logs 拿到本地 nfs 中。

⚠️ 注意
如果遇到使用PVC 创建 pod 的时候发现无法创建成功。出现一下报错的时候请参考 kubernetes 使用 PCV 创建 pod 报错 persistentvolume-controller waiting for a volume to be created

具体 yaml 如下：

apiVersion: apps/v1 
kind: Deployment   
metadata:             
  name: tomcat-deployment     
  labels:       
    app: tomcat  
spec:          
  replicas: 3
  selector:      
    matchLabels: 
      app: tomcat
  minReadySeconds: 1
  progressDeadlineSeconds: 60
  revisionHistoryLimit: 2
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 1
  template:        
    metadata:  
      labels:  
        app: tomcat
    spec:         
      containers:     
      - name: tomcat     
        image: wenlongxue/tomcat:tomcat-demo-62-123xw2    
        imagePullPolicy: Always          
        ports:
        - containerPort: 8080
        resources:
          requests:
            memory: "2Gi"
            cpu: "80m"
          limits: 
            memory: "2Gi" 
            cpu: "80m"
        readinessProbe:
          httpGet:
            path: /
            port: 8080
          initialDelaySeconds: 180
          periodSeconds: 5
          timeoutSeconds: 3
          successThreshold: 1
          failureThreshold: 30
        volumeMounts:
        - mountPath: "/usr/local/tomcat/logs"
          name: tomcat
# pvc 部分
      volumes:
      - name: tomcat
        persistentVolumeClaim:
          claimName: tomcat
---
# Service 服务部分
apiVersion: v1
kind: Service
metadata:      
  name: tomcat-service
  labels:      
    app: tomcat 
spec:        
  selector:   
    app: tomcat  
  ports:
  - name: tomcat-port 
    protocol: TCP      
    port: 8080         
    targetPort: 8080   
  type: ClusterIP 
---
# ingress 服务部分
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: tomcat
  annotations:
    kubernetes.io/ingress.class: "nginx"
spec:
  tls:
  - hosts:
    - tomcat.cnsre.cn
    secretName: tls-secret
  rules:
  - host: tomcat.cnsre.cn
    http:
      paths:
      - path: "/"
        pathType: Prefix
        backend:
          service:
            name: tomcat-service
            port:
              number: 8080

部署 pod 服务

1
2
3

kubectl  apply  -f tomcatc.yaml
# 输出如下
deployment.apps/tomcat-deployment created

查看状态

kubectl get pod
# 输出如下
NAME                                     READY   STATUS    RESTARTS   AGE
nfs-client-provisioner-fd74f99b4-wr58j   1/1     Running   0          76m
tomcat-deployment-7588b5c8fd-cnwvt       1/1     Running   0          59m
tomcat-deployment-7588b5c8fd-kl8fj       1/1     Running   0          59m
tomcat-deployment-7588b5c8fd-ksbg9       1/1     Running   0          59m

查看 PV PVC

[root@master tomccat]# kubectl  get  pv,pvc
NAME                                                        CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS   CLAIM            STORAGECLASS          REASON   AGE
persistentvolume/pvc-d35c82e3-29f3-4f6d-b25d-3ccdd365d1ec   500Mi      RWX            Delete           Bound    default/tomcat   managed-nfs-storage            65m

NAME                           STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS          AGE
persistentvolumeclaim/tomcat   Bound    pvc-d35c82e3-29f3-4f6d-b25d-3ccdd365d1ec   500Mi      RWX            managed-nfs-storage   65m

查看 nfs server 目录中信息

[root@node1 ~]# ll /home/bsh/nfs/default-tomcat-pvc-d35c82e3-29f3-4f6d-b25d-3ccdd365d1ec/
总用量 220
-rw-r-----. 1 root root  22217 9月   3 14:49 catalina.2021-09-03.log
-rw-r-----. 1 root root      0 9月   3 14:41 host-manager.2021-09-03.log
-rw-r-----. 1 root root   2791 9月   3 14:49 localhost.2021-09-03.log
-rw-r-----. 1 root root 118428 9月   3 15:31 localhost_access_log.2021-09-03.txt
-rw-r-----. 1 root root      0 9月   3 14:41 manager.2021-09-03.log

作者：SRE运维博客
博客地址：https://www.cnsre.cn
文章地址：https://www.cnsre.cn/posts/210908023010/
相关话题：https://www.cnsre.cn/tags/kubernetes/

kubernetes 使用 PCV 创建 pod 报错 persistentvolume-controller waiting for a volume to be created

Wenlong — Mon, 06 Sep 2021 09:49:57 +0800

作者：SRE运维博客
博客地址：https://www.cnsre.cn
文章地址：https://www.cnsre.cn/posts/210906949577/
相关话题：https://www.cnsre.cn/tags/kubernetes/

故障表现

在使用PVC 创建 pod 的时候发现无法创建成功。

问题排查过程

先通过看日志发现

 Normal  ExternalProvisioning  8s (x3 over 19s)  persistentvolume-controller  waiting for a volume to be created, either by external provisioner "fuseim.pri/ifs" or manually created by system administrator

最后通过在网上查阅资料发现原来是 1.20 版本默认禁止使用 selfLink 。我的版本为 v1.20.6
参考链接 Guthub Issues

问题解决

当前的解决方法是编辑 /etc/kubernetes/manifests/kube-apiserver.yaml
在 kube-apiserver 下新增一行
具体如下

spec:
  containers:
  - command:
    - kube-apiserver
    - --feature-gates=RemoveSelfLink=false

然后更新即可。

`1`	`kubectl apply -f /etc/kubernetes/manifests/kube-apiserver.yaml`

作者：SRE运维博客
博客地址：https://www.cnsre.cn
文章地址：https://www.cnsre.cn/posts/210906949577/
相关话题：https://www.cnsre.cn/tags/kubernetes/

kubernetes 使用 PV 和 PVC 管理数据存储

Wenlong — Fri, 03 Sep 2021 10:21:49 +0800

作者：SRE运维博客
博客地址：https://www.cnsre.cn
文章地址：https://www.cnsre.cn/posts/210903021487/
相关话题：https://www.cnsre.cn/tags/kubernetes/

容器磁盘上的文件的生命周期是短暂的，这就使得在容器中运行重要应用时会出现一些问题。首先，当容器崩溃时，kubelet 会重启它，但是容器中的文件将丢失——容器以干净的状态（镜像最初的状态）重新启动。其次，在 Pod 中同时运行多个容器时，这些容器之间通常需要共享文件。所以我会用 NFS 为例，创建 PV 、PVC.

PV 属于集群中的资源。PVC 是对这些资源的请求，也作为对资源的请求的检查。 PV 和 PVC 之间的相互作用遵循这样的生命周期.

PersistentVolume（PV）

PersistentVolume（PV）是由管理员设置的存储，它是群集的一部分。就像节点是集群中的资源一样，PV 也是集群中的资源。 PV 是 Volume 之类的卷插件，但具有独立于使用 PV 的 Pod 的生命周期。此 API 对象包含存储实现的细节，即 NFS、iSCSI 或特定于云供应商的存储系统。

PV 有两种方式来配置：静态和动态。

静态
集群管理员创建一些 PV。它们带有可供群集用户使用的实际存储的细节。它们存在于 Kubernetes API 中，可用于消费。
动态
根据 StorageClasses，当管理员创建的静态 PV 都不匹配用户的 PersistentVolumeClaim 时，集群可能会尝试动态地为 PVC 创建卷。

安装并配置 nfs rpcbind

yum install -y nfs-utils rpcbind
mkdir -p /home/bsh/nfs
vim /etc/exports
/home/bsh/nfs *(rw,sync,no_root_squash)

配置详解：
ro	只读访问
rw	读写访问
sync	所有数据在请求时写入共享
async	NFS在写入数据前可以相应请求
secure	NFS通过1024以下的安全TCP/IP端口发送
insecure	NFS通过1024以上的端口发送
wdelay	如果多个用户要写入NFS目录，则归组写入（默认）
no_wdelay	如果多个用户要写入NFS目录，则立即写入，当使用async时，无需此设置。
Hide	在NFS共享目录中不共享其子目录
no_hide	共享NFS目录的子目录
subtree_check	如果共享/usr/bin之类的子目录时，强制NFS检查父目录的权限（默认）
no_subtree_check	和上面相对，不检查父目录权限
all_squash	共享文件的UID和GID映射匿名用户anonymous，适合公用目录。
no_all_squash	保留共享文件的UID和GID（默认）
root_squash	root用户的所有请求映射成如anonymous用户一样的权限（默认）
no_root_squas	root用户具有根目录的完全管理访问权限
anonuid=xxx	指定NFS服务器/etc/passwd文件中匿名用户的UID

启动 nfs rpcbind

1
2

systemctl enable nfs rpcbind
systemctl start nfs rpcbind

创建PV

创建 yaml 文件
vim tomcat-log-pv.yaml

apiVersion: v1
kind: PersistentVolume
metadata:
  name: tomcat
spec:
  capacity:
    storage: 1Gi
  accessModes:
    - ReadWriteMany
  nfs:
    path: /home/bsh/nfs/tomcat-log
    server: 10.0.10.51

创建 pv

`1`	`kubectl apply -f tomcat-log-pv.yaml`

查看pv

1
2
3

[root@master ]# kubectl  get  pv
NAME     CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS      CLAIM   STORAGECLASS   REASON   AGE
tomcat   1Gi        RWX            Retain           Available                                   26s

pv 属性详解

PV的存储容量

PV 将具有特定的存储容量。这是使用PV的capacity属性设置的。

目前，存储大小是可以设置或请求的唯一资源。未来的属性可能包括 IOPS、吞吐量等。

PV的访问模式

PersistentVolume可以以资源提供者支持的任何方式挂载到主机上。如下表所示，供应商具有不同的功能，每个 PV 的访问模式都将被设置为该卷支持的特定模式。例如，NFS 可以支持多个读/写客户端，但特定的 NFS PV 可能以只读方式导出到服务器上。每个 PV 都有一套自己的用来描述特定功能的访问模式。
存储模式包括：

ReadWriteOnce——该卷可以被单个节点以读/写模式挂载
ReadOnlyMany——该卷可以被多个节点以只读模式挂载
ReadWriteMany——该卷可以被多个节点以读/写模式挂载
在命令行中，访问模式缩写为：
RWO - ReadWriteOnce
ROX - ReadOnlyMany
RWX - ReadWriteMany
一个卷一次只能使用一种访问模式挂载，即使它支持很多访问模式。例如，GCEPersistentDisk 可以由单个节点作为 ReadWriteOnce 模式挂载，或由多个节点以 ReadOnlyMany 模式挂载，但不能同时挂载
PV的回收策略
persistentVolumeReclaimPolicy属性用来指定PV的回收策略

当前的回收策略包括：

Retain（保留）——手动回收
Recycle（回收）——基本擦除（rm -rf /thevolume/*）
Delete（删除）——关联的存储资产（例如 AWS EBS、GCE PD、Azure Disk 和 OpenStack Cinder 卷）将被删除
当前，只有 NFS 和 HostPath 支持回收策略。AWS EBS、GCE PD、Azure Disk 和 Cinder 卷支持删除策略。

storageClassName PV 可以具有一个类，通过将 storageClassName 属性设置为 StorageClass 的名称来指定该类。一个特定类别的 PV 只能绑定到请求该类别的 PVC。没有 storageClassName 的 PV 就没有类，它只能绑定到不需要特定类的 PVC。

PersistentVolumeClaim（PVC）

PersistentVolumeClaim（PVC）是用户存储的请求。它与 Pod 相似。Pod 消耗节点资源，PVC 消耗 PV 资源。Pod 可以请求特定级别的资源（CPU 和内存）。声明可以请求特定的大小和访问模式（例如，可以以读/写一次或只读多次模式挂载）。

创建PVC

创建 yaml 文件
vim tomcat-log-pvc.yaml

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: tomcat
spec:
  accessModes:
    - ReadWriteMany
  resources:
    requests:
      storage: 1Gi

创建 pv

`1`	`kubectl apply -f tomcat-log-pvc.yaml`

查看pv

1
2
3

[root@master ]# kubectl  get pvc
NAME     STATUS   VOLUME   CAPACITY   ACCESS MODES   STORAGECLASS   AGE
tomcat   Bound    tomcat   1Gi        RWX                           18s

使用PVC

vim tomcat.yaml

apiVersion: apps/v1 
kind: Deployment   
metadata:             
  name: tomcat-deployment     
  labels:       
    app: tomcat  
spec:          
  replicas: 3
  selector:      
    matchLabels: 
      app: tomcat
  minReadySeconds: 1
  progressDeadlineSeconds: 60
  revisionHistoryLimit: 2
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 1
  template:        
    metadata:  
      labels:  
        app: tomcat
    spec:         
      containers:     
      - name: tomcat     
        image: wenlongxue/tomcat:tomcat-demo-62-8fe6052    
        imagePullPolicy: Always          
        ports:
        - containerPort: 8080
        resources:
          requests:
            memory: "2Gi"
            cpu: "80m"
          limits: 
            memory: "2Gi" 
            cpu: "80m"
        readinessProbe:
          httpGet:
            path: /
            port: 8080
          initialDelaySeconds: 180
          periodSeconds: 5
          timeoutSeconds: 3
          successThreshold: 1
          failureThreshold: 30
        volumeMounts:
        - mountPath: "/usr/local/tomcat/logs"
          name: tomcat

      volumes:
      - name: tomcat
        persistentVolumeClaim:
          claimName: tomcat

部署查看 pod

# 部署
kubectl  apply  -f tomcat.yaml 
# 查看
kubectl  get  pods |grep  tomcat
tomcat-deployment-7588b5c8fd-4grh2       1/1     Running   0          31s
tomcat-deployment-7588b5c8fd-l89t7       1/1     Running   0          31s
tomcat-deployment-7588b5c8fd-mb8bh       1/1     Running   0          31s

最后

PVC 不关心后端存储提供者是 NFS 还是 GFS，具体使用哪种类型的存储由 PV 来定义，PVC 只和隐藏了存储实现细节的 PV 对接。
本方式为静态分配，如果有一千个 Pod，每个 Pod 有一个 PVC，那么管理员需要人工开设一千个 PV，随着集群规模的扩大，将导致无法有效管理。
K8S 提供了一种可以动态分配的工作机制，可以自动创建 PV，该机制依赖一个叫做 StorageClass 的 API 对象。

作者：SRE运维博客
博客地址：https://www.cnsre.cn
文章地址：https://www.cnsre.cn/posts/210903021487/
相关话题：https://www.cnsre.cn/tags/kubernetes/

kubernetes 安装 ingress controller

Wenlong — Thu, 02 Sep 2021 13:30:01 +0800

作者：SRE运维博客
博客地址：https://www.cnsre.cn
文章地址：https://www.cnsre.cn/posts/210902330007/
相关话题：https://www.cnsre.cn/tags/kubernetes/

ingress-nginx

ingress 官方网站
ingress 仓库地址
ingress-nginx v1.0 最新版本 v1.0
适用于 Kubernetes 版本 v1.19+ （包括 v1.19 ）
Kubernetes-v1.22+ 需要使用 ingress-nginx>=1.0，因为 networking.k8s.io/v1beta 已经移除

直接部署 ingress-nginx

直接部署比较简单，直接拉去 girhub 的文件就可以了，如果遇到长时间无响应，可以终止任务从新拉取。
拉取镜像部分，可以修改为一下的镜像地址

wget https://raw.githubusercontent.com/kubernetes/ingress-nginx/controller-v1.0.0/deploy/static/provider/baremetal/deploy.yaml

sed -i 's@k8s.gcr.io/ingress-nginx/controller:v1.0.0\(.*\)@cnsre/ingress-nginx-controller:v1.0.0@' deploy.yaml
sed -i 's@k8s.gcr.io/ingress-nginx/kube-webhook-certgen:v1.0\(.*\)$@cnsre/ingress-nginx-kube-webhook-certgen:v1.0@' deploy.yaml
kubectl apply -f deploy.yaml

检查安装

Completed 状态的是正常的，可以忽略。

[root@master ~]# kubectl get po -n ingress-nginx
NAME                                        READY   STATUS      RESTARTS   AGE
ingress-nginx-admission-create-pm6sw        0/1     Completed   0          22m
ingress-nginx-admission-patch-m8w94         0/1     Completed   0          22m
ingress-nginx-controller-7d4df87d89-272ft   1/1     Running     0          22m
[root@master ~]# kubectl get svc -n ingress-nginx
NAME                                 TYPE        CLUSTER-IP     EXTERNAL-IP   PORT(S)                      AGE
ingress-nginx-controller             NodePort    10.96.88.139   <none>        80:30497/TCP,443:32581/TCP   22m
ingress-nginx-controller-admission   ClusterIP   10.96.193.26   <none>        443/TCP                      22m

创建应用yaml

`1`	`vim tomcat.yaml`

apiVersion: apps/v1 
kind: Deployment   
metadata:             
  name: tomcat-deployment     
  labels:       
    app: tomcat  
spec:          
  replicas: 2 
  selector:      
    matchLabels: 
      app: tomcat
  minReadySeconds: 1
  progressDeadlineSeconds: 60
  revisionHistoryLimit: 2
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 1
  template:        
    metadata:  
      labels:  
        app: tomcat
    spec:         
      containers:     
      - name: tomcat     
        image: wenlongxue/tomcat:tomcat-demo-62-8fe6052    
        imagePullPolicy: Always          
        ports:
        - containerPort: 8080
        resources:
          requests:
            memory: "2Gi"
            cpu: "80m"
          limits: 
            memory: "2Gi" 
            cpu: "80m"
        readinessProbe:
          httpGet:
            path: /
            port: 8080
          initialDelaySeconds: 180
          periodSeconds: 5
          timeoutSeconds: 3
          successThreshold: 1
          failureThreshold: 30
---
apiVersion: v1
kind: Service
metadata:      
  name: tomcat-service
  labels:      
    app: tomcat 
spec:        
  selector:   
    app: tomcat  
  ports:
  - name: tomcat-port 
    protocol: TCP      
    port: 8080         
    targetPort: 8080   
  type: ClusterIP

部署 tomcat 应用

`1`	`kubectl apply -f tomcat.yaml`

创建 ingress yaml

`1`	`vim tomcat-ingress.yaml`

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: tomcat
  annotations:
    kubernetes.io/ingress.class: "nginx"
spec:
  rules:
  - host: tomcat.cnsre.cn
    http:
      paths:
      - path: "/"
        pathType: Prefix
        backend:
          service:
            name: tomcat-service
            port:
              number: 8080

部署 tomcat ingress yaml

`1`	`kubectl apply -f tomcat-ingress.yaml`

查看 ingress 对应节点的端口

 kubectl get svc -n ingress-nginx
NAME                                 TYPE        CLUSTER-IP     EXTERNAL-IP   PORT(S)                      AGE
ingress-nginx-controller             NodePort    10.96.88.139   <none>        80:30497/TCP,443:32581/TCP   54m
ingress-nginx-controller-admission   ClusterIP   10.96.193.26   <none>        443/TCP                      54m

添加 hosts

在 hosts 文件最后追加 ingress 节点的 IP 地址

54.xxx.xxx.xxx tomcat.cnsre.cn

然后在浏览器中访问 tomcat.cnsre.cn:30497。

使用 hostNetwork 的方式部署 ingress-nginx

每次部署 ingres-nginx 都随机一个 nodePort ，而使用 ingres-nginx 访问的时候也要以 域名:端口 的形式去访问如何直接使用域名去访问呢？下面介绍另外一种安装方式。

wget https://raw.githubusercontent.com/kubernetes/ingress-nginx/controller-v1.0.0/deploy/static/provider/baremetal/deploy.yaml

sed -i 's@k8s.gcr.io/ingress-nginx/controller:v1.0.0\(.*\)@cnsre/ingress-nginx-controller:v1.0.0@' deploy.yaml
sed -i 's@k8s.gcr.io/ingress-nginx/kube-webhook-certgen:v1.0\(.*\)$@cnsre/ingress-nginx-kube-webhook-certgen:v1.0@' deploy.yaml

优化 ingress-nginx

使用 hostNetwork

默认 ingress-nginx 随机提供 nodeport 端口，开启 hostNetwork 启用80、443端口。
修改 Deployment 下面的 spec
参数如下：

...
    spec:
      hostNetwork: true # 新增
      dnsPolicy: ClusterFirst
      containers:
        - name: controller
          image: cnsre/ingress-nginx-controller:v1.0.0  # 更换镜像地址
          imagePullPolicy: IfNotPresent
          lifecycle:
...

修改负载均衡问题

把 kind: Deployment 改为 kind: DaemonSet 模式，这样每台 node 上都有 ingress-nginx-controller pod 副本。
参数如下：

...
# Source: ingress-nginx/templates/controller-deployment.yaml
apiVersion: apps/v1
#kind: Deployment   # 注释
kind: DaemonSet     # 新增
metadata:
  labels:
    helm.sh/chart: ingress-nginx-4.0.1
...

修改 ingressClass 问题

如果不关心 ingressClass 或者很多没有 ingressClass 配置的 ingress 对象，
添加参数 ingress-controller --watch-ingress-without-class=true 。

...
          args:
            - /nginx-ingress-controller
            - --election-id=ingress-controller-leader
            - --controller-class=k8s.io/ingress-nginx
            - --configmap=$(POD_NAMESPACE)/ingress-nginx-controller
            - --validating-webhook=:8443
            - --validating-webhook-certificate=/usr/local/certificates/cert
            - --validating-webhook-key=/usr/local/certificates/key
            - --watch-ingress-without-class=true  # 新增
...

部署检查 ingress

# 部署 
kubectl apply -f ingress-nginx.yaml
# 检查 pod 
[root@master ~]# kubectl  get  pods -n ingress-nginx  -o wide 
NAME                                   READY   STATUS      RESTARTS   AGE   IP               NODE     NOMINATED NODE   READINESS GATES
ingress-nginx-admission-create-gmnmp   0/1     Completed   0          84m   10.100.219.105   master   <none>           <none>
ingress-nginx-admission-patch-f5sgc    0/1     Completed   0          84m   10.100.219.106   master   <none>           <none>
ingress-nginx-controller-b62w7         1/1     Running     0          84m   10.0.10.51       master   <none>           <none>
ingress-nginx-controller-lsn7h         1/1     Running     0          84m   10.0.20.222      node1    <none>           <none>
# 检查端口
[root@master ~]# netstat  -pntl |grep 443 
tcp        0      0 0.0.0.0:443             0.0.0.0:*               LISTEN      31248/nginx: master 
[root@master ~]# netstat  -pntl |grep 80        
tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN      31248/nginx: master

创建应用yaml

`1`	`vim tomcat.yaml`

apiVersion: apps/v1 
kind: Deployment   
metadata:             
  name: tomcat-deployment     
  labels:       
    app: tomcat  
spec:          
  replicas: 2 
  selector:      
    matchLabels: 
      app: tomcat
  minReadySeconds: 1
  progressDeadlineSeconds: 60
  revisionHistoryLimit: 2
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 1
  template:        
    metadata:  
      labels:  
        app: tomcat
    spec:         
      containers:     
      - name: tomcat     
        image: wenlongxue/tomcat:tomcat-demo-62-8fe6052    
        imagePullPolicy: Always          
        ports:
        - containerPort: 8080
        resources:
          requests:
            memory: "2Gi"
            cpu: "80m"
          limits: 
            memory: "2Gi" 
            cpu: "80m"
        readinessProbe:
          httpGet:
            path: /
            port: 8080
          initialDelaySeconds: 180
          periodSeconds: 5
          timeoutSeconds: 3
          successThreshold: 1
          failureThreshold: 30
---
apiVersion: v1
kind: Service
metadata:      
  name: tomcat-service
  labels:      
    app: tomcat 
spec:        
  selector:   
    app: tomcat  
  ports:
  - name: tomcat-port 
    protocol: TCP      
    port: 8080         
    targetPort: 8080   
  type: ClusterIP

部署 tomcat 应用

`1`	`kubectl apply -f tomcat.yaml`

创建 ingress yaml

`1`	`vim tomcat-ingress.yaml`

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: tomcat
  annotations:
    kubernetes.io/ingress.class: "nginx"
spec:
  rules:
  - host: tomcat.cnsre.cn
    http:
      paths:
      - path: "/"
        pathType: Prefix
        backend:
          service:
            name: tomcat-service
            port:
              number: 8080

部署 tomcat ingress yaml

`1`	`kubectl apply -f tomcat-ingress.yaml`

添加 hosts

在 hosts 文件最后追加 ingress 节点的 IP 地址

54.xxx.xxx.xxx tomcat.cnsre.cn

然后在浏览器中访问 tomcat.cnsre.cn。

给 ingress-nginx 配置 HTTPS 访问

创建自签证书文件

`1`	`openssl req -x509 -nodes -newkey rsa:2048 -keyout tls.key -out tls.crt -subj "/CN=nginx/O=nginx"`

创建后会生成两个文件

1
2
3

ll tls.*
-rw-r--r--. 1 root root 1127 9月   2 13:04 tls.crt
-rw-r--r--. 1 root root 1708 9月   2 13:04 tls.key

创建 secret

`1`	`kubectl create secret tls tls-secret --key tls.key --cert tls.crt`

修改 tomcat-ingress yaml

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: tomcat
  annotations:
    kubernetes.io/ingress.class: "nginx"
spec:
  tls:                      # 新增
  - hosts:                  # 新增
    - tomcat.cnsre.cn       # 新增
    secretName: tls-secret  # 新增
  rules:
  - host: tomcat.cnsre.cn
    http:
      paths:
      - path: "/"
        pathType: Prefix
        backend:
          service:
            name: tomcat-service
            port:
              number: 8080

修改完重新部署下

`1`	`kubectl apply -f tomcat-ingress.yaml`

验证证书

访问tomcat.cnsre.cn

作者：SRE运维博客
博客地址：https://www.cnsre.cn
文章地址：https://www.cnsre.cn/posts/210902330007/
相关话题：https://www.cnsre.cn/tags/kubernetes/

kubernetes 常见故障以及解决方法

Wenlong — Thu, 19 Aug 2021 09:55:38 +0800

作者：SRE运维博客
博客地址：https://www.cnsre.cn
文章地址：https://www.cnsre.cn/posts/210819955387/
相关话题：https://www.cnsre.cn/tags/kubernetes/

查看节点状态失败

`1`	`Error from server (NotFound): the server could not find the requested resource (get services http:heapster:)`

原因分析：没有heapster服务。
解决方法：安装promethus监控组件即可。

K8S 集群服务访问失败

案例 1

curl: (60) Peer's Certificate issuer is not recognized.

More details here: http://curl.haxx.se/docs/sslcerts.html

curl performs SSL certificate verification by default, using a "bundle"
of Certificate Authority (CA) public keys (CA certs). If the default
bundle file isn't adequate, you can specify an alternate file
using the --cacert option.
If this HTTPS server uses a certificate signed by a CA represented in
the bundle, the certificate verification probably failed due to a
problem with the certificate (it might be expired, or the name might
not match the domain name in the URL).
If you'd like to turn off curl's verification of the certificate, use
the -k (or --insecure) option.

原因分析：证书不能被识别，其原因为：自定义证书，过期等。
解决方法：更新证书即可。

案例 2

`1`	`curl: (7) Failed connect to 10.103.22.158:3000; Connection refused`

原因分析：端口映射错误，服务正常工作，但不能提供服务。
解决方法：删除svc，重新映射端口即可。

`1`	`kubectl delete svc nginx-deployment`

K8S 集群服务暴露失败

`1`	`Error from server (AlreadyExists): services "nginx-deployment" already exists`

原因分析：该容器已暴露服务了。
解决方法：删除svc，重新映射端口即可。

外网无法访问 K8S 集群提供的服务

原因分析：K8S集群的type为ClusterIP，未将服务暴露至外网。
解决方法：修改K8S集群的type为NodePort即可，于是可通过所有K8S集群节点访问服务。

pod 创建失败

案例 1

readiness-httpget-pod 0/1 Pending 0 0s
readiness-httpget-pod 0/1 Pending 0 0s
readiness-httpget-pod 0/1 ContainerCreating 0 0s
readiness-httpget-pod 0/1 Error 0 2s
readiness-httpget-pod 0/1 Error 1 3s
readiness-httpget-pod 0/1 CrashLoopBackOff 1 4s
readiness-httpget-pod 0/1 Error 2 15s
readiness-httpget-pod 0/1 CrashLoopBackOff 2 26s
readiness-httpget-pod 0/1 Error 3 37s
readiness-httpget-pod 0/1 CrashLoopBackOff 3 52s
readiness-httpget-pod 0/1 Error 4 82s

原因分析：镜像问题导致容器无法启动。
解决方法：更换镜像。

案例 2

原因分析：yml文件内容出错—-使用中文字符；
解决方法：修改myregistrykey内容即可。

pod 的 ready 状态未进入

`1`	`readiness-httpget-pod 0/1 Running 0 116s`

原因分析：POD的执行命令失败，无法获取资源。
解决方法：进入容器内部，创建yaml定义的资源

pod 状态为 ErrImagePull

`1`	`rnginx-deployment 0/1 ErrImagePull 0 10s`

原因分析：image无法拉取
解决方法：更换镜像即可。

pod 一直处于 pending 状态

原因分析：由于已使用同样镜像发布了pod，导致无节点可调度。
解决方法：删除所有pod后部署pod即可。

探测存活 pod 状态为 CrashLoopBackOff

原因分析：镜像问题，导致容器重启失败。
解决方法：更换镜像即可。

创建服务 status 为 ErrImagePull

排查思路：

`1`	`kubectl describe pod test-nginx`

原因分析：拉取镜像名称问题。
解决方法：删除错误pod；重新拉取镜像；

`1`	`kubectl delete pod test-nginx;kubectl run test-nginx --image=10.0.0.81:5000/nginx:alpine`

创建 init C容器后，其状态不正常

1
2

NAME READY STATUS RESTARTS AGE
myapp-pod 0/1 Init:0/2 0 20s

原因分析：查看日志发现，pod一直出于初始化中；然后查看pod详细信息，定位pod创建失败的原因为：初始化容器未执行完毕。

`1`	`Error from server (BadRequest): container "myapp-container" in pod "myapp-pod" is waiting to start: PodInitializing`

waiting for myservice

Server: 10.96.0.10
Address: 10.96.0.10:53

** server can't find myservice.default.svc.cluster.local: NXDOMAIN

*** Can't find myservice.svc.cluster.local: No answer
*** Can't find myservice.cluster.local: No answer
*** Can't find myservice.default.svc.cluster.local: No answer
*** Can't find myservice.svc.cluster.local: No answer
*** Can't find myservice.cluster.local: No answer

解决方法：创建相关service，将SVC的name写入K8S集群的coreDNS服务器中，于是coreDNS就能对POD的initC容器执行过程中的域名解析了。

`1`	`kubectl apply -f myservice.yaml`

阿

NAME READY STATUS RESTARTS AGE

myapp-pod 0/1 Init:1/2 0 27m
myapp-pod 0/1 PodInitializing 0 28m
myapp-pod 1/1 Running 0 28m

创建 PV 失败

原因分析：pv的name字段重复。
解决方法：修改pv的name字段即可。

pod 无法挂载 PVC

原因分析：pod无法挂载PVC。accessModes与可使用的PV不一致，导致无法挂载PVC，由于只能挂载大于1G且accessModes为RWO的PV，故只能成功创建1个pod，第2个pod一致pending，按序创建时则第3个pod一直未被创建；
解决方法：修改yml文件中accessModes或PV的accessModes即可。

pod 使用 PV 后，无法访问其内容

原因分析：nfs卷中没有文件或权限不对。
解决方法：在nfs卷中创建文件并授予权限。

kube-flannel-ds-amd64-ndsf7 插件 pod 的 status 为 Init:0/1

排查思路：kubectl -n kube-system describe pod kube-flannel-ds-amd64-ndsf7 #查询pod描述信息；

原因分析：k8s-slave1节点拉取镜像失败。
解决方法：登录k8s-slave1，重启docker服务，手动拉取镜像。

k8s-master节点，重新安装插件即可。

`1`	`kubectl create -f kube-flannel.yml;kubectl get nodes`

不能进入指定容器内部

原因分析：yml文件comtainers字段重复，导致该pod没有该容器。
解决方法：去掉yml文件中多余的containers字段，重新生成pod。

作者：SRE运维博客
博客地址：https://www.cnsre.cn
文章地址：https://www.cnsre.cn/posts/210819955387/
相关话题：https://www.cnsre.cn/tags/kubernetes/

Kubernetes 1.19 安装 Prometheus-Oprator

Wenlong — Mon, 21 Jun 2021 15:50:41 +0800

作者：SRE运维博客
博客地址：https://www.cnsre.cn
文章地址：https://www.cnsre.cn/posts/210621550392/
相关话题：https://www.cnsre.cn/tags/prometheus/

简介

Prometheus 介绍

Prometheus 是一套开源的监控 & 报警 & 时间序列数据库的组合,起始是由 SoundCloud 公司开发的。成立于 2012 年，之后许多公司和组织接受和采用 prometheus,他们便将它独立成开源项目，并且有公司来运作.该项目有非常活跃的社区和开发人员，目前是独立的开源项目，任何公司都可以使用它，2016 年，Prometheus 加入了云计算基金会，成为 kubernetes 之后的第二个托管项目.google SRE 的书内也曾提到跟他们 BorgMon 监控系统相似的实现是 Prometheus。现在最常见的 Kubernetes 容器管理系统中，通常会搭配 Prometheus 进行监控。

Kubernetes Operator 介绍

Prometheus-operator 已经改名为 Kube-promethues

在 Kubernetes 的支持下，管理和伸缩 Web 应用、移动应用后端以及 API 服务都变得比较简单了。其原因是这些应用一般都是无状态的，所以 Deployment 这样的基础 Kubernetes API 对象就可以在无需附加操作的情况下，对应用进行伸缩和故障恢复了。

而对于数据库、缓存或者监控系统等有状态应用的管理，就是个挑战了。这些系统需要应用领域的知识，来正确的进行伸缩和升级，当数据丢失或不可用的时候，要进行有效的重新配置。我们希望这些应用相关的运维技能可以编码到软件之中，从而借助 Kubernetes` 的能力，正确的运行和管理复杂应用。

Operator 这种软件，使用 TPR (第三方资源，现在已经升级为 CRD) 机制对 Kubernetes API 进行扩展，将特定应用的知识融入其中，让用户可以创建、配置和管理应用。和 Kubernetes 的内置资源一样，Operator 操作的不是一个单实例应用，而是集群范围内的多实例。

Prometheus Operator 介绍

Kubernetes 的 Prometheus Operator 为 Kubernetes 服务和 Prometheus 实例的部署和管理提供了简单的监控定义。

安装完毕后，Prometheus Operator 提供了以下功能：

创建/毁坏：在 Kubernetes namespace 中更容易启动一个 Prometheus 实例，一个特定的应用程序或团队更容易使用Operator。
简单配置：配置 Prometheus 的基础东西，比如在 Kubernetes 的本地资源 versions, persistence, retention policies, 和 replicas。
Target Services 通过标签：基于常见的 Kubernetes label 查询，自动生成监控 target 配置；不需要学习 Prometheus 特定的配置语言。

架构

Prometheus

为一个监控系统， Prometheus 项目的作用和工作方式，其实可以用如下所示的一张官方示意图来解释：

可以看到， Prometheus 项目工作的核心，是使用 Pull （抓取）的方式去搜集被监控对象的 Metrics 数据（监控指标数据），然后，再把这些数据保存在一个 TSDB （时间序列数据库，比如 OpenTSDB、InfluxDB 等）当中，以便后续可以按照时间进行检索。有了这套核心监控机制， Prometheus 剩下的组件就是用来配合这套机制的运行。比如 Pushgateway ，可以允许被监控对象以 Push 的方式向 Prometheus 推送 Metrics 数据。而 Alertmanager ，则可以根据 Metrics 信息灵活地设置报警。当然， Prometheus 最受用户欢迎的功能，还是通过 Grafana 对外暴露出的、可以灵活配置的监控数据可视化界面。

Prometheus Operator

Operator： Operator 资源会根据自定义资源（Custom Resource Definition / CRDs）来部署和管理 Prometheus Server ，同时监控这些自定义资源事件的变化来做相应的处理，是整个系统的控制中心。
Prometheus： Prometheus 资源是声明性地描述 Prometheus 部署的期望状态。
Prometheus Server： Operator 根据自定义资源 Prometheus 类型中定义的内容而部署的 Prometheus Server 集群，这些自定义资源可以看作是用来管理 Prometheus Server 集群的 StatefulSets 资源。
ServiceMonitor： ServiceMonitor 也是一个自定义资源，它描述了一组被 Prometheus 监控的 targets 列表。该资源通过 Labels 来选取对应的 Service Endpoint ，让 Prometheus Server 通过选取的 Service 来获取 Metrics 信息。
Service： Service 资源主要用来对应 Kubernetes 集群中的 Metrics Server Pod ，来提供给 ServiceMonitor 选取让 Prometheus Server 来获取信息。简单的说就是 Prometheus Node Exporter Service 、Mysql Exporter Service 等等。
Alertmanager： Alertmanager 也是一个自定义资源类型，由 Operator 根据资源描述内容来部署 Alertmanager 集群

安装前须知

在k8s中部署Prometheus监控的方法

通常在k8s中部署 prometheus 监控可以采取的方法有以下三种

通过yaml手动部署
operator部署
通过helm chart部署

kube-prometheus 兼容说明

kube-prometheus stack	Kubernetes 1.18	Kubernetes 1.19	Kubernetes 1.20	Kubernetes 1.21
`release-0.5`	✔	✗	✗	✗
`release-0.6`	✗	✔	✗	✗
`release-0.7`	✗	✔	✔	✗
`release-0.8`	✗	✗	✔	✔
`HEAD`	✗	✗	✔	✔

环境参数

系统参数：
Kube-promethues 版本： 0.7.0
Kubernetes 版本： v1.19.5
项目 Github 地址： https://github.com/coreos/kube-prometheus

拉取 kube-prometheus 0.7

先从 Github 上将源码拉取下来，利用源码项目已经写好的 kubernetes 的 yaml 文件进行一系列集成镜像的安装，如 grafana 、prometheus 等等。

`1`	`wget https://github.com/prometheus-operator/kube-prometheus/archive/refs/tags/v0.7.0.zip`

解压

`1`	`cd kube-prometheus-0.7.0/`

yaml 文件分类

由于它的文件都存放在项目源码的 manifests 文件夹下，所以需要进入其中进行启动这些 kubernetes 应用 yaml 文件。又由于这些文件堆放在一起，不利于分类启动，所以这里将它们分类。

进入源码的 manifests 文件夹：

`1`	`cd manifests/`

创建文件夹并且将 yaml 文件分类：

# 创建文件夹
mkdir -p node-exporter alertmanager grafana kube-state-metrics prometheus serviceMonitor adapter

# 移动 yaml 文件，进行分类到各个文件夹下
mv *-serviceMonitor* serviceMonitor/
mv grafana-* grafana/
mv kube-state-metrics-* kube-state-metrics/
mv alertmanager-* alertmanager/
mv node-exporter-* node-exporter/
mv prometheus-adapter* adapter/
mv prometheus-* prometheus/

基本目录结构如下：

[root@master kube-prometheus-0.7.0]# tree  manifests/
manifests/
|-- adapter
|   |-- prometheus-adapter-apiService.yaml
|   |-- prometheus-adapter-clusterRoleAggregatedMetricsReader.yaml
|   |-- prometheus-adapter-clusterRoleBindingDelegator.yaml
|   |-- prometheus-adapter-clusterRoleBinding.yaml
|   |-- prometheus-adapter-clusterRoleServerResources.yaml
|   |-- prometheus-adapter-clusterRole.yaml
|   |-- prometheus-adapter-configMap.yaml
|   |-- prometheus-adapter-deployment.yaml
|   |-- prometheus-adapter-roleBindingAuthReader.yaml
|   |-- prometheus-adapter-serviceAccount.yaml
|   `-- prometheus-adapter-service.yaml
|-- alertmanager
|   |-- alertmanager-alertmanager.yaml
|   |-- alertmanager-secret.yaml
|   |-- alertmanager-serviceAccount.yaml
|   `-- alertmanager-service.yaml
|-- grafana
|   |-- grafana-dashboardDatasources.yaml
|   |-- grafana-dashboardDefinitions.yaml
|   |-- grafana-dashboardSources.yaml
|   |-- grafana-deployment.yaml
|   |-- grafana-serviceAccount.yaml
|   `-- grafana-service.yaml
|-- kube-state-metrics
|   |-- kube-state-metrics-clusterRoleBinding.yaml
|   |-- kube-state-metrics-clusterRole.yaml
|   |-- kube-state-metrics-deployment.yaml
|   |-- kube-state-metrics-serviceAccount.yaml
|   `-- kube-state-metrics-service.yaml
|-- node-exporter
|   |-- node-exporter-clusterRoleBinding.yaml
|   |-- node-exporter-clusterRole.yaml
|   |-- node-exporter-daemonset.yaml
|   |-- node-exporter-serviceAccount.yaml
|   `-- node-exporter-service.yaml
|-- prometheus
|   |-- prometheus-clusterRoleBinding.yaml
|   |-- prometheus-clusterRole.yaml
|   |-- prometheus-prometheus.yaml
|   |-- prometheus-roleBindingConfig.yaml
|   |-- prometheus-roleBindingSpecificNamespaces.yaml
|   |-- prometheus-roleConfig.yaml
|   |-- prometheus-roleSpecificNamespaces.yaml
|   |-- prometheus-rules.yaml
|   |-- prometheus-serviceAccount.yaml
|   `-- prometheus-service.yaml
|-- serviceMonitor
|   |-- alertmanager-serviceMonitor.yaml
|   |-- grafana-serviceMonitor.yaml
|   |-- kube-state-metrics-serviceMonitor.yaml
|   |-- node-exporter-serviceMonitor.yaml
|   |-- prometheus-adapter-serviceMonitor.yaml
|   |-- prometheus-operator-serviceMonitor.yaml
|   |-- prometheus-serviceMonitorApiserver.yaml
|   |-- prometheus-serviceMonitorCoreDNS.yaml
|   |-- prometheus-serviceMonitorKubeControllerManager.yaml
|   |-- prometheus-serviceMonitorKubelet.yaml
|   |-- prometheus-serviceMonitorKubeScheduler.yaml
|   `-- prometheus-serviceMonitor.yaml
`-- setup
    |-- 0namespace-namespace.yaml
    |-- prometheus-operator-0alertmanagerConfigCustomResourceDefinition.yaml
    |-- prometheus-operator-0alertmanagerCustomResourceDefinition.yaml
    |-- prometheus-operator-0podmonitorCustomResourceDefinition.yaml
    |-- prometheus-operator-0probeCustomResourceDefinition.yaml
    |-- prometheus-operator-0prometheusCustomResourceDefinition.yaml
    |-- prometheus-operator-0prometheusruleCustomResourceDefinition.yaml
    |-- prometheus-operator-0servicemonitorCustomResourceDefinition.yaml
    |-- prometheus-operator-0thanosrulerCustomResourceDefinition.yaml
    |-- prometheus-operator-clusterRoleBinding.yaml
    |-- prometheus-operator-clusterRole.yaml
    |-- prometheus-operator-deployment.yaml
    |-- prometheus-operator-serviceAccount.yaml
    `-- prometheus-operator-service.yaml

修改 Service 端口设置

修改 prometheus-service.yaml 文件

`1`	`vim prometheus/prometheus-service.yaml`

修改 prometheus Service 端口类型为 NodePort，设置 NodePort 端口为 30100：

apiVersion: v1
kind: Service
metadata:
  labels:
    prometheus: k8s
  name: prometheus-k8s
  namespace: monitoring
spec:
  type: NodePort     # 增加配置
  ports:
  - name: web
    port: 9090
    targetPort: web
    nodePort: 30100  # 增加配置
  selector:
    app: prometheus
    prometheus: k8s
  sessionAffinity: ClientIP

修改 Grafana Service

修改 grafana-service.yaml 文件：

`1`	`vim grafana/grafana-service.yaml`

apiVersion: v1
kind: Service
metadata:
  labels:
    app: grafana
  name: grafana
  namespace: monitoring
spec:
  type: NodePort     # 增加配置
  ports:
  - name: http
    port: 3000
    targetPort: http
    nodePort: 30101  # 增加配置
  selector:
    app: grafana

安装Prometheus Operator

所有文件都在 manifests 目录下执行。

安装 Operator

`1`	`kubectl apply -f setup/`

查看 Pod，等 pod 创建起来在进行下一步：

1
2
3

[root@master manifests]# kubectl get pods -n monitoring
NAME                                   READY   STATUS    RESTARTS   AGE
prometheus-operator-7649c7454f-q5f2r   2/2     Running   0          50s

这会创建一个名为 monitoring 的命名空间，以及相关的 CRD 资源对象声明和 Prometheus Operator 控制器。前面中我们介绍过 CRD 和 Operator 的使用，当我们声明完 CRD 过后，就可以来自定义资源清单了，但是要让我们声明的自定义资源对象生效就需要安装对应的 Operator 控制器，这里我们都已经安装了，所以接下来就可以来用 CRD 创建真正的自定义资源对象了。其实在 manifests 目录下面的就是我们要去创建的 Prometheus 、Alertmanager 以及各种监控对象的资源清单。

安装其它组件

没有特殊的定制需求我们可以直接一键安装：

kubectl apply -f adapter/
kubectl apply -f alertmanager/
kubectl apply -f node-exporter/
kubectl apply -f kube-state-metrics/
kubectl apply -f grafana/
kubectl apply -f prometheus/
kubectl apply -f serviceMonitor/

查看 Pod 状态：

[root@master manifests]# kubectl  get  pods -n  monitoring 
NAME                                   READY   STATUS    RESTARTS   AGE
alertmanager-main-0                    2/2     Running   0          16m
alertmanager-main-1                    2/2     Running   0          16m
alertmanager-main-2                    2/2     Running   0          16m
grafana-6f777cf998-sv4mz               1/1     Running   0          16m
kube-state-metrics-587bfd4f97-mhj94    3/3     Running   0          16m
node-exporter-cgbl2                    2/2     Running   0          16m
node-exporter-k9fqg                    2/2     Running   0          16m
prometheus-adapter-69b8496df6-954s6    1/1     Running   0          16m
prometheus-k8s-0                       2/2     Running   0          16m
prometheus-k8s-1                       2/2     Running   0          16m
prometheus-operator-7649c7454f-q5f2r   2/2     Running   0          16m

查看 Prometheus & Grafana

查看 Prometheus

打开地址：http://node_ip:30100 查看 Prometheus 采集的目标，看其各个采集服务状态有没有错误。

查看 Grafana

打开地址：http://node_ip:30101 查看 Grafana 图表，看其 Kubernetes 集群是否能正常显示。
默认用户名：admin
默认密码：admin

查看仪表盘：

微信报警

获取企业 ID 等信息

配置前参数说明:

获取企业微信的对外接口
企业微信的 secret_api
企业信息ID corp_id

wechat_api_url:
企业微信对外接口 https://qyapi.weixin.qq.com/cgi-bin/
api_secret: 应用管理–应用–你的应用
agent_id: 应用管理–应用–你的应用
corp_id: 我的企业– 企业信息–下拉至最下–企业ID
to_party: 通讯录–组–部门ID
to_user： 通讯录–组–部门ID–选中接收告警的人–账号

登录企业微信–应用管理–应用–下拉到最下面点击创建应用

需要记着 AgentId、Secret

点击我的企业– 企业信息–下拉至最下–企业ID

通讯录–组–部门ID

将对应秘钥填入yaml

配置 alertmanager.yaml

cd alertmanager/
cat <<EOF > alertmanager.yaml    
global:
  resolve_timeout: 5m  
receivers:
- name: wechat
  wechat_configs:
  - agent_id: "1000005"
    api_secret: _UCBVsNYTQwY75TFKQ4V6jj2YQKsyxxxxx
    corp_id: ww022bebbed74fxxxx
    send_resolved: true
    to_user: xuewenlong
route:
  group_by:
  - job
  group_interval: 5m
  group_wait: 30s
  receiver: wechat
  repeat_interval: 1h
  routes:
  - match:
      alertname: Watchdog
    receiver: wechat
templates:
- /etc/alertmanager/config/wechat.tmpl
EOF

个性化配置报警模板，网上有很多例子

cat <<EOF > wechat.tmpl  
{{ define "wechat.default.message" }}
{{- if gt (len .Alerts.Firing) 0 -}}
{{- range $index, $alert := .Alerts -}}
{{- if eq $index 0 }}
==========异常告警==========
告警类型: {{ $alert.Labels.alertname }}
告警级别: {{ $alert.Labels.severity }}
告警详情: {{ $alert.Annotations.message }}{{ $alert.Annotations.description}};{{$alert.Annotations.summary}}
故障时间: {{ ($alert.StartsAt.Add 28800e9).Format "2006-01-02 15:04:05" }}
{{- if gt (len $alert.Labels.instance) 0 }}
实例信息: {{ $alert.Labels.instance }}
{{- end }}
{{- if gt (len $alert.Labels.namespace) 0 }}
命名空间: {{ $alert.Labels.namespace }}
{{- end }}
{{- if gt (len $alert.Labels.node) 0 }}
节点信息: {{ $alert.Labels.node }}
{{- end }}
{{- if gt (len $alert.Labels.pod) 0 }}
实例名称: {{ $alert.Labels.pod }}
{{- end }}
============END============
{{- end }}
{{- end }}
{{- end }}
{{- if gt (len .Alerts.Resolved) 0 -}}
{{- range $index, $alert := .Alerts -}}
{{- if eq $index 0 }}
==========异常恢复==========
告警类型: {{ $alert.Labels.alertname }}
告警级别: {{ $alert.Labels.severity }}
告警详情: {{ $alert.Annotations.message }}{{ $alert.Annotations.description}};{{$alert.Annotations.summary}}
故障时间: {{ ($alert.StartsAt.Add 28800e9).Format "2006-01-02 15:04:05" }}
恢复时间: {{ ($alert.EndsAt.Add 28800e9).Format "2006-01-02 15:04:05" }}
{{- if gt (len $alert.Labels.instance) 0 }}
实例信息: {{ $alert.Labels.instance }}
{{- end }}
{{- if gt (len $alert.Labels.namespace) 0 }}
命名空间: {{ $alert.Labels.namespace }}
{{- end }}
{{- if gt (len $alert.Labels.node) 0 }}
节点信息: {{ $alert.Labels.node }}
{{- end }}
{{- if gt (len $alert.Labels.pod) 0 }}
实例名称: {{ $alert.Labels.pod }}
{{- end }}
============END============
{{- end }}
{{- end }}
{{- end }}
{{- end }}
EOF

部署secret

1
2

kubectl delete secret alertmanager-main -n monitoring
kubectl create secret generic alertmanager-main --from-file=alertmanager.yaml --from-file=wechat.tmpl -n monitoring

查看容器中的配置文件

1
2
3

kubectl exec -it  alertmanager-main-0 -n monitoring /bin/sh
ls /etc/alertmanager/config/
# 如果能看到  alertmanager.yaml  wechat.tmpl 两个文件就证明更新成功了。

验证

更新后就会收到消息

自动发现规则

在k8s中会部署非常多的service和 pod，如果要一个一个手动的添加监控非常麻烦且不必要，使用自动发现机制。将会减少很多不必要的工作。

创建 yaml 文件

创建prometheus-additional.yaml

cd prometheus/
cat prometheus-additional.yaml
- job_name: 'kubernetes-service-endpoints'
  kubernetes_sd_configs:
  - role: endpoints
  relabel_configs:
  - source_labels: [__meta_kubernetes_service_annotation_prometheus_io_scrape]
    action: keep
    regex: true
  - source_labels: [__meta_kubernetes_service_annotation_prometheus_io_scheme]
    action: replace
    target_label: __scheme__
    regex: (https?)
  - source_labels: [__meta_kubernetes_service_annotation_prometheus_io_path]
    action: replace
    target_label: __metrics_path__
    regex: (.+)
  - source_labels: [__address__, __meta_kubernetes_service_annotation_prometheus_io_port]
    action: replace
    target_label: __address__
    regex: ([^:]+)(?::\d+)?;(\d+)
    replacement: $1:$2
  - action: labelmap
    regex: __meta_kubernetes_service_label_(.+)
  - source_labels: [__meta_kubernetes_namespace]
    action: replace
    target_label: kubernetes_namespace
  - source_labels: [__meta_kubernetes_service_name]
    action: replace
    target_label: kubernetes_name

要想自动被发现，只需要在 service 的配置清单中加上 annotations: prometheus.io/scrape=true 。

创建 secret

然后用这个文件创建一个 secret

`1`	`kubectl -n monitoring create secret generic additional-config --from-file=prometheus-additional.yaml`

修改 prometheus 配置清单

在 prometheus 的配置清单中添加以下配置：

1
2
3

  additionalScrapeConfigs:
    name: additional-config
    key: prometheus-additional.yaml

具体如下：

cat prometheus-prometheus.yaml
apiVersion: monitoring.coreos.com/v1
kind: Prometheus
metadata:
  labels:
    app.kubernetes.io/component: prometheus
    app.kubernetes.io/name: prometheus
    app.kubernetes.io/part-of: kube-prometheus
    app.kubernetes.io/version: 2.26.0
    prometheus: k8s
  name: k8s
  namespace: monitoring
spec:
  alerting:
    alertmanagers:
    - apiVersion: v2
      name: alertmanager-main
      namespace: monitoring
      port: web
  externalLabels: {}
  image: quay.io/prometheus/prometheus:v2.26.0
  nodeSelector:
    kubernetes.io/os: linux
  podMetadata:
    labels:
      app.kubernetes.io/component: prometheus
      app.kubernetes.io/name: prometheus
      app.kubernetes.io/part-of: kube-prometheus
      app.kubernetes.io/version: 2.26.0
  podMonitorNamespaceSelector: {}
  podMonitorSelector: {}
  probeNamespaceSelector: {}
  probeSelector: {}
  replicas: 2
  resources:
    requests:
      memory: 400Mi
  ruleSelector:
    matchLabels:
      prometheus: k8s
      role: alert-rules
  securityContext:
    fsGroup: 2000
    runAsNonRoot: true
    runAsUser: 1000
  additionalScrapeConfigs:            # 添加内容
    name: additional-configs          # 添加内容
    key: prometheus-additional.yaml   # 添加内容
  serviceAccountName: prometheus-k8s
  serviceMonitorNamespaceSelector: {}
  serviceMonitorSelector: {}
  version: 2.26.0

然后更新 prometheus 的配置

`1`	`kubectl apply -f prometheus-prometheus.yaml`

修改 clusterrole 权限

Prometheus 绑定了一个名为 prometheus-k8s 的 ServiceAccount 对象，而这个对象绑定的是一个名为 prometheus-k8s 的 ClusterRole （prometheus-clusterRole.yaml）
需要让他有 Service 或者 Pod 的 list 权限

cat prometheus-clusterRole.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: prometheus-k8s
rules:
- apiGroups:
  - ""
  resources:
  - nodes/metrics
  - configmaps
  verbs:
  - get
- apiGroups:
  - ""
  resources:
  - nodes
  - pods
  - services
  - endpoints
  - nodes/proxy
  verbs:
  - get
  - list
  - watch
- nonResourceURLs:
  - /metrics
  verbs:
  - get

更新 clusterrole

`1`	`kubectl apply -f prometheus-clusterRole.yaml`

等待一段时间可以发现自动发现成功

配置自动发现，首先 annotations 里需要配置 prometheus.io/scrape=true ，其次你的应用要有 exporter 去收集信息。

  annotations:
    prometheus.io/scrape: 'true'    # 添加内容
    prometheus.io/path: '/metrics'  # 添加内容
    prometheus.io/port: '80'        # 添加内容

比如 Nginx 配置：

apiVersion: apps/v1     
kind: Deployment        
metadata:               
  name: nginx-deployment  
  labels:       
    app: nginx  
  annotations:
    prometheus.io/scrape: 'true'
    prometheus.io/path: '/metrics'
    prometheus.io/port: '80'
spec:           
  replicas: 2   
  selector:         
    matchLabels: 
      app: nginx
  minReadySeconds: 1
  progressDeadlineSeconds: 60
  revisionHistoryLimit: 2
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 1
  template:         
    metadata:   
      labels:   
        app: nginx
      annotations:
        prometheus.io/scrape: 'true'
        prometheus.io/path: '/metrics'
        prometheus.io/port: '80'
    spec:          
      containers:      
      - name: nginx   
        image: wenlongxue/nginx:waynex-ce995b8    
        imagePullPolicy: Always         
        ports:
        - containerPort: 80
        resources:
          requests:
            memory: "100Mi"
            cpu: "100m"
          limits: 
            memory: "100Mi" 
            cpu: "100m"
        readinessProbe:
          httpGet:
            path: /index.html
            port: 80
          periodSeconds: 5
          timeoutSeconds: 3
          successThreshold: 1
          failureThreshold: 30       
---
apiVersion: v1
kind: Service
metadata:      
  name: nginx-service 
  labels:       
    app: nginx  
  annotations:
    prometheus.io/scrape: 'true'    # 添加内容
    prometheus.io/path: '/metrics'  # 添加内容
    prometheus.io/port: '80'        # 添加内容
spec:       
  selector: 
    app: nginx
  ports:
  - name: nginx-port 
    protocol: TCP      
    port: 80           
    nodePort: 30081  
    targetPort: 80     
  type: NodePort

钉钉告警

配置 prometheus-operate 钉钉告警

创建 webhook 的配置文件

# vim dingTalk-webhook-configmap.yml
apiVersion: v1
kind: ConfigMap
metadata:
  namespace: monitoring
  name: dingtalk-webhook-config
data:
  config.yml: |
    # Request timeout
    timeout: 5s

    ## Customizable templates path
    templates:
    - /etc/prometheus-webhook-dingtalk/templates/*.tmpl

    ## You can also override default template using `default_message`
    ## The following example to use the 'legacy' template from v0.3.0
    # default_message:
    #   title: '{{ template "legacy.title" . }}'
    #   text: '{{ template "legacy.content" . }}'

    ## Targets, previously was known as "profiles"
    targets:
      guiji:
        url: https://oapi.dingtalk.com/robot/send?access_token=1a3ed90fefa5d1a8f4d61f063xxxxxxxxxxxxxxxxx
        message:
          title: '{{ template "ding.link.title" . }}'
          text: '{{ template "ding.link.content" . }}'
        mention:
          all: true
          mobiles: ['153xxxxxxxx']

创建告警模板配置文件：

# vim dingTalk-webhook-template.yml
apiVersion: v1
kind: ConfigMap
metadata:
  namespace: monitoring
  name: dingtalk-webhook-template
data:
  template.tmpl: |
    {{ define "__subject" }}[{{ .Status | toUpper }}{{ if eq .Status "firing" }}:{{ .Alerts.Firing | len }}{{ end }}] {{ .GroupLabels.SortedPairs.Values     | join " " }} {{ if gt (len .CommonLabels) (len .GroupLabels) }}({{ with .CommonLabels.Remove .GroupLabels.Names }}{{ .Values | join " " }}{{ end     }}){{ end }}{{ end }}
    {{ define "__alertmanagerURL" }}{{ .ExternalURL }}/#/alerts?receiver={{ .Receiver }}{{ end }}

    {{ define "__text_alert_list" }}{{ range . }}
    **Labels**
    {{ range .Labels.SortedPairs }}&gt; - {{ .Name }}: {{ .Value | markdown | html }}
    {{ end }}
    **Annotations**
    {{ range .Annotations.SortedPairs }}&gt; - {{ .Name }}: {{ .Value | markdown | html }}
    {{ end }}
    **Source:** [{{ .GeneratorURL }}]({{ .GeneratorURL }})
    {{ end }}{{ end }}

    {{ define "default.__text_alert_list" }}{{ range . }}
    ---
    **告警级别:** {{ .Labels.severity | upper }}

    **运营团队:** {{ .Labels.team | upper }}

    **触发时间:** {{ dateInZone "2006.01.02 15:04:05" (.StartsAt) "Asia/Shanghai" }}

    **事件信息:**
    {{ range .Annotations.SortedPairs }}&gt; - {{ .Name }}: {{ .Value | markdown | html }}

    {{ end }}

    **事件标签:**
    {{ range .Labels.SortedPairs }}{{ if and (ne (.Name) "severity") (ne (.Name) "summary") (ne (.Name) "team") }}&gt; - {{ .Name }}: {{ .Value |     markdown | html }}
    {{ end }}{{ end }}
    {{ end }}
    {{ end }}
    {{ define "default.__text_alertresovle_list" }}{{ range . }}
    ---
    **告警级别:** {{ .Labels.severity | upper }}

    **运营团队:** {{ .Labels.team | upper }}

    **触发时间:** {{ dateInZone "2006.01.02 15:04:05" (.StartsAt) "Asia/Shanghai" }}

    **结束时间:** {{ dateInZone "2006.01.02 15:04:05" (.EndsAt) "Asia/Shanghai" }}

    **事件信息:**
    {{ range .Annotations.SortedPairs }}&gt; - {{ .Name }}: {{ .Value | markdown | html }}

    {{ end }}

    **事件标签:**
    {{ range .Labels.SortedPairs }}{{ if and (ne (.Name) "severity") (ne (.Name) "summary") (ne (.Name) "team") }}&gt; - {{ .Name }}: {{ .Value |     markdown | html }}
    {{ end }}{{ end }}
    {{ end }}
    {{ end }}

    {{/* Default */}}
    {{ define "default.title" }}{{ template "__subject" . }}{{ end }}
    {{ define "default.content" }}#### \[{{ .Status | toUpper }}{{ if eq .Status "firing" }}:{{ .Alerts.Firing | len }}{{ end }}\] **[{{ index     .GroupLabels "alertname" }}]({{ template "__alertmanagerURL" . }})**
    {{ if gt (len .Alerts.Firing) 0 -}}

    ![警报 图标](https://ss0.bdstatic.com/70cFuHSh_Q1YnxGkpoWK1HF6hhy/it/u=3626076420,1196179712&amp;fm=15&amp;gp=0.jpg)
    **====侦测到故障====**
    {{ template "default.__text_alert_list" .Alerts.Firing }}

    {{- end }}

    {{ if gt (len .Alerts.Resolved) 0 -}}
    {{ template "default.__text_alertresovle_list" .Alerts.Resolved }}

    {{- end }}
    {{- end }}

    {{/* Legacy */}}
    {{ define "legacy.title" }}{{ template "__subject" . }}{{ end }}
    {{ define "legacy.content" }}#### \[{{ .Status | toUpper }}{{ if eq .Status "firing" }}:{{ .Alerts.Firing | len }}{{ end }}\] **[{{ index     .GroupLabels "alertname" }}]({{ template "__alertmanagerURL" . }})**
    {{ template "__text_alert_list" .Alerts.Firing }}
    {{- end }}

    {{/* Following names for compatibility */}}
    {{ define "ding.link.title" }}{{ template "default.title" . }}{{ end }}
    {{ define "ding.link.content" }}{{ template "default.content" . }}{{ end }}

创建 webhook 的资源配置清单

# cat dingTalk-webhook-deployment.yml
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  namespace: monitoring
  name: dingtalk-webhook
  labels:
    app: dingtalk-webhook
spec:
  selector:
    matchLabels:
      app: dingtalk-webhook
  replicas: 1
  template:
    metadata:
      labels:
        app: dingtalk-webhook
    spec:
      containers:
      - name: dingtalk-webhook
        image: harbor.zsf.com/public/prometheus-webhook-dingtalk
        args:
        - --config.file=/etc/prometheus-webhook-dingtalk/config.yml
        #- --ding.profile=guiji=https://oapi.dingtalk.com/robot/send?access_token=5752a9d10727165d116b883b4e7d312b781a3ed90
        ports:
        - containerPort: 8060
          protocol: TCP
        volumeMounts:
        - mountPath: "/etc/prometheus-webhook-dingtalk"
          name: dingtalk-webhook-confing
          subPath: config.yml
        - mountPath: "/etc/prometheus-webhook-dingtalk/templates"
          name: dingtalk-webhook-template
          subPath: template.tmpl
      volumes:
      - name: dingtalk-webhook-confing
        configMap:
          name: dingtalk-webhook-config
      - name: dingtalk-webhook-template
        configMap:
          name: dingtalk-webhook-template
---
apiVersion: v1
kind: Service
metadata:
  namespace: monitoring
  name: dingtalk-webhook
  labels:
    app: dingtalk-webhook
spec:
  selector:
    app: dingtalk-webhook
  ports:
  - name: http
    port: 8060
    targetPort: 8060
    protocol: TCP

解决ControllerManager、Scheduler监控问题

默认安装后访问 prometheus ，会发现有以下有三个报警：

Watchdog 、KubeControllerManagerDown 、 KubeSchedulerDown

Watchdog 是一个正常的报警，这个告警的作用是：如果 alermanger 或者 prometheus 本身挂掉了就发不出告警了，因此一般会采用另一个监控来监控 prometheus ，或者自定义一个持续不断的告警通知，哪一天这个告警通知不发了，说明监控出现问题了。 prometheus operator 已经考虑了这一点，本身携带一个 watchdog ，作为对自身的监控。

如果需要关闭，删除或注释掉 Watchdog 部分

vim kube-prometheus-prometheusRule.yaml
...
  - name: general.rules
    rules:
    - alert: TargetDown
      annotations:
        message: \'xxx\'
      expr: 100 * (count(up == 0) BY (job, namespace, service) / count(up) BY (job, namespace, service)) > 10
      for: 10m
      labels:
        severity: warning
#    - alert: Watchdog
#      annotations:
#        message: |
#          This is an alert meant to ensure that the entire alerting pipeline is functional.
#          This alert is always firing, therefore it should always be firing in Alertmanager
#          and always fire against a receiver. There are integrations with various notification
#          mechanisms that send a notification when this alert is not firing. For example the
#          "DeadMansSnitch" integration in PagerDuty.
#      expr: vector(1)
#      labels:
#        severity: none

其他两个 KubeControllerManagerDown 、 KubeSchedulerDown 需要自定义监控，在这边不详细说。

作者：SRE运维博客
博客地址：https://www.cnsre.cn
文章地址：https://www.cnsre.cn/posts/210621550392/
相关话题：https://www.cnsre.cn/tags/prometheus/

k8s 存活探针，滚动更新

Wenlong — Wed, 09 Jun 2021 12:16:22 +0800

作者：SRE运维博客
博客地址：https://www.cnsre.cn
文章地址：https://www.cnsre.cn/posts/210609216215/
相关话题：https://www.cnsre.cn/tags/kubernetes/

存活探针

Kubelet使用liveness probe（存活探针）来确定何时重启容器。例如，当应用程序处于运行状态但无法做进一步操作，liveness探针将捕获到deadlock，重启处于该状态下的容器，使应用程序在存在bug的情况下依然能够继续运行下去（谁的程序还没几个bug呢）。

Kubelet使用readiness probe（就绪探针）来确定容器是否已经就绪可以接受流量。只有当Pod中的容器都处于就绪状态时kubelet才会认定该Pod处于就绪状态。该信号的作用是控制哪些Pod应该作为service的后端。如果Pod处于非就绪状态，那么它们将会被从service的load balancer中移除。

重启策略（RestartPolicy ）

Always：当容器终止退出后，总是重启容器，默认策略。
OnFailure：当容器异常退出（退出状态码非0）时，才重启容器。
Never：当容器终止退出，从不重启容器。

probe有以下两种类型：

livenessProbe：如果检查失败，将杀死容器，根据Pod的restartPolicy来操作。
readinessProbe：如果检查失败，Kubernetes会把Pod从service endpoints中剔除

Probe支持以下三种检查方法：

httpGet：发送HTTP请求，返回200-400范围状态码为成功。
exec：执行Shell命令返回状态码是0为成功。
tcpSocket：发起TCP Socket建立成功。

健康检查的方法

方法一 httpGet

nginx使用httpGet健康检查的方法

复制代码apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx
spec:
  replicas: 1
  selector:
    matchLabels:
      app: nginx
  minReadySeconds: 1
  progressDeadlineSeconds: 60
  revisionHistoryLimit: 2
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 1
  template:
    metadata:
      name: nginx
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.19
        ports:
        - containerPort: 80
        resources:
          requests:
            memory: "500Mi"
            cpu: "250m"
          limits: 
            memory: "500Mi" 
            cpu: "500m"
       livenessProbe:
           httpGet:
             path: /index.html
             port: 80
           initialDelaySeconds: 10  #pod启动10秒执行第一次检查
           periodSeconds: 5         #第一次检查后每隔5秒检查一次**
        volumeMounts:
        - name: html
          mountPath: /usr/share/nginx/html
      volumes:
      - name: html
        hostPath:
          path: /home/k8s/data/nginx
---
apiVersion: v1
kind: Service
metadata:
  name: nginx
spec:
  type: NodePort
  ports:
   - port: 8080
     nodePort: 30080
  selector:
    app: nginx

方法二：tcpSocket

nginx使用tcpSocket健康检查的方法

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx
spec:
  replicas: 1
  selector:
    matchLabels:
      app: nginx
  minReadySeconds: 1
  progressDeadlineSeconds: 60
  revisionHistoryLimit: 2
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 1
  template:
    metadata:
      name: nginx
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.19
        ports:
        - containerPort: 80
        resources:
          requests:
            memory: "500Mi"
            cpu: "250m"
          limits: 
            memory: "500Mi" 
            cpu: "500m"
        livenessProbe:
           tcpSocket:
             port: 80
           initialDelaySeconds: 10
           periodSeconds: 5
        volumeMounts:
        - name: html
          mountPath: /usr/share/nginx/html
      volumes:
      - name: html
        hostPath:
          path: /home/k8s/data/nginx
---
apiVersion: v1
kind: Service
metadata:
  name: nginx
spec:
  type: NodePort
  ports:
   - port: 8080
     nodePort: 30080
  selector:
    app: nginx

滚动发布

k8s创建副本应用程序的最佳方法就是部署(Deployment)，部署自动创建副本集(ReplicaSet)，副本集可以精确地控制每次替换的Pod数量，从而可以很好的实现滚动更新。具体来说，k8s每次使用一个新的副本控制器(replication controller)来替换已存在的副本控制器，从而始终使用一个新的Pod模板来替换旧的pod模板。
步骤如下:

创建一个新的replication controller。
增加或减少pod副本数量，直到满足当前批次期望的数量。
删除旧的replication controller

实战练习

Q：假如一个nginx服务起了3个pod，我做了发版，然后没想到这次发版有问题。健康检查也没过！这种情况下发布，会把3个pod都替换掉？还是说检测到一个pod健康检查有问题，下一个就pod就不发布了？已经发布的pod会对外提供服务吗？
带着这些疑问，来做个实验。

创建nginx服务

创建一个nginx服务，选择1个副本。

具体yaml如下

apiVersion: apps/v1
kind: Deployment        
metadata:
  name: nginx-deployment
  labels:           
    app: nginx  
spec:            
  replicas: 1    
  selector:       
    matchLabels:  
      app: nginx
  minReadySeconds: 1
  progressDeadlineSeconds: 60
  revisionHistoryLimit: 2
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 1
  template:      
    metadata:    
      labels:    
        app: nginx
    spec:         
      containers:  
      - name: nginx   
        image: wenlongxue/xxxx:6f965dd    # 需要修改自己的镜像
        imagePullPolicy: Always           
        ports:
        - containerPort: 80
        resources:
          requests:
            memory: "600Mi"
            cpu: "250m"
          limits: 
            memory: "600Mi" 
            cpu: "500m"
        readinessProbe:
          httpGet:
            path: /actuator/health
            port: 80
          periodSeconds: 5
          timeoutSeconds: 3
          successThreshold: 1
          failureThreshold: 30     
---
apiVersion: v1
kind: Service
metadata:      
  name: nginx-service 
  labels:        
    app: nginx   
spec:        
  selector:    
    app: nginx  
  ports:
  - name: nginx-port 
    protocol: TCP     
    port: 80           
    nodePort: 30081    
    targetPort: 80      
  type: NodePort

查看当前pod

另起一个窗口

`1`	`kubectl get pods -l app=nginx -w`

发布健康检查有问题的版本

修改yaml
将副本数replicas: 1 设置为replicas: 3
将健康检查path: / 修改为一个不存在的静态页面，这样健康检查就不过了。
具体代码

...
spec:            
  replicas: 3  
...
        readinessProbe:
          httpGet:
            path: /cnsre.html
            port: 80
          periodSeconds: 5
          timeoutSeconds: 3
          successThreshold: 1
          failureThreshold: 30

执行滚动发布并观察

执行更新滚动发布

`1`	`kubectl apply -f nginx.yaml`

查看pod状态

`1`	`kubectl get pods -l app=nginx`

观察滚动更新过程

`1`	`kubectl get pods -l app=nginx -w`

健康检查滚动发布实验结果

通过实验发现，新发版，健康检查没过！这种情况下发布，会把之前的pod保留，新发布的pod 运行，但是不对外提供服务。
带着这些疑问，来做个实验。

作者：SRE运维博客
博客地址：https://www.cnsre.cn
文章地址：https://www.cnsre.cn/posts/210609216215/
相关话题：https://www.cnsre.cn/tags/kubernetes/

kubernetes使用jenkins Pipeline 部署Nginx

Wenlong — Tue, 08 Jun 2021 16:07:30 +0800

作者：SRE运维博客
博客地址：https://www.cnsre.cn
文章地址：https://www.cnsre.cn/posts/210608607296/
相关话题：https://www.cnsre.cn/tags/kubernetes/

环境需求

kubernetes 未安装参考使用kubeadm安装kubernetes 1.21
jenkins
github/gitee/gitlab 静态页面
镜像仓库(我使用的 hub.docker)
如果你未准备好的以上环境，点击链接参考文章进行安装。

安装 jenkins

我这边的jenkins是将jenkins 安装在了k8s的宿主机中，并没有用容器运行。

安装JDK

`1`	`yum install -y java`

安装jenkins

方法1 添加Jenkins库到yum库，Jenkins将从这里下载安装。

1
2
3

wget -O /etc/yum.repos.d/jenkins.repo http://pkg.jenkins-ci.org/redhat/jenkins.repo
rpm --import https://jenkins-ci.org/redhat/jenkins-ci.org.key
yum install -y jenkins

方法2 如果不能安装就到官网下载jenkis的rmp包，官网地址（http://pkg.jenkins-ci.org/redhat-stable/）

1
2

wget http://pkg.jenkins-ci.org/redhat-stable/jenkins-2.7.3-1.1.noarch.rpm
rpm -ivh jenkins-2.7.3-1.1.noarch.rpm

安装 Jenkins 插件

安装完jenkins，设置完密码，安装完默认插件以后，我们需要安装 Pipeline 需要的插件。

修改下方地址然后提交

1
2
3

# jenkins插件清华大学镜像地址
https://mirrors.tuna.tsinghua.edu.cn/jenkins/updates/update-center.json
http://mirror.xmission.com/jenkins/updates/update-center.json

安装git和pipeline插件

创建 jenkins Pipeline

添加Pipeline job

创建job完成后，配置Pipeline script，点击Pipeline语法，来自动生成我们需要的配置。

如下图，我们Git方式，配置Git仓库地址，再添加认证相关。

分别填写github/gitee的账号和密码然后点击添加

添加完成后，在凭据中，选中刚添加的，这样我们就可以生成Pipeline脚本了。点击下方生成流水线脚本，然后复制方框内的内容。

编写 Pipeline 脚本

编写我们所需要的Pipeline脚本如下，将其粘贴到script的拉取代码模块中，并修改分支master为${branch}，其他模块内容自行编写。
文章链接

node {
   stage('拉取代码') { 
    //拉取代码
    git credentialsId: 'b34b0b78-e99f-4aa0-a616-xxxxxx', url: 'https://gitee.com/xxx/xxxxx.git'
    //将上次打包的代删除掉，并将拉取到的新代码代码打包
    sh 'rm -rf *.tar && cd waynex &&  tar -cvf waynex.tar ./*'
    script {
    //获取comment id
    env.imageTag = sh (script: 'git rev-parse --short HEAD ${GIT_COMMIT}', returnStdout: true).trim()
}
   }
   // 项目打包到镜像并推送到镜像仓库
   stage('构建推送镜像') {
sh '''
REPOSITORY=wenlongxue/waynex:${imageTag}
cat > Dockerfile << EOF
FROM wenlongxue/nginx

## 设置工作目录
WORKDIR /usr/local/nginx/html

RUN  rm -rf /usr/local/nginx/html/* 
ADD  waynex/waynex.tar  /usr/local/nginx/html/

## 启动nginx
CMD ["nginx","-g","daemon off;"]
EOF

docker build -t waynex:${imageTag} .
docker login
docker tag waynex:${imageTag} $REPOSITORY
docker push $REPOSITORY
'''
   }
   // 部署到k8s主机
   stage('部署到k8s') 
{
sh '''
REPOSITORY=wenlongxue/waynex:${imageTag}
cat > nginx.yaml << EOF
apiVersion: apps/v1           #与k8s集群版本有关，使用 kubectl api-versions 即可查看当前集群支持的版本
kind: Deployment              #该配置的类型，我们使用的是 Deployment
metadata:                     #译名为元数据，即 Deployment 的一些基本属性和信息
  name: nginx-deployment      #Deployment 的名称
  labels:                     #标签，可以灵活定位一个或多个资源，其中key和value均可自定义，可以定义多组，目前不需要理解
    app: nginx                #为该Deployment设置key为app，value为nginx的标签
spec:                         #这是关于该Deployment的描述，可以理解为你期待该Deployment在k8s中如何使用
  replicas: 1                 #使用该Deployment创建一个应用程序实例
  selector:                   #标签选择器，与上面的标签共同作用，目前不需要理解
    matchLabels:              #选择包含标签app:nginx的资源
      app: nginx
  minReadySeconds: 1
  progressDeadlineSeconds: 60
  revisionHistoryLimit: 2
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 1
  template:                   #这是选择或创建的Pod的模板
    metadata:                 #Pod的元数据
      labels:                 #Pod的标签，上面的selector即选择包含标签app:nginx的Pod
        app: nginx
    spec:                     #期望Pod实现的功能（即在pod中部署）
      containers:             #生成container，与docker中的container是同一种
      - name: nginx           #container的名称
        image: \$REPOSITORY   #使用之前推送的镜像
        imagePullPolicy: Always #总是拉取最新的。默认为,本地有则使用本地镜像,不拉取
        ports:
        - containerPort: 80
        resources:
          requests:
            memory: "600Mi"
            cpu: "250m"
          limits: 
            memory: "600Mi" 
            cpu: "500m"
        livenessProbe:
           httpGet:
             path: /
             port: 80
           initialDelaySeconds: 10  #pod启动10秒执行第一次检查
           periodSeconds: 5         #第一次检查后每隔5秒检查一次
---
apiVersion: v1
kind: Service
metadata:                           #译名为元数据，即Deployment的一些基本属性和信息
  name: nginx-service               #Service 的名称
  labels:                           #标签，可以灵活定位一个或多个资源，其中key和value均可自定义，可以定义多组
    app: nginx                      #为该Deployment设置key为app，value为nginx的标签
spec:                               #这是关于该 Service 的定义，描述了 Service 如何选择 Pod，如何被访问
  selector:                         #标签选择器
    app: nginx                      #选择包含标签 app:nginx 的 Pod
  ports:
  - name: nginx-port                #端口的名字
    protocol: TCP                   #协议类型 TCP/UDP
    port: 80                        #集群内的其他容器组可通过 80 端口访问 Service
    nodePort: 30081                 #通过任意节点的 30080 端口访问 Service
    targetPort: 80                  #将请求转发到匹配 Pod 的 80 端口
  type: NodePort                    #Serive的类型，ClusterIP/NodePort/LoaderBalancer
EOF
sudo kubectl  apply -f  nginx.yaml
'''
   }
}

在Pipeline脚本里面我们指定了一个branch参数，所以我们需要传递一个参数变量，这里我们选择参数化构建，默认值为master分支。

然后保存配置。

发布测试

回到主界面，我们开始构建任务：

查看构建成功后的图形构建过程：

通过浏览器来访问项目：http://你的IP:30080/
至此部署完成

作者：SRE运维博客
博客地址：https://www.cnsre.cn
文章地址：https://www.cnsre.cn/posts/210608607296/
相关话题：https://www.cnsre.cn/tags/kubernetes/

kubernetes部署一个应用程序

Wenlong — Thu, 03 Jun 2021 10:28:46 +0800

作者：SRE运维博客
博客地址：https://www.cnsre.cn
文章地址：https://www.cnsre.cn/posts/210603028465/
相关话题：https://www.cnsre.cn/tags/kubernetes/

部署 nginx Deployment

如果你已经完成了Kubernetes的搭建，那我跟我一块来部署第一个应用程序吧。没有完成 Kubernetes 集群搭建的，请参考文档使用 kubeadm 安装 kubernetes 1.21

创建 YAML 文件

创建文件 nginx-deploy.yaml，内容如下：

apiVersion: apps/v1	#与k8s集群版本有关，使用 kubectl api-versions 即可查看当前集群支持的版本
kind: Deployment	#该配置的类型，我们使用的是 Deployment
metadata:	        #译名为元数据，即 Deployment 的一些基本属性和信息
  name: nginx-deployment	#Deployment 的名称
  labels:	    #标签，可以灵活定位一个或多个资源，其中key和value均可自定义，可以定义多组，目前不需要理解
    app: nginx	#为该Deployment设置key为app，value为nginx的标签
spec:	        #这是关于该Deployment的描述，可以理解为你期待该Deployment在k8s中如何使用
  replicas: 1	#使用该Deployment创建一个应用程序实例
  selector:	    #标签选择器，与上面的标签共同作用，目前不需要理解
    matchLabels: #选择包含标签app:nginx的资源
      app: nginx
  template:	    #这是选择或创建的Pod的模板
    metadata:	#Pod的元数据
      labels:	#Pod的标签，上面的selector即选择包含标签app:nginx的Pod
        app: nginx
    spec:	    #期望Pod实现的功能（即在pod中部署）
      containers:	#生成container，与docker中的container是同一种
      - name: nginx	#container的名称
        image: nginx:1.7.9	#使用镜像nginx:1.7.9创建container，该container默认80端口可访问

应用 YAML 文件

`1`	`kubectl apply -f nginx-deploy.yaml`

查看部署结果

# 查看 Deployment
kubectl get deployments

# 查看 Pod
kubectl get pods

如上图可分别查看到一个名为 nginx-deployment 的 Deployment 和一个名为 nginx-deployment-xxxxxxx 的 Pod

kubectl 常用命令

kubectl get

显示资源列表

# kubectl get 资源类型

#获取类型为Deployment的资源列表
kubectl get deployments

#获取类型为Pod的资源列表
kubectl get pods

#获取类型为Node的资源列表
kubectl get nodes

名称空间

在命令后增加 -A 或 –all-namespaces 可查看所有名称空间中的对象，使用参数 -n 可查看指定名称空间的对象，例如

# 查看所有名称空间的 Deployment
kubectl get deployments -A
kubectl get deployments --all-namespaces
# 查看 kube-system 名称空间的 Deployment
kubectl get deployments -n kube-system

kubectl describe

显示有关资源的详细信息

# kubectl describe 资源类型 资源名称

#查看名称为nginx-XXXXXX的Pod的信息
kubectl describe pod nginx-XXXXXX	

#查看名称为nginx的Deployment的信息
kubectl describe deployment nginx

kubectl logs

查看pod中的容器的打印日志

# kubectl logs Pod名称

#查看名称为nginx-pod-XXXXXXX的Pod内的容器打印的日志
#本案例中的 nginx-pod 没有输出日志，所以您看到的结果是空的
kubectl logs -f nginx-pod-XXXXXXX

kubectl exec

在pod中的容器环境内执行命令

# kubectl exec Pod名称 操作命令

# 在名称为nginx-pod-xxxxxx的Pod中运行bash
kubectl exec -it nginx-pod-xxxxxx /bin/bash

为nginx Deployment 创建 Service

创建文件 nginx-service.yaml

apiVersion: v1
kind: Service
metadata:	#译名为元数据，即Deployment的一些基本属性和信息
  name: nginx-service	#Service 的名称
  labels:	#标签，可以灵活定位一个或多个资源，其中key和value均可自定义，可以定义多组
    app: nginx	#为该Deployment设置key为app，value为nginx的标签
spec:	    #这是关于该 Service 的定义，描述了 Service 如何选择 Pod，如何被访问
  selector:	    #标签选择器
    app: nginx	#选择包含标签 app:nginx 的 Pod
  ports:
  - name: nginx-port	#端口的名字
    protocol: TCP	    #协议类型 TCP/UDP
    port: 80	        #集群内的其他容器组可通过 80 端口访问 Service
    nodePort: 30080   #通过任意节点的 30080 端口访问 Service
    targetPort: 80	#将请求转发到匹配 Pod 的 80 端口
  type: NodePort	#Serive的类型，ClusterIP/NodePort/LoaderBalancer

执行命令

`1`	`kubectl apply -f nginx-service.yaml`

检查执行结果

`1`	`kubectl get services -o wide`

如上图可查看到名称为 nginx-service 的服务。

访问服务

`1`	`curl <任意节点的 IP>:30080`

伸缩应用程序

伸缩的实现可以通过更改 nginx-deployment.yaml 文件中部署的 replicas（副本数）来完成

1
2

spec:
  replicas: 2    #使用该Deployment创建两个应用程序实例

修改 nginx-deploy.yaml 文件

apiVersion: apps/v1     #与k8s集群版本有关，使用 kubectl api-versions 即可查看当前集群支持的版本
kind: Deployment        #该配置的类型，我们使用的是 Deployment
metadata:               #译名为元数据，即 Deployment 的一些基本属性和信息
  name: nginx-deployment        #Deployment 的名称
  labels:           #标签，可以灵活定位一个或多个资源，其中key和value均可自定义，可以定义多组，目前不需要理解
    app: nginx  #为该Deployment设置key为app，value为nginx的标签
spec:           #这是关于该Deployment的描述，可以理解为你期待该Deployment在k8s中如何使用
  replicas: 2   #使用该Deployment创建一个应用程序实例
  selector:         #标签选择器，与上面的标签共同作用，目前不需要理解
    matchLabels: #选择包含标签app:nginx的资源
      app: nginx
  template:         #这是选择或创建的Pod的模板
    metadata:   #Pod的元数据
      labels:   #Pod的标签，上面的selector即选择包含标签app:nginx的Pod
        app: nginx
    spec:           #期望Pod实现的功能（即在pod中部署）
      containers:       #生成container，与docker中的container是同一种
      - name: nginx     #container的名称
        image: nginx:1.7.9      #使用镜像nginx:1.7.9创建container，该container默认80端口可访问

执行命令

`1`	`kubectl apply -f nginx-deployment.yaml`

查看结果

`1`	`watch kubectl get pods -o wide`

如上图，你将会看到有两个应用程序在运行，运行了多个应用程序实例，可以在不停机的情况下执行滚动更新。

滚动更新

滚动更新允许以下操作：

将应用程序从准上线环境升级到生产环境（通过更新容器镜像）
回滚到以前的版本
持续集成和持续交付应用程序，无需停机
如果需要滚动更新执行如下命令即可

`1`	`kubectl apply -f nginx-deployment.yaml`

查看过程及结果
执行命令，可观察到 pod 逐个被替换的过程。

`1`	`watch kubectl get pods -l app=nginx`

作者：SRE运维博客
博客地址：https://www.cnsre.cn
文章地址：https://www.cnsre.cn/posts/210603028465/
相关话题：https://www.cnsre.cn/tags/kubernetes/

使用kubeadm安装kubernetes 1.21

Wenlong — Wed, 02 Jun 2021 10:36:12 +0800

作者：SRE运维博客
博客地址：https://www.cnsre.cn
文章地址：https://www.cnsre.cn/posts/210602036084/
相关话题：https://www.cnsre.cn/tags/kubernetes/

配置要求

至少2台 2核4G 的服务器
本文档中，CPU必须为 x86架构
CentOS 7.8 或 CentOS Stream 8

安装后的软件版本为

Kubernetes v1.21.x
- calico 3.17.1
- nginx-ingress 1.9.1
Containerd.io 1.4.3

操作系统兼容性

CentOS版本	本文档是否兼容	备注
CentOS Stream 8	😄	已验证
CentOS 7.8	😄	已验证
CentOS 7.7	😞	未验证
CentOS 7.6	😞	未验证

Kubernetes v1.21 开始，默认移除 docker 的依赖，如果宿主机上安装了 docker 和 containerd，将优先使用 docker 作为容器运行引擎，如果宿主机上未安装 docker 只安装了 containerd，将使用 containerd 作为容器运行引擎；
本文使用 containerd 作为容器运行引擎；

kubeadm 是 Kubernetes 官方支持的安装方式，“二进制” 不是。本文档采用 kubernetes.io 官方推荐的 kubeadm 工具安装 kubernetes 集群。

检查 centos / hostname

# 在 master 节点和 worker 节点都要执行
cat /etc/redhat-release

# 此处 hostname 的输出将会是该机器在 Kubernetes 集群中的节点名字
# 不能使用 localhost 作为节点的名字
hostname

# 请使用 lscpu 命令，核对 CPU 信息
# Architecture: x86_64    本安装文档不支持 arm 架构
# CPU(s):       2         CPU 内核数量不能低于 2
lscpu

修改 hostname

# 修改 hostname
hostnamectl set-hostname your-new-host-name
# 查看修改结果
hostnamectl status
# 设置 hostname 解析
echo "127.0.0.1   $(hostname)" >> /etc/hosts

检查网络

在所有节点执行命令

[root@demo-master-a-1 ~]$ ip route show
default via 172.21.0.1 dev eth0 
169.254.0.0/16 dev eth0 scope link metric 1002 
172.21.0.0/20 dev eth0 proto kernel scope link src 172.21.0.12 

[root@demo-master-a-1 ~]$ ip address
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 00:16:3e:12:a4:1b brd ff:ff:ff:ff:ff:ff
    inet 172.17.216.80/20 brd 172.17.223.255 scope global dynamic eth0
       valid_lft 305741654sec preferred_lft 305741654sec

ip route show 命令中，可以知道机器的默认网卡，通常是 eth0，如 default via 172.21.0.23 dev eth0
ip address 命令中，可显示默认网卡的 IP 地址，Kubernetes 将使用此 IP 地址与集群内的其他节点通信，如 172.17.216.80
所有节点上 Kubernetes 所使用的 IP 地址必须可以互通（无需 NAT 映射、无安全组或防火墙隔离）

安装

使用 root 身份在所有节点执行如下代码，以安装软件：

containerd
nfs-utils
kubectl / kubeadm / kubelet

请将脚本最后的 1.21.0 替换成您需要的版本号（必须是 1.21 的小版本，不能是 1.19.1 等） 脚本中间的 v1.21.x 不要替换

docker hub 镜像请根据自己网络的情况任选一个

第四行为腾讯云 docker hub 镜像
第六行为DaoCloud docker hub 镜像
第八行为华为云 docker hub 镜像
第十行为阿里云 docker hub 镜像

# 在 master 节点和 worker 节点都要执行
# 最后一个参数 1.21.0 用于指定 kubenetes 版本，支持所有 1.21.x 版本的安装
# 腾讯云 docker hub 镜像
# export REGISTRY_MIRROR="https://mirror.ccs.tencentyun.com"
# DaoCloud 镜像
# export REGISTRY_MIRROR="http://f1361db2.m.daocloud.io"
# 华为云镜像
# export REGISTRY_MIRROR="https://05f073ad3c0010ea0f4bc00b7105ec20.mirror.swr.myhuaweicloud.com"
# 阿里云 docker hub 镜像
export REGISTRY_MIRROR=https://registry.cn-hangzhou.aliyuncs.com
curl -sSL https://kuboard.cn/install-script/v1.21.x/install_kubelet.sh | sh -s 1.21.0

手动执行以下代码，结果与快速安装相同。 请将脚本第79行（已高亮）的 ${1} 替换成您需要的版本号，例如 1.21.0

docker hub 镜像请根据自己网络的情况任选一个

第四行为腾讯云 docker hub 镜像
第六行为DaoCloud docker hub 镜像
第八行为阿里云 docker hub 镜像

# 在 master 节点和 worker 节点都要执行
# 最后一个参数 1.21.0 用于指定 kubenetes 版本，支持所有 1.21.x 版本的安装
# 腾讯云 docker hub 镜像
# export REGISTRY_MIRROR="https://mirror.ccs.tencentyun.com"
# DaoCloud 镜像
# export REGISTRY_MIRROR="http://f1361db2.m.daocloud.io"
# 阿里云 docker hub 镜像
export REGISTRY_MIRROR=https://registry.cn-hangzhou.aliyuncs.com

#!/bin/bash

# 在 master 节点和 worker 节点都要执行

# 安装 containerd
# 参考文档如下
# https://kubernetes.io/docs/setup/production-environment/container-runtimes/#containerd

cat <<EOF | sudo tee /etc/modules-load.d/containerd.conf
overlay
br_netfilter
EOF

sudo modprobe overlay
sudo modprobe br_netfilter

# Setup required sysctl params, these persist across reboots.
cat <<EOF | sudo tee /etc/sysctl.d/99-kubernetes-cri.conf
net.bridge.bridge-nf-call-iptables  = 1
net.ipv4.ip_forward                 = 1
net.bridge.bridge-nf-call-ip6tables = 1
EOF

# Apply sysctl params without reboot
sysctl --system

# 卸载旧版本
yum remove -y containerd.io

# 设置 yum repository
yum install -y yum-utils device-mapper-persistent-data lvm2
yum-config-manager --add-repo https://download.docker.com/linux/centos/docker-ce.repo

# 安装 containerd
yum install -y containerd.io-1.4.3

mkdir -p /etc/containerd
containerd config default > /etc/containerd/config.toml

sed -i "s#k8s.gcr.io#registry.aliyuncs.com/k8sxio#g"  /etc/containerd/config.toml
sed -i '/containerd.runtimes.runc.options/a\ \ \ \ \ \ \ \ \ \ \ \ SystemdCgroup = true' /etc/containerd/config.toml
sed -i "s#https://registry-1.docker.io#${REGISTRY_MIRROR}#g"  /etc/containerd/config.toml


systemctl daemon-reload
systemctl enable containerd
systemctl restart containerd


# 安装 nfs-utils
# 必须先安装 nfs-utils 才能挂载 nfs 网络存储
yum install -y nfs-utils
yum install -y wget

# 关闭 防火墙
systemctl stop firewalld
systemctl disable firewalld

# 关闭 SeLinux
setenforce 0
sed -i "s/SELINUX=enforcing/SELINUX=disabled/g" /etc/selinux/config

# 关闭 swap
swapoff -a
yes | cp /etc/fstab /etc/fstab_bak
cat /etc/fstab_bak |grep -v swap > /etc/fstab

# 配置K8S的yum源
cat <<EOF > /etc/yum.repos.d/kubernetes.repo
[kubernetes]
name=Kubernetes
baseurl=http://mirrors.aliyun.com/kubernetes/yum/repos/kubernetes-el7-x86_64
enabled=1
gpgcheck=0
repo_gpgcheck=0
gpgkey=http://mirrors.aliyun.com/kubernetes/yum/doc/yum-key.gpg
       http://mirrors.aliyun.com/kubernetes/yum/doc/rpm-package-key.gpg
EOF

# 卸载旧版本
yum remove -y kubelet kubeadm kubectl

# 安装kubelet、kubeadm、kubectl
# 将 ${1} 替换为 kubernetes 版本号，例如 1.20.1
yum install -y kubelet-${1} kubeadm-${1} kubectl-${1}

crictl config runtime-endpoint /run/containerd/containerd.sock

# 重启 docker，并启动 kubelet
systemctl daemon-reload
systemctl enable kubelet && systemctl start kubelet

containerd --version
kubelet --version

如果此时执行 systemctl status kubelet 命令，将得到 kubelet 启动失败的错误提示，请忽略此错误，因为必须完成后续步骤中 kubeadm init 的操作，kubelet 才能正常启动

初始化 master 节点

APISERVER_NAME 不能是 master 的 hostname
APISERVER_NAME 必须全为小写字母、数字、小数点，不能包含减号
POD_SUBNET 所使用的网段不能与 master节点/worker节点所在的网段重叠。该字段的取值为一个 CIDR 值，如果您对 CIDR 这个概念还不熟悉，请仍然执行 export POD_SUBNET=10.100.0.1/16 命令，不做修改

请将脚本最后的 1.21.0 替换成您需要的版本号（必须是 1.21 的小版本，不能是 1.19.1 等） 脚本中间的 v1.21.x 不要替换

# 只在 master 节点执行
# 替换 x.x.x.x 为 master 节点实际 IP（请使用内网 IP）
# export 命令只在当前 shell 会话中有效，开启新的 shell 窗口后，如果要继续安装过程，请重新执行此处的 export 命令
export MASTER_IP=x.x.x.x
# 替换 apiserver.demo 为 您想要的 dnsName
export APISERVER_NAME=apiserver.demo
# Kubernetes 容器组所在的网段，该网段安装完成后，由 kubernetes 创建，事先并不存在于您的物理网络中
export POD_SUBNET=10.100.0.1/16
echo "${MASTER_IP}    ${APISERVER_NAME}" >> /etc/hosts
curl -sSL https://kuboard.cn/install-script/v1.21.x/init_master.sh | sh -s 1.21.0

手动执行以下代码，结果与快速安装相同。 请将脚本第79行（已高亮）的 ${1} 替换成您需要的版本号，例如 1.21.0

# 只在 master 节点执行
# 替换 x.x.x.x 为 master 节点的内网IP
# export 命令只在当前 shell 会话中有效，开启新的 shell 窗口后，如果要继续安装过程，请重新执行此处的 export 命令
export MASTER_IP=x.x.x.x
# 替换 apiserver.demo 为 您想要的 dnsName
export APISERVER_NAME=apiserver.demo
# Kubernetes 容器组所在的网段，该网段安装完成后，由 kubernetes 创建，事先并不存在于您的物理网络中
export POD_SUBNET=10.100.0.1/16
echo "${MASTER_IP}    ${APISERVER_NAME}" >> /etc/hosts

#!/bin/bash

# 只在 master 节点执行

# 脚本出错时终止执行
set -e

if [ ${#POD_SUBNET} -eq 0 ] || [ ${#APISERVER_NAME} -eq 0 ]; then
  echo -e "\033[31;1m请确保您已经设置了环境变量 POD_SUBNET 和 APISERVER_NAME \033[0m"
  echo 当前POD_SUBNET=$POD_SUBNET
  echo 当前APISERVER_NAME=$APISERVER_NAME
  exit 1
fi


# 查看完整配置选项 https://godoc.org/k8s.io/kubernetes/cmd/kubeadm/app/apis/kubeadm/v1beta2
rm -f ./kubeadm-config.yaml
cat <<EOF > ./kubeadm-config.yaml
---
apiVersion: kubeadm.k8s.io/v1beta2
kind: ClusterConfiguration
kubernetesVersion: v${1}
imageRepository: registry.aliyuncs.com/k8sxio
controlPlaneEndpoint: "${APISERVER_NAME}:6443"
networking:
  serviceSubnet: "10.96.0.0/16"
  podSubnet: "${POD_SUBNET}"
  dnsDomain: "cluster.local"
dns:
  type: CoreDNS
  imageRepository: swr.cn-east-2.myhuaweicloud.com${2}
  imageTag: 1.8.0

---
apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
cgroupDriver: systemd
EOF

# kubeadm init
# 根据您服务器网速的情况，您需要等候 3 - 10 分钟
echo ""
echo "抓取镜像，请稍候..."
kubeadm config images pull --config=kubeadm-config.yaml
echo ""
echo "初始化 Master 节点"
kubeadm init --config=kubeadm-config.yaml --upload-certs

# 配置 kubectl
rm -rf /root/.kube/
mkdir /root/.kube/
cp -i /etc/kubernetes/admin.conf /root/.kube/config

# 安装 calico 网络插件
# 参考文档 https://docs.projectcalico.org/v3.13/getting-started/kubernetes/self-managed-onprem/onpremises
echo ""
echo "安装calico-3.17.1"
rm -f calico-3.17.1.yaml
kubectl create -f https://kuboard.cn/install-script/v1.21.x/calico-operator.yaml
wget https://kuboard.cn/install-script/v1.21.x/calico-custom-resources.yaml
sed -i "s#192.168.0.0/16#${POD_SUBNET}#" calico-custom-resources.yaml
kubectl create -f calico-custom-resources.yaml

检查 master 初始化结果

# 只在 master 节点执行

# 执行如下命令，等待 3-10 分钟，直到所有的容器组处于 Running 状态
watch kubectl get pod -n kube-system -o wide

# 查看 master 节点初始化结果
kubectl get nodes -o wide

初始化 worker节点

获得 join命令参数

在 master 节点上执行

# 只在 master 节点执行
kubeadm token create --print-join-command
# 返回如下
kubeadm join apiserver.demo:6443 --token 9ukzcs.qp4ozxbn1knc13sx --discovery-token-ca-cert-hash sha256:0cb945ea0c6329b4df58cf358e2be697fd31a85f55c23d47356f06f69a27283d

该 token 的有效时间为 2 个小时，2小时内，您可以使用此 token 初始化任意数量的 worker 节点。

初始化worker

针对所有的 worker 节点执行

# 只在 worker 节点执行
# 替换 x.x.x.x 为 master 节点的内网 IP
export MASTER_IP=x.x.x.x
# 替换 apiserver.demo 为初始化 master 节点时所使用的 APISERVER_NAME
export APISERVER_NAME=apiserver.demo
echo "${MASTER_IP}    ${APISERVER_NAME}" >> /etc/hosts

# 替换为 master 节点上 kubeadm token create 命令的输出
kubeadm join apiserver.demo:6443 --token 9ukzcs.qp4ozxbn1knc13sx --discovery-token-ca-cert-hash sha256:0cb945ea0c6329b4df58cf358e2be697fd31a85f55c23d47356f06f69a27283d

检查初始化结果

在 master 节点上执行

# 只在 master 节点执行
kubectl get nodes -o wide
# 输出结果如下所示
[root@master ~]# kubectl get nodes
NAME     STATUS   ROLES                  AGE   VERSION
master   Ready    control-plane,master   54m   v1.21.0
node1    Ready    <none>                 35m   v1.21.0

安装 Ingress Controller

在 master 节点上执行
部分情况下，下面的这条指令，您需要执行两次才能成功。

1
2

# 只在 master 节点执行
kubectl apply -f https://kuboard.cn/install-script/v1.21.x/nginx-ingress.yaml

在 master 节点上执行

只在您想选择其他 Ingress Controller 的情况下卸载

1
2

# 只在 master 节点执行
kubectl delete -f https://kuboard.cn/install-script/v1.21.x/nginx-ingress.yaml

配置域名解析

将域名 cnsre.cn 解析到 demo-worker-a-2 的 IP 地址 z.z.z.z （也可以是 demo-worker-a-1 的地址 y.y.y.y）

验证配置

在浏览器访问 cnsre.cn，将得到 404 NotFound 错误页面

作者：SRE运维博客
博客地址：https://www.cnsre.cn
文章地址：https://www.cnsre.cn/posts/210602036084/
相关话题：https://www.cnsre.cn/tags/kubernetes/

Kubernetes on SRE运维博客

多云搭建 K3S 集群

环境介绍

搭建前准备

升级内核

升级内核前

升级内核

修改默认内核版本

安装 WireGuard

所有节点执行

配置 WireGuard

配置说明

各节点配置

启动 WireGuard

自动化

配置热重载

安装 K3S 集群

master节点安装

Agent 安装

如何解决 Amazon EKS 中 Fargate 无法访问公网的问题

如何解决 Amazon EKS 中 Fargate 无法访问公网的问题

背景介绍

案例描述

关键问题

分析与调查

解决方案

步骤如下：

结果验证

Fargate Pod 成功连接公网输出

常见问题与预防

为什么 Fargate 和 EC2 的网络行为不同？

如何避免类似问题？

结论

实现Kubernetes跨Namespace Service访问的最佳实践

实现Kubernetes跨Namespace Service访问的最佳实践

1. 场景需求

2. 创建Service和Pod

在myns Namespace中创建Pod和Service

在mytest Namespace中创建Pod和Service

3. 检查创建结果

4. 跨Namespace Service通信问题

5. 解决方案：使用ExternalName类型的Service

在myns Namespace中创建ExternalName Service

在mytest Namespace中创建ExternalName Service

6. 验证跨Namespace通信

7. 总结

Amazon EKS 中 EFS 持久性存储

学习目标

前提条件

创建 IAM 策略

将 efs 策略 附件到 eks node 角色中

安装 Amazon EFS 驱动程序

yaml 清单部署

创建 Amazon EFS 文件系统

为 Amazon EKS 集群创建 Amazon EFS 文件系统

创建入站规则

部署示例应用程序

部署静态供给

部署动态供给

如何彻底删除EKS中一直卡在Terminating的Namespace

介绍

如何彻底删除 namespace

获取namespace的详情信息并转为json

打开 json 文件编辑

执行清理命令

最后的检查

AWS eks绑定alb 使用aws-load-balancer-controller(Ingress Controller)提供服务

AWS Load Balancer Controller 介绍

AWS Load Balancer Controller 的工作原理

安装前的准备

创建AWS Load Balancer Controller 的 IAM 策略

赋予 EKS node 权限

在 EKS 中安装 AWS Load Balancer Controller

安装证书管理器

部署 YAML

部署示例应用程序

kubectl 彩色输出 -- kubecolor

kubecolor 是什么？

安装

通过 GitHub 发布下载

在`myns` Namespace中创建Pod和Service

在`mytest` Namespace中创建Pod和Service

5. 解决方案：使用`ExternalName`类型的Service

在`myns` Namespace中创建`ExternalName` Service

在`mytest` Namespace中创建`ExternalName` Service

将 efs 策略附件到 eks node 角色中

k3s单机版安装部署附一键安装脚本