kubernetes控制平面组件：etcd

Posted 2023-04-08

参考技术A

--listen-peer-urls

--listen-client-urls

--initial-advertise-peer-urls

--initial-cluster

--initial-cluster-state

--advertise-client-urls

1.code

headless svc, 像DNS RR ClusterIP:None

kubectl -n stg1 get endpoints

client 怎么访问：

2.配置文件

3.apply

官方的code有两个问题

本地访问

扩容

利用反亲和性 分布etcd pod到不同节点

~ ❯❯❯ etcdctl get / --prefix

从 etcd 的架构图中我们可以看到，etcd 主要分为四个部分。

etcd 目前支持 V2 和 V3 两个大版本，这两个版本在实现上有比较大的不同，一方面是对外提供接口的方式，另一方面就是底层的存储引擎，V2 版本的实例是一个纯内存的实现，所有的数据都没有存储在磁盘上，而 V3 版本的实例就支持了数据的持久化。

v3默认boltdb

consortium etcd2+mysql

数据默认会存放在 /var/lib/etcd/default/ 目录。我们会发现数据所在的目录，会被分为两个文件夹中，分别是 snap 和 wal目录。

解决三个问题：节点选举、日志复制以及安全性 。

每一个 Raft 集群中都包含多个服务器，在任意时刻，每一台服务器只可能处于 Leader 、 Follower 以及 Candidate 三种状态；在处于正常的状态时，集群中只会存在一个 Leader 状态，其余的服务器都是 Follower 状态。

所有的 Follower 节点都是被动的，它们不会主动发出任何的请求 ，只会响应 Leader 和 Candidate 发出的请求。对于每一个用户的可变操作，都会被路由给 Leader 节点进行处理，除了 Leader 和 Follower 节点之外，Candidate 节点其实只是集群运行过程中的一个临时状态。

每一个服务器都会存储当前集群的最新任期，它就像是一个单调递增的逻辑时钟，能够同步各个节点之间的状态，当前节点持有的任期会随着每一个请求被传递到其他的节点上。Raft 协议在每一个任期的开始时都会从一个集群中选出一个节点作为集群的 Leader 节点，这个节点会负责集群中的日志的复制以及管理工作。

客户端通过 监听指定的key可以迅速感知key的变化并作出相应处理 ，watch机制的实现依赖于 资源版本号revision的设计 ，每一次key的更新都会使得revision原子递增，因此根据不同的版本号revision的对比就可以感知新事件的发生。etcd watch机制有着广泛的应用，比如利用etcd实现分布式锁； k8s中监听各种资源的变化 ，从而实现各种controller逻辑等。

watch机制的实现主要可分为三个部分

client使用 watchClient 的watch接口发起watch请求，与server端建立一个 gRPCStream 连接。

server端会为每个client生成唯一一个watch id，并记录每个client也就是watcher监听的key或者key range，通过recvLoop接收client请求，通过sendLoop发送请求，server端只负责收发请求和响应。

主要的实现都放在了watchalbStore层，watchalbStore会监听key的变化，然后通过syncWatchersLoop和syncVictimsLoop两个处理流程将key的更新变化包装成event，通过channel发送给gRPC server。

MVCC（Multiversion Concurrency Control）多版本并发控制机制

场景1:

这就是悲观锁

悲观锁：悲观得认为并发事务会冲突，所以要先拿锁，拿到锁的作修改操作

场景2

数据库：写回磁盘，A写好了。哎，B和C都是version 13，我咋写？算了，报错吧。。

就是乐观锁，默认不加锁，你尽管写，冲突我认怂！乐观锁其实不是锁，只是相对悲观锁来定义，适合读多写少。

乐观锁：乐观得认为数据不会冲突，但发生冲突时要能检测到。

场景3

这就是MVCC，在 MVCC 数据库中，你更新一个 key-value 数据的时候，它并不会直接覆盖原数据，而是 新增一个版本来存储新的数据，每个数据都有一个版本号 ，版本号是一个逻辑时钟，不会因为服务器时间的差异而受影响。

MVCC不等于乐观锁！

--rev 查的是main

在底层boltdb里，实际分布是这样的：

底层的key是revision，/奥特曼是用户key，“他很帅”就是用户value

删除

之前有delete动作，但是依然有版本记录。为什么？

删除这个动作，其实etcd是在blotdb里写了一条，“删除用户/奥特曼”

此时有个问题：用户说我的确删除了啊，真的不要了！请把空间还给我啊！

回收 compact（压缩）

etcdctl compact version

compact 需要一个版本号。这个版本号就是写事务递增的那个版本号，compact 12345，就是说把版本12345以前的 标记删除了的数据 释放掉，用户没删除的数据肯定不能回收。

如何压缩：

注意修改go.mod

Watch

服务发现要解决的也是分布式系统中最常见的问题之一，即在同一个分布式集群中的进程或服务，要如何才能找到对方并建立连接。本质上来说，服务发现就是想要了解集群中是否有进程在监听 udp 或 tcp 端口，并且通过名字就可以查找和连接。

需要实现的功能；

discover.go

eBay payment

ebay kubernetes 控制面架构

问题

自动化集成：Kubernetes容器引擎详解

一、基础简介

Kubernetes简称K8S，是一个开源的分布式的容器编排引擎，用来对容器化应用进行自动化部署和管理。

Control-Plane-Components：控制平面组件，对集群做出全局决策，例如：调度、检测和事件响应，可以在集群中的任何节点上运行；

• api：作为K8S控制面的组件，开放K8S的API，相当于控制面的前端；
• etcd：兼具一致性和高可用性的键值数据库，作为保存K8S数据的后台库;
• scheduler：监听新建未指定运行节点的Pods，并为Pod选择运行节点；
• controllermanager：运行控制器进程，逻辑上是一个单独的进程；

