Skip to content


k8s_安装rocky9_二进制安装1.29.2

查看环境

查看系统版本

cat /etc/redhat-release
Rocky Linux release 9.3 (Blue Onyx)

查看内核版本

uname -a Linux localhost.localdomain 5.14.0-362.8.1.el9_3.x86_64 #1 SMP PREEMPT_DYNAMIC Wed Nov 8 17:36:32 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux

查看ssh及openssl 版本

ssh -V OpenSSH_8.7p1, OpenSSL 3.0.7 1 Nov 2022 不升级

python版本

python -V
Python 3.9.18

glibc版本

ldd –version ldd (GNU libc) 2.34

主机名设定,各个主机上设定

使用hostnamectl设定
hostnamectl set-hostname dev-k8s-master01.local
hostnamectl set-hostname dev-k8s-node01.local
hostnamectl set-hostname dev-k8s-node02.local

使用nmcli设定
nmcli general hostname dev-k8s-master01.local

查看环境信息

hostnamectl status
Static hostname: dev-k8s-master01.local
       Icon name: computer-vm
         Chassis: vm 
                            Machine ID: 45d4ec6ccf3646248a8b9cc382baf29d
         Boot ID: e3167b9bd8864d3a9de968f7459f73d2
  Virtualization: oracle
Operating System: Rocky Linux 9.3 (Blue Onyx)      
     CPE OS Name: cpe:/o:rocky:rocky:9::baseos
          Kernel: Linux 5.14.0-362.8.1.el9_3.x86_64
    Architecture: x86-64
 Hardware Vendor: innotek GmbH
  Hardware Model: VirtualBox
Firmware Version: VirtualBox

rocky9上打开加密兼容

便于低版本ssh 连接
update-crypto-policies –show
update-crypto-policies –set LEGACY

关闭 swap

kubelet 的默认行为是在节点上检测到交换内存时无法启动。 kubelet 自 v1.22 起已开始支持交换分区。自 v1.28 起,仅针对 cgroup v2 支持交换分区; kubelet 的 NodeSwap 特性门控处于 Beta 阶段,但默认被禁用。

#临时关闭
swapoff -a
#永久关闭
swapoff -a && sed -ri 's/.*swap.*/#&/' /etc/fstab

修改ip

查看当前ip

ip a
nmcli device show
nmcli con show

使用配制文件修改

vi /etc/NetworkManager/system-connections/enp0s3.nmconnection

[ipv4]
method=manual
address1=192.168.244.14/24,192.168.244.1
dns=223.5.5.5;1.1.1.1

重新载入生效

nmcli connection reload
nmcli connection down enp0s3 && nmcli connection up enp0s3

使用命令修改

nmcli con mod enp0s3 ipv4.addresses 192.168.244.14/24; nmcli con mod enp0s3 ipv4.gateway  192.168.244.1; nmcli con mod enp0s3 ipv4.method manual; nmcli con mod enp0s3 ipv4.dns "8.8.8.8"; nmcli con up enp0s3

machine-id修改

在master节点和node节点都需要执行,主要是为了清除克隆机器machine-id值一样的问题
rm -f /etc/machine-id && systemd-machine-id-setup

机器product_uuid

确保每个节点上 MAC 地址和 product_uuid 的唯一性
你可以使用命令 ip link 或 ifconfig -a 来获取网络接口的 MAC 地址
可以使用 sudo cat /sys/class/dmi/id/product_uuid 命令对 product_uuid 校验
生成uuid可以使用uuidgen命令,或者cat一下这个节点获取:/proc/sys/kernel/random/uuid

uuidgen
9729e211-c76b-42fb-8635-75128ec44be6

cat /sys/class/dmi/id/product_uuid
5a8da902-c112-4c97-881b-63c917cce8b7

修改网卡uuid

# 若虚拟机是进行克隆的那么网卡的UUID会重复
# 若UUID重复需要重新生成新的UUID
# UUID重复无法获取到IPV6地址
## uuidgen eth0 
# 
# 查看当前的网卡列表和 UUID:
# nmcli con show
# 删除要更改 UUID 的网络连接:
# nmcli con delete uuid <原 UUID>
# 重新生成 UUID:
# nmcli con add type ethernet ifname <接口名称> con-name <新名称>
# 重新启用网络连接:
# nmcli con up <新名称>

安装中文语言包

localectl list-locales |grep zh
dnf list |grep glibc-langpack
dnf install glibc-langpack-zh

systemctl stop firewalld
systemctl disable firewalld

24小时制

localectl set-locale LC_TIME=en_GB.UTF-8

selinux

setenforce 0 && sed -i ‘/SELINUX/s/enforcing/disabled/’ /etc/selinux/config

vim 打开黏贴模式

echo ‘set paste’ >> ~/.vimrc

其它初始化省略

设置好各机的hostname

hostnamectl set-hostname dev-k8s-master01.local hostnamectl set-hostname dev-k8s-node01.local
hostnamectl set-hostname dev-k8s-node02.local

写入主机名入IP映射

cat >> /etc/hosts << EOF 192.168.244.14 dev-k8s-master01 dev-k8s-master01.local 192.168.244.15 dev-k8s-node01 dev-k8s-node01.local 192.168.244.16 dev-k8s-node02 dev-k8s-node02.local EOF

免密连接,在master01上

生成主机身份验证密钥

ssh-keygen -t ed25519 -C ‘support OpenSSH 6.5~’

分发到目标主机

ssh-copy-id -i ~/.ssh/id_ed25519 [email protected]
ssh-copy-id -i ~/.ssh/id_ed25519 [email protected]

k8s主机网段规划

网段 物理主机:192.168.244.0/24 service:10.96.0.0/12 pod:172.16.0.0/12

升级内核

uname -a 查看当前内核
Linux dev-k8s-master01.local 5.14.0-362.8.1.el9_3.x86_64 #1 SMP PREEMPT_DYNAMIC Wed Nov 8 17:36:32 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux

引入rpm库

rpm –import https://www.elrepo.org/RPM-GPG-KEY-elrepo.org
rhel9的库
wget https://www.elrepo.org/elrepo-release-9.el9.elrepo.noarch.rpm
rpm -Uvh elrepo-release-9.el9.elrepo.noarch.rpm

查看现在elrepo里有什么版本的新内核可以用,运行
yum –disablerepo=”*” –enablerepo=”elrepo-kernel” list available

kernel-lt.x86_64  6.1.82-1.el9.elrepo  elrepo-kernel  
kernel-ml.x86_64  6.8.1-1.el9.elrepo  elrepo-kernel  

安装长期支持版

yum –enablerepo=elrepo-kernel install kernel-lt-devel kernel-lt -y

先不安装 kernel-lt-headers,两个版本的headers会冲突
先移除kernel-headers-5.14,再安装新版本kernel-headers
yum -y remove kernel-headers-5.14.0-284.11.1.el9_2.x86_64
yum –enablerepo=”elrepo-kernel” install -y kernel-lt-headers

确认已安装内核版本

rpm -qa | grep kernel
kernel-lt-6.1.82-1.el9.elrepo.x86_64

设置开机从新内核启动

grub2-editenv list
grub2-set-default 0
grub2-editenv list

cp /boot/grub2/grub.cfg /boot/grub2/grub.bak.cfg

grub2-mkconfig -o /boot/grub2/grub.cfg

重启并查看内核版本

reboot
uname -a
Linux dev-k8s-master01.local 6.1.82-1.el9.elrepo.x86_64 #1 SMP PREEMPT_DYNAMIC Fri Mar 15 18:18:05 EDT 2024 x86_64 x86_64 x86_64 GNU/Linux

查看内核模块

lsmod modinfo nf_conntrack

安装ipset和ipvsadm

所有工作节点上均执行 yum install ipset ipvsadmin ipvsadm sysstat conntrack conntrack-tools libseccomp -y

加载内核

cat >> /etc/modules-load.d/ipvs.conf <<EOF 
ip_vs
ip_vs_rr
ip_vs_wrr
ip_vs_sh
nf_conntrack
ip_tables
ip_set
xt_set
ipt_set
ipt_rpfilter
ipt_REJECT
ipip
EOF

重新载入

systemctl restart systemd-modules-load.service

查看内核模块

lsmod |grep ipip lsmod |grep -e ip_vs -e nf_conntrack

ip_vs_sh               16384  0
ip_vs_wrr              16384  0
ip_vs_rr               16384  0
ip_vs                 192512  6 ip_vs_rr,ip_vs_sh,ip_vs_wrr
nf_conntrack          188416  1 ip_vs
nf_defrag_ipv6         24576  2 nf_conntrack,ip_vs
nf_defrag_ipv4         16384  1 nf_conntrack
libcrc32c              16384  3 nf_conntrack,xfs,ip_vs

安装常用工具

yum -y install wget vim net-tools nfs-utils telnet yum-utils device-mapper-persistent-data lvm2 tar curl lrzsz rsync psmisc sysstat lsof

下载所需软件

cd /root/
mkdir -p k8s/shell && cd k8s/shell
vi down.sh

#!/bin/bash

# 查看版本地址:
# 
# https://github.com/containernetworking/plugins/releases/
# https://github.com/containerd/containerd/releases/
# https://github.com/kubernetes-sigs/cri-tools/releases/
# https://github.com/Mirantis/cri-dockerd/releases/
# https://github.com/etcd-io/etcd/releases/
# https://github.com/cloudflare/cfssl/releases/
# https://github.com/kubernetes/kubernetes/tree/master/CHANGELOG
# https://download.docker.com/linux/static/stable/x86_64/
# https://github.com/opencontainers/runc/releases/
# https://mirrors.tuna.tsinghua.edu.cn/elrepo/kernel/el7/x86_64/RPMS/
# https://github.com/helm/helm/tags
# http://nginx.org/download/

# Version numbers
cni_plugins_version='v1.4.0'
cri_containerd_cni_version='1.7.13'
crictl_version='v1.29.0'
cri_dockerd_version='0.3.10'
etcd_version='v3.5.12'
cfssl_version='1.6.4'
kubernetes_server_version='1.29.2'
docker_version='25.0.3'
runc_version='1.1.12'
kernel_version='5.4.268'
helm_version='3.14.1'
nginx_version='1.25.4'

# URLs 
base_url='https://github.com'
kernel_url="http://mirrors.tuna.tsinghua.edu.cn/elrepo/kernel/el7/x86_64/RPMS/kernel-lt-${kernel_version}-1.el7.elrepo.x86_64.rpm"
runc_url="${base_url}/opencontainers/runc/releases/download/v${runc_version}/runc.amd64"
docker_url="https://mirrors.ustc.edu.cn/docker-ce/linux/static/stable/x86_64/docker-${docker_version}.tgz"
cni_plugins_url="${base_url}/containernetworking/plugins/releases/download/${cni_plugins_version}/cni-plugins-linux-amd64-${cni_plugins_version}.tgz"
cri_containerd_cni_url="${base_url}/containerd/containerd/releases/download/v${cri_containerd_cni_version}/cri-containerd-cni-${cri_containerd_cni_version}-linux-amd64.tar.gz"
crictl_url="${base_url}/kubernetes-sigs/cri-tools/releases/download/${crictl_version}/crictl-${crictl_version}-linux-amd64.tar.gz"
cri_dockerd_url="${base_url}/Mirantis/cri-dockerd/releases/download/v${cri_dockerd_version}/cri-dockerd-${cri_dockerd_version}.amd64.tgz"
etcd_url="${base_url}/etcd-io/etcd/releases/download/${etcd_version}/etcd-${etcd_version}-linux-amd64.tar.gz"
cfssl_url="${base_url}/cloudflare/cfssl/releases/download/v${cfssl_version}/cfssl_${cfssl_version}_linux_amd64"
cfssljson_url="${base_url}/cloudflare/cfssl/releases/download/v${cfssl_version}/cfssljson_${cfssl_version}_linux_amd64"
helm_url="https://mirrors.huaweicloud.com/helm/v${helm_version}/helm-v${helm_version}-linux-amd64.tar.gz"
kubernetes_server_url="https://storage.googleapis.com/kubernetes-release/release/v${kubernetes_server_version}/kubernetes-server-linux-amd64.tar.gz"
nginx_url="http://nginx.org/download/nginx-${nginx_version}.tar.gz"

# Download packages
packages=(
  $kernel_url
  $runc_url
  $docker_url
  $cni_plugins_url
  $cri_containerd_cni_url
  $crictl_url
  $cri_dockerd_url
  $etcd_url
  $cfssl_url
  $cfssljson_url
  $helm_url
  $kubernetes_server_url
  $nginx_url
)

for package_url in "${packages[@]}"; do
  filename=$(basename "$package_url")
  if curl --parallel --parallel-immediate -k -L -C - -o "$filename" "$package_url"; then
    echo "Downloaded $filename"
  else
    echo "Failed to download $filename"
    exit 1
  fi
done

在master01上下载

chmod 755 down.sh
./down.sh

传输到其它node

scp * [email protected]:k8s/  
scp * [email protected]:k8s/  

calico网络配置

cat > /etc/NetworkManager/conf.d/calico.conf << EOF 
[keyfile]
unmanaged-devices=interface-name:cali*;interface-name:tunl*
EOF
cat > /etc/NetworkManager/conf.d/calico.conf <<EOF
[keyfile]
unmanaged-devices=interface-name:cali*;interface-name:tunl*;interface-name:vxlan.calico;interface-name:wireguard.cali
EOF

systemctl restart NetworkManager

# 参数解释
#
# 这个参数用于指定不由 NetworkManager 管理的设备。它由以下两个部分组成
# 
# interface-name:cali*
# 表示以 "cali" 开头的接口名称被排除在 NetworkManager 管理之外。例如,"cali0", "cali1" 等接口不受 NetworkManager 管理。
# 
# interface-name:tunl*
# 表示以 "tunl" 开头的接口名称被排除在 NetworkManager 管理之外。例如,"tunl0", "tunl1" 等接口不受 NetworkManager 管理。
# 
# 通过使用这个参数,可以将特定的接口排除在 NetworkManager 的管理范围之外,以便其他工具或进程可以独立地管理和配置这些接口。

安装Containerd作为Runtime

创建cni插件所需目录
mkdir -p /etc/cni/net.d /opt/cni/bin

解压cni二进制包 tar xf cni-plugins-linux-amd64-v*.tgz -C /opt/cni/bin/

解压
tar -xzf cri-containerd-cni-*-linux-amd64.tar.gz -C /

创建服务启动文件

cat > /etc/systemd/system/containerd.service <<EOF
[Unit]
Description=containerd container runtime
Documentation=https://containerd.io
After=network.target local-fs.target

[Service]
ExecStartPre=-/sbin/modprobe overlay
ExecStart=/usr/local/bin/containerd
Type=notify
Delegate=yes
KillMode=process
Restart=always
RestartSec=5
LimitNPROC=infinity
LimitCORE=infinity
LimitNOFILE=infinity
TasksMax=infinity
OOMScoreAdjust=-999

[Install]
WantedBy=multi-user.target
EOF

配置Containerd所需的模块

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

systemctl restart systemd-modules-load.service

确认Containerd所需的内核为1,都已开启
sysctl net.bridge.bridge-nf-call-iptables
sysctl net.ipv4.ip_forward
sysctl net.bridge.bridge-nf-call-ip6tables

创建Containerd的配置文件
mkdir -p /etc/containerd

修改Containerd的配置文件

containerd config default | tee  /etc/containerd/config.toml

sed -i "s#SystemdCgroup\ \=\ false#SystemdCgroup\ \=\ true#g" /etc/containerd/config.toml
cat /etc/containerd/config.toml | grep SystemdCgroup
sed -i "s#registry.k8s.io#m.daocloud.io/registry.k8s.io#g" /etc/containerd/config.toml
cat /etc/containerd/config.toml | grep sandbox_image
sed -i "s#config_path\ \=\ \"\"#config_path\ \=\ \"/etc/containerd/certs.d\"#g" /etc/containerd/config.toml
cat /etc/containerd/config.toml | grep certs.d

新版本的containerd镜像仓库配置都是建议放在一个单独的文件夹当中,并且在/etc/containerd/config.toml配置文件当中打开config_path配置,指向镜像仓库配置目录即可。 特别需要注意的是,hosts.toml中可以配置多个镜像仓库,containerd下载竟像时会根据配置的顺序使用镜像仓库,只有当上一个仓库下载失败才会使用下一个镜像仓库。因此,镜像仓库的配置原则就是镜像仓库下载速度越快,那么这个仓库就应该放在最前面。

配置加速器

https://docker.mirrors.ustc.edu.cn 不可用
https://registry.cn-hangzhou.aliyuncs.com 需验证

mkdir /etc/containerd/certs.d/docker.io -pv
cat > /etc/containerd/certs.d/docker.io/hosts.toml << EOF
server = "https://docker.io"
[host."https://docker.nju.edu.cn/"]
  capabilities = ["pull", "resolve"]
EOF

如果报以下错误,那么需要更换镜像源,可以去阿里申请免费私人加速源https://xxx.mirror.aliyuncs.com “PullImage from image service failed” err=”rpc error: code = Unknown desc = failed to pull and unpack ima

配置本地harbor私仓示列

设定hosts

假设harbor私仓在192.168.244.6
echo ‘192.168.244.6 repo.k8s.local’ >> /etc/hosts

设定配制文件

vi /etc/containerd/config.toml

[plugins."io.containerd.grpc.v1.cri".registry]
   config_path = "/etc/containerd/certs.d"
      [plugins."io.containerd.grpc.v1.cri".registry.configs."repo.k8s.local".auth]
        username = "k8s_pull"
        password = "k8s_Pul1"

mkdir -p /etc/containerd/certs.d/repo.k8s.local

#harbor私仓使用https方式
cat > /etc/containerd/certs.d/repo.k8s.local/hosts.toml <<EOF
server = "https://repo.k8s.local"
[host."https://repo.k8s.local"]
  capabilities = ["pull", "resolve","push"]
  skip_verify = true
EOF

启动并设置为开机启动
systemctl daemon-reload
systemctl enable –now containerd.service
systemctl stop containerd.service
systemctl start containerd.service
systemctl restart containerd.service
systemctl status containerd.service

配置crictl客户端连接的运行时位置

tar xf crictl-v*-linux-amd64.tar.gz -C /usr/bin/
#生成配置文件
cat > /etc/crictl.yaml <<EOF
runtime-endpoint: unix:///run/containerd/containerd.sock
image-endpoint: unix:///run/containerd/containerd.sock
timeout: 10
debug: false
EOF

systemctl restart containerd

crictl info

crictl -version
crictl version 1.27.0

测试拉取

crictl pull docker.io/library/nginx 
crictl pull repo.k8s.local/google_containers/busybox:9.9
crictl images
IMAGE                                                              TAG                 IMAGE ID            SIZE
docker.io/library/nginx                                            latest              92b11f67642b6       70.5MB
docker.io/library/busybox                                          1.28                
repo.k8s.local/google_containers/busybox                           9.9                 a416a98b71e22       2.22MB

k8s与etcd下载及安装(仅在master01操作)

解压k8s安装包

tar -xf kubernetes-server-linux-amd64.tar.gz –strip-components=3 -C /usr/local/bin kubernetes/server/bin/kube{let,ctl,-apiserver,-controller-manager,-scheduler,-proxy}

# - --strip-components=3:表示解压时忽略压缩文件中的前3级目录结构,提取文件时直接放到目标目录中。
# - -C /usr/local/bin:指定提取文件的目标目录为/usr/local/bin。
# - kubernetes/server/bin/kube{let,ctl,-apiserver,-controller-manager,-scheduler,-proxy}:要解压和提取的文件名模式,用花括号括起来表示模式中的多个可能的文件名。
# 
# 总的来说,这个命令的作用是将kubernetes-server-linux-amd64.tar.gz文件中的kubelet、kubectl、kube-apiserver、kube-controller-manager、kube-scheduler和kube-proxy六个文件提取到/usr/local/bin目录下,同时忽略文件路径中的前三级目录结构。

解压etcd安装文件

tar -xf etcd.tar.gz && mv etcd-/etcd /usr/local/bin/ && mv etcd-*/etcdctl /usr/local/bin/
ls /usr/local/bin/

containerd               containerd-shim-runc-v2  critest      etcd            kube-controller-manager  kube-proxy
containerd-shim          containerd-stress        ctd-decoder  etcdctl         kubectl                  kube-scheduler
containerd-shim-runc-v1  crictl                   ctr          kube-apiserver  kubelet

