cn Archives - Page 21 of 31

06 May 2021 Thursday

Docker 启动etcd cluster

Etcd 默认使用 2380 端口监听其他server的请求，2379 则用来提供 HTTP API 服务

–auto-compaction-retention
- 由于ETCD数据存储多版本数据，随着写入的主键增加历史版本需要定时清理，默认的历史数据是不会清理的，数据达到2G就不能写入，必须要清理压缩历史数据才能继续写入;所以根据业务需求，在上生产环境之前就提前确定，历史数据多长时间压缩一次;推荐一小时压缩一次数据这样可以极大的保证集群稳定，减少内存和磁盘占用
–max-request-bytes
- etcd Raft消息最大字节数，ETCD默认该值为1.5M; 但是很多业务场景发现同步数据的时候1.5M完全没法满足要求，所以提前确定初始值很重要;由于1.5M导致我们线上的业务无法写入元数据的问题，我们紧急升级之后把该值修改为默认32M，但是官方推荐的是10M，大家可以根据业务情况自己调整
–quota-backend-bytes
- ETCD db数据大小，默认是2G，当数据达到2G的时候就不允许写入，必须对历史数据进行压缩才能继续写入;参加1里面说的，我们启动的时候就应该提前确定大小，官方推荐是8G，这里我们也使用8G的配置

–initial-cluster
- 指定集群内的节点，用逗号分隔需要匹配 –initial-advertise-peer-urls

–initial-cluster-token
- 每个集群独一无二的token

–listen-client-urls
- 指定的主机名/IP + 端口上监听客户端请求

–advertise-client-urls
- 指定的主机名/IP + 端口向集群内其他成员发布

docker run --restart=always --net host -it --name etcd1 -d -v /var/etcd:/var/etcd -v /etc/localtime:/etc/localtime registry.cn-hangzhou.aliyuncs.com/google_containers/etcd:3.2.24 etcd --name etcd-s1 --auto-compaction-retention=1 --max-request-bytes=33554432 --quota-backend-bytes=8589934592 --data-dir=/var/etcd/etcd-data --listen-client-urls http://0.0.0.0:2379 --listen-peer-urls http://0.0.0.0:2380 --initial-advertise-peer-urls http://192.168.194.164:2380 --advertise-client-urls http://192.168.194.164:2379,http://192.168.194.164:2380 --initial-cluster-token etcd-cluster --initial-cluster "etcd-s1=http://192.168.194.164:2380,etcd-s2=http://192.168.194.165:2380,etcd-s3=http://192.168.194.166:2380" --initial-cluster-state new

docker run --restart=always --net host -it --name etcd2 -d -v /var/etcd:/var/etcd -v /etc/localtime:/etc/localtime registry.cn-hangzhou.aliyuncs.com/google_containers/etcd:3.2.24 etcd --name etcd-s2 --auto-compaction-retention=1 --max-request-bytes=33554432 --quota-backend-bytes=8589934592 --data-dir=/var/etcd/etcd-data --listen-client-urls http://0.0.0.0:2379 --listen-peer-urls http://0.0.0.0:2380 --initial-advertise-peer-urls http://192.168.194.165:2380 --advertise-client-urls http://192.168.194.165:2379,http://192.168.194.165:2380 --initial-cluster-token etcd-cluster --initial-cluster "etcd-s1=http://192.168.194.164:2380,etcd-s2=http://192.168.194.165:2380,etcd-s3=http://192.168.194.166:2380" --initial-cluster-state new

docker run --restart=always --net host -it --name etcd3 -d -v /var/etcd:/var/etcd -v /etc/localtime:/etc/localtime registry.cn-hangzhou.aliyuncs.com/google_containers/etcd:3.2.24 etcd --name etcd-s3 --auto-compaction-retention=1 --max-request-bytes=33554432 --quota-backend-bytes=8589934592 --data-dir=/var/etcd/etcd-data --listen-client-urls http://0.0.0.0:2379 --listen-peer-urls http://0.0.0.0:2380 --initial-advertise-peer-urls http://192.168.194.166:2380 --advertise-client-urls http://192.168.194.166:2379,http://192.168.194.166:2380 --initial-cluster-token etcd-cluster --initial-cluster "etcd-s1=http://192.168.194.164:2380,etcd-s2=http://192.168.194.165:2380,etcd-s3=http://192.168.194.166:2380" --initial-cluster-state new

By studyk8s 0 Comments

06 May 2021 Thursday

Etcd 强一致性

Etcd 读和写都可以保证线性一致

线性一致性读需要在所有节点走一遍确认，查询速度会有所降低，要开启线性一致性读，在不同的 client是有所区别的:

