OpenShift节点kubelet证书过期异常的解决步骤

环境：OpenShift 3.10 or 3.11

问题:

步骤：

或者

Manually recreate OpenShift Node TLS bootstrapped certificates and kubeconfig files.

Red Hat Enterprise Linux CoreOS (RHCOS)代表了下一代的单用途容器 *** 作系统技术。RHCOS是由创建Red Hat Enterprise Linux Atomic Host和CoreOS Container Linux的开发团队创建的，它将Red Hat Enterprise Linux (RHEL)的质量标准与Container Linux的自动化、远程升级特性结合在一起。

RHCOS仅作为OpenShift容器平台4.3的一个组件被支持，适用于所有的OpenShift容器平台机器。RHCOS是OpenShift容器平台控制平面或主机的唯一支持的 *** 作系统。虽然RHCOS是所有集群机器的默认 *** 作系统，但是您可以创建使用RHEL作为其 *** 作系统的 compute 节点(也称为 worker 节点)。RHCOS在OpenShift容器平台上的部署方式有两种:

基于RHEL : 底层 *** 作系统主要由RHEL组件组成。支持RHEL的同样质量、安全和控制措施也支持RHCOS。例如，RHCOS软件在RPM包中，每个RHCOS系统都启动一个RHEL内核和一组由systemd init系统管理的服务。

受控不变性 : 虽然它包含RHEL组件，但RHCOS的设计比默认的RHEL安装管理更严格。管理是在OpenShift容器平台集群中远程执行的。当您设置您的RHCOS机器时，您只能修改一些系统设置。这种受控制的不变性允许OpenShift容器平台在集群中存储RHCOS系统的最新状态，因此它总是能够创建额外的机器，并根据最新的RHCOS配置执行更新。

crio容器运行时 :虽然RHCOS包含运行Docker所需的OCI和libcontainer格式容器的特性，但它合并了crio容器引擎，而不是Docker容器引擎。通过专注于Kubernetes平台所需的特性(如OpenShift容器平台)，crio可以提供与Kubernetes不同版本的特定兼容性。与提供更大特性集的容器引擎相比，crio还提供了更小的足迹和更少的攻击面。目前，crio仅作为OpenShift容器平台集群中的容器引擎可用。

容器工具集 :对于诸如构建、复制和以其他方式管理容器的任务，RHCOS使用一组兼容的容器工具替换Docker CLI工具。podman CLI工具支持许多容器运行时特性，比如运行、启动、停止、列出和删除容器和容器映像。skopeo CLI工具可以复制、验证和签署图像。您可以使用crictl CLI工具来处理来自crio容器引擎的容器和吊舱。虽然不鼓励在RHCOS中直接使用这些工具，但是可以将它们用于调试目的。

rpm-ostree升级 :RHCOS提供使用rpm-ostree系统的事务升级。更新是通过容器映像交付的，并且是OpenShift容器平台更新过程的一部分。部署后，将提取、提取容器映像并将其写入磁盘，然后修改引导装载程序以引导到新版本。机器将以滚动的方式重新启动更新，以确保集群容量受到的影响最小。

通过MachineConfigOperator更新 :在OpenShift容器平台中，Machine Config Operator 处理 *** 作系统升级。与通过yum升级来升级单个包不同，rpm-ostree将 *** 作系统的升级作为一个原子单元来交付。新的 *** 作系统部署在升级期间进行，并在下一次重新启动时生效。如果升级出现问题，一次回滚和重新启动将使系统恢复到以前的状态。OpenShift容器平台中的RHCOS升级是在集群更新期间执行的。

对于RHCOS系统，rpm-ostree文件系统的布局具有以下特点:

RHCOS被设计成部署在OpenShift容器平台集群上，只需要最少的用户配置。其最基本的形式包括:

因为OpenShift容器平台中的RHCOS系统被设计为在此之后完全由OpenShift容器平台集群管理，所以不鼓励直接更改RHCOS机器。虽然可以出于调试目的对RHCOS机器集群进行有限的直接访问，但是不应该直接配置RHCOS系统。相反，如果您需要在您的OpenShift容器平台节点上添加或更改特性，请考虑通过以下方式进行更改:

下面是一些你可以在 day-1 进行的定制的例子:

为了完成这些任务，您可以扩展openshift-install过程，以包括额外的对象，如MachineConfigs。那些导致创建MachineConfigs的过程可以在集群启动后传递给Machine Config Operator。

针对OpenShift容器平台的RHCOS部署之间的差异取决于您是部署在安装程序提供的基础设施上，还是部署在用户提供的基础设施上:

Ignition只有在首次安装RHCOS系统时才能运行。之后，可以使用MachineConfigs提供Ignition配置。

Ignition是在初始配置期间被RHCOS用来 *** 作磁盘的实用工具。它完成常见的磁盘任务，包括分区磁盘、格式化分区、编写文件和配置用户。在第一次启动时，Ignition从安装介质或您指定的位置读取其配置，并将配置应用到机器上。

无论您是安装集群还是向集群中添加机器，Ignition总是执行OpenShift容器平台集群机器的初始配置。大多数实际的系统设置是在每台机器上进行的。对于每台机器，Ignition将获取RHCOS镜像并启动RHCOS内核。在内核命令行上的选项，识别部署类型和启用了启动的初始Ram磁盘(initramfs)的位置。

要使用Ignition创建机器，您需要Ignition配置文件。OpenShift容器平台安装程序创建了部署集群所需的Ignition配置文件。这些文件基于您直接或通过安装配置提供信息给install-config.yaml 文件。

Ignition配置机器的方式与cloud-init或Linux Anaconda kickstart等工具配置系统的方式类似，但有一些重要的区别:

在OpenShift容器平台集群中，RHCOS机器的Ignition过程包括以下几个步骤:

然后，机器就可以加入集群，不需要重新启动。

要查看用于部署引导机的Ignition配置文件，请运行以下命令:

在你回答了几个问题之后，bootstrap.ign, master.ign, 和worker.ign文件出现在您输入的目录中。

为了查看 bootstrap.ign文件，通过jq过滤器，以下是该文件的一个片段:

解码 bootstrap.ign文件内容。将表示该文件内容的base64编码的数据字符串通过管道传输到base64 -d命令。下面是一个例子，使用/etc/motd文件的内容从上面的输出添加到引导机:

在master.ign 和 worker.ign 文件上重复这些命令，查看每种机器类型的Ignition配置文件的来源。对于worker.ign，您应该看到类似下面这样的一行。确定它如何从引导机获得Ignition配置:

下面是一些你可以从bootstrap.ign文件学到:

Machine Config Pools管理节点集群及其相应的Machine Configs。Machine Configs包含集群的配置信息。列出所有已知的Machine Config Pools：

列出所有的Machine Config:

在应用这些MachineConfigs时，Machine Config Operator 的行为与Ignition有所不同。machineconfigs按顺序读取(从00 到99 )。machineconfigs中的标签标识每个节点(主节点或工作节点)的类型。如果相同的文件出现在多个machineconfig文件中，则最后一个获胜。因此，例如，出现在99 文件中的任何文件都将替换出现在00 文件中的相同文件。输入的machineconfig对象被合并到一个“呈现的”machineconfig对象中，该对象将被operator用作目标，并且是您可以在machineconfigpool中看到的值。

要查看从一个MachineConfigs中管理哪些文件，请在一个特定的MachineConfigs中查找“Path:”。例如:

如果您想要更改其中一个文件中的设置，例如将crio.conf文件中的pids_limit更改为1500 (pids_limit = 1500)，您可以创建一个新的只包含您想要更改的文件的machineconfig。

确保稍后为machineconfig指定一个名称(例如10-worker-container-runtime)。请记住，每个文件的内容都是url样式的数据。然后将新的machineconfig应用于集群。

说明：xfs文件格式，docker overlay2存储设备必须设置 ftype=1 。

强制同步时间

将普通用户添加到docker用户组

/etc/sysconfig/docker-storage

DOCKER_STORAGE_OPTIONS="--storage-driver overlay2 "

/etc/sysconfig/docker

OPTIONS=" --log-opt max-size=1M --log-opt max-file=3 --live-restore=true "

设置docker与kubelet的 cgroup driver 为systemd。OpenShift默认安装就是设置的systemd，而社区版的kubelet默认是cgroupfs，需要注意。。

添加文件

管理网：集群间组件通信，Node与Master节点通信网络

业务网：应用间网络通信，pod间网络通信

存储网：与存储设备网络通信

还可以将与外部镜像仓库的网络也考虑进去

每个网络，使用两张网卡做bond，提高网络性能及可用性。

其中管理网与业务网必须互通，否则部分组件服务将不可用。

将私有镜像仓库的CA文件拷贝到镜像仓库所在服务器的/etc/pki/ca-trust/source/anchors/目录下

为OpenShift节点设置默认的登录信息

OpenShift官方推荐规则

通常，它需要保留5％-10％的节点资源来保护节点，越高越安全。

AWS的规则：

内存预留值（AWS）:

Reserved memory = 255MiB + 11MiB * MAX_POD_PER_INSTANCE

CPU预留值（AWS）:

GKE的规则：

内存预留值（GKE）:

CPU预留值（GKE）::

例子：2 vCPU and 7.5GB

Azure的规则：

内存预留值（Azure）:

CPU预留值（Azure）:

另外：

Google和亚马逊产品的hard eviction threshold 为100MB，而AKS则为750MB。

其中各证书的文件名不要使用与Master组件默认的名字重复，否则会覆盖掉组件间的自签证书。

另外可以自签证书生成长有效期的相关证书。 自签证书步骤如下：

OpenShift 3.11中默念Node的证书有效期为1年，满1年后会自动更新证书。更新证书时，该节点会向集群发送证书签发请求，批准之后才能继续添加到集群。

说明：对于已经部署好的集群可以通过执行ansible-playbook来配置

或者部署时更新以下文件内容(openshift 3.9以上)

roles/openshift_node/defaults/main.yml

将message日志只保留最近三天的日志

如果要设置普通用户可查看/var/log/messages文件，需要在/etc/rsyslog.conf配置的前面添加messages文件可读权限

做为定时任务定期作清理

ROUTER_THREADS 设置为CPU核数

ROUTER_MAX_CONNECTIONS 默认值是20000

设置页面HTML，覆盖/var/lib/haproxy/conf/error-page-503.http文件

补充 ： Openshift自定义Router配置

minimum-container-ttl-duration : 容器可以进行垃圾收集的最低时长。 默认值为0，表示不限制。 可以使用单位后缀来指定此设置的值，例如h表示小时，m表示分钟，s表示秒。

maximum-dead-containers-per-container ：每个pod容器要保留的实例数。 预设值为1。

maximum-dead-containers ：节点中死容器总数的最大值。 默认值为-1，表示无限制。

核心步骤是：

具体 *** 作参考笔者之前的文章： OpenShift部署时如何延长组件证书的有效期

参考文章：

linux journalctl 命令

配置 logrotate 的终极指导

Allocatable memory and CPU in Kubernetes Nodes

OpenShift容器云平台建设之部署前准备

企业级容器云平台建设之功能汇总

---