Node：节点组件：每个节点上运行，维护运行的Pod并提供Kubernetes运行环境；

• kubelet：在每个节点上运行的代理，保证容器都运行在Pod中；
• kube-proxy：每个节点上运行的网络代理， 维护节点上的网络规则；

Container-Runtime：容器运行时，负责运行容器的软件，支持Docker、containerd、CRI-O等多个容器运行环境，以及任何实现Kubernetes-CRI容器运行环境接口。

二、环境配置

1、服务搭建

使用Git拉取k8s-docker-desktop-for-mac仓库，执行load_images.sh脚本，会拉取本地docker对应的k8s版本，注意这里要等到脚本流程执行完毕，可能因为Git连接的问题，耗时较长，下面是脚本拉取的镜像：

docker images
REPOSITORY                           TAG                                                  
docker/desktop-kubernetes            kubernetes-v1.21.5-cni-v0.8.5-critools-v1.17.0-debian
k8s.gcr.io/kube-apiserver            v1.21.5                                              
k8s.gcr.io/kube-proxy                v1.21.5                                              
k8s.gcr.io/kube-controller-manager   v1.21.5                                              
k8s.gcr.io/kube-scheduler            v1.21.5                                              
docker/desktop-vpnkit-controller     v2.0                                                 
docker/desktop-storage-provisioner   v2.0                                                 
k8s.gcr.io/pause                     3.4.1                                                
k8s.gcr.io/coredns/coredns           v1.8.0                                               
k8s.gcr.io/etcd                      3.4.13-0                                             

上述镜像下载完成后，通过docker桌面软件启动k8s即可，这里启动时间相对偏长，启动成功之后界面左下角K8S显示绿色状态：

2、环境查看

# 查看版本：kubectl version
Client Version GitVersion:v1.21.5
Server Version GitVersion:v1.21.5

# 查看集群：kubectl cluster-info
Kubernetes control plane is running at local-host:6443

# 查看节点：kubectl get nodes
NAME             STATUS   ROLES                  AGE   VERSION
docker-desktop   Ready    control-plane,master   23h   v1.21.5

三、部署Docker镜像

1、核心组件

在执行Docker镜像部署之前，首先要理解该流程中几个核心的概念：

• Pod：是可以在Kubernetes中创建和管理的、最小的可部署的计算单元；就Docker概念的术语而言，Pod类似于共享命名空间和文件系统卷的一组Docker容器；
• ReplicaSet：目的是维护一组在任何时候都处于运行状态的Pod副本的稳定集合；通常用来保证一定数量的、完全相同的Pod的可用性；
• Deployment：为Pods和ReplicaSets提供声明式的更新能力，可以定义Deployment以创建新的ReplicaSet，或删除现有Deployment；
• Service：抽象的方式将运行在一组Pods上的应用程序公开为网络服务，在K8S中逻辑上Pods集合与访问策略，这种模式被称为微服务；

2、脚本文件

这里将Deployment与Service放在一个.yaml文件中；镜像加载设置imagePullPolicy:Never即本地读取；其中服务发现采用的是NodePort类型，并没有设置具体端口，控制平面会在默认范围内分配一个端口号；

---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: cloud-app-deployment
  labels:
    app: cloud-app
spec:
  selector:
    matchLabels:
      app: cloud-app
  template:
    metadata:
      labels:
        app: cloud-app
    spec:
      containers:
      - name: cloud-app
        image: Cloud_Url/cicada-image/cloud-app
        imagePullPolicy: Never
        ports: 
        - containerPort: 8079
---
apiVersion: v1
kind: Service
metadata:
  name: cloud-app-service
  labels:
    app: cloud-app
spec:
  type: NodePort
  ports: 
    - port: 8080
      targetPort: 8079
  selector:
    app: cloud-app

3、资源管理

创建资源

kubectl create -f pod.yaml

查看资源

# 1、查看Pod信息
kubectl get pods -o wide

# 2、查看Service信息
kubectl get svc -o wide

# 3、查看Node信息
kubectl get nodes -o wide

也可以在K8S的Web控制台上，查看资源的可视化界面，下面截图几个脚本中明确声明的资源信息：

删除资源

# 1、通过文件删除
kubectl delete -f pod.yaml

# 2、通过具体资源名删除
kubectl delete pod cloud-app

4、访问资源

# 查看服务的详细描述
kubectl describe svc cloud-app-service
Name:                     cloud-app-service
NodePort:                 <unset>  30930/TCP
Endpoints:                Pod_IP:Pod_端口

这里NodePort端口默认分配30930，当外部访问流量到达Service时，会路由到指定Endpoints（端点），通过上面的资源查看可知，这里Endpoints即Pod的IP与端口；

通过：本机IP:分配端口/API方式，即localhost:30930/client访问到docker容器中应用，也可以在Web界面的Pod模块查看具体的日志输出：

四、控制台组件

Dashboard是基于Web的Kubernetes用户界面,可以使用Dashboard将容器应用部署到Kubernetes集群中，也可以对容器应用排错，还能管理集群资源，查看日志等。

1、创建命名空间

kubectl create namespace cm-dev

查看命名空间

2、查看Pod

3、查看Deployment

4、查看Service

---

同系列推荐：

• Jenkins管理工具详解
• Pipeline流水语法详解
• Docker容器入门简介
• Pipeline整合Docker容器
• 微服务组件二次浅封装

---

五、源代码地址

GitEE·地址
https://gitee.com/cicadasmile/butte-auto-parent
Wiki·地址
https://gitee.com/cicadasmile/butte-java-note