v2 版本：通过 sdk访问时，quorum=true 的时候读取是线性一致的，通过etcdctl访问时，该参数默认为true。
v3 版本：通过 sdk访问时，WithSerializable=true 的时候读取是线性一致的，通过etcdctl访问时consistency=“l”表示线性（默认为 l，非线性为 s）

为了保证线性一致性读，早期的 etcd（_etcd v3.0 _）对所有的读写请求都会走一遍 Raft 协议来满足强一致性。然而通常在现实使用中，读请求占了 etcd 所有请求中的绝大部分，如果每次读请求都要走一遍 raft 协议落盘，etcd 性能将非常差。

因此在 etcd v3.1 版本中优化了读请求（PR#6275），使用的方法满足一个简单的策略：每次读操作时记录此时集群的 commit index，当状态机的 apply index 大于或者等于 commit index 时即可返回数据。由于此时状态机已经把读请求所要读的 commit index 对应的日志进行了 apply 操作，符合线性一致读的要求，便可返回此时读到的结果。

综上所述，当超半数节点宕机时，由于无法 apply ，也就没法进行读取动作

By studyk8s 0 Comments

05 May 2021 Wednesday

RAFT 算法

raft 算法主要使用两种方式来提高可理解性

问题分解
- 领导人选举
- 日志复制
- 安全性
- 成员关系变化
减少状态空间
- 强领导人
- 领导人选举
- 成员变化

raft协议组织的集群中，一共包含3类角色

Leader
Candidate
Follower

raft 算法将时间划分成为任意个不同长度的任期，任期是单调递增的，用连续的数字 1、2、3 … 表示。
每一个任期，都是由一次选举人选举开始的。

每个任期只能选举出一个领导人，如果选票被平分，那么本次选举失败，系统会直接进入下一任期

每一个raft节点各自都在本地维护一个当前任期值，增加这个数字以进入下一任期
主要有两种场景：开始选举和与其他节点交换信息
当节点进行通信时，会相互交换当前的任期号。如果一个节点的当前任期号比其他节点的任期号小，则将自己本地的任期号自觉地更新为较大的任期号。如果一个候选人或领导人意识到自己的任期号过时了（比别人小），那么它会立刻切换回群众状态，如果一个节点收到的拉票请求锁携带的任期号是过时的，那么该节点就会拒绝本次拉票请求。

领导人选举
raft 通过选举一个权力至高无上的领导人，并采取赋予它管理复制日志权力的方式来维护节点间日志的一致性。领导人从客户端接收日志条目，再把日志条目复制到其他服务器上，并且在保证安全的前提下，告诉其他服务器将日志条目应用它们的状态机中。

每个候选人携带一个 “造反计时器”，并且每个选举人的计时器时间是随机的，各不相同。
领导人会定时向各个节点发送 “不要造反心跳”，各节点接收到 “不要造反心跳” 后，会重置自己的 “造反计时器”，为了避免频繁地发生选举，Leader广播心跳的周期会小于 “造反计时器” （选举定时器）的超时时间。

如果一个Follower决定参加选举，那么它会执行以下步骤

把自己的任期号 +1
切换自己到候选人状态
向其他节点发送拉票请求（带着自己的新任期号）

然后它可能会得到以下结果

成功拉票超过半数，成为Leader
发现已经有节点在自己之前成功当选，主动切换回 Follower
过了一段时间之后，发现没有人赢得选举，重新发起一次选举

日志复制
一旦某个领导人赢得了选举，那么它就会开始接受客户端的请求。
客户端请求都将被解析成一条需要复制状态机执行的指令。领导人节点把这条指令作为一个新的日志条目加入它的日志文件中，然后并行地向其他raft节点发起 AppendEntries RPC，要求其他节点复制这个日志条目。

过半数节点复制成功之后，领导人节点会发起 apply 指令将这条日志应用到它的状态机中，并向客户端返回，然后再向其他节点广播应用消息。

这里因为 Follower 节点会无条件的服从 Leader，如果Leader在响应了客户端请求之后（日志已经分发，但是还没有apply）发生了故障，那么新当选的 leader 和之前的leader 数据可能发生冲突。所以在raft中有一个重要限制，任何领导人都必须拥有之前任期提交的全部日志条目
raft采用拉票的方式来保证这一机制，当候选人进行拉票时，投票人会检查候选人提交的最新日志条目是否大于等于自己本地的条目，如果候选人的条目没有比自己的日志条目更新，那么选举人将拒绝此次投票请求。比较的依据是日志文件中最后一个条目的索引和任期号

By studyk8s 0 Comments

05 May 2021 Wednesday

Etcd watch 机制

首先用docker来启动etcd

docker run -d\
  -p 2379:2379 \
  -p 2380:2380 \
  --name etcd quay.io/coreos/etcd:latest \
  /usr/local/bin/etcd \
  --data-dir=/etcd-data --name node1 --listen-client-urls http://0.0.0.0:2379 --advertise-client-urls http://0.0.0.0:2379 --listen-peer-urls=http://0.0.0.0:2380 --initial-advertise-peer-urls=http://0.0.0.0:2380

