小五的个人杂货铺

https://www.reddit.com/r/kubernetes/comments/kqx5ql/difference_between_master_and_worker_concepts_in/ leader选举方案的不同在于用于备份主服务器的数据库 领导者选举是针对分布式数据库 etcd 的。由于 etcd 往往存在于 K8S 中的主节点上, 所以会和k3s混淆 K3S 默认使用 SQLite，因此不需要leader选举

前言官方文档 K3s 启动时会自动生成 CA 证书，CA 证书的有效期为 10 年。其他证书有效期为 1 年，如果证书已经过期或剩余的时间不足 90 天，则在 K3s 重启时轮换证书。K3s 服务只是一个进程，K3s 服务重启不会影响正在运行的 pod，也不会影响你的业务。 证书轮换方式（3种任选其一）使用crontab + shell脚本方式实现证书轮换编写脚本 - upgradeCert.sh，并放在主节点服务器上 查看主节点位置：kubectl get nodes -l 'node-role.kubernetes.io/control-plane'|awk '{if (NR>1){print $1}}' server node脚本 1234567891011121314151617181920#!/bin/bash# 目标目录DIR="/var/lib/rancher/k3s/server/tls"now=$(date +%s)# 递归查找.crt文件for FIL...

转自: https://blog.csdn.net/hakula007/article/details/125786395 Pod status 状态解释 [1] CrashLoopBackOff：容器退出，kubelet正在将它重启 InvalidImageName：无法解析镜像名称 ImageInspectError：无法校验镜像 ErrImageNeverPull：策略禁止拉取镜像 ImagePullBackOff：镜像正在重试拉取 RegistryUnavailable：连接不到镜像中心 ErrImagePull：通用的拉取镜像出错 CreateContainerConfigError：不能创建kubelet使用的容器配置 CreateContainerError：创建容器失败 m.internalLifecycle.PreStartContainer：执行hook报错 RunContainerError：启动容器失败 PostStartHookError：执行hook报错 ContainersNotInitialized：容器没有初始化完毕 ContainersNotR...

filebeat_daemonset.yaml123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194...

使用 etcdctletcdctl 为 etcd 提供了一个 CLI。 如果您想在安装带有嵌入式 etcd 的 K3s 后使用 etcdctl，请使用官方文档安装 etcdctl。 123VERSION="v3.5.0"curl -L https://github.com/etcd-io/etcd/releases/download/${VERSION}/etcd-${VERSION}-linux-amd64.tar.gz --output etcdctl-linux-amd64.tar.gztar -zxvf etcdctl-linux-amd64.tar.gz --strip-components=1 -C /usr/local/bin etcd-${VERSION}-linux-amd64/etcdctl 然后开始使用带有适当 K3s 标志的 etcdctl 命令： 1234etcdctl --endpoints="https://127.0.0.1:2379" --cac...

job 主要用于负责**批量处理(一次要处理指定数量任务)短暂的一次性(每个任务仅运行一次就结束)**任务。Job特点如下： 当Job创建的pod执行成功结束时，Job将记录成功结束的pod数量 当成功结束的pod达到指定的数量时，Job将完成执行 关于重启策略设置的说明： 如果指定为OnFailure，则job会在pod出现故障时重启容器，而不是创建pod，failed次数不变 如果指定为Never，则job会在pod出现故障时创建新的pod，并且故障pod不会消失，也不会重启，failed次数加1 job.yaml 12345678910111213141516171819202122232425262728293031323334apiVersion: batch/v1kind: Jobmetadata: name: job labels: app: jobspec: # 允许使用selector(默认是false) manualSelector: true # 指定job在任一时刻应该并发运行Pods的数量。默认值: 1 par...

在describe或kubelet日志中没有明确记录错误原因，基本都是因为command命令不合法导致 命令和参数说明：command 和 args 分别对应于 Dockerfile 中的 ENTRYPOINT 和 CMD。command 表示要执行的命令，args 是传递给该命令的参数。 如果command和args均没有写，那么用Dockerfile的配置。如果command写了，但args没有写，那么Dockerfile默认的配置会被忽略，执行输入的command（不带任何参数，当然command中可自带参数）。如果command没写，但args写了，那么Dockerfile中配置的ENTRYPOINT的命令行会被执行，并且将args中填写的参数追加到ENTRYPOINT中。如果command和args都写了，那么Dockerfile的配置被忽略，执行command并追加上args参数。比如： command：/test.sh,p1,p2args: p3,p4 关于CMD和ENTRYPOINT还有一点需要特别注意的是：如果一个Dockerfile中有多个CMD...

kubernetes组件一个kubernetes集群主要是由控制节点(master)、**工作节点(node)**构成，每个节点上都会安装不同的组件。 master：集群的控制平面，负责集群的决策 ( 管理 )ApiServer : 资源操作的唯一入口，接收用户输入的命令，提供认证、授权、API注册和发现等机制; 客户端与k8s群集及K8s内部组件的通信，都要通过Api Server这个组件；Scheduler : 负责集群资源调度，按照预定的调度策略将Pod调度到相应的node节点上。（算哪个节点）ControllerManager : 负责维护集群的状态，比如程序部署安排、故障检测、自动扩展、滚动更新等（部署和维护的）Etcd/节点信息存储 ：负责存储集群中各种资源对象的信息 **node：集群的数据平面，负责为容器提供运行环境 ( 干活 ) **Kubelet : 负责维护容器的生命周期，即通过控制docker/containerd，来创建、更新、销毁容器KubeProxy : 负责提供集群内部的服务发现和负载均衡 部署流程下面，以部署一个nginx服务...

摘自：https://blog.csdn.net/hancoder/article/details/118070296 访问控制概述 Kubernetes作为一个分布式集群的管理工具，保证集群的安全性是其一个重要的任务。所谓的安全性其实就是保证对Kubernetes的各种客户端进行认证和鉴权操作。 客户端 在Kubernetes集群中，客户端通常有两类： User Account：一般是独立于kubernetes之外的其他服务管理的用户账号。 Service Account：kubernetes管理的账号，用于为Pod中的服务进程在访问Kubernetes时提供身份标识。 认证、授权与准入控制 ApiServer是访问及管理资源对象的唯一入口。任何一个请求访问ApiServer，都要经过下面三个流程： Authentication（认证）：身份鉴别，只有正确的账号才能够通过认证 Authorization（授权）： 判断用户是否有权限对访问的资源执行特定的动作 Admission Control（准入控制）：用于补充授权机制以实现更加精细的访问控制功能。 认证管理...

重启策略 一些rs对象：必须设置为Always，需要保证该容器持续运行。Job和CronJob：OnFailure或Never，确保容器执行完成后不再重启。 重启策略适用于pod对象中的所有容器，首次需要重启的容器，将在其需要时立即进行重启，随后再次需要重启的操作将由kubelet延迟一段时间后进行，且反复的重启操作的延迟时长为10s，20s，40s，80s，160s，300s。300s是最大延迟时长 健康检测 记: 在服务刚启动时也许会提示检查失败的警告 Warning Unhealthy 18s (x2 over 24s) kubelet Readiness probe failed: dial tcp 10.42.2.55:32000: connect: connection refused,这个时候需要结合pod的启动日志进行查看是否真的启动成功 容器进程返回值非零，Kubernetes则认为容器 发生故障，需要重启。有不少情况是发生了故障，但进程并不会退出。比如访问Web服务器时显示500内部错误，可能是系统超载，也 可能是资源死锁，此时h...