查看版本

kubelet –version

Kubernetes v1.29.2
etcdctl version
etcdctl version: 3.5.12
API version: 3.5

分发

分发master组件
Master=’dev-k8s-master02 dev-k8s-master03′
Work=’dev-k8s-node01 dev-k8s-node02′

for NODE in $Master; do echo $NODE; scp /usr/local/bin/kube{let,ctl,-apiserver,-controller-manager,-scheduler,-proxy} $NODE:/usr/local/bin/; scp /usr/local/bin/etcd* $NODE:/usr/local/bin/; done

# 该命令是一个for循环,对于在$Master变量中的每个节点,执行以下操作:
# 
# 1. 打印出节点的名称。
# 2. 使用scp命令将/usr/local/bin/kubelet、kubectl、kube-apiserver、kube-controller-manager、kube-scheduler和kube-proxy文件复制到节点的/usr/local/bin/目录下。
# 3. 使用scp命令将/usr/local/bin/etcd*文件复制到节点的/usr/local/bin/目录下。

分发work组件

for NODE in $Work; do echo $NODE; scp /usr/local/bin/kube{let,-proxy} $NODE:/usr/local/bin/ ; done

# 该命令是一个for循环,对于在$Work变量中的每个节点,执行以下操作:
# 
# 1. 打印出节点的名称。
# 2. 使用scp命令将/usr/local/bin/kubelet和kube-proxy文件复制到节点的/usr/local/bin/目录下。

所有节点执行
mkdir -p /opt/cni/bin

相关证书生成

cp cfssl__linuxamd64 /usr/local/bin/cfssl
cp cfssljson
_linux_amd64 /usr/local/bin/cfssljson

添加执行权限

chmod +x /usr/local/bin/cfssl /usr/local/bin/cfssljson

生成etcd证书

以下操作在所有master节点操作
所有master节点创建证书存放目录
mkdir /etc/etcd/ssl -p
master01节点生成etcd证书

写入生成证书所需的配置文件

cat > ca-config.json << EOF 
{
  "signing": {
    "default": {
      "expiry": "876000h"
    },
    "profiles": {
      "kubernetes": {
        "usages": [
            "signing",
            "key encipherment",
            "server auth",
            "client auth"
        ],
        "expiry": "876000h"
      }
    }
  }
}
EOF
# 这段配置文件是用于配置加密和认证签名的一些参数。
# 
# 在这里,有两个部分:`signing`和`profiles`。
# 
# `signing`包含了默认签名配置和配置文件。
# 默认签名配置`default`指定了证书的过期时间为`876000h`。`876000h`表示证书有效期为100年。
# 
# `profiles`部分定义了不同的证书配置文件。
# 在这里,只有一个配置文件`kubernetes`。它包含了以下`usages`和过期时间`expiry`:
# 
# 1. `signing`:用于对其他证书进行签名
# 2. `key encipherment`:用于加密和解密传输数据
# 3. `server auth`:用于服务器身份验证
# 4. `client auth`:用于客户端身份验证
# 
# 对于`kubernetes`配置文件,证书的过期时间也是`876000h`,即100年。
cat > etcd-ca-csr.json  << EOF 
{
  "CN": "etcd",
  "key": {
    "algo": "rsa",
    "size": 2048
  },
  "names": [
    {
      "C": "CN",
      "ST": "Beijing",
      "L": "Beijing",
      "O": "etcd",
      "OU": "Etcd Security"
    }
  ],
  "ca": {
    "expiry": "876000h"
  }
}
EOF
# 这是一个用于生成证书签名请求(Certificate Signing Request,CSR)的JSON配置文件。JSON配置文件指定了生成证书签名请求所需的数据。
# 
# - "CN": "etcd" 指定了希望生成的证书的CN字段(Common Name),即证书的主题,通常是该证书标识的实体的名称。
# - "key": {} 指定了生成证书所使用的密钥的配置信息。"algo": "rsa" 指定了密钥的算法为RSA,"size": 2048 指定了密钥的长度为2048位。
# - "names": [] 包含了生成证书时所需的实体信息。在这个例子中,只包含了一个实体,其相关信息如下:
#   - "C": "CN" 指定了实体的国家/地区代码,这里是中国。
#   - "ST": "Beijing" 指定了实体所在的省/州。
#   - "L": "Beijing" 指定了实体所在的城市。
#   - "O": "etcd" 指定了实体的组织名称。
#   - "OU": "Etcd Security" 指定了实体所属的组织单位。
# - "ca": {} 指定了生成证书时所需的CA(Certificate Authority)配置信息。
#   - "expiry": "876000h" 指定了证书的有效期,这里是876000小时。
# 
# 生成证书签名请求时,可以使用这个JSON配置文件作为输入,根据配置文件中的信息生成相应的CSR文件。然后,可以将CSR文件发送给CA进行签名,以获得有效的证书。

# 生成etcd证书和etcd证书的key(如果你觉得以后可能会扩容,可以在ip那多写几个预留出来)
# 若没有IPv6 可删除可保留 

cfssl gencert -initca etcd-ca-csr.json | cfssljson -bare /etc/etcd/ssl/etcd-ca

# 具体的解释如下:
# 
# cfssl是一个用于生成TLS/SSL证书的工具,它支持PKI、JSON格式配置文件以及与许多其他集成工具的配合使用。
# 
# gencert参数表示生成证书的操作。-initca参数表示初始化一个CA(证书颁发机构)。CA是用于签发其他证书的根证书。etcd-ca-csr.json是一个JSON格式的配置文件,其中包含了CA的详细信息,如私钥、公钥、有效期等。这个文件提供了生成CA证书所需的信息。
# 
# | 符号表示将上一个命令的输出作为下一个命令的输入。
# 
# cfssljson是cfssl工具的一个子命令,用于格式化cfssl生成的JSON数据。 -bare参数表示直接输出裸证书,即只生成证书文件,不包含其他格式的文件。/etc/etcd/ssl/etcd-ca是指定生成的证书文件的路径和名称。
# 
# 所以,这条命令的含义是使用cfssl工具根据配置文件ca-csr.json生成一个CA证书,并将证书文件保存在/etc/etcd/ssl/etcd-ca路径下。
cat > etcd-csr.json << EOF 
{
  "CN": "etcd",
  "key": {
    "algo": "rsa",
    "size": 2048
  },
  "names": [
    {
      "C": "CN",
      "ST": "Beijing",
      "L": "Beijing",
      "O": "etcd",
      "OU": "Etcd Security"
    }
  ]
}
EOF

# 这段代码是一个JSON格式的配置文件,用于生成一个证书签名请求(Certificate Signing Request,CSR)。
# 
# 首先,"CN"字段指定了该证书的通用名称(Common Name),这里设为"etcd"。
# 
# 接下来,"key"字段指定了密钥的算法("algo"字段)和长度("size"字段),此处使用的是RSA算法,密钥长度为2048位。
# 
# 最后,"names"字段是一个数组,其中包含了一个名字对象,用于指定证书中的一些其他信息。这个名字对象包含了以下字段:
# - "C"字段指定了国家代码(Country),这里设置为"CN"。
# - "ST"字段指定了省份(State)或地区,这里设置为"Beijing"。
# - "L"字段指定了城市(Locality),这里设置为"Beijing"。
# - "O"字段指定了组织(Organization),这里设置为"etcd"。
# - "OU"字段指定了组织单元(Organizational Unit),这里设置为"Etcd Security"。
# 
# 这些字段将作为证书的一部分,用于标识和验证证书的使用范围和颁发者等信息。

cfssl gencert \
   -ca=/etc/etcd/ssl/etcd-ca.pem \
   -ca-key=/etc/etcd/ssl/etcd-ca-key.pem \
   -config=ca-config.json \
   -hostname=127.0.0.1,dev-k8s-master01,dev-k8s-master02,dev-k8s-master03,192.168.244.14,192.168.244.15,192.168.244.16,::1 \
   -profile=kubernetes \
   etcd-csr.json | cfssljson -bare /etc/etcd/ssl/etcd
 ```

这是一条使用cfssl生成etcd证书的命令,下面是各个参数的解释:

-ca=/etc/etcd/ssl/etcd-ca.pem:指定用于签名etcd证书的CA文件的路径。

-ca-key=/etc/etcd/ssl/etcd-ca-key.pem:指定用于签名etcd证书的CA私钥文件的路径。

-config=ca-config.json:指定CA配置文件的路径,该文件定义了证书的有效期、加密算法等设置。

-hostname=xxxx:指定要为etcd生成证书的主机名和IP地址列表。

-profile=kubernetes:指定使用的证书配置文件,该文件定义了证书的用途和扩展属性。

etcd-csr.json:指定etcd证书请求的JSON文件的路径,该文件包含了证书请求的详细信息。

| cfssljson -bare /etc/etcd/ssl/etcd:通过管道将cfssl命令的输出传递给cfssljson命令,并使用-bare参数指定输出文件的前缀路径,这里将生成etcd证书的.pem和-key.pem文件。

这条命令的作用是使用指定的CA证书和私钥,根据证书请求的JSON文件和配置文件生成etcd的证书文件。


## 将证书复制到其他节点

Master=’dev-k8s-master02 dev-k8s-master03′
for NODE in $Master; do ssh $NODE “mkdir -p /etc/etcd/ssl”; for FILE in etcd-ca-key.pem etcd-ca.pem etcd-key.pem etcd.pem; do scp /etc/etcd/ssl/${FILE} $NODE:/etc/etcd/ssl/${FILE}; done; done

这个命令是一个简单的for循环,在一个由$Master存储的主机列表中迭代执行。对于每个主机,它使用ssh命令登录到主机,并在远程主机上创建一个名为/etc/etcd/ssl的目录(如果不存在)。接下来,它使用scp将本地主机上/etc/etcd/ssl目录中的四个文件(etcd-ca-key.pemetcd-ca.pemetcd-key.pemetcd.pem)复制到远程主机的/etc/etcd/ssl目录中。最终的结果是,远程主机上的/etc/etcd/ssl目录中包含与本地主机上相同的四个文件的副本。


## 生成k8s相关证书
mkdir -p /etc/kubernetes/pki
master01节点生成k8s证书
**  写入生成证书所需的配置文件 **  

cat > ca-csr.json << EOF { "CN": "kubernetes", "key": { "algo": "rsa", "size": 2048 }, "names": [ { "C": "CN", "ST": "Beijing", "L": "Beijing", "O": "Kubernetes", "OU": "Kubernetes-manual" } ], "ca": { "expiry": "876000h" } } EOF

这是一个用于生成 Kubernetes 相关证书的配置文件。该配置文件中包含以下信息:

– CN:CommonName,即用于标识证书的通用名称。在此配置中,CN 设置为 “kubernetes”,表示该证书是用于 Kubernetes。

– key:用于生成证书的算法和大小。在此配置中,使用的算法是 RSA,大小是 2048 位。

– names:用于证书中的名称字段的详细信息。在此配置中,有以下字段信息:

– C:Country,即国家。在此配置中,设置为 “CN”。

– ST:State,即省/州。在此配置中,设置为 “Beijing”。

– L:Locality,即城市。在此配置中,设置为 “Beijing”。

– O:Organization,即组织。在此配置中,设置为 “Kubernetes”。

– OU:Organization Unit,即组织单位。在此配置中,设置为 “Kubernetes-manual”。

– ca:用于证书签名的证书颁发机构(CA)的配置信息。在此配置中,设置了证书的有效期为 876000 小时。

这个配置文件可以用于生成 Kubernetes 相关的证书,以确保集群中的通信安全性。


cfssl gencert -initca ca-csr.json | cfssljson -bare /etc/kubernetes/pki/ca

具体的解释如下:

cfssl是一个用于生成TLS/SSL证书的工具,它支持PKI、JSON格式配置文件以及与许多其他集成工具的配合使用。

gencert参数表示生成证书的操作。-initca参数表示初始化一个CA(证书颁发机构)。CA是用于签发其他证书的根证书。ca-csr.json是一个JSON格式的配置文件,其中包含了CA的详细信息,如私钥、公钥、有效期等。这个文件提供了生成CA证书所需的信息。

| 符号表示将上一个命令的输出作为下一个命令的输入。

cfssljson是cfssl工具的一个子命令,用于格式化cfssl生成的JSON数据。 -bare参数表示直接输出裸证书,即只生成证书文件,不包含其他格式的文件。/etc/kubernetes/pki/ca是指定生成的证书文件的路径和名称。

所以,这条命令的含义是使用cfssl工具根据配置文件ca-csr.json生成一个CA证书,并将证书文件保存在/etc/kubernetes/pki/ca路径下。

cat > apiserver-csr.json << EOF { "CN": "kube-apiserver", "key": { "algo": "rsa", "size": 2048 }, "names": [ { "C": "CN", "ST": "Beijing", "L": "Beijing", "O": "Kubernetes", "OU": "Kubernetes-manual" } ] } EOF

这是一个用于生成 Kubernetes 相关证书的配置文件。该配置文件中包含以下信息:

CN 字段指定了证书的通用名称 (Common Name),这里设置为 “kube-apiserver”,表示该证书用于 Kubernetes API Server。

key 字段指定了生成证书时所选用的加密算法和密钥长度。这里选用了 RSA 算法,密钥长度为 2048 位。

names 字段包含了一组有关证书持有者信息的项。这里使用了以下信息:

C 表示国家代码 (Country),这里设置为 “CN” 表示中国。

ST 表示州或省份 (State),这里设置为 “Beijing” 表示北京市。

L 表示城市或地区 (Location),这里设置为 “Beijing” 表示北京市。

O 表示组织名称 (Organization),这里设置为 “Kubernetes” 表示 Kubernetes。

OU 表示组织单位 (Organizational Unit),这里设置为 “Kubernetes-manual” 表示手动管理的 Kubernetes 集群。

这个配置文件可以用于生成 Kubernetes 相关的证书,以确保集群中的通信安全性。

生成一个根证书 ,多写了一些IP作为预留IP,为将来添加node做准备

10.96.0.1是service网段的第一个地址,需要计算,192.168.1.36为高可用vip地址

若没有IPv6 可删除可保留

cfssl gencert \ -ca=/etc/kubernetes/pki/ca.pem \ -ca-key=/etc/kubernetes/pki/ca-key.pem \ -config=ca-config.json \ -hostname=10.96.0.1,127.0.0.1,kubernetes,kubernetes.default,kubernetes.default.svc,kubernetes.default.svc.cluster,kubernetes.default.svc.cluster.local,192.168.244.14,192.168.244.15,192.168.244.16,::1 \ -profile=kubernetes apiserver-csr.json | cfssljson -bare /etc/kubernetes/pki/apiserver

这个命令是使用cfssl工具生成Kubernetes API Server的证书。

命令的参数解释如下:

-ca=/etc/kubernetes/pki/ca.pem:指定证书的颁发机构(CA)文件路径。

-ca-key=/etc/kubernetes/pki/ca-key.pem:指定证书的颁发机构(CA)私钥文件路径。

-config=ca-config.json:指定证书生成的配置文件路径,配置文件中包含了证书的有效期、加密算法等信息。

-hostname=10.96.0.1,192.168.1.36,127.0.0.1,fc00:43f4:1eea:1::10:指定证书的主机名或IP地址列表。

-profile=kubernetes:指定证书生成的配置文件中的配置文件名。

apiserver-csr.json:API Server的证书签名请求配置文件路径。

| cfssljson -bare /etc/kubernetes/pki/apiserver:通过管道将生成的证书输出到cfssljson工具,将其转换为PEM编码格式,并保存到 /etc/kubernetes/pki/apiserver.pem/etc/kubernetes/pki/apiserver-key.pem 文件中。

最终,这个命令将会生成API Server的证书和私钥,并保存到指定的文件中。


生成apiserver聚合证书

cat > front-proxy-ca-csr.json << EOF { "CN": "kubernetes", "key": { "algo": "rsa", "size": 2048 }, "ca": { "expiry": "876000h" } } EOF

这个JSON文件表示了生成一个名为”kubernetes”的证书的配置信息。这个证书是用来进行Kubernetes集群的身份验证和安全通信。

配置信息包括以下几个部分:

1. “CN”: “kubernetes”:这表示了证书的通用名称(Common Name),也就是证书所代表的实体的名称。在这里,证书的通用名称被设置为”kubernetes”,表示这个证书是用来代表Kubernetes集群。

2. “key”:这是用来生成证书的密钥相关的配置。在这里,配置使用了RSA算法,并且设置了密钥的大小为2048位。

3. “ca”:这个字段指定了证书的颁发机构(Certificate Authority)相关的配置。在这里,配置指定了证书的有效期为876000小时,即100年。这意味着该证书在100年内将被视为有效,过期后需要重新生成。

总之,这个JSON文件中的配置信息描述了如何生成一个用于Kubernetes集群的证书,包括证书的通用名称、密钥算法和大小以及证书的有效期。


cfssl gencert   -initca front-proxy-ca-csr.json | cfssljson -bare /etc/kubernetes/pki/front-proxy-ca 

具体的解释如下:

cfssl是一个用于生成TLS/SSL证书的工具,它支持PKI、JSON格式配置文件以及与许多其他集成工具的配合使用。

gencert参数表示生成证书的操作。-initca参数表示初始化一个CA(证书颁发机构)。CA是用于签发其他证书的根证书。front-proxy-ca-csr.json是一个JSON格式的配置文件,其中包含了CA的详细信息,如私钥、公钥、有效期等。这个文件提供了生成CA证书所需的信息。

| 符号表示将上一个命令的输出作为下一个命令的输入。

cfssljson是cfssl工具的一个子命令,用于格式化cfssl生成的JSON数据。 -bare参数表示直接输出裸证书,即只生成证书文件,不包含其他格式的文件。/etc/kubernetes/pki/front-proxy-ca是指定生成的证书文件的路径和名称。

所以,这条命令的含义是使用cfssl工具根据配置文件ca-csr.json生成一个CA证书,并将证书文件保存在/etc/kubernetes/pki/front-proxy-ca路径下。

cat > front-proxy-client-csr.json << EOF { "CN": "front-proxy-client", "key": { "algo": "rsa", "size": 2048 } } EOF

这是一个JSON格式的配置文件,用于描述一个名为”front-proxy-client”的配置。配置包括两个字段:CN和key。

– CN(Common Name)字段表示证书的通用名称,这里为”front-proxy-client”。

– key字段描述了密钥的算法和大小。”algo”表示使用RSA算法,”size”表示密钥大小为2048位。

该配置文件用于生成一个SSL证书,用于在前端代理客户端进行认证和数据传输的加密。这个证书中的通用名称是”front-proxy-client”,使用RSA算法生成,密钥大小为2048位。

cfssl gencert \ -ca=/etc/kubernetes/pki/front-proxy-ca.pem \ -ca-key=/etc/kubernetes/pki/front-proxy-ca-key.pem \ -config=ca-config.json \ -profile=kubernetes front-proxy-client-csr.json | cfssljson -bare /etc/kubernetes/pki/front-proxy-client

```

# 这个命令使用cfssl工具生成一个用于Kubernetes的front-proxy-client证书。
# 
# 主要参数解释如下:
# - `-ca=/etc/kubernetes/pki/front-proxy-ca.pem`: 指定用于签署证书的根证书文件路径。
# - `-ca-key=/etc/kubernetes/pki/front-proxy-ca-key.pem`: 指定用于签署证书的根证书的私钥文件路径。
# - `-config=ca-config.json`: 指定用于配置证书签署的配置文件路径。该配置文件描述了证书生成的一些规则,如加密算法和有效期等。
# - `-profile=kubernetes`: 指定生成证书时使用的配置文件中定义的profile,其中包含了一些默认的参数。
# - `front-proxy-client-csr.json`: 指定用于生成证书的CSR文件路径,该文件包含了证书请求的相关信息。
# - `| cfssljson -bare /etc/kubernetes/pki/front-proxy-client`: 通过管道将生成的证书输出到cfssljson工具进行解析,并通过`-bare`参数将证书和私钥分别保存到指定路径。
# 
# 这个命令的作用是根据提供的CSR文件和配置信息,使用指定的根证书和私钥生成一个前端代理客户端的证书,并将证书和私钥分别保存到`/etc/kubernetes/pki/front-proxy-client.pem`和`/etc/kubernetes/pki/front-proxy-client-key.pem`文件中。

生成controller-manage的证书 选择使用那种高可用方案 若使用 haproxy、keepalived 那么为 –server=https://192.168.1.36:9443 若使用 nginx方案,那么为 –server=https://127.0.0.1:8443

cat > manager-csr.json << EOF 
{
  "CN": "system:kube-controller-manager",
  "key": {
    "algo": "rsa",
    "size": 2048
  },
  "names": [
    {
      "C": "CN",
      "ST": "Beijing",
      "L": "Beijing",
      "O": "system:kube-controller-manager",
      "OU": "Kubernetes-manual"
    }
  ]
}
EOF
# 这是一个用于生成密钥对(公钥和私钥)的JSON配置文件。下面是针对该文件中每个字段的详细解释:
# 
# - "CN": 值为"system:kube-controller-manager",代表通用名称(Common Name),是此密钥对的主题(subject)。
# - "key": 这个字段用来定义密钥算法和大小。
#   - "algo": 值为"rsa",表示使用RSA算法。
#   - "size": 值为2048,表示生成的密钥大小为2048位。
# - "names": 这个字段用来定义密钥对的各个名称字段。
#   - "C": 值为"CN",表示国家(Country)名称是"CN"(中国)。
#   - "ST": 值为"Beijing",表示省/州(State/Province)名称是"Beijing"(北京)。
#   - "L": 值为"Beijing",表示城市(Locality)名称是"Beijing"(北京)。
#   - "O": 值为"system:kube-controller-manager",表示组织(Organization)名称是"system:kube-controller-manager"。
#   - "OU": 值为"Kubernetes-manual",表示组织单位(Organizational Unit)名称是"Kubernetes-manual"。
# 
# 这个JSON配置文件基本上是告诉生成密钥对的工具,生成一个带有特定名称和属性的密钥对。
cfssl gencert \
   -ca=/etc/kubernetes/pki/ca.pem \
   -ca-key=/etc/kubernetes/pki/ca-key.pem \
   -config=ca-config.json \
   -profile=kubernetes \
   manager-csr.json | cfssljson -bare /etc/kubernetes/pki/controller-manager
# 这是一个命令行操作,使用cfssl工具生成证书。
# 
# 1. `cfssl gencert` 是cfssl工具的命令,用于生成证书。
# 2. `-ca` 指定根证书的路径和文件名,这里是`/etc/kubernetes/pki/ca.pem`。
# 3. `-ca-key` 指定根证书的私钥的路径和文件名,这里是`/etc/kubernetes/pki/ca-key.pem`。
# 4. `-config` 指定配置文件的路径和文件名,这里是`ca-config.json`。
# 5. `-profile` 指定证书使用的配置文件中的配置模板,这里是`kubernetes`。
# 6. `manager-csr.json` 是证书签发请求的配置文件,用于生成证书签发请求。
# 7. `|` 管道操作符,将前一条命令的输出作为后一条命令的输入。
# 8. `cfssljson -bare` 是 cfssl 工具的命令,作用是将证书签发请求的输出转换为PKCS#1、PKCS#8和x509 PEM文件。
# 9. `/etc/kubernetes/pki/controller-manager` 是转换后的 PEM 文件的存储位置和文件名。
# 
# 这个命令的作用是根据根证书和私钥、配置文件以及证书签发请求的配置文件,生成经过签发的控制器管理器证书和私钥,并将转换后的 PEM 文件保存到指定的位置。
# 设置一个集群项
# 选择使用那种高可用方案
# 若使用 haproxy、keepalived 那么为 `--server=https://192.168.244.14:9443`
# 若使用 nginx方案,那么为 `--server=https://127.0.0.1:8443`
kubectl config set-cluster kubernetes \
     --certificate-authority=/etc/kubernetes/pki/ca.pem \
     --embed-certs=true \
     --server=https://127.0.0.1:8443 \
     --kubeconfig=/etc/kubernetes/controller-manager.kubeconfig
# kubectl config set-cluster命令用于配置集群信息。
# --certificate-authority选项指定了集群的证书颁发机构(CA)的路径,这个CA会验证kube-apiserver提供的证书是否合法。
# --embed-certs选项用于将证书嵌入到生成的kubeconfig文件中,这样就不需要在kubeconfig文件中单独指定证书文件路径。
# --server选项指定了kube-apiserver的地址,这里使用的是127.0.0.1:8443,表示使用本地主机上的kube-apiserver,默认端口为8443。
# --kubeconfig选项指定了生成的kubeconfig文件的路径和名称,这里指定为/etc/kubernetes/controller-manager.kubeconfig。
# 综上所述,kubectl config set-cluster命令的作用是在kubeconfig文件中设置集群信息,包括证书颁发机构、证书、kube-apiserver地址等。

设置一个环境项,一个上下文

kubectl config set-context system:kube-controller-manager@kubernetes \
    --cluster=kubernetes \
    --user=system:kube-controller-manager \
    --kubeconfig=/etc/kubernetes/controller-manager.kubeconfig
# 这个命令用于配置 Kubernetes 控制器管理器的上下文信息。下面是各个参数的详细解释:
# 1. `kubectl config set-context system:kube-controller-manager@kubernetes`: 设置上下文的名称为 `system:kube-controller-manager@kubernetes`,这是一个标识符,用于唯一标识该上下文。
# 2. `--cluster=kubernetes`: 指定集群的名称为 `kubernetes`,这是一个现有集群的标识符,表示要管理的 Kubernetes 集群。
# 3. `--user=system:kube-controller-manager`: 指定使用的用户身份为 `system:kube-controller-manager`。这是一个特殊的用户身份,具有控制 Kubernetes 控制器管理器的权限。
# 4. `--kubeconfig=/etc/kubernetes/controller-manager.kubeconfig`: 指定 kubeconfig 文件的路径为 `/etc/kubernetes/controller-manager.kubeconfig`。kubeconfig 文件是一个用于管理 Kubernetes 配置的文件,包含了集群、用户和上下文的相关信息。
# 通过运行这个命令,可以将这些配置信息保存到 `/etc/kubernetes/controller-manager.kubeconfig` 文件中,以便在后续的操作中使用。

设置一个用户项

 kubectl config set-credentials system:kube-controller-manager \
       --client-certificate=/etc/kubernetes/pki/controller-manager.pem \
       --client-key=/etc/kubernetes/pki/controller-manager-key.pem \
       --embed-certs=true \
       --kubeconfig=/etc/kubernetes/controller-manager.kubeconfig
# 上述命令是用于设置 Kubernetes 的 controller-manager 组件的客户端凭据。下面是每个参数的详细解释:
# 
# - 
<code>kubectl config: 是使用 kubectl 命令行工具的配置子命令。
# - 
set-credentials: 是定义一个新的用户凭据配置的子命令。
# - 
system:kube-controller-manager: 是设置用户凭据的名称,system: 是 Kubernetes API Server 内置的身份验证器使用的用户标识符前缀,它表示是一个系统用户,在本例中是 kube-controller-manager 组件使用的身份。
# - 
--client-certificate=/etc/kubernetes/pki/controller-manager.pem: 指定 controller-manager.pem 客户端证书的路径。
# - 
--client-key=/etc/kubernetes/pki/controller-manager-key.pem: 指定 controller-manager-key.pem 客户端私钥的路径。
# - 
--embed-certs=true: 表示将证书和私钥直接嵌入到生成的 kubeconfig 文件中,而不是通过引用外部文件。
# - 
--kubeconfig=/etc/kubernetes/controller-manager.kubeconfig: 指定生成的 kubeconfig 文件的路径和文件名,即 controller-manager.kubeconfig。
# 
# 通过运行上述命令,将根据提供的证书和私钥信息,为 kube-controller-manager 创建一个 kubeconfig 文件,以便后续使用该文件进行身份验证和访问 Kubernetes API。

设置默认环境


kubectl config use-context system:kube-controller-manager@kubernetes \
     --kubeconfig=/etc/kubernetes/controller-manager.kubeconfig
# 这个命令是用来指定kubectl使用指定的上下文环境来执行操作。上下文环境是kubectl用来确定要连接到哪个Kubernetes集群以及使用哪个身份验证信息的配置。
# 
# 在这个命令中,
<code>kubectl config use-context是用来设置当前上下文环境的命令。 system:kube-controller-manager@kubernetes是指定的上下文名称,它告诉kubectl要使用的Kubernetes集群和身份验证信息。 
# 
--kubeconfig=/etc/kubernetes/controller-manager.kubeconfig是用来指定使用的kubeconfig文件的路径。kubeconfig文件是存储集群连接和身份验证信息的配置文件。
# 通过执行这个命令,kubectl将使用指定的上下文来执行后续的操作,包括部署和管理Kubernetes资源。

kubectl config view

生成kube-scheduler的证书

cat > scheduler-csr.json 
# 这个命令是用来创建一个叫做scheduler-csr.json的文件,并将其中的内容赋值给该文件。
# 
# 文件内容是一个JSON格式的文本,包含了一个描述证书请求的结构。
# 
# 具体内容如下:
# 
# - "CN": "system:kube-scheduler":Common Name字段,表示该证书的名称为system:kube-scheduler。
# - "key": {"algo": "rsa", "size": 2048}:key字段指定生成证书时使用的加密算法是RSA,并且密钥的长度为2048位。
# - "names": [...]:names字段定义了证书中的另外一些标识信息。
# - "C": "CN":Country字段,表示国家/地区为中国。
# - "ST": "Beijing":State字段,表示省/市为北京。
# - "L": "Beijing":Locality字段,表示所在城市为北京。
# - "O": "system:kube-scheduler":Organization字段,表示组织为system:kube-scheduler。
# - "OU": "Kubernetes-manual":Organizational Unit字段,表示组织单元为Kubernetes-manual。
# 
# 而EOF是一个占位符,用于标记开始和结束的位置。在开始的EOF之后到结束的EOF之间的内容将会被写入到scheduler-csr.json文件中。
# 
# 总体来说,这个命令用于生成一个描述kube-scheduler证书请求的JSON文件。
cfssl gencert \
   -ca=/etc/kubernetes/pki/ca.pem \
   -ca-key=/etc/kubernetes/pki/ca-key.pem \
   -config=ca-config.json \
   -profile=kubernetes \
   scheduler-csr.json | cfssljson -bare /etc/kubernetes/pki/scheduler
# 上述命令是使用cfssl工具生成Kubernetes Scheduler的证书。
# 
# 具体解释如下:
# 
# 1. 
<code>cfssl gencert:使用cfssl工具生成证书。
# 2. 
-ca=/etc/kubernetes/pki/ca.pem:指定根证书文件的路径。在这里,是指定根证书的路径为/etc/kubernetes/pki/ca.pem。
# 3. 
-ca-key=/etc/kubernetes/pki/ca-key.pem:指定根证书私钥文件的路径。在这里,是指定根证书私钥的路径为/etc/kubernetes/pki/ca-key.pem。
# 4. 
-config=ca-config.json:指定证书配置文件的路径。在这里,是指定证书配置文件的路径为ca-config.json。
# 5. 
-profile=kubernetes:指定证书的配置文件中的一个配置文件模板。在这里,是指定配置文件中的kubernetes配置模板。
# 6. 
scheduler-csr.json:指定Scheduler的证书签名请求文件(CSR)的路径。在这里,是指定请求文件的路径为scheduler-csr.json。
# 7. 
|(管道符号):将前一个命令的输出作为下一个命令的输入。
# 8. 
cfssljson:将cfssl工具生成的证书签名请求(CSR)进行解析。
# 9. 
-bare /etc/kubernetes/pki/scheduler:指定输出路径和前缀。在这里,是将解析的证书签名请求生成以下文件:/etc/kubernetes/pki/scheduler.pem(包含了证书)、/etc/kubernetes/pki/scheduler-key.pem(包含了私钥)。
# 
# 总结来说,这个命令的目的是根据根证书、根证书私钥、证书配置文件、CSR文件等生成Kubernetes Scheduler的证书和私钥文件。
# 选择使用那种高可用方案
# 若使用 haproxy、keepalived 那么为 
<code>--server=https://192.168.244.14:9443
# 若使用 nginx方案,那么为 
--server=https://127.0.0.1:8443
kubectl config set-cluster kubernetes \
     --certificate-authority=/etc/kubernetes/pki/ca.pem \
     --embed-certs=true \
     --server=https://127.0.0.1:8443 \
     --kubeconfig=/etc/kubernetes/scheduler.kubeconfig
# 该命令用于配置一个名为"kubernetes"的集群,并将其应用到/etc/kubernetes/scheduler.kubeconfig文件中。
# 
# 该命令的解释如下:
# - 
<code>kubectl config set-cluster kubernetes: 设置一个集群并命名为"kubernetes"。
# - 
--certificate-authority=/etc/kubernetes/pki/ca.pem: 指定集群使用的证书授权机构的路径。
# - 
--embed-certs=true: 该标志指示将证书嵌入到生成的kubeconfig文件中。
# - 
--server=https://127.0.0.1:8443: 指定集群的 API server 位置。
# - 
--kubeconfig=/etc/kubernetes/scheduler.kubeconfig: 指定要保存 kubeconfig 文件的路径和名称。
kubectl config set-credentials system:kube-scheduler \
     --client-certificate=/etc/kubernetes/pki/scheduler.pem \
     --client-key=/etc/kubernetes/pki/scheduler-key.pem \
     --embed-certs=true \
     --kubeconfig=/etc/kubernetes/scheduler.kubeconfig
# 这段命令是用于设置 kube-scheduler 组件的身份验证凭据,并生成相应的 kubeconfig 文件。
# 
# 解释每个选项的含义如下:
# - 
<code>kubectl config set-credentials system:kube-scheduler:设置 system:kube-scheduler 用户的身份验证凭据。
# - 
--client-certificate=/etc/kubernetes/pki/scheduler.pem:指定一个客户端证书文件,用于基于证书的身份验证。在这种情况下,指定了 kube-scheduler 组件的证书文件路径。
# - 
--client-key=/etc/kubernetes/pki/scheduler-key.pem:指定与客户端证书相对应的客户端私钥文件。
# - 
--embed-certs=true:将客户端证书和私钥嵌入到生成的 kubeconfig 文件中。
# - 
--kubeconfig=/etc/kubernetes/scheduler.kubeconfig:指定生成的 kubeconfig 文件的路径和名称。
# 
# 该命令的目的是为 kube-scheduler 组件生成一个 kubeconfig 文件,以便进行身份验证和访问集群资源。kubeconfig 文件是一个包含了连接到 Kubernetes 集群所需的所有配置信息的文件,包括服务器地址、证书和秘钥等。
kubectl config set-context system:kube-scheduler@kubernetes \
     --cluster=kubernetes \
     --user=system:kube-scheduler \
     --kubeconfig=/etc/kubernetes/scheduler.kubeconfig
# 该命令用于设置一个名为"system:kube-scheduler@kubernetes"的上下文,具体配置如下:
# 
# 1. --cluster=kubernetes: 指定集群的名称为"kubernetes",这个集群是在当前的kubeconfig文件中已经定义好的。
# 2. --user=system:kube-scheduler: 指定用户的名称为"system:kube-scheduler",这个用户也是在当前的kubeconfig文件中已经定义好的。这个用户用于认证和授权kube-scheduler组件访问Kubernetes集群的权限。
# 3. --kubeconfig=/etc/kubernetes/scheduler.kubeconfig: 指定kubeconfig文件的路径为"/etc/kubernetes/scheduler.kubeconfig",这个文件将被用来保存上下文的配置信息。
# 
# 这个命令的作用是将上述的配置信息保存到指定的kubeconfig文件中,以便后续使用该文件进行认证和授权访问Kubernetes集群。
kubectl config use-context system:kube-scheduler@kubernetes \
     --kubeconfig=/etc/kubernetes/scheduler.kubeconfig
# 上述命令是使用<code>kubectl命令来配置Kubernetes集群中的调度器组件。
# 
# 
kubectl config use-context命令用于切换kubectl当前使用的上下文。上下文是Kubernetes集群、用户和命名空间的组合,用于确定kubectl的连接目标。下面解释这个命令的不同部分:
# 
# - 
system:kube-scheduler@kubernetes是一个上下文名称。它指定了使用kube-scheduler用户和kubernetes命名空间的系统级别上下文。系统级别上下文用于操作Kubernetes核心组件。
# 
# - 
--kubeconfig=/etc/kubernetes/scheduler.kubeconfig用于指定Kubernetes配置文件的路径。Kubernetes配置文件包含连接到Kubernetes集群所需的身份验证和连接信息。
# 
# 通过运行以上命令,
kubectl将使用指定的上下文和配置文件,以便在以后的命令中能正确地与Kubernetes集群中的调度器组件进行交互。

生成admin的证书配置

cat > admin-csr.json 
# 这段代码是一个JSON格式的配置文件,用于创建和配置一个名为"admin"的Kubernetes凭证。
# 
# 这个凭证包含以下字段:
# 
# - "CN": "admin": 这是凭证的通用名称,表示这是一个管理员凭证。
# - "key": 这是一个包含证书密钥相关信息的对象。
#   - "algo": "rsa":这是使用的加密算法类型,这里是RSA加密算法。
#   - "size": 2048:这是密钥的大小,这里是2048位。
# - "names": 这是一个包含证书名称信息的数组。
#   - "C": "CN":这是证书的国家/地区字段,这里是中国。
#   - "ST": "Beijing":这是证书的省/州字段,这里是北京。
#   - "L": "Beijing":这是证书的城市字段,这里是北京。
#   - "O": "system:masters":这是证书的组织字段,这里是system:masters,表示系统的管理员组。
#   - "OU": "Kubernetes-manual":这是证书的部门字段,这里是Kubernetes-manual。
# 
# 通过这个配置文件创建的凭证将具有管理员权限,并且可以用于管理Kubernetes集群。
cfssl gencert \
   -ca=/etc/kubernetes/pki/ca.pem \
   -ca-key=/etc/kubernetes/pki/ca-key.pem \
   -config=ca-config.json \
   -profile=kubernetes \
   admin-csr.json | cfssljson -bare /etc/kubernetes/pki/admin
# 上述命令是使用cfssl工具生成Kubernetes admin的证书。
# 
# 具体解释如下:
# 
# 1. 
<code>cfssl gencert:使用cfssl工具生成证书。
# 2. 
-ca=/etc/kubernetes/pki/ca.pem:指定根证书文件的路径。在这里,是指定根证书的路径为/etc/kubernetes/pki/ca.pem。
# 3. 
-ca-key=/etc/kubernetes/pki/ca-key.pem:指定根证书私钥文件的路径。在这里,是指定根证书私钥的路径为/etc/kubernetes/pki/ca-key.pem。
# 4. 
-config=ca-config.json:指定证书配置文件的路径。在这里,是指定证书配置文件的路径为ca-config.json。
# 5. 
-profile=kubernetes:指定证书的配置文件中的一个配置文件模板。在这里,是指定配置文件中的kubernetes配置模板。
# 6. 
admin-csr.json:指定admin的证书签名请求文件(CSR)的路径。在这里,是指定请求文件的路径为admin-csr.json。
# 7. 
|(管道符号):将前一个命令的输出作为下一个命令的输入。
# 8. 
cfssljson:将cfssl工具生成的证书签名请求(CSR)进行解析。
# 9. 
-bare /etc/kubernetes/pki/admin:指定输出路径和前缀。在这里,是将解析的证书签名请求生成以下文件:/etc/kubernetes/pki/admin.pem(包含了证书)、/etc/kubernetes/pki/admin-key.pem(包含了私钥)。
# 
# 总结来说,这个命令的目的是根据根证书、根证书私钥、证书配置文件、CSR文件等生成Kubernetes Scheduler的证书和私钥文件。
# 选择使用那种高可用方案
# 若使用 haproxy、keepalived 那么为 
<code>--server=https://192.168.244.14:9443
# 若使用 nginx方案,那么为 
--server=https://127.0.0.1:8443
kubectl config set-cluster kubernetes     \
  --certificate-authority=/etc/kubernetes/pki/ca.pem     \
  --embed-certs=true     \
  --server=https://127.0.0.1:8443     \
  --kubeconfig=/etc/kubernetes/admin.kubeconfig
# 该命令用于配置一个名为"kubernetes"的集群,并将其应用到/etc/kubernetes/scheduler.kubeconfig文件中。
# 
# 该命令的解释如下:
# - 
<code>kubectl config set-cluster kubernetes: 设置一个集群并命名为"kubernetes"。
# - 
--certificate-authority=/etc/kubernetes/pki/ca.pem: 指定集群使用的证书授权机构的路径。
# - 
--embed-certs=true: 该标志指示将证书嵌入到生成的kubeconfig文件中。
# - 
--server=https://127.0.0.1:8443: 指定集群的 API server 位置。
# - 
--kubeconfig=/etc/kubernetes/admin.kubeconfig: 指定要保存 kubeconfig 文件的路径和名称。
kubectl config set-credentials kubernetes-admin  \
  --client-certificate=/etc/kubernetes/pki/admin.pem     \
  --client-key=/etc/kubernetes/pki/admin-key.pem     \
  --embed-certs=true     \
  --kubeconfig=/etc/kubernetes/admin.kubeconfig
# 这段命令是用于设置 kubernetes-admin 组件的身份验证凭据,并生成相应的 kubeconfig 文件。
# 
# 解释每个选项的含义如下:
# - 
<code>kubectl config set-credentials kubernetes-admin:设置 kubernetes-admin 用户的身份验证凭据。
# - 
--client-certificate=/etc/kubernetes/pki/admin.pem:指定一个客户端证书文件,用于基于证书的身份验证。在这种情况下,指定了 admin 组件的证书文件路径。
# - 
--client-key=/etc/kubernetes/pki/admin-key.pem:指定与客户端证书相对应的客户端私钥文件。
# - 
--embed-certs=true:将客户端证书和私钥嵌入到生成的 kubeconfig 文件中。
# - 
--kubeconfig=/etc/kubernetes/admin.kubeconfig:指定生成的 kubeconfig 文件的路径和名称。
# 
# 该命令的目的是为 admin 组件生成一个 kubeconfig 文件,以便进行身份验证和访问集群资源。kubeconfig 文件是一个包含了连接到 Kubernetes 集群所需的所有配置信息的文件,包括服务器地址、证书和秘钥等。
kubectl config set-context kubernetes-admin@kubernetes    \
  --cluster=kubernetes     \
  --user=kubernetes-admin     \
  --kubeconfig=/etc/kubernetes/admin.kubeconfig

“`

该命令用于设置一个名为”kubernetes-admin@kubernetes”的上下文,具体配置如下:

1. –cluster=kubernetes: 指定集群的名称为”kubernetes”,这个集群是在当前的kubeconfig文件中已经定义好的。

2. –user=kubernetes-admin: 指定用户的名称为”kubernetes-admin”,这个用户也是在当前的kubeconfig文件中已经定义好的。这个用户用于认证和授权admin组件访问Kubernetes集群的权限。

3. –kubeconfig=/etc/kubernetes/admin.kubeconfig: 指定kubeconfig文件的路径为”/etc/kubernetes/admin.kubeconfig”,这个文件将被用来保存上下文的配置信息。

这个命令的作用是将上述的配置信息保存到指定的kubeconfig文件中,以便后续使用该文件进行认证和授权访问Kubernetes集群。

kubectl config use-context kubernetes-admin@kubernetes –kubeconfig=/etc/kubernetes/admin.kubeconfig

上述命令是使用`kubectl`命令来配置Kubernetes集群中的调度器组件。

`kubectl config use-context`命令用于切换`kubectl`当前使用的上下文。上下文是Kubernetes集群、用户和命名空间的组合,用于确定`kubectl`的连接目标。下面解释这个命令的不同部分:

– `kubernetes-admin@kubernetes`是一个上下文名称。它指定了使用`kubernetes-admin`用户和`kubernetes`命名空间的系统级别上下文。系统级别上下文用于操作Kubernetes核心组件。

– `–kubeconfig=/etc/kubernetes/admin.kubeconfig`用于指定Kubernetes配置文件的路径。Kubernetes配置文件包含连接到Kubernetes集群所需的身份验证和连接信息。

通过运行以上命令,`kubectl`将使用指定的上下文和配置文件,以便在以后的命令中能正确地与Kubernetes集群中的调度器组件进行交互。


创建kube-proxy证书
选择使用那种高可用方案 若使用 haproxy、keepalived 那么为 --server=https://192.168.244.14:9443 若使用 nginx方案,那么为 --server=https://127.0.0.1:8443

cat > kube-proxy-csr.json << EOF { "CN": "system:kube-proxy", "key": { "algo": "rsa", "size": 2048 }, "names": [ { "C": "CN", "ST": "Beijing", "L": "Beijing", "O": "system:kube-proxy", "OU": "Kubernetes-manual" } ] } EOF

这段代码是一个JSON格式的配置文件,用于创建和配置一个名为”kube-proxy-csr”的Kubernetes凭证。

这个凭证包含以下字段:

– “CN”: “system:kube-proxy”: 这是凭证的通用名称,表示这是一个管理员凭证。

– “key”: 这是一个包含证书密钥相关信息的对象。

– “algo”: “rsa”:这是使用的加密算法类型,这里是RSA加密算法。

– “size”: 2048:这是密钥的大小,这里是2048位。

– “names”: 这是一个包含证书名称信息的数组。

– “C”: “CN”:这是证书的国家/地区字段,这里是中国。

– “ST”: “Beijing”:这是证书的省/州字段,这里是北京。

– “L”: “Beijing”:这是证书的城市字段,这里是北京。

– “O”: “system:kube-proxy”:这是证书的组织字段,这里是system:kube-proxy。

– “OU”: “Kubernetes-manual”:这是证书的部门字段,这里是Kubernetes-manual。

通过这个配置文件创建的凭证将具有管理员权限,并且可以用于管理Kubernetes集群。

cfssl gencert \ -ca=/etc/kubernetes/pki/ca.pem \ -ca-key=/etc/kubernetes/pki/ca-key.pem \ -config=ca-config.json \ -profile=kubernetes \ kube-proxy-csr.json | cfssljson -bare /etc/kubernetes/pki/kube-proxy

上述命令是使用cfssl工具生成Kubernetes admin的证书。

具体解释如下:

1. `cfssl gencert`:使用cfssl工具生成证书。

2. `-ca=/etc/kubernetes/pki/ca.pem`:指定根证书文件的路径。在这里,是指定根证书的路径为`/etc/kubernetes/pki/ca.pem`。

3. `-ca-key=/etc/kubernetes/pki/ca-key.pem`:指定根证书私钥文件的路径。在这里,是指定根证书私钥的路径为`/etc/kubernetes/pki/ca-key.pem`。

4. `-config=ca-config.json`:指定证书配置文件的路径。在这里,是指定证书配置文件的路径为`ca-config.json`。

5. `-profile=kubernetes`:指定证书的配置文件中的一个配置文件模板。在这里,是指定配置文件中的`kubernetes`配置模板。

6. `kube-proxy-csr.json`:指定admin的证书签名请求文件(CSR)的路径。在这里,是指定请求文件的路径为`kube-proxy-csr.json`。

7. `|`(管道符号):将前一个命令的输出作为下一个命令的输入。

8. `cfssljson`:将cfssl工具生成的证书签名请求(CSR)进行解析。

9. `-bare /etc/kubernetes/pki/kube-proxy`:指定输出路径和前缀。在这里,是将解析的证书签名请求生成以下文件:`/etc/kubernetes/pki/kube-proxy.pem`(包含了证书)、`/etc/kubernetes/pki/kube-proxy-key.pem`(包含了私钥)。

总结来说,这个命令的目的是根据根证书、根证书私钥、证书配置文件、CSR文件等生成Kubernetes Scheduler的证书和私钥文件。


创建kube-proxy证书

选择使用那种高可用方案

若使用 haproxy、keepalived 那么为 `–server=https://192.168.244.14:9443`;

若使用 nginx方案,那么为 `–server=https://127.0.0.1:8443`;

kubectl config set-cluster kubernetes \ –certificate-authority=/etc/kubernetes/pki/ca.pem \ –embed-certs=true \ –server=https://127.0.0.1:8443 \ –kubeconfig=/etc/kubernetes/kube-proxy.kubeconfig

该命令用于配置一个名为”kubernetes”的集群,并将其应用到/etc/kubernetes/kube-proxy.kubeconfig文件中。

该命令的解释如下:

– `kubectl config set-cluster kubernetes`: 设置一个集群并命名为”kubernetes”。

– `–certificate-authority=/etc/kubernetes/pki/ca.pem`: 指定集群使用的证书授权机构的路径。

– `–embed-certs=true`: 该标志指示将证书嵌入到生成的kubeconfig文件中。

– `–server=https://127.0.0.1:8443`;: 指定集群的 API server 位置。

– `–kubeconfig=/etc/kubernetes/kube-proxy.kubeconfig`: 指定要保存 kubeconfig 文件的路径和名称。

kubectl config set-credentials kube-proxy \ –client-certificate=/etc/kubernetes/pki/kube-proxy.pem \ –client-key=/etc/kubernetes/pki/kube-proxy-key.pem \ –embed-certs=true \ –kubeconfig=/etc/kubernetes/kube-proxy.kubeconfig

这段命令是用于设置 kube-proxy 组件的身份验证凭据,并生成相应的 kubeconfig 文件。

解释每个选项的含义如下:

– `kubectl config set-credentials kube-proxy`:设置 `kube-proxy` 用户的身份验证凭据。

– `–client-certificate=/etc/kubernetes/pki/kube-proxy.pem`:指定一个客户端证书文件,用于基于证书的身份验证。在这种情况下,指定了 kube-proxy 组件的证书文件路径。

– `–client-key=/etc/kubernetes/pki/kube-proxy-key.pem`:指定与客户端证书相对应的客户端私钥文件。

– `–embed-certs=true`:将客户端证书和私钥嵌入到生成的 kubeconfig 文件中。

– `–kubeconfig=/etc/kubernetes/kube-proxy.kubeconfig`:指定生成的 kubeconfig 文件的路径和名称。

该命令的目的是为 kube-proxy 组件生成一个 kubeconfig 文件,以便进行身份验证和访问集群资源。kubeconfig 文件是一个包含了连接到 Kubernetes 集群所需的所有配置信息的文件,包括服务器地址、证书和秘钥等。

kubectl config set-context kube-proxy@kubernetes \ –cluster=kubernetes \ –user=kube-proxy \ –kubeconfig=/etc/kubernetes/kube-proxy.kubeconfig

该命令用于设置一个名为”kube-proxy@kubernetes”的上下文,具体配置如下:

1. –cluster=kubernetes: 指定集群的名称为”kubernetes”,这个集群是在当前的kubeconfig文件中已经定义好的。

2. –user=kube-proxy: 指定用户的名称为”kube-proxy”,这个用户也是在当前的kubeconfig文件中已经定义好的。这个用户用于认证和授权kube-proxy组件访问Kubernetes集群的权限。

3. –kubeconfig=/etc/kubernetes/kube-proxy.kubeconfig: 指定kubeconfig文件的路径为”/etc/kubernetes/kube-proxy.kubeconfig”,这个文件将被用来保存上下文的配置信息。

这个命令的作用是将上述的配置信息保存到指定的kubeconfig文件中,以便后续使用该文件进行认证和授权访问Kubernetes集群。

kubectl config use-context kube-proxy@kubernetes –kubeconfig=/etc/kubernetes/kube-proxy.kubeconfig

上述命令是使用`kubectl`命令来配置Kubernetes集群中的调度器组件。

`kubectl config use-context`命令用于切换`kubectl`当前使用的上下文。上下文是Kubernetes集群、用户和命名空间的组合,用于确定`kubectl`的连接目标。下面解释这个命令的不同部分:

– `kube-proxy@kubernetes`是一个上下文名称。它指定了使用`kube-proxy`用户和`kubernetes`命名空间的系统级别上下文。系统级别上下文用于操作Kubernetes核心组件。

– `–kubeconfig=/etc/kubernetes/kube-proxy.kubeconfig`用于指定Kubernetes配置文件的路径。Kubernetes配置文件包含连接到Kubernetes集群所需的身份验证和连接信息。

通过运行以上命令,`kubectl`将使用指定的上下文和配置文件,以便在以后的命令中能正确地与Kubernetes集群中的调度器组件进行交互。


### 创建ServiceAccount Key ——secret

openssl genrsa -out /etc/kubernetes/pki/sa.key 2048 openssl rsa -in /etc/kubernetes/pki/sa.key -pubout -out /etc/kubernetes/pki/sa.pub

这两个命令是使用OpenSSL工具生成RSA密钥对。

命令1:openssl genrsa -out /etc/kubernetes/pki/sa.key 2048

该命令用于生成私钥文件。具体解释如下:

– openssl:openssl命令行工具。

– genrsa:生成RSA密钥对。

– -out /etc/kubernetes/pki/sa.key:指定输出私钥文件的路径和文件名。

– 2048:指定密钥长度为2048位。

命令2:openssl rsa -in /etc/kubernetes/pki/sa.key -pubout -out /etc/kubernetes/pki/sa.pub

该命令用于从私钥中导出公钥。具体解释如下:

– openssl:openssl命令行工具。

– rsa:与私钥相关的RSA操作。

– -in /etc/kubernetes/pki/sa.key:指定输入私钥文件的路径和文件名。

– -pubout:指定输出公钥。

– -out /etc/kubernetes/pki/sa.pub:指定输出公钥文件的路径和文件名。

总结:通过以上两个命令,我们可以使用OpenSSL工具生成一个RSA密钥对,并将私钥保存在/etc/kubernetes/pki/sa.key文件中,将公钥保存在/etc/kubernetes/pki/sa.pub文件中。


### 将证书发送到其他master节点

其他节点创建目录

mkdir /etc/kubernetes/pki/ -p

for NODE in dev-k8s-master02 dev-k8s-master03; do for FILE in $(ls /etc/kubernetes/pki | grep -v etcd); do scp /etc/kubernetes/pki/${FILE} $NODE:/etc/kubernetes/pki/${FILE}; done; for FILE in admin.kubeconfig controller-manager.kubeconfig scheduler.kubeconfig; do scp /etc/kubernetes/${FILE} $NODE:/etc/kubernetes/${FILE}; done; done


### 查看证书
ls /etc/kubernetes/pki/

admin.csr apiserver.pem controller-manager-key.pem front-proxy-client.csr scheduler.csr admin-key.pem ca.csr controller-manager.pem front-proxy-client-key.pem scheduler-key.pem admin.pem ca-key.pem front-proxy-ca.csr front-proxy-client.pem scheduler.pem apiserver.csr ca.pem front-proxy-ca-key.pem sa.key apiserver-key.pem controller-manager.csr front-proxy-ca.pem sa.pub


### k8s系统组件配置
etcd配置
这个配置文件是用于 etcd 集群的配置,其中包含了一些重要的参数和选项:
  • `name`:指定了当前节点的名称,用于集群中区分不同的节点。
  • `data-dir`:指定了 etcd 数据的存储目录。
  • `wal-dir`:指定了 etcd 数据写入磁盘的目录。
  • `snapshot-count`:指定了触发快照的事务数量。
  • `heartbeat-interval`:指定了 etcd 集群中节点之间的心跳间隔。
  • `election-timeout`:指定了选举超时时间。
  • `quota-backend-bytes`:指定了存储的限额,0 表示无限制。
  • `listen-peer-urls`:指定了节点之间通信的 URL,使用 HTTPS 协议。
  • `listen-client-urls`:指定了客户端访问 etcd 集群的 URL,同时提供了本地访问的 URL。
  • `max-snapshots`:指定了快照保留的数量。
  • `max-wals`:指定了日志保留的数量。
  • `initial-advertise-peer-urls`:指定了节点之间通信的初始 URL。
  • `advertise-client-urls`:指定了客户端访问 etcd 集群的初始 URL。
  • `discovery`:定义了 etcd 集群发现相关的选项。
  • `initial-cluster`:指定了 etcd 集群的初始成员。
  • `initial-cluster-token`:指定了集群的 token。
  • `initial-cluster-state`:指定了集群的初始状态。
  • `strict-reconfig-check`:指定了严格的重新配置检查选项。
  • `enable-v2`:启用了 v2 API。
  • `enable-pprof`:启用了性能分析。
  • `proxy`:设置了代理模式。
  • `client-transport-security`:客户端的传输安全配置。
  • `peer-transport-security`:节点之间的传输安全配置。
  • `debug`:是否启用调试模式。
  • `log-package-levels`:日志的输出级别。
  • `log-outputs`:指定了日志的输出类型。
  • `force-new-cluster`:是否强制创建一个新的集群。

这些参数和选项可以根据实际需求进行调整和配置。

master01配置

如果要用IPv6那么把IPv4地址修改为IPv6即可


cat > /etc/etcd/etcd.config.yml << EOF 
name: 'dev-k8s-master01'
data-dir: /var/lib/etcd
wal-dir: /var/lib/etcd/wal
snapshot-count: 5000
heartbeat-interval: 100
election-timeout: 1000
quota-backend-bytes: 0
listen-peer-urls: 'https://192.168.244.14:2380'
listen-client-urls: 'https://192.168.244.14:2379,http://127.0.0.1:2379'
max-snapshots: 3
max-wals: 5
cors:
initial-advertise-peer-urls: 'https://192.168.244.14:2380'
advertise-client-urls: 'https://192.168.244.14:2379'
discovery:
discovery-fallback: 'proxy'
discovery-proxy:
discovery-srv:
initial-cluster: 'dev-k8s-master01=https://192.168.244.14:2380'
initial-cluster-token: 'etcd-k8s-cluster'
initial-cluster-state: 'new'
strict-reconfig-check: false
enable-v2: true
enable-pprof: true
proxy: 'off'
proxy-failure-wait: 5000
proxy-refresh-interval: 30000
proxy-dial-timeout: 1000
proxy-write-timeout: 5000
proxy-read-timeout: 0
client-transport-security:
  cert-file: '/etc/kubernetes/pki/etcd/etcd.pem'
  key-file: '/etc/kubernetes/pki/etcd/etcd-key.pem'
  client-cert-auth: true
  trusted-ca-file: '/etc/kubernetes/pki/etcd/etcd-ca.pem'
  auto-tls: true
peer-transport-security:
  cert-file: '/etc/kubernetes/pki/etcd/etcd.pem'
  key-file: '/etc/kubernetes/pki/etcd/etcd-key.pem'
  peer-client-cert-auth: true
  trusted-ca-file: '/etc/kubernetes/pki/etcd/etcd-ca.pem'
  auto-tls: true
debug: false
log-package-levels:
log-outputs: [default]
force-new-cluster: false
EOF

创建service(所有master节点操作)

创建etcd.service并启动

cat > /usr/lib/systemd/system/etcd.service << EOF
[Unit]
Description=Etcd Service
Documentation=https://coreos.com/etcd/docs/latest/
After=network.target

[Service]
Type=notify
ExecStart=/usr/local/bin/etcd --config-file=/etc/etcd/etcd.config.yml
Restart=on-failure
RestartSec=10
LimitNOFILE=65536

[Install]
WantedBy=multi-user.target
Alias=etcd3.service

EOF
# 这是一个系统服务配置文件,用于启动和管理Etcd服务。
# 
# [Unit] 部分包含了服务的一些基本信息,它定义了服务的描述和文档链接,并指定了服务应在网络连接之后启动。
# 
# [Service] 部分定义了服务的具体配置。在这里,服务的类型被设置为notify,意味着当服务成功启动时,它将通知系统。ExecStart 指定了启动服务时要执行的命令,这里是运行 /usr/local/bin/etcd 命令并传递一个配置文件 /etc/etcd/etcd.config.yml。Restart 设置为 on-failure,意味着当服务失败时将自动重启,并且在10秒后进行重启。LimitNOFILE 指定了服务的最大文件打开数。
# 
# [Install] 部分定义了服务的安装配置。WantedBy 指定了服务应该被启动的目标,这里是 multi-user.target,表示在系统进入多用户模式时启动。Alias 定义了一个别名,可以通过etcd3.service来引用这个服务。
# 
# 这个配置文件描述了如何启动和管理Etcd服务,并将其安装到系统中。通过这个配置文件,可以确保Etcd服务在系统启动后自动启动,并在出现问题时进行重启。

创建etcd证书目录

mkdir /etc/kubernetes/pki/etcd
ln -s /etc/etcd/ssl/* /etc/kubernetes/pki/etcd/

systemctl daemon-reload  
# 用于重新加载systemd管理的单位文件。当你新增或修改了某个单位文件(如.service文件、.socket文件等),需要运行该命令来刷新systemd对该文件的配置。

systemctl enable --now etcd.service
# 启用并立即启动etcd.service单元。etcd.service是etcd守护进程的systemd服务单元。

systemctl restart etcd.service
# 重启etcd.service单元,即重新启动etcd守护进程。

systemctl status etcd.service
# etcd.service单元的当前状态,包括运行状态、是否启用等信息。

查看etcd状态

如果要用IPv6那么把IPv4地址修改为IPv6即可

export ETCDCTL_API=3
etcdctl --endpoints="192.168.244.14:2379" --cacert=/etc/kubernetes/pki/etcd/etcd-ca.pem --cert=/etc/kubernetes/pki/etcd/etcd.pem --key=/etc/kubernetes/pki/etcd/etcd-key.pem  endpoint status --write-out=table
+---------------------+------------------+---------+---------+-----------+------------+-----------+------------+--------------------+--------+
|      ENDPOINT       |        ID        | VERSION | DB SIZE | IS LEADER | IS LEARNER | RAFT TERM | RAFT INDEX | RAFT APPLIED INDEX | ERRORS |
+---------------------+------------------+---------+---------+-----------+------------+-----------+------------+--------------------+--------+
| 192.168.244.14:2379 | fa8e297f3f09517f |  3.5.12 |   20 kB |      true |      false |         3 |          6 |                  6 |        |
+---------------------+------------------+---------+---------+-----------+------------+-----------+------------+--------------------+--------+
# 这个命令是使用etcdctl工具,用于查看指定etcd集群的健康状态。下面是每个参数的详细解释:
# 
# - `--endpoints`:指定要连接的etcd集群节点的地址和端口。在这个例子中,指定了3个节点的地址和端口,分别是`192.168.1.33:2379,192.168.1.32:2379,192.168.1.31:2379`。
# - `--cacert`:指定用于验证etcd服务器证书的CA证书的路径。在这个例子中,指定了CA证书的路径为`/etc/kubernetes/pki/etcd/etcd-ca.pem`。CA证书用于验证etcd服务器证书的有效性。
# - `--cert`:指定用于与etcd服务器进行通信的客户端证书的路径。在这个例子中,指定了客户端证书的路径为`/etc/kubernetes/pki/etcd/etcd.pem`。客户端证书用于在与etcd服务器建立安全通信时进行身份验证。
# - `--key`:指定与客户端证书配对的私钥的路径。在这个例子中,指定了私钥的路径为`/etc/kubernetes/pki/etcd/etcd-key.pem`。私钥用于对通信进行加密解密和签名验证。
# - `endpoint status`:子命令,用于检查etcd集群节点的健康状态。
# - `--write-out`:指定输出的格式。在这个例子中,指定以表格形式输出。
# 
# 通过执行这个命令,可以获取到etcd集群节点的健康状态,并以表格形式展示。

查看calico数据

etcdctl –endpoints=”192.168.244.14:2379″ –cacert=/etc/kubernetes/pki/etcd/etcd-ca.pem –cert=/etc/kubernetes/pki/etcd/etcd.pem –key=/etc/kubernetes/pki/etcd/etcd-key.pem get /registry/crd.projectcalico.org/ –prefix –keys-only

/registry/crd.projectcalico.org/blockaffinities/dev-k8s-master01.local-172-17-50-192-26

/registry/crd.projectcalico.org/blockaffinities/dev-k8s-node01.local-172-21-244-64-26

/registry/crd.projectcalico.org/blockaffinities/dev-k8s-node02.local-172-22-227-64-26

/registry/crd.projectcalico.org/clusterinformations/default

/registry/crd.projectcalico.org/felixconfigurations/default

/registry/crd.projectcalico.org/ipamblocks/172-17-50-192-26

/registry/crd.projectcalico.org/ipamblocks/172-21-244-64-26

/registry/crd.projectcalico.org/ipamblocks/172-22-227-64-26

/registry/crd.projectcalico.org/ipamconfigs/default

/registry/crd.projectcalico.org/ipamhandles/ipip-tunnel-addr-dev-k8s-master01.local

/registry/crd.projectcalico.org/ipamhandles/ipip-tunnel-addr-dev-k8s-node01.local

/registry/crd.projectcalico.org/ipamhandles/ipip-tunnel-addr-dev-k8s-node02.local

/registry/crd.projectcalico.org/ipamhandles/k8s-pod-network.96126796171ab0ac6b9081542112c9be79e02a006351a7fec66f389870b82983

/registry/crd.projectcalico.org/ipamhandles/k8s-pod-network.d278382a1b5a5b16faeebfc7e75ce83b2021962eeea3a754c107d51470063008

/registry/crd.projectcalico.org/ipamhandles/k8s-pod-network.d6236f8b68ef7f04d099ceef31b9861869c8af6b09e6c19be60ba7c124e49000

/registry/crd.projectcalico.org/ipamhandles/k8s-pod-network.e5d490330b24e0f953c525e9f81c77ea8fdcb71f2df06b0040d9d57b9678d984

/registry/crd.projectcalico.org/ippools/default-ipv4-ippool

/registry/crd.projectcalico.org/kubecontrollersconfigurations/default

NGINX高可用方案

安装编译环境

yum install gcc -y

下载解压nginx二进制文件

wget http://nginx.org/download/nginx-1.25.3.tar.gz
tar xvf nginx- .tar.gz
cd nginx-

进行编译

./configure –with-stream –without-http –without-http_uwsgi_module –without-http_scgi_module –without-http_fastcgi_module make && make install

分发编译好的nginx

Master=’dev-k8s-master02 dev-k8s-master03′
Work=’dev-k8s-node01 dev-k8s-node02′
for NODE in $Master; do scp -r /usr/local/nginx/ $NODE:/usr/local/nginx/; done
for NODE in $Work; do scp -r /usr/local/nginx/ $NODE:/usr/local/nginx/; done

# 这是一系列命令行指令,用于编译和安装软件。
# 
# 1. `./configure` 是用于配置软件的命令。在这个例子中,配置的软件是一个Web服务器,指定了一些选项来启用流模块,并禁用了HTTP、uwsgi、scgi和fastcgi模块。
# 2. `--with-stream` 指定启用流模块。流模块通常用于代理TCP和UDP流量。
# 3. `--without-http` 指定禁用HTTP模块。这意味着编译的软件将没有HTTP服务器功能。
# 4. `--without-http_uwsgi_module` 指定禁用uwsgi模块。uwsgi是一种Web服务器和应用服务器之间的通信协议。
# 5. `--without-http_scgi_module` 指定禁用scgi模块。scgi是一种用于将Web服务器请求传递到应用服务器的协议。
# 6. `--without-http_fastcgi_module` 指定禁用fastcgi模块。fastcgi是一种用于在Web服务器和应用服务器之间交换数据的协议。
# 7. `make` 是用于编译软件的命令。该命令将根据之前的配置生成可执行文件。
# 8. `make install` 用于安装软件。该命令将生成的可执行文件和其他必要文件复制到系统的适当位置,以便可以使用该软件。
# 
# 总之,这个命令序列用于编译一个配置了特定选项的Web服务器,并将其安装到系统中。

写入nginx配置文件

cat > /usr/local/nginx/conf/kube-nginx.conf <<EOF
worker_processes 1;
events {
    worker_connections  1024;
}
stream {
    upstream backend {
        least_conn;
        hash $remote_addr consistent;
        server 192.168.244.14:6443        max_fails=3 fail_timeout=30s;
    }
    server {
        listen 127.0.0.1:8443;
        proxy_connect_timeout 1s;
        proxy_pass backend;
    }
}
EOF
# 这段配置是一个nginx的stream模块的配置,用于代理TCP和UDP流量。
# 
# 首先,`worker_processes 1;`表示启动一个worker进程用于处理流量。
# 接下来,`events { worker_connections 1024; }`表示每个worker进程可以同时处理最多1024个连接。
# 在stream块里面,定义了一个名为`backend`的upstream,用于负载均衡和故障转移。
# `least_conn`表示使用最少连接算法进行负载均衡。
# `hash $remote_addr consistent`表示用客户端的IP地址进行哈希分配请求,保持相同IP的请求始终访问同一台服务器。
# `server`指令用于定义后端的服务器,每个服务器都有一个IP地址和端口号,以及一些可选的参数。
# `max_fails=3`表示当一个服务器连续失败3次时将其标记为不可用。
# `fail_timeout=30s`表示如果一个服务器被标记为不可用,nginx将在30秒后重新尝试。
# 在server块内部,定义了一个监听地址为127.0.0.1:8443的服务器。
# `proxy_connect_timeout 1s`表示与后端服务器建立连接的超时时间为1秒。
# `proxy_pass backend`表示将流量代理到名为backend的上游服务器组。
# 
# 总结起来,这段配置将流量代理到一个包含3个后端服务器的上游服务器组中,使用最少连接算法进行负载均衡,并根据客户端的IP地址进行哈希分配请求。如果一个服务器连续失败3次,则将其标记为不可用,并在30秒后重新尝试。

写入启动配置文件

cat > /etc/systemd/system/kube-nginx.service <<EOF
[Unit]
Description=kube-apiserver nginx proxy
After=network.target
After=network-online.target
Wants=network-online.target

[Service]
Type=forking
ExecStartPre=/usr/local/nginx/sbin/nginx -c /usr/local/nginx/conf/kube-nginx.conf -p /usr/local/nginx -t
ExecStart=/usr/local/nginx/sbin/nginx -c /usr/local/nginx/conf/kube-nginx.conf -p /usr/local/nginx
ExecReload=/usr/local/nginx/sbin/nginx -c /usr/local/nginx/conf/kube-nginx.conf -p /usr/local/nginx -s reload
PrivateTmp=true
Restart=always
RestartSec=5
StartLimitInterval=0
LimitNOFILE=65536

[Install]
WantedBy=multi-user.target
EOF
# 
# [Unit]部分包含了单位的描述和依赖关系。它指定了在network.target和network-online.target之后启动,并且需要network-online.target。
# 
# [Service]部分定义了如何运行该服务。Type指定了服务进程的类型(forking表示主进程会派生一个子进程)。ExecStartPre指定了在服务启动之前需要运行的命令,用于检查NGINX配置文件的语法是否正确。ExecStart指定了启动服务所需的命令。ExecReload指定了在重新加载配置文件时运行的命令。PrivateTmp设置为true表示将为服务创建一个私有的临时文件系统。Restart和RestartSec用于设置服务的自动重启机制。StartLimitInterval设置为0表示无需等待,可以立即重启服务。LimitNOFILE指定了服务的文件描述符的限制。
# 
# [Install]部分指定了在哪些target下该单位应该被启用。
# 
# 综上所述,此单位文件用于启动和管理kube-apiserver的NGINX代理服务。它通过NGINX来反向代理和负载均衡kube-apiserver的请求。该服务会在系统启动时自动启动,并具有自动重启的机制。

设置开机自启

systemctl daemon-reload

# 用于重新加载systemd管理的单位文件。当你新增或修改了某个单位文件(如.service文件、.socket文件等),需要运行该命令来刷新systemd对该文件的配置。
systemctl enable --now kube-nginx.service
# 启用并立即启动kube-nginx.service单元。kube-nginx.service是kube-nginx守护进程的systemd服务单元。
systemctl restart kube-nginx.service
# 重启kube-nginx.service单元,即重新启动kube-nginx守护进程。
systemctl status kube-nginx.service
# kube-nginx.service单元的当前状态,包括运行状态、是否启用等信息。

测试

每个node上
telnet 127.0.0.1 8443

Trying 127.0.0.1...
Connected to 127.0.0.1.
Escape character is '^]'.
^CConnection closed by foreign host.

curl https://127.0.0.1:8443/healthz -k
ok
curl https://192.168.244.14:6443/healthz -k
ok
curl https://192.168.244.14:8443/healthz -k
ok

k8s组件配置

所有k8s节点创建以下目录

mkdir -p /etc/kubernetes/manifests/ /etc/systemd/system/kubelet.service.d /var/lib/kubelet /var/log/kubernetes

创建apiserver(所有master节点)

master01节点配置

cat > /usr/lib/systemd/system/kube-apiserver.service << EOF

[Unit]
Description=Kubernetes API Server
Documentation=https://github.com/kubernetes/kubernetes
After=network.target

[Service]
ExecStart=/usr/local/bin/kube-apiserver \\
      --v=2  \\
      --allow-privileged=true  \\
      --bind-address=0.0.0.0  \\
      --secure-port=6443  \\
      --advertise-address=192.168.244.14 \\
      --service-cluster-ip-range=10.96.0.0/12 \\
      --service-node-port-range=30000-32767  \\
      --etcd-servers=https://192.168.244.14:2379 \\
      --etcd-cafile=/etc/etcd/ssl/etcd-ca.pem  \\
      --etcd-certfile=/etc/etcd/ssl/etcd.pem  \\
      --etcd-keyfile=/etc/etcd/ssl/etcd-key.pem  \\
      --client-ca-file=/etc/kubernetes/pki/ca.pem  \\
      --tls-cert-file=/etc/kubernetes/pki/apiserver.pem  \\
      --tls-private-key-file=/etc/kubernetes/pki/apiserver-key.pem  \\
      --kubelet-client-certificate=/etc/kubernetes/pki/apiserver.pem  \\
      --kubelet-client-key=/etc/kubernetes/pki/apiserver-key.pem  \\
      --service-account-key-file=/etc/kubernetes/pki/sa.pub  \\
      --service-account-signing-key-file=/etc/kubernetes/pki/sa.key  \\
      --service-account-issuer=https://kubernetes.default.svc.cluster.local \\
      --kubelet-preferred-address-types=InternalIP,ExternalIP,Hostname  \\
      --enable-admission-plugins=NamespaceLifecycle,LimitRanger,ServiceAccount,DefaultStorageClass,DefaultTolerationSeconds,NodeRestriction,ResourceQuota  \
      --authorization-mode=Node,RBAC  \\
      --enable-bootstrap-token-auth=true  \\
      --requestheader-client-ca-file=/etc/kubernetes/pki/front-proxy-ca.pem  \\
      --proxy-client-cert-file=/etc/kubernetes/pki/front-proxy-client.pem  \\
      --proxy-client-key-file=/etc/kubernetes/pki/front-proxy-client-key.pem  \\
      --requestheader-allowed-names=aggregator  \\
      --requestheader-group-headers=X-Remote-Group  \\
      --requestheader-extra-headers-prefix=X-Remote-Extra-  \\
      --requestheader-username-headers=X-Remote-User \\
      --enable-aggregator-routing=true
Restart=on-failure
RestartSec=10s
LimitNOFILE=65535

[Install]
WantedBy=multi-user.target

EOF

该配置文件是用于定义Kubernetes API Server的systemd服务的配置。systemd是一个用于启动和管理Linux系统服务的守护进程。

[Unit]

  • Description: 服务的描述信息,用于显示在日志和系统管理工具中。
  • Documentation: 提供关于服务的文档链接。
  • After: 规定服务依赖于哪些其他服务或单元。在这个例子中,API Server服务在网络目标启动之后启动。

[Service]

  • ExecStart: 定义服务的命令行参数和命令。这里指定了API Server的启动命令,包括各种参数选项。
  • Restart: 指定当服务退出时应该如何重新启动。在这个例子中,服务在失败时将被重新启动。
  • RestartSec: 指定两次重新启动之间的等待时间。
  • LimitNOFILE: 指定进程可以打开的文件描述符的最大数量。

[Install]

  • WantedBy: 指定服务应该安装到哪个系统目标。在这个例子中,服务将被安装到multi-user.target目标,以便在多用户模式下启动。

上述配置文件中定义的kube-apiserver服务将以指定的参数运行,这些参数包括:

- `--v=2` 指定日志级别为2,打印详细的API Server日志。
- `--allow-privileged=true` 允许特权容器运行。
- `--bind-address=0.0.0.0` 绑定API Server监听的IP地址。
- `--secure-port=6443` 指定API Server监听的安全端口。
- `--advertise-address=192.168.1.31` 广告API Server的地址。
- `--service-cluster-ip-range=10.96.0.0/12,fd00:1111::/112` 指定服务CIDR范围。
- `--service-node-port-range=30000-32767` 指定NodePort的范围。
- `--etcd-servers=https://192.168.1.31:2379,https://192.168.1.32:2379,https://192.168.1.33:2379` 指定etcd服务器的地址。
- `--etcd-cafile` 指定etcd服务器的CA证书。
- `--etcd-certfile` 指定etcd服务器的证书。
- `--etcd-keyfile` 指定etcd服务器的私钥。
- `--client-ca-file` 指定客户端CA证书。
- `--tls-cert-file` 指定服务的证书。
- `--tls-private-key-file` 指定服务的私钥。
- `--kubelet-client-certificate` 和 `--kubelet-client-key` 指定与kubelet通信的客户端证书和私钥。
- `--service-account-key-file` 指定服务账户公钥文件。
- `--service-account-signing-key-file` 指定服务账户签名密钥文件。
- `--service-account-issuer` 指定服务账户的发布者。
- `--kubelet-preferred-address-types` 指定kubelet通信时的首选地址类型。
- `--enable-admission-plugins` 启用一系列准入插件。
- `--authorization-mode` 指定授权模式。
- `--enable-bootstrap-token-auth` 启用引导令牌认证。
- `--requestheader-client-ca-file` 指定请求头中的客户端CA证书。
- `--proxy-client-cert-file` 和 `--proxy-client-key-file` 指定代理客户端的证书和私钥。
- `--requestheader-allowed-names` 指定请求头中允许的名字。
- `--requestheader-group-headers` 指定请求头中的组头。
- `--requestheader-extra-headers-prefix` 指定请求头中的额外头前缀。
- `--requestheader-username-headers` 指定请求头中的用户名头。
- `--enable-aggregator-routing` 启用聚合路由。

整个配置文件为Kubernetes API Server提供了必要的参数,以便正确地启动和运行。

systemctl daemon-reload
# 用于重新加载systemd管理的单位文件。当你新增或修改了某个单位文件(如.service文件、.socket文件等),需要运行该命令来刷新systemd对该文件的配置。

systemctl enable --now kube-apiserver.service
# 启用并立即启动kube-apiserver.service单元。kube-apiserver.service是kube-apiserver守护进程的systemd服务单元。

systemctl restart kube-apiserver.service
# 重启kube-apiserver.service单元,即重新启动etcd守护进程。

systemctl status kube-apiserver.service
# kube-apiserver.service单元的当前状态,包括运行状态、是否启用等信息。

配置kube-controller-manager service

所有master节点配置,且配置相同
172.16.0.0/12为pod网段,按需求设置你自己的网段

cat > /usr/lib/systemd/system/kube-controller-manager.service << EOF

[Unit]
Description=Kubernetes Controller Manager
Documentation=https://github.com/kubernetes/kubernetes
After=network.target

[Service]
ExecStart=/usr/local/bin/kube-controller-manager \\
      --v=2 \\
      --bind-address=0.0.0.0 \\
      --root-ca-file=/etc/kubernetes/pki/ca.pem \\
      --cluster-signing-cert-file=/etc/kubernetes/pki/ca.pem \\
      --cluster-signing-key-file=/etc/kubernetes/pki/ca-key.pem \\
      --service-account-private-key-file=/etc/kubernetes/pki/sa.key \\
      --kubeconfig=/etc/kubernetes/controller-manager.kubeconfig \\
      --leader-elect=true \\
      --use-service-account-credentials=true \\
      --node-monitor-grace-period=40s \\
      --node-monitor-period=5s \\
      --controllers=*,bootstrapsigner,tokencleaner \\
      --allocate-node-cidrs=true \\
      --service-cluster-ip-range=10.96.0.0/12 \\
      --cluster-cidr=172.16.0.0/12 \\
      --node-cidr-mask-size-ipv4=24 \\
      --requestheader-client-ca-file=/etc/kubernetes/pki/front-proxy-ca.pem

Restart=always
RestartSec=10s

[Install]
WantedBy=multi-user.target

EOF

这是一个用于启动 Kubernetes 控制器管理器的 systemd 服务单元文件。下面是对每个部分的详细解释:

[Unit]:单元的基本信息部分,用于描述和标识这个服务单元。

  • Description:服务单元的描述信息,说明了该服务单元的作用,这里是 Kubernetes 控制器管理器。
  • Documentation:可选项,提供了关于该服务单元的文档链接。
  • After:定义了该服务单元在哪些其他单元之后启动,这里是 network.target,即在网络服务启动之后启动。

[Service]:定义了服务的运行参数和行为。

  • ExecStart:指定服务启动时执行的命令,这里是 /usr/local/bin/kube-controller-manager,并通过后续+ 的行继续传递了一系列的参数设置。
  • Restart:定义了服务在退出后的重新启动策略,这里设置为 always,表示总是重新启动服务。
  • RestartSec:定义了重新启动服务的时间间隔,这里设置为 10 秒。

[Install]:定义了如何安装和启用服务单元。

  • WantedBy:指定了服务单元所属的 target,这里是 multi-user.target,表示启动多用户模式下的服务。 在 ExecStart 中传递的参数说明如下:
--v=2:设置日志的详细级别为 2。
--bind-address=0.0.0.0:绑定的 IP 地址,用于监听 Kubernetes 控制平面的请求,这里设置为 0.0.0.0,表示监听所有网络接口上的请求。
--root-ca-file:根证书文件的路径,用于验证其他组件的证书。
--cluster-signing-cert-file:用于签名集群证书的证书文件路径。
--cluster-signing-key-file:用于签名集群证书的私钥文件路径。
--service-account-private-key-file:用于签名服务账户令牌的私钥文件路径。
--kubeconfig:kubeconfig 文件的路径,包含了与 Kubernetes API 服务器通信所需的配置信息。
--leader-elect=true:启用 Leader 选举机制,确保只有一个控制器管理器作为 leader 在运行。
--use-service-account-credentials=true:使用服务账户的凭据进行认证和授权。
--node-monitor-grace-period=40s:节点监控的优雅退出时间,节点长时间不响应时会触发节点驱逐。
--node-monitor-period=5s:节点监控的检测周期,用于检测节点是否正常运行。
--controllers:指定要运行的控制器类型,在这里使用了通配符 *,表示运行所有的控制器,同时还包括了 bootstrapsigner 和 tokencleaner 控制器。
--allocate-node-cidrs=true:为节点分配 CIDR 子网,用于分配 Pod 网络地址。
--service-cluster-ip-range:定义 Service 的 IP 范围,这里设置为 10.96.0.0/12 。
--cluster-cidr:定义集群的 CIDR 范围,这里设置为 172.16.0.0/12 。
--node-cidr-mask-size-ipv4:分配给每个节点的 IPv4 子网掩码大小,默认是 24。
--node-cidr-mask-size-ipv6:分配给每个节点的 IPv6 子网掩码大小,默认是 120。
--requestheader-client-ca-file:设置请求头中客户端 CA 的证书文件路径,用于认证请求头中的 CA 证书。

这个服务单元文件描述了 Kubernetes 控制器管理器的启动参数和行为,并且定义了服务的依赖关系和重新启动策略。通过 systemd 启动该服务单元,即可启动 Kubernetes 控制器管理器组件。

启动kube-controller-manager,并查看状态

systemctl daemon-reload
# 用于重新加载systemd管理的单位文件。当你新增或修改了某个单位文件(如.service文件、.socket文件等),需要运行该命令来刷新systemd对该文件的配置。

systemctl enable --now kube-controller-manager.service
# 启用并立即启动kube-controller-manager.service单元。kube-controller-manager.service是kube-controller-manager守护进程的systemd服务单元。

systemctl restart kube-controller-manager.service
# 重启kube-controller-manager.service单元,即重新启动etcd守护进程。

systemctl status kube-controller-manager.service
# kube-controller-manager.service单元的当前状态,包括运行状态、是否启用等信息。

配置kube-scheduler service

所有master节点配置,且配置相同

cat > /usr/lib/systemd/system/kube-scheduler.service << EOF

[Unit]
Description=Kubernetes Scheduler
Documentation=https://github.com/kubernetes/kubernetes
After=network.target

[Service]
ExecStart=/usr/local/bin/kube-scheduler \\
      --v=2 \\
      --bind-address=0.0.0.0 \\
      --leader-elect=true \\
      --kubeconfig=/etc/kubernetes/scheduler.kubeconfig

Restart=always
RestartSec=10s

[Install]
WantedBy=multi-user.target

EOF

这是一个用于启动 Kubernetes 调度器的 systemd 服务单元文件。下面是对每个部分的详细解释:

[Unit]:单元的基本信息部分,用于描述和标识这个服务单元。

  • Description:服务单元的描述信息,说明了该服务单元的作用,这里是 Kubernetes 调度器。
  • Documentation:可选项,提供了关于该服务单元的文档链接。
  • After:定义了该服务单元在哪些其他单元之后启动,这里是 network.target,即在网络服务启动之后启动。

[Service]:定义了服务的运行参数和行为。

  • ExecStart:指定服务启动时执行的命令,这里是 /usr/local/bin/kube-scheduler,并通过后续的行继续传+ 递了一系列的参数设置。
  • Restart:定义了服务在退出后的重新启动策略,这里设置为 always,表示总是重新启动服务。
  • RestartSec:定义了重新启动服务的时间间隔,这里设置为 10 秒。

[Install]:定义了如何安装和启用服务单元。

  • WantedBy:指定了服务单元所属的 target,这里是 multi-user.target,表示启动多用户模式下的服务。

在 ExecStart 中传递的参数说明如下:

--v=2:设置日志的详细级别为 2。
--bind-address=0.0.0.0:绑定的 IP 地址,用于监听 Kubernetes 控制平面的请求,这里设置为 0.0.0.0,表示监听所有网络接口上的请求。
--leader-elect=true:启用 Leader 选举机制,确保只有一个调度器作为 leader 在运行。
--kubeconfig=/etc/kubernetes/scheduler.kubeconfig:kubeconfig 文件的路径,包含了与 Kubernetes API 服务器通信所需的配置信息。

这个服务单元文件描述了 Kubernetes 调度器的启动参数和行为,并且定义了服务的依赖关系和重新启动策略。通过 systemd 启动该服务单元,即可启动 Kubernetes 调度器组件。

启动并查看服务状态

systemctl daemon-reload
# 用于重新加载systemd管理的单位文件。当你新增或修改了某个单位文件(如.service文件、.socket文件等),需要运行该命令来刷新systemd对该文件的配置。

systemctl enable --now kube-scheduler.service
# 启用并立即启动kube-scheduler.service单元。kube-scheduler.service是kube-scheduler守护进程的systemd服务单元。

systemctl restart kube-scheduler.service
# 重启kube-scheduler.service单元,即重新启动etcd守护进程。

systemctl status kube-scheduler.service
# kube-scheduler.service单元的当前状态,包括运行状态、是否启用等信息。

TLS Bootstrapping配置

在master01上配置

# 选择使用那种高可用方案
# 若使用 haproxy、keepalived 那么为 `--server=https://192.168.1.36:8443`
# 若使用 nginx方案,那么为 `--server=https://127.0.0.1:8443`

参考:

https://kubernetes.io/zh-cn/docs/reference/access-authn-authz/bootstrap-tokens/ https://www.kancloud.cn/pshizhsysu/kubernetes/1827157

令牌格式
启动引导令牌使用 abcdef.0123456789abcdef 的形式。 更加规范地说,它们必须符合正则表达式 [a-z0-9]{6}.[a-z0-9]{16}。

令牌的第一部分是 “Token ID”,它是一种公开信息,用于引用令牌并确保不会 泄露认证所使用的秘密信息。 第二部分是“令牌秘密(Token Secret)”,它应该被共享给受信的第三方。

证书轮换
RotateKubeletClientCertificate 会导致 kubelet 在其现有凭据即将过期时通过 创建新的 CSR 来轮换其客户端证书。要启用此功能特性,可将下面的标志传递给 kubelet:

--rotate-certificates

生成随机密码

len=16; tr -dc a-z0-9 < /dev/urandom | head -c ${len} | xargs
w4d0fuek41tdwk80
len=6; tr -dc a-z0-9 < /dev/urandom | head -c ${len} | xargs
92c1wc

bootstrap

mkdir /root/k8s/bootstrap
cd /root/k8s/bootstrap

修改其中的密钥
新建secret,修改其中的token
cat > bootstrap.secret.yaml<< EOF
apiVersion: v1
kind: Secret
metadata:
  name: bootstrap-token-92c1wc
  namespace: kube-system
type: bootstrap.kubernetes.io/token
stringData:
  description: "The default bootstrap token generated by 'kubelet '."
  token-id: 92c1wc
  token-secret: w4d0fuek41tdwk80
  usage-bootstrap-authentication: "true"
  usage-bootstrap-signing: "true"
  auth-extra-groups:  system:bootstrappers:default-node-token,system:bootstrappers:worker,system:bootstrappers:ingress

---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: kubelet-bootstrap
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: system:node-bootstrapper
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: Group
  name: system:bootstrappers:default-node-token
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: node-autoapprove-bootstrap
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: system:certificates.k8s.io:certificatesigningrequests:nodeclient
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: Group
  name: system:bootstrappers:default-node-token
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: node-autoapprove-certificate-rotation
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: system:certificates.k8s.io:certificatesigningrequests:selfnodeclient
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: Group
  name: system:nodes
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  annotations:
    rbac.authorization.kubernetes.io/autoupdate: "true"
  labels:
    kubernetes.io/bootstrapping: rbac-defaults
  name: system:kube-apiserver-to-kubelet
rules:
  - apiGroups:
      - ""
    resources:
      - nodes/proxy
      - nodes/stats
      - nodes/log
      - nodes/spec
      - nodes/metrics
    verbs:
      - "*"
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: system:kube-apiserver
  namespace: ""
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: system:kube-apiserver-to-kubelet
subjects:
  - apiGroup: rbac.authorization.k8s.io
    kind: User
    name: kube-apiserver
EOF

kubectl config set-cluster kubernetes     \
--certificate-authority=/etc/kubernetes/pki/ca.pem     \
--embed-certs=true     --server=https://127.0.0.1:8443     \
--kubeconfig=/etc/kubernetes/bootstrap-kubelet.kubeconfig
# 这是一个使用 kubectl 命令设置 Kubernetes 集群配置的命令示例。下面是对每个选项的详细解释:
# 
# config set-cluster kubernetes:指定要设置的集群名称为 "kubernetes",表示要修改名为 "kubernetes" 的集群配置。
# --certificate-authority=/etc/kubernetes/pki/ca.pem:指定证书颁发机构(CA)的证书文件路径,用于验证服务器证书的有效性。
# --embed-certs=true:将证书文件嵌入到生成的 kubeconfig 文件中。这样可以避免在 kubeconfig 文件中引用外部证书文件。
# --server=https://127.0.0.1:8443:指定 Kubernetes API 服务器的地址和端口,这里使用的是 https 协议和本地地址(127.0.0.1),端口号为 8443。你可以根据实际环境修改该参数。
# --kubeconfig=/etc/kubernetes/bootstrap-kubelet.kubeconfig:指定 kubeconfig 文件的路径和名称,这里是 /etc/kubernetes/bootstrap-kubelet.kubeconfig。
# 通过执行此命令,你可以设置名为 "kubernetes" 的集群配置,并提供 CA 证书、API 服务器地址和端口,并将这些配置信息嵌入到 bootstrap-kubelet.kubeconfig 文件中。这个 kubeconfig 文件可以用于认证和授权 kubelet 组件与 Kubernetes API 服务器之间的通信。请确保路径和文件名与实际环境中的配置相匹配。

kubectl config set-credentials tls-bootstrap-token-user     \
--token=92c1wc.w4d0fuek41tdwk80 \
--kubeconfig=/etc/kubernetes/bootstrap-kubelet.kubeconfig
# 这是一个使用 kubectl 命令设置凭证信息的命令示例。下面是对每个选项的详细解释:
# 
# config set-credentials tls-bootstrap-token-user:指定要设置的凭证名称为 "tls-bootstrap-token-user",表示要修改名为 "tls-bootstrap-token-user" 的用户凭证配置。
# --token=92c1wc.w4d0fuek41tdwk80:指定用户的身份验证令牌(token)。在这个示例中,令牌是 92c1wc.w4d0fuek41tdwk80。你可以根据实际情况修改该令牌,须是小写字母及数字。
# --kubeconfig=/etc/kubernetes/bootstrap-kubelet.kubeconfig:指定 kubeconfig 文件的路径和名称,这里是 /etc/kubernetes/bootstrap-kubelet.kubeconfig。
# 通过执行此命令,你可以设置名为 "tls-bootstrap-token-user" 的用户凭证,并将令牌信息加入到 bootstrap-kubelet.kubeconfig 文件中。这个 kubeconfig 文件可以用于认证和授权 kubelet 组件与 Kubernetes API 服务器之间的通信。请确保路径和文件名与实际环境中的配置相匹配。
kubectl config set-context tls-bootstrap-token-user@kubernetes     \
--cluster=kubernetes     \
--user=tls-bootstrap-token-user     \
--kubeconfig=/etc/kubernetes/bootstrap-kubelet.kubeconfig
# 这是一个使用 kubectl 命令设置上下文信息的命令示例。下面是对每个选项的详细解释:
# 
# config set-context tls-bootstrap-token-user@kubernetes:指定要设置的上下文名称为 "tls-bootstrap-token-user@kubernetes",表示要修改名为 "tls-bootstrap-token-user@kubernetes" 的上下文配置。
# --cluster=kubernetes:指定上下文关联的集群名称为 "kubernetes",表示使用名为 "kubernetes" 的集群配置。
# --user=tls-bootstrap-token-user:指定上下文关联的用户凭证名称为 "tls-bootstrap-token-user",表示使用名为 "tls-bootstrap-token-user" 的用户凭证配置。
# --kubeconfig=/etc/kubernetes/bootstrap-kubelet.kubeconfig:指定 kubeconfig 文件的路径和名称,这里是 /etc/kubernetes/bootstrap-kubelet.kubeconfig。
# 通过执行此命令,你可以设置名为 "tls-bootstrap-token-user@kubernetes" 的上下文,并将其关联到名为 "kubernetes" 的集群配置和名为 "tls-bootstrap-token-user" 的用户凭证配置。这样,bootstrap-kubelet.kubeconfig 文件就包含了完整的上下文信息,可以用于指定与 Kubernetes 集群建立连接时要使用的集群和凭证。请确保路径和文件名与实际环境中的配置相匹配。
kubectl config use-context tls-bootstrap-token-user@kubernetes     \
--kubeconfig=/etc/kubernetes/bootstrap-kubelet.kubeconfig
# 这是一个使用 kubectl 命令设置当前上下文的命令示例。下面是对每个选项的详细解释:
# 
# config use-context tls-bootstrap-token-user@kubernetes:指定要使用的上下文名称为 "tls-bootstrap-token-user@kubernetes",表示要将当前上下文切换为名为 "tls-bootstrap-token-user@kubernetes" 的上下文。
# --kubeconfig=/etc/kubernetes/bootstrap-kubelet.kubeconfig:指定 kubeconfig 文件的路径和名称,这里是 /etc/kubernetes/bootstrap-kubelet.kubeconfig。
# 通过执行此命令,你可以将当前上下文设置为名为 "tls-bootstrap-token-user@kubernetes" 的上下文。这样,当你执行其他 kubectl 命令时,它们将使用该上下文与 Kubernetes 集群进行交互。请确保路径和文件名与实际环境中的配置相匹配。

token的位置在bootstrap.secret.yaml,如果修改的话到这个文件修改

mkdir -p /root/.kube ; cp /etc/kubernetes/admin.kubeconfig /root/.kube/config

kube-controller-manager -h | grep RotateKubeletServerCertificate
参数是默认开启的

查看集群状态,没问题的话继续后续操作
重启一下controller-manager


export ETCDCTL_API=3
etcdctl --endpoints="192.168.244.14:2379" --cacert=/etc/kubernetes/pki/etcd/etcd-ca.pem --cert=/etc/kubernetes/pki/etcd/etcd.pem --key=/etc/kubernetes/pki/etcd/etcd-key.pem  endpoint status --write-out=table
+---------------------+------------------+---------+---------+-----------+------------+-----------+------------+--------------------+--------+
|      ENDPOINT       |        ID        | VERSION | DB SIZE | IS LEADER | IS LEARNER | RAFT TERM | RAFT INDEX | RAFT APPLIED INDEX | ERRORS |
+---------------------+------------------+---------+---------+-----------+------------+-----------+------------+--------------------+--------+
| 192.168.244.14:2379 | fa8e297f3f09517f |  3.5.12 |  860 kB |      true |      false |         3 |      63042 |              63042 |        |
+---------------------+------------------+---------+---------+-----------+------------+-----------+------------+--------------------+--------+

kubectl get cs


Warning: v1 ComponentStatus is deprecated in v1.19+
NAME                 STATUS    MESSAGE   ERROR
scheduler            Healthy   ok        
controller-manager   Healthy   ok        
etcd-0               Healthy   ok        

切记执行,别忘记!!!

kubectl create -f bootstrap.secret.yaml

secret/bootstrap-token-92c1wc created
clusterrolebinding.rbac.authorization.k8s.io/kubelet-bootstrap created
clusterrolebinding.rbac.authorization.k8s.io/node-autoapprove-bootstrap created
clusterrolebinding.rbac.authorization.k8s.io/node-autoapprove-certificate-rotation created
clusterrole.rbac.authorization.k8s.io/system:kube-apiserver-to-kubelet created
clusterrolebinding.rbac.authorization.k8s.io/system:kube-apiserver created

kubelet配置

node节点配置
在master01上将证书复制到node节点
cd /etc/kubernetes/

Master='dev-k8s-master02 dev-k8s-master03'
Work='dev-k8s-node01 dev-k8s-node02'

for NODE in $Master; do ssh $NODE mkdir -p /etc/kubernetes/pki; for FILE in pki/ca.pem pki/ca-key.pem pki/front-proxy-ca.pem bootstrap-kubelet.kubeconfig kube-proxy.kubeconfig; do scp /etc/kubernetes/$FILE $NODE:/etc/kubernetes/${FILE}; done; done

for NODE in $Work; do ssh $NODE mkdir -p /etc/kubernetes/pki; for FILE in pki/ca.pem pki/ca-key.pem pki/front-proxy-ca.pem bootstrap-kubelet.kubeconfig kube-proxy.kubeconfig; do scp /etc/kubernetes/$FILE $NODE:/etc/kubernetes/${FILE}; done; done

kubelet配置
用Containerd作为Runtime (推荐)

mkdir -p /var/lib/kubelet /var/log/kubernetes /etc/systemd/system/kubelet.service.d /etc/kubernetes/manifests/

所有k8s节点配置kubelet service

cat > /usr/lib/systemd/system/kubelet.service << EOF

[Unit]
Description=Kubernetes Kubelet
Documentation=https://github.com/kubernetes/kubernetes
After=network-online.target firewalld.service containerd.service
Wants=network-online.target
Requires=containerd.service

[Service]
ExecStart=/usr/local/bin/kubelet \\
    --bootstrap-kubeconfig=/etc/kubernetes/bootstrap-kubelet.kubeconfig  \\
    --kubeconfig=/etc/kubernetes/kubelet.kubeconfig \\
    --config=/etc/kubernetes/kubelet-conf.yml \\
    --container-runtime-endpoint=unix:///run/containerd/containerd.sock  \\
    --node-labels=node.kubernetes.io/node=

[Install]
WantedBy=multi-user.target
EOF
# 这是一个表示 Kubernetes Kubelet 服务的 systemd 单位文件示例。与之前相比,添加了 After 和 Requires 字段来指定依赖关系。
# 
# [Unit]
# 
# Description=Kubernetes Kubelet:指定了此单位文件对应的服务描述信息为 "Kubernetes Kubelet"。
# Documentation=...:指定了对该服务的文档链接。
# - After: 说明该服务在哪些其他服务之后启动,这里是在网络在线、firewalld服务和containerd服务后启动。
# - Wants: 说明该服务想要的其他服务,这里是网络在线服务。
# - Requires: 说明该服务需要的其他服务,这里是docker.socket和containerd.service。
# [Service]
# 
# ExecStart=/usr/local/bin/kubelet ...:指定了启动 Kubelet 服务的命令和参数,与之前的示例相同。
# --container-runtime-endpoint=unix:///run/containerd/containerd.sock:修改了容器运行时接口的端点地址,将其更改为使用 containerd 运行时(通过 UNIX 套接字)。
# [Install]
# 
# WantedBy=multi-user.target:指定了在 multi-user.target 被启动时,该服务应该被启用。
# 通过这个单位文件,你可以配置 Kubelet 服务的启动参数,并指定了它依赖的 containerd 服务。确保路径和文件名与你实际环境中的配置相匹配。

所有k8s节点创建kubelet的配置文件

cat > /etc/kubernetes/kubelet-conf.yml <<EOF
apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
address: 0.0.0.0
port: 10250
readOnlyPort: 10255
authentication:
  anonymous:
    enabled: false
  webhook:
    cacheTTL: 2m0s
    enabled: true
  x509:
    clientCAFile: /etc/kubernetes/pki/ca.pem
authorization:
  mode: Webhook
  webhook:
    cacheAuthorizedTTL: 5m0s
    cacheUnauthorizedTTL: 30s
cgroupDriver: systemd
cgroupsPerQOS: true
clusterDNS:
- 10.96.0.10
clusterDomain: cluster.local
containerLogMaxFiles: 5
containerLogMaxSize: 10Mi
contentType: application/vnd.kubernetes.protobuf
cpuCFSQuota: true
cpuManagerPolicy: none
cpuManagerReconcilePeriod: 10s
enableControllerAttachDetach: true
enableDebuggingHandlers: true
enforceNodeAllocatable:
- pods
eventBurst: 10
eventRecordQPS: 5
evictionHard:
  imagefs.available: 15%
  memory.available: 100Mi
  nodefs.available: 10%
  nodefs.inodesFree: 5%
evictionPressureTransitionPeriod: 5m0s
failSwapOn: true
fileCheckFrequency: 20s
hairpinMode: promiscuous-bridge
healthzBindAddress: 127.0.0.1
healthzPort: 10248
httpCheckFrequency: 20s
imageGCHighThresholdPercent: 85
imageGCLowThresholdPercent: 80
imageMinimumGCAge: 2m0s
iptablesDropBit: 15
iptablesMasqueradeBit: 14
kubeAPIBurst: 10
kubeAPIQPS: 5
makeIPTablesUtilChains: true
maxOpenFiles: 1000000
maxPods: 110
nodeStatusUpdateFrequency: 10s
oomScoreAdj: -999
podPidsLimit: -1
registryBurst: 10
registryPullQPS: 5
resolvConf: /etc/resolv.conf
rotateCertificates: true
runtimeRequestTimeout: 2m0s
serializeImagePulls: true
staticPodPath: /etc/kubernetes/manifests
streamingConnectionIdleTimeout: 4h0m0s
syncFrequency: 1m0s
volumeStatsAggPeriod: 1m0s
EOF
# 这是一个Kubelet的配置文件,用于配置Kubelet的各项参数。
# 
# - apiVersion: kubelet.config.k8s.io/v1beta1:指定了配置文件的API版本为kubelet.config.k8s.io/v1beta1。
# - kind: KubeletConfiguration:指定了配置类别为KubeletConfiguration。
# - address: 0.0.0.0:指定了Kubelet监听的地址为0.0.0.0。
# - port: 10250:指定了Kubelet监听的端口为10250。
# - readOnlyPort: 10255:指定了只读端口为10255,用于提供只读的状态信息。
# - authentication:指定了认证相关的配置信息。
#   - anonymous.enabled: false:禁用了匿名认证。
#   - webhook.enabled: true:启用了Webhook认证。
#   - x509.clientCAFile: /etc/kubernetes/pki/ca.pem:指定了X509证书的客户端CA文件路径。
# - authorization:指定了授权相关的配置信息。
#   - mode: Webhook:指定了授权模式为Webhook。
#   - webhook.cacheAuthorizedTTL: 5m0s:指定了授权缓存时间段为5分钟。
#   - webhook.cacheUnauthorizedTTL: 30s:指定了未授权缓存时间段为30秒。
# - cgroupDriver: systemd:指定了Cgroup驱动为systemd。
# - cgroupsPerQOS: true:启用了每个QoS类别一个Cgroup的设置。
# - clusterDNS: 指定了集群的DNS服务器地址列表。
#   - 10.96.0.10:指定了DNS服务器地址为10.96.0.10。
# - clusterDomain: cluster.local:指定了集群的域名后缀为cluster.local。
# - containerLogMaxFiles: 5:指定了容器日志文件保留的最大数量为5个。
# - containerLogMaxSize: 10Mi:指定了容器日志文件的最大大小为10Mi。
# - contentType: application/vnd.kubernetes.protobuf:指定了内容类型为protobuf。
# - cpuCFSQuota: true:启用了CPU CFS Quota。
# - cpuManagerPolicy: none:禁用了CPU Manager。
# - cpuManagerReconcilePeriod: 10s:指定了CPU管理器的调整周期为10秒。
# - enableControllerAttachDetach: true:启用了控制器的挂载和拆卸。
# - enableDebuggingHandlers: true:启用了调试处理程序。
# - enforceNodeAllocatable: 指定了强制节点可分配资源的列表。
#   - pods:强制节点可分配pods资源。
# - eventBurst: 10:指定了事件突发的最大数量为10。
# - eventRecordQPS: 5:指定了事件记录的最大请求量为5。
# - evictionHard: 指定了驱逐硬性限制参数的配置信息。
#   - imagefs.available: 15%:指定了镜像文件系统可用空间的限制为15%。
#   - memory.available: 100Mi:指定了可用内存的限制为100Mi。
#   - nodefs.available: 10%:指定了节点文件系统可用空间的限制为10%。
#   - nodefs.inodesFree: 5%:指定了节点文件系统可用inode的限制为5%。
# - evictionPressureTransitionPeriod: 5m0s:指定了驱逐压力转换的时间段为5分钟。
# - failSwapOn: true:指定了在发生OOM时禁用交换分区。
# - fileCheckFrequency: 20s:指定了文件检查频率为20秒。
# - hairpinMode: promiscuous-bridge:设置了Hairpin Mode为"promiscuous-bridge"。
# - healthzBindAddress: 127.0.0.1:指定了健康检查的绑定地址为127.0.0.1。
# - healthzPort: 10248:指定了健康检查的端口为10248。
# - httpCheckFrequency: 20s:指定了HTTP检查的频率为20秒。
# - imageGCHighThresholdPercent: 85:指定了镜像垃圾回收的上阈值为85%。
# - imageGCLowThresholdPercent: 80:指定了镜像垃圾回收的下阈值为80%。
# - imageMinimumGCAge: 2m0s:指定了镜像垃圾回收的最小时间为2分钟。
# - iptablesDropBit: 15:指定了iptables的Drop Bit为15。
# - iptablesMasqueradeBit: 14:指定了iptables的Masquerade Bit为14。
# - kubeAPIBurst: 10:指定了KubeAPI的突发请求数量为10个。
# - kubeAPIQPS: 5:指定了KubeAPI的每秒请求频率为5个。
# - makeIPTablesUtilChains: true:指定了是否使用iptables工具链。
# - maxOpenFiles: 1000000:指定了最大打开文件数为1000000。
# - maxPods: 110:指定了最大的Pod数量为110。
# - nodeStatusUpdateFrequency: 10s:指定了节点状态更新的频率为10秒。
# - oomScoreAdj: -999:指定了OOM Score Adjustment为-999。
# - podPidsLimit: -1:指定了Pod的PID限制为-1,表示无限制。
# - registryBurst: 10:指定了Registry的突发请求数量为10个。
# - registryPullQPS: 5:指定了Registry的每秒拉取请求数量为5个。
# - resolvConf: /etc/resolv.conf:指定了resolv.conf的文件路径。
# - rotateCertificates: true:指定了是否轮转证书。
# - runtimeRequestTimeout: 2m0s:指定了运行时请求的超时时间为2分钟。
# - serializeImagePulls: true:指定了是否序列化镜像拉取。
# - staticPodPath: /etc/kubernetes/manifests:指定了静态Pod的路径。
# - streamingConnectionIdleTimeout: 4h0m0s:指定了流式连接的空闲超时时间为4小时。
# - syncFrequency: 1m0s:指定了同步频率为1分钟。
# - volumeStatsAggPeriod: 1m0s:指定了卷统计聚合周期为1分钟。

启动kubelet

systemctl daemon-reload
# 用于重新加载systemd管理的单位文件。当你新增或修改了某个单位文件(如.service文件、.socket文件等),需要运行该命令来刷新systemd对该文件的配置。

systemctl enable --now kubelet.service
# 启用并立即启动kubelet.service单元。kubelet.service是kubelet守护进程的systemd服务单元。

systemctl restart kubelet.service
# 重启kubelet.service单元,即重新启动kubelet守护进程。

systemctl status kubelet.service
# kubelet.service单元的当前状态,包括运行状态、是否启用等信息。

查看集群

kubectl get node

NAME                     STATUS   ROLES    AGE   VERSION
dev-k8s-master01.local   Ready    <none>   21m   v1.29.2
dev-k8s-node01.local     Ready    <none>   21m   v1.29.2
dev-k8s-node02.local     Ready    <none>   21m   v1.29.2

在执行kubectl get node时发现节点直接为空
SSL certificate problem: unable to get local issuer certificate “Unable to register node with API server” err=”nodes is forbidden: User \”system:anonymous\” cannot create resource \”nodes\” in API group

kubelet客户端证书,也没缺 ls /var/lib/kubelet/pki/kubelet*

/var/lib/kubelet/pki/kubelet-client-2024-03-26-17-00-50.pem  /var/lib/kubelet/pki/kubelet-client-current.pem  /var/lib/kubelet/pki/kubelet.crt  /var/lib/kubelet/pki/kubelet.key

在kube-controller-manager.service,没有配ipv6但多配了个参数,去掉后重启,可以看到nod
–node-cidr-mask-size-ipv6

测试环境临时解决

kubectl create clusterrolebinding test:anonymous --clusterrole=cluster-admin --user=system:anonymous

test:anonymous角色绑定名称,随意取名,重新启动kube-proxy

查看容器运行时 kubectl describe node | grep Runtime

  Container Runtime Version:  containerd://1.7.13
  Container Runtime Version:  containerd://1.7.13
  Container Runtime Version:  containerd://1.7.13

kube-proxy配置

将kubeconfig发送至其他节点

master-1执行

Master='dev-k8s-master02 dev-k8s-master03'
Work='dev-k8s-node01 dev-k8s-node02'
for NODE in $Master; do scp /etc/kubernetes/kube-proxy.kubeconfig $NODE:/etc/kubernetes/kube-proxy.kubeconfig; done
for NODE in $Work; do scp /etc/kubernetes/kube-proxy.kubeconfig $NODE:/etc/kubernetes/kube-proxy.kubeconfig; done

所有k8s节点添加kube-proxy的service文件

cat >  /usr/lib/systemd/system/kube-proxy.service << EOF
[Unit]
Description=Kubernetes Kube Proxy
Documentation=https://github.com/kubernetes/kubernetes
After=network.target

[Service]
ExecStart=/usr/local/bin/kube-proxy \\
  --config=/etc/kubernetes/kube-proxy.yaml \\
  --cluster-cidr=172.16.0.0/12 \\
  --v=2
Restart=always
RestartSec=10s

[Install]
WantedBy=multi-user.target

EOF
# 这是一个 systemd 服务单元文件的示例,用于配置 Kubernetes Kube Proxy 服务。下面是对其中一些字段的详细解释:
# 
# [Unit]
# 
# Description: 描述了该服务单元的用途,这里是 Kubernetes Kube Proxy。
# Documentation: 指定了该服务单元的文档地址,即 https://github.com/kubernetes/kubernetes。
# After: 指定该服务单元应在 network.target(网络目标)之后启动。
# [Service]
# 
# ExecStart: 指定了启动 Kube Proxy 服务的命令。通过 /usr/local/bin/kube-proxy 命令启动,并指定了配置文件的路径为 /etc/kubernetes/kube-proxy.yaml,同时指定了日志级别为 2。
# Restart: 配置了服务在失败或退出后自动重启。
# RestartSec: 配置了重启间隔,这里是每次重启之间的等待时间为 10 秒。
# [Install]
# 
# WantedBy: 指定了该服务单元的安装目标为 multi-user.target(多用户目标),表示该服务将在多用户模式下启动。
# 通过配置这些字段,你可以启动和管理 Kubernetes Kube Proxy 服务。请注意,你需要根据实际情况修改 ExecStart 中的路径和文件名,确保与你的环境一致。另外,可以根据需求修改其他字段的值,以满足你的特定要求。

所有k8s节点添加kube-proxy的配置

cat > /etc/kubernetes/kube-proxy.yaml << EOF
apiVersion: kubeproxy.config.k8s.io/v1alpha1
bindAddress: 0.0.0.0
clientConnection:
  acceptContentTypes: ""
  burst: 10
  contentType: application/vnd.kubernetes.protobuf
  kubeconfig: /etc/kubernetes/kube-proxy.kubeconfig
  qps: 5
clusterCIDR: 172.16.0.0/12
configSyncPeriod: 15m0s
conntrack:
  max: null
  maxPerCore: 32768
  min: 131072
  tcpCloseWaitTimeout: 1h0m0s
  tcpEstablishedTimeout: 24h0m0s
enableProfiling: false
healthzBindAddress: 0.0.0.0:10256
hostnameOverride: ""
iptables:
  masqueradeAll: false
  masqueradeBit: 14
  minSyncPeriod: 0s
  syncPeriod: 30s
ipvs:
  masqueradeAll: true
  minSyncPeriod: 5s
  scheduler: "rr"
  syncPeriod: 30s
kind: KubeProxyConfiguration
metricsBindAddress: 127.0.0.1:10249
mode: "ipvs"
nodePortAddresses: null
oomScoreAdj: -999
portRange: ""
udpIdleTimeout: 250ms
EOF
# 这是一个Kubernetes的kube-proxy组件配置文件示例。以下是每个配置项的详细解释:
# 
# 1. apiVersion: kubeproxy.config.k8s.io/v1alpha1
#    - 指定该配置文件的API版本。
# 
# 2. bindAddress: 0.0.0.0
#    - 指定kube-proxy使用的监听地址。0.0.0.0表示监听所有网络接口。
# 
# 3. clientConnection:
#    - 客户端连接配置项。
# 
#    a. acceptContentTypes: ""
#       - 指定接受的内容类型。
# 
#    b. burst: 10
#       - 客户端请求超出qps设置时的最大突发请求数。
# 
#    c. contentType: application/vnd.kubernetes.protobuf
#       - 指定客户端请求的内容类型。
# 
#    d. kubeconfig: /etc/kubernetes/kube-proxy.kubeconfig
#       - kube-proxy使用的kubeconfig文件路径。
# 
#    e. qps: 5
#       - 每秒向API服务器发送的请求数量。
# 
# 4. clusterCIDR: 172.16.0.0/12,fc00:2222::/112
#    - 指定集群使用的CIDR范围,用于自动分配Pod IP。
# 
# 5. configSyncPeriod: 15m0s
#    - 指定kube-proxy配置同步到节点的频率。
# 
# 6. conntrack:
#    - 连接跟踪设置。
# 
#    a. max: null
#       - 指定连接跟踪的最大值。
# 
#    b. maxPerCore: 32768
#       - 指定每个核心的最大连接跟踪数。
# 
#    c. min: 131072
#       - 指定最小的连接跟踪数。
# 
#    d. tcpCloseWaitTimeout: 1h0m0s
#       - 指定处于CLOSE_WAIT状态的TCP连接的超时时间。
# 
#    e. tcpEstablishedTimeout: 24h0m0s
#       - 指定已建立的TCP连接的超时时间。
# 
# 7. enableProfiling: false
#    - 是否启用性能分析。
# 
# 8. healthzBindAddress: 0.0.0.0:10256
#    - 指定健康检查监听地址和端口。
# 
# 9. hostnameOverride: ""
#    - 指定覆盖默认主机名的值。
# 
# 10. iptables:
#     - iptables设置。
# 
#     a. masqueradeAll: false
#        - 是否对所有流量使用IP伪装。
# 
#     b. masqueradeBit: 14
#        - 指定伪装的Bit标记。
# 
#     c. minSyncPeriod: 0s
#        - 指定同步iptables规则的最小间隔。
# 
#     d. syncPeriod: 30s
#        - 指定同步iptables规则的时间间隔。
# 
# 11. ipvs:
#     - ipvs设置。
# 
#     a. masqueradeAll: true
#        - 是否对所有流量使用IP伪装。
# 
#     b. minSyncPeriod: 5s
#        - 指定同步ipvs规则的最小间隔。
# 
#     c. scheduler: "rr"
#        - 指定ipvs默认使用的调度算法。
# 
#     d. syncPeriod: 30s
#        - 指定同步ipvs规则的时间间隔。
# 
# 12. kind: KubeProxyConfiguration
#     - 指定该配置文件的类型。
# 
# 13. metricsBindAddress: 127.0.0.1:10249
#     - 指定指标绑定的地址和端口。
# 
# 14. mode: "ipvs"
#     - 指定kube-proxy的模式。这里指定为ipvs,使用IPVS代理模式。
# 
# 15. nodePortAddresses: null
#     - 指定可用于NodePort的网络地址。
# 
# 16. oomScoreAdj: -999
#     - 指定kube-proxy的OOM优先级。
# 
# 17. portRange: ""
#     - 指定可用于服务端口范围。
# 
# 18. udpIdleTimeout: 250ms
#     - 指定UDP连接的空闲超时时间。

启动kube-proxy

systemctl daemon-reload
# 用于重新加载systemd管理的单位文件。当你新增或修改了某个单位文件(如.service文件、.socket文件等),需要运行该命令来刷新systemd对该文件的配置。

systemctl enable --now kube-proxy.service
# 启用并立即启动kube-proxy.service单元。kube-proxy.service是kube-proxy守护进程的systemd服务单元。

systemctl restart kube-proxy.service
systemctl start kube-proxy.service
# 重启kube-proxy.service单元,即重新启动kube-proxy守护进程。

systemctl status kube-proxy.service
# kube-proxy.service单元的当前状态,包括运行状态、是否启用等信息。

验证

netstat -ntlp | grep kube-proxy

kubectl -n kube-system get ds kube-proxy
kubectl -n kube-system get cm kube-proxy

iptables -nL | grep -v KUBE 
# 查看查看 ipvs 路由规则
ipvsadm -ln

批量查看证书过期时间

for NODE in `ls /etc/kubernetes/pki/*.pem`; do ls $NODE; done  
for NODE in `ls /etc/kubernetes/pki/*.pem`; do openssl x509 -in $NODE  -noout -text|grep 'Not'; done  

检查Kube-Proxy模式
默认,Kube-Proxy在端口10249上运行,并暴露一组端点,你可以使用这些端点查询Kube-Proxy的信息
curl -v localhost:10249/proxyMode

*   Trying 127.0.0.1:10249...
* Connected to localhost (127.0.0.1) port 10249 (#0)
> GET /proxyMode HTTP/1.1
> Host: localhost:10249
> User-Agent: curl/7.76.1
> Accept: */*
> 
* Mark bundle as not supporting multiuse
< HTTP/1.1 200 OK
< Content-Type: text/plain; charset=utf-8
< X-Content-Type-Options: nosniff
< Date: Mon, 22 Apr 2024 05:43:59 GMT
< Content-Length: 4
< 
* Connection #0 to host localhost left intact

安装Calico

Calico是一个纯3层的数据中心网络方案,而且无缝集成像OpenStack这种IaaS云架构,能够提供可控的VM、容器、裸机之间的IP通信。 Calico的原理是通过修改每个主机节点上的iptables和路由表规则,实现容器间数据路由和访问控制,并通过Etcd协调节点配置信息的。因此Calico服务本身和许多分布式服务一样,需要运行在集群的每一个节点上。

Calico Typha(可选的扩展组件)
Typha是Calico的一个扩展组件,用于Calico通过Typha直接与Etcd通信,而不是通过kube-apiserver。通常当K8S的规模超过50个节点的时候推荐启用它,以降低kube-apiserver的负载。每个Pod/calico-typha可承载100~200个Calico节点的连接请求,最多不要超过200个。
当集群规模大于50节点时,应该使用calico-typha.yaml。calico-typha的作用主要是:减轻Apiserver的压力;因为各节点的Felix都会监听Apiserver,当节点数众多时,Apiserver的Watch压力会很大;当安装了calico-typha后,Felix不监听Apiserver,而是由calico-typha监听Apiserver,然后calico-typha再和Felix进行通信。

calico的优点

  • endpoints组成的网络是单纯的三层网络,报文的流向完全通过路由规则控制,没有overlay等额外开销;
  • calico的endpoint可以漂移,并且实现了acl。

calico的缺点

  • 路由的数目与容器数目相同,非常容易超过路由器、三层交换、甚至node的处理能力,从而限制了整个网络的扩+ 张;
  • calico的每个node上会设置大量(海量)的iptables规则、路由,运维、排障难度大;
  • calico的原理决定了它不可能支持VPC,容器只能从calico设置的网段中获取ip;
  • calico目前的实现没有流量控制的功能,会出现少数容器抢占node多数带宽的情况;
  • calico的网络规模受到BGP网络规模的限制。

Calico有多种安装方式:

  • 使用calico.yaml清单文件安装
  • 使用Tigera Calico Operator安装Calico(官方最新指导)
    Tigera Calico Operator,Calico操作员是一款用于管理Calico安装、升级的管理工具,它用于管理Calico的安装生命周期。从Calico-v3.15版本官方开始使用此工具。

配置NetworkManager

如果主机系统使用NetworkManager来管理网络的话,则需要配置NetworkManager,以允许Calico管理接口。 NetworkManger操作默认网络命名空间接口的路由表,这可能会干扰Calico代理正确路由的能力。 在所有主机上操作:

cat > /etc/NetworkManager/conf.d/calico.conf <<EOF
[keyfile]
unmanaged-devices=interface-name:cali*;interface-name:tunl*;interface-name:vxlan.calico;interface-name:wireguard.cali
EOF

更改calico网段

mkdir /root/k8s/yaml && cd /root/k8s/yaml
wget https://raw.githubusercontent.com/projectcalico/calico/master/manifests/calico-typha.yaml

curl https://docs.projectcalico.org/v3.25/manifests/calico.yaml -O

wget https://raw.githubusercontent.com/projectcalico/calico/v3.27.2/manifests/tigera-operator.yaml

修改网段

cp calico-typha.yaml calico.yaml
默认为192.168.0.0/16 grep -C1 ‘CALICO_IPV4POOL_CIDR’ calico.yaml

            # no effect. This should fall within `--cluster-cidr`.
            - name: CALICO_IPV4POOL_CIDR
              value: "192.168.0.0/16"

vim calico.yaml
若POD网段不是192.168.0.0/16,需打开注释修改:CALICO_IPV4POOL_CIDR
要和kubeadm init pod-network-cidr的值一致, 或者单独安装的clusterCIDR一致 注意空格对齐,不然报错error: error parsing calico.yaml: error converting YAML to JSON: yaml: line 210: did not find expected ‘-‘ indicator

             - name: CALICO_IPV4POOL_CIDR
               value: "172.16.0.0/12"

若docker镜像拉不下来,可以使用国内的仓库

grep 'image:' calico.yaml 
          image: docker.io/calico/cni:v3.25.0
          image: docker.io/calico/cni:v3.25.0
          image: docker.io/calico/node:v3.25.0
          image: docker.io/calico/node:v3.25.0
          image: docker.io/calico/kube-controllers:v3.25.0

sed -i "s#docker.io/calico/#m.daocloud.io/docker.io/calico/#g" calico.yaml 

kubectl apply -f calico.yaml

poddisruptionbudget.policy/calico-kube-controllers created
serviceaccount/calico-kube-controllers created
serviceaccount/calico-node created
configmap/calico-config created
customresourcedefinition.apiextensions.k8s.io/bgpconfigurations.crd.projectcalico.org created
customresourcedefinition.apiextensions.k8s.io/bgppeers.crd.projectcalico.org created
customresourcedefinition.apiextensions.k8s.io/blockaffinities.crd.projectcalico.org created
customresourcedefinition.apiextensions.k8s.io/caliconodestatuses.crd.projectcalico.org created
customresourcedefinition.apiextensions.k8s.io/clusterinformations.crd.projectcalico.org created
customresourcedefinition.apiextensions.k8s.io/felixconfigurations.crd.projectcalico.org created
customresourcedefinition.apiextensions.k8s.io/globalnetworkpolicies.crd.projectcalico.org created
customresourcedefinition.apiextensions.k8s.io/globalnetworksets.crd.projectcalico.org created
customresourcedefinition.apiextensions.k8s.io/hostendpoints.crd.projectcalico.org created
customresourcedefinition.apiextensions.k8s.io/ipamblocks.crd.projectcalico.org created
customresourcedefinition.apiextensions.k8s.io/ipamconfigs.crd.projectcalico.org created
customresourcedefinition.apiextensions.k8s.io/ipamhandles.crd.projectcalico.org created
customresourcedefinition.apiextensions.k8s.io/ippools.crd.projectcalico.org created
customresourcedefinition.apiextensions.k8s.io/ipreservations.crd.projectcalico.org created
customresourcedefinition.apiextensions.k8s.io/kubecontrollersconfigurations.crd.projectcalico.org created
customresourcedefinition.apiextensions.k8s.io/networkpolicies.crd.projectcalico.org created
customresourcedefinition.apiextensions.k8s.io/networksets.crd.projectcalico.org created
clusterrole.rbac.authorization.k8s.io/calico-kube-controllers created
clusterrole.rbac.authorization.k8s.io/calico-node created
clusterrolebinding.rbac.authorization.k8s.io/calico-kube-controllers created
clusterrolebinding.rbac.authorization.k8s.io/calico-node created
daemonset.apps/calico-node created
deployment.apps/calico-kube-controllers created

删除calico

kubectl delete -f calico.yaml

查看容器状态

kubectl get pod -n kube-system

kube-system   calico-kube-controllers-58b845f4cb-xk7nc   0/1     ContainerCreating   0          84s
kube-system   calico-node-4hptf                          0/1     Init:0/3            0          84s
kube-system   calico-node-862cx                          0/1     Init:2/3            0          84s
kube-system   calico-node-8dnvr                          0/1     Init:2/3            0          84s

NAME READY STATUS RESTARTS AGE calico-kube-controllers-58b845f4cb-sjjlj 0/1 Unknown 0 59m calico-node-2pz2z 0/1 Completed 0 59m calico-node-n7t97 0/1 Unknown 0 59m calico-node-q4r5w 0/1 Completed 0 59m coredns-84748f969f-6gtzh 0/1 Completed 11 8d metrics-server-57d65996cf-w48gs 0/1 Completed 21 8d

kubectl -n kube-system logs ds/calico-node kubectl -n kube-system describe pod calico-node-8dnvr
kubectl -n kube-system describe pod calico-node-sw8dv kubectl -n kube-system describe pod calico-kube-controllers-58b845f4cb-wnc2k kubectl -n kube-system logs calico-node-n7t97

master上镜像查看
crictl images

IMAGE                                 TAG                 IMAGE ID            SIZE
m.daocloud.io/docker.io/calico/cni    master              9f486eed9534a       92.4MB
m.daocloud.io/registry.k8s.io/pause   3.8                 4873874c08efc       311kB

cat calico.yaml |grep image:

          image: m.daocloud.io/docker.io/calico/cni:master
          image: m.daocloud.io/docker.io/calico/cni:master
          image: m.daocloud.io/docker.io/calico/node:master
          image: m.daocloud.io/docker.io/calico/node:master
          image: m.daocloud.io/docker.io/calico/kube-controllers:master
      - image: m.daocloud.io/docker.io/calico/typha:master

手动拉取

crictl pull m.daocloud.io/docker.io/calico/node:master
crictl pull m.daocloud.io/docker.io/calico/kube-controllers:master
crictl pull m.daocloud.io/docker.io/calico/typha:master

node上镜像查看
crictl images

IMAGE                                  TAG                 IMAGE ID            SIZE
m.daocloud.io/docker.io/calico/cni     master              9f486eed9534a       92.4MB
m.daocloud.io/docker.io/calico/typha   master              4f4b8e34f5143       30.3MB
m.daocloud.io/registry.k8s.io/pause    3.8                 4873874c08efc       311kB

kubectl get pod -A

NAMESPACE     NAME                                       READY   STATUS    RESTARTS   AGE
kube-system   calico-kube-controllers-58b845f4cb-xk7nc   1/1     Running   0          15m
kube-system   calico-node-4hptf                          1/1     Running   0          15m
kube-system   calico-node-862cx                          1/1     Running   0          15m
kube-system   calico-node-8dnvr                          1/1     Running   0          15m

https://blog.csdn.net/weixin_45015255/article/details/117207177?utm_medium=distribute.pc_relevant.none-task-blog-2~default~baidujs_baidulandingword~default-5-117207177-blog-136372820.235^v43^pc_blog_bottom_relevance_base1&spm=1001.2101.3001.4242.4&utm_relevant_index=8

Readiness probe failed: calico/node is not ready: BIRD is not ready: Failed to stat() nodename file: stat /var/lib/calico/nodename: no such file or directory

Readiness probe failed: calico/node is not ready: BIRD is not ready: Error querying BIRD: unable to connect to BIRDv4 socket: dial unix /var/run/bird/bird.ctl: connect: no such file or directory

错误
kubectl -n kube-system logs ds/calico-node

Found 3 pods, using pod/calico-node-9fhv9
Defaulted container "calico-node" out of: calico-node, upgrade-ipam (init), install-cni (init), mount-bpffs (init)
Error from server (BadRequest): container "calico-node" in pod "calico-node-9fhv9" is waiting to start: PodInitializing  

解决
crictl ps -a

CONTAINER           IMAGE               CREATED             STATE               NAME                               ATTEMPT             POD ID              POD
d878cd05d0992       d70a5947d57e5       3 minutes ago       Exited              install-cni                        678                 6eee2eeb107e8       calico-node-tt7gg
6f351d95632f3       ffcc66479b5ba       5 minutes ago       Exited              controller                         1108                9a2ba30bdbd93       ingress-nginx-controller-hnc7t
304e25cfbf755       d70a5947d57e5       2 days ago          Exited              upgrade-ipam                       0                   6eee2eeb107e8       calico-node-tt7gg

crictl logs d878cd05d0992

[ERROR][1] cni-installer/<nil> <nil>: Unable to create token for CNI kubeconfig error=Post "https://10.96.0.1:443/api/v1/namespaces/kube-system/serviceaccounts/calico-node/token": dial tcp 10.96.0.1:443: i/o timeout

kube-proxy没有启动,启动
systemctl start kube-proxy.service

使用Tigera Calico Operator安装Calico

wget https://raw.githubusercontent.com/projectcalico/calico/v3.27.2/manifests/tigera-operator.yaml -O calico-tigera-operator.yaml –no-check-certificate

wget https://raw.githubusercontent.com/projectcalico/calico/v3.27.2/manifests/custom-resources.yaml -O calico-custom-resources.yaml –no-check-certificate

cat calico-tigera-operator.yaml |grep ‘image:’

                    image:
          image: quay.io/tigera/operator:v1.32.5

sed -i “s#image: quay.io#image: m.daocloud.io/quay.io#g” calico-tigera-operator.yaml

注:这边需要修改一下Pod分配子网范围(CIDR),该地址需要与kubeadm初始化集群时的”podSubnet”字段或”–pod-network-cidr”参数中填写的值相同。l清单文件中”CALICO_IPV4POOL_CIDR”部分 vim calico-custom-resources.yaml

      cidr: 172.16.0.0/12

kubectl apply -f calico-tigera-operator.yaml
kubectl apply -f calico-custom-resources.yaml

calicoctl工具下载

下载地址,需跟calico网络插件版本一致

wget https://github.com/projectcalico/calico/releases/download/v3.25.0/calicoctl-linux-amd64
wget https://mirrors.chenby.cn/https://github.com/projectcalico/calico/releases/download/v3.25.0/calicoctl-linux-amd64
wget https://mirrors.chenby.cn/https://github.com/projectcalico/calico/releases/download/v3.27.3/calicoctl-linux-amd64

移动并重命名工具 mv calicoctl-linux-amd64 /usr/local/bin/calicoctl

赋予执行权限 chmod +x /usr/local/bin/calicoctl

calicoctl version

Client Version:    v3.25.0
Git commit:        3f7fe4d29
Cluster Version:   v3.25.0
Cluster Type:      k8s,bgp,kdd

calicoctl查看节点状态,默认为Peers模式

calicoctl node status

Calico process is running.

IPv4 BGP status
+----------------+-------------------+-------+----------+-------------+
|  PEER ADDRESS  |     PEER TYPE     | STATE |  SINCE   |    INFO     |
+----------------+-------------------+-------+----------+-------------+
| 192.168.244.16 | node-to-node mesh | up    | 09:38:16 | Established |
| 192.168.244.15 | node-to-node mesh | up    | 09:39:52 | Established |
+----------------+-------------------+-------+----------+-------------+

IPv6 BGP status
No IPv6 peers found.

calicoctl get wep -o wide

NAME                                                                     WORKLOAD                            NODE                     NETWORKS           INTERFACE         PROFILES                          NATS   
dev--k8s--master01.local-k8s-nginx--deployment--588c996f64--f8bt2-eth0   nginx-deployment-588c996f64-f8bt2   dev-k8s-master01.local   172.17.50.192/32   calib539a8e3e41   kns.default,ksa.default.default          
dev--k8s--node02.local-k8s-nginx--deployment--588c996f64--nrddh-eth0     nginx-deployment-588c996f64-nrddh   dev-k8s-node02.local     172.22.227.73/32   calif7e8750fa84   kns.default,ksa.default.default          
dev--k8s--node01.local-k8s-nginx--deployment--588c996f64--r68r5-eth0     nginx-deployment-588c996f64-r68r5   dev-k8s-node01.local     172.21.244.66/32   cali45575135b87   kns.default,ksa.default.default   

查看 IP 资源池

calicoctl get ippool -o wide

NAME                  CIDR            NAT    IPIPMODE   VXLANMODE   DISABLED   DISABLEBGPEXPORT   SELECTOR   
default-ipv4-ippool   172.16.0.0/12   true   Always     Never       false      false              all()      

calicoctl查看配制

calicoctl get ipPool -o yaml

apiVersion: projectcalico.org/v3
items:
- apiVersion: projectcalico.org/v3
  kind: IPPool
  metadata:
    creationTimestamp: "2024-03-27T09:38:11Z"
    name: default-ipv4-ippool
    resourceVersion: "230578"
    uid: 2f7a2e97-8574-49bc-a816-186223f7bcb8
  spec:
    allowedUses:
    - Workload
    - Tunnel
    blockSize: 26
    cidr: 172.16.0.0/12
    ipipMode: Always
    natOutgoing: true
    nodeSelector: all()
    vxlanMode: Never
kind: IPPoolList
metadata:
  resourceVersion: "340939"

一些场景往往对IP地址有依赖,需要使用固定IP地址的Pod,可以使用kube-ipam轻松解决这类问题.

修改ipipMode: CrossSubnet

DATASTORE_TYPE=kubernetes KUBECONFIG=~/.kube/config calicoctl get ippool default-ipv4-ippool -o yaml > ippool.yaml

#修改 ipipMode 值为 CrossSubnet
apiVersion: v1
items:
- apiVersion: crd.projectcalico.org/v1
  kind: IPPool
  metadata:
    annotations:
      projectcalico.org/metadata: '{"uid":"50222d78-c525-4362-a783-ef09c6aa77c3","creationTimestamp":"2024-03-27T09:38:11Z"}'
    creationTimestamp: "2024-03-27T09:38:11Z"
    generation: 1
    name: default-ipv4-ippool
    resourceVersion: "230578"
    uid: 2f7a2e97-8574-49bc-a816-186223f7bcb8
  spec:
    allowedUses:
    - Workload
    - Tunnel
    blockSize: 26
    cidr: 172.16.0.0/12
    ipipMode: CrossSubnet
    natOutgoing: true
    nodeSelector: all()
    vxlanMode: Never
kind: List
metadata:
  resourceVersion: ""

重新使用 DATASTORE_TYPE=kubernetes KUBECONFIG=~/.kube/config calicoctl apply -f ippool.yaml应用既可

删除calico

如果之前是使用yaml部署并且保留了原来的文件的,可以直接使用yaml进行

kubectl delete -f calico-tigera-operator.yaml --grace-period=0 --force
kubectl delete -f calico-custom-resources.yaml --grace-period=0 --force
 # 检查所有名字里面带有 calico|tigera 的资源: 
 kubectl get all --all-namespaces | egrep "calico|tigera"
 ​
 # 检查所有名字里面带有 calico|tigera 的 api resources: 
 kubectl api-resources --verbs=list --namespaced -o name | egrep "calico|tigera"
 ​
 # 检查所有名字里面带有 calico|tigera 的 不带namespace信息的 api resources: 
 kubectl api-resources --verbs=list -o name  | egrep "calico|tigera"
手动删除一直Terminating
kube-system            pod/calico-kube-controllers-58b845f4cb-xk7nc              0/1     Terminating   2               13d

kubectl delete pod calico-kube-controllers-58b845f4cb-xk7nc  -n kube-system

kubectl delete pod calico-kube-controllers-58b845f4cb-xk7nc -n kube-system --grace-period=0 --force

当出现资源无法删除的时候可以通过检查其finalizers字段来定位信息 检查calico-node这个serviceaccounts的配置文件,查看对应的finalizers和status中的conditions定位故障原因

 kubectl get serviceaccounts calico-node -n calico-system -o yaml

如果是finalizers中存在tigera.io/cni-protector导致资源无法被顺利删除,可以尝试修改为finalizers: []。这个问题看起来似乎是个Kubernetes上游的BUG,在github上面能找到相关的issue,主要集中在使用tigera-operator部署的calico。

最后删除所有节点上面残留的cni配置文件,然后重启集群的所有机器

 # 删除cni下相关的配置文件
cp -ar  /etc/cni/net.d/  /etc/cni/net.d.calico
rm -rf /etc/cni/net.d/

重启机器之后会把此前calico创建的路由信息、iptables规则和cni网卡删除,当然不想重启也可以手动删除干净

 # 清理路由信息
 $ ip route flush proto bird
 ​
 # 清理calico相关网卡
 $ ip link list | grep cali | awk '{print $2}' | cut -c 1-15 | xargs -I {} ip link delete {}
 ​
 # 删除ipip模块
 $ modprobe -r ipip
 ​
 # 清理iptables规则
 $ iptables-save | grep -i cali | iptables -F
 $ iptables-save | grep -i cali | iptables -X
 ​
 # 清理ipvsadm规则
 $ ipvsadm -C
 ip link del kube-ipvs0

安装cilium

参考:
https://developer.aliyun.com/article/1436812

要使用完整的 Cilium 功能, 需要非常新版本的 Linux 内核. 目前官方推荐的 Linux Kernel 是 ≥ 5.10.

将 Kubernetes 的 CNI 从其他组件切换为 Cilium, 已经可以有效地提升网络的性能。但是通过对 Cilium 不同模式的切换/功能的启用,可以进一步提升 Cilium 的网络性能。具体调优项包括不限于:

  • 启用本地路由 (Native Routing)
  • 完全替换 KubeProxy
  • IP 地址伪装 (Masquerading) 切换为基于 eBPF 的模式,使用POD本身的真实IP
  • Kubernetes NodePort 实现在 DSR(Direct Server Return) 模式下运行
  • 绕过 iptables 连接跟踪 (Bypass iptables Connection Tracking)
  • 主机路由 (Host Routing) 切换为基于 BPF 的模式 (需要 Linux Kernel >= 5.10)
  • 启用 IPv6 BIG TCP (需要 Linux Kernel >= 5.19)
  • 禁用 Hubble(但是不建议,可观察性比一点点的性能提升更重要)
  • 修改 MTU 为巨型帧 (jumbo frames) (需要网络条件允许)
  • 启用带宽管理器 (Bandwidth Manager) (需要 Kernel >= 5.1)
  • 启用 Pod 的 BBR 拥塞控制 (需要 Kernel >= 5.18)
  • 启用 XDP 加速 (需要 支持本地 XDP 驱动程序)
  • (高级用户可选)调整 eBPF Map Size
  • Linux Kernel 优化和升级
    • CONFIG_PREEMPT_NONE=y
  • 其他:
    • tuned network-* profiles, 如:tuned-adm profile network-latency 或 network-throughput
    • CPU 调为性能模式
    • 停止 irqbalance,将网卡中断引脚指向特定 CPU
    • 在网络/网卡设备/OS 等条件满足的情况下,我们尽可能多地启用这些调优选项,

Posted in 安装k8s/kubernetes.

Tagged with , , .


No Responses (yet)

Stay in touch with the conversation, subscribe to the RSS feed for comments on this post.



Some HTML is OK

or, reply to this post via trackback.