我们往etcd里加入一个键值对

curl http://127.0.0.1:2379/v2/keys/key1 -XPUT -d value="Hello world"

etcd 的 watch 监听分为两种，一次性监听和持续监听

一次性监听

监听到了事件则返回json数据。返回后监听退出，后续需要再次启动监听。recursive为监听所有子节点变化。

curl http://127.0.0.1:2379/v2/keys/key1?wait=true&recursive=true

然后我们来改变这个key1的值

curl http://127.0.0.1:2379/v2/keys/key1 -XPUT -d value="changed value"

当key1的值变化后，可以看到之前wait的进程结束了，并且监听到了返回

永久监听，监听到了事件不会退出，持续返回数据。相比一次性监听要可靠

curl http://127.0.0.1:2379/v2/keys/key1\?wait\=true\&recursive\=true\&stream\=true

By studyk8s 0 Comments

30 Apr 2021 Friday

Rancher Backups and Disaster Recovery

这里我使用的是 Longhorn 作为 PV，实际上S3也是一个不错的选择

选择 rancher backups

安装以后把默认存储改成 Storage Class

Rancher backups 会创建一个对应的PVC

选择创建备份

在 Longhorn 中查看

使用backup还原

等待上面截图中 restore 状态从 active 变为 Completed

rancher backup 会还原以下3种资源

Custom Resource Definitions (CRDs)
Cluster-scoped resources
Namespaced resources

By studyk8s 0 Comments

29 Apr 2021 Thursday

RKE2 Etcd Backup and Restore

默认的备份存储路径是

/var/lib/rancher/rke2/server/db/snapshots

默认的etcd数据保存在

/var/lib/rancher/rke2/server/db/etcd

第一种情况，如果要直接使用 /var/lib/rancher/rke2/server/db/etcd 中的原数据，然后把集群节点缩减到只剩一台 server 节点，可以直接使用 reset 命令

systemctl stop rke2-server
rke2 server --cluster-reset

第二种情况，想使用备份还原

rke2 server \
  --cluster-reset \
  --cluster-reset-restore-path=<PATH-TO-SNAPSHOT>

此命令会生成一个文件 /var/lib/rancher/rke2/server/db/etc/reset-file，如果想要再次reset，需要删除这个文件

By studyk8s 0 Comments

29 Apr 2021 Thursday

Kubelet 和 CRI

Kubelet的核心功能是在宿主机上创建Pod，并启动它所定义的各个容器。

在Kubernetes社区中，Kubelet 和 CRI 都属于 SIG-Node。

Kubernetes 有两个不可替代的组件，一个是kube-apiserver 另一个就是 Kubelet。

Kubelet本身是按照控制器模式来工作的。工作核心是一个控制循环 SyncLoop

驱动该控制循环运行的事件包括四种

Pod 更新事件
Pod 生命周期变化
Kubelet 本身设置的执行周期
定时清理事件

Kubelet会通过Watch机制，监听与自己相关的Pod对象的变化。当然，这个watch的过滤条件是该Pod的nodeName字段与自己的相同。Kubelet会把这些Pod的信息缓存在自己的内存中。

这里需要注意的是，kubelet 调用下层容器运行时的执行过程并不会直接调用Docker的API，而是通过一组叫做CRI的gRPC接口来间接执行的。在1.6 版本之前的Kubernetes，是直接调用Docker API来创建和管理容器的

CRI机制的核心就在于每种容器项目现在都可以自己实现一个CRI shim，自行对CRI请求进行处理。这样，Kubernetes就有了一个统一的容器抽象层。

除了dockershim之外，其他容器运行时的CRI shim 都需要额外部署在宿主机上。

CNCF中的 containerd 项目就可以提供一个典型的 CRI shim 能力，把Kubernetes发出的CRI请求转换成对 containerd的调用，然后创建出runC容器。而runC项目才是负责执行设置容器 Namespace、Cgroups 和 chroot 等基础操作的组件。

CRI 里还有一组叫做 RunPodSandbox接口。它对应的并不是Kubernetes 里的Pod API 对象，而只是抽取了 Pod 里的一部分与容器运行时相关的字段，如 HostName、DnsConfig、CgroupParent 等。
作为具体的容器项目，你需要自己决定如何使用这些字段来实现一个Kubernetes期望的Pod模型。

当执行了 kubectl run创建了一个包含 A、B两个容器的Pod之后，这个Pod的信息最后来到kubelet。

然后kubelet会按照一下步骤创建 A、B两个容器

RunPodSandbox（foo）
CreatContainer(A)
StartContainer(A)
CreatContainer(B)
StartContainer(B)

在具体的CRI shim中，这些接口的实现可以完全不同

如果是Docker项目，dockershim就会创建出一个名为 foo 的 Infra容器（pause容器），用来 hold 整个Pod的Network Namespace。
如果是基于虚拟化技术的容器，比如 Kata Containers项目，它的CRI实现就会直接创建出一个轻量级的虚拟机来充当Pod

在RunPodSandbox 接口实现中，还需要调用 networkPlugin.SetUpPod(…)来为这个Sandbox设置网络。这个SetUpPod(…)就是执行CNI插件里的add(…)方法。

所以最后在宿主机上，dockershim会留下3个容器，Kata Containers 则会留下一个轻量级虚拟机。

如果对一个容器调用 kubectl exec ，这个请求会先交给 api server，然后api server会调用 kubelet的exec api，这样kubelet就会调用CRI 的 exec 接口，而负责响应这个接口的是 CRI shim。

CRI shim会返回一个此CRI shim的 streaming server 的地址和端口 URL 给kubelet，kubelet拿到URL之后，会以 redirect的方式返回给 api server，api server 就会通过重定向来向 streaming server 发起真正的 exec 请求，并与它建立长连接。

By studyk8s 0 Comments

28 Apr 2021 Wednesday

Node capacity

查看当前Node 的 capacity

Capacity:
  cpu:                4
  ephemeral-storage:  50824704Ki
  hugepages-1Gi:      0
  hugepages-2Mi:      0
  memory:             8123340Ki
  pods:               110

如果要在上述 status 字段里添加新的 capacity ，必须使用 PATCH API

启动proxy

kubectl proxy

添加新的 capacity

curl --header "Content-Type: application/json-patch+json" \
--request PATCH \
--data '[{"op": "add", "path": "/status/capacity/studyk8s.com~1lizhe", "value": "4"}]' \
http://localhost:8001/api/v1/nodes/k1/status

curl --header "Content-Type: application/json-patch+json" \
--request PATCH \
--data '[{"op": "remove", "path": "/status/capacity/studyk8s.com~1lizhe"}]' \
http://localhost:8001/api/v1/nodes/k1/status

上面代码会生成 studyk8s.com/lizhe: 4

然后就可以在dep中使用

        resources:
          limits:
            studyk8s.com/lizhe: 4

这样 studyk8s.com/lizhe 就成为了一种资源

因为只有node1带有这种资源，而且已经被耗尽了，所以无法部署多个

By studyk8s 0 Comments

28 Apr 2021 Wednesday

Kubernetes 默认调度器的优先级和抢占机制

优先级和抢占机制解决的是 Pod 调度失败之后应该怎么办的问题

默认情况下，当一个Pod调度失败之后，它会被先搁置，直到 Pod 被更新或者集群状态发生变化时，调度器才会重新调度这个Pod。

但是有时候我们会希望让某个优先级较高的Pod，挤走某个优先级较低的Pod

首先需要在Kubernetes里提交一个 PriorityClass的定义

apiVersion: scheduling.k8s.io/v1
kind: PriorityClass
metadata:
 name: high-priority-10000
value: 10000
globalDefault: false
description: "my desc 10000"

如果不标识 PriorityClass ，那么它的优先级是 0

如果你设置了 globalDefault: false 那么这个PC的值就会变成系统的默认值

我们的集群状态是 3个节点，每个有4内核，8GB内存

我部署3个nginx，标记每个需要3个内核

    resources:
      limits:
        cpu: 3
        memory: 2Gi
      requests:
        cpu: 3
        memory: 2Gi

这样我们就把所有的cpu资源都吃掉了

然后再来部署一个用来竞争的nginx

同样的requests同样的limits，在不使用优先级和抢占机制时，调度器是无法完成调度的

加入优先级之后的情况

最终 nginx1 挤掉了所有的 nginx0

By studyk8s 0 Comments

27 Apr 2021 Tuesday

RKE2 crictl

RKE2 已经移除了对Docker的支持改用containerd

那么如果也就意味着我们无法像以前一样使用 docker images 来手动查看本地镜像

这里先剧透一下如何在RKE2中手动查看 image

./crictl --runtime-endpoint unix:///run/k3s/containerd/containerd.sock image

如何确定sock文件位置呢？

cat /var/lib/rancher/rke2/agent/etc/crictl.yaml

我们来查一下RKE2是如何指定CRI的

pull镜像

crictl --runtime-endpoint unix:///run/k3s/containerd/containerd.sock pull nginx

由于CRI携带了Pod接口，所以它可以非常魔性的直接读取当前宿主机上的Pod信息，这在docker上是绝对不可能的

crictl --runtime-endpoint unix:///run/k3s/containerd/containerd.sock pods

By studyk8s 0 Comments

cn

Send a Message