etcd数据库（etcm数据库检索方法）

本篇文章给大家谈谈etcd数据库，以及etcm数据库检索方法对应的知识点，希望对各位有所帮助，不要忘了收藏本站喔。

本文目录一览：

• 1、超全K8s集群构建指南，建议收藏
• 2、kubernetes控制平面组件：etcd
• 3、查询 k8s 中 etcd 数据库信息

超全K8s集群构建指南，建议收藏

1. 什么是kubernetes

　Kubernetes(k8s)是Google开源的容器集群管理系统（谷歌内部:Borg）。在Docker技术的基础上，为容器化的应用提供部署运行、资源调度、服务发现和动态伸缩等一系列完整功能，提高了大规模容器集群管理的便捷性。

2. kubernetes核心组件说明

Kubernetes 集群中主要存在两种类型的节点，分别是 master 节点 ，以及 minion 节点 。

Minion 节点是实际运行 Docker 容器的节点，负责和节点上运行的 Docker 进行交互，并且提供了代理功能。

Master 节点负责对外提供一系列管理集群的 API 接口，并且通过和 Minion 节点交互来实现对集群的操作管理。

apiserver ：用户和 kubernetes 集群交互的入口，封装了核心对象的增删改查操作，提供了 RESTFul 风格的 API 接口，通过 etcd 来实现持久化并维护对象的一致性。

scheduler ：负责集群资源的调度和管理，例如当有 pod 异常退出需要重新分配机器时，scheduler 通过一定的调度算法从而找到最合适的节点。

controller-manager ：主要是用于保证 replicationController 定义的复制数量和实际运行的 pod 数量亮禅一致，另外还保证了从 service 到 pod 的映射关系总是最新的。

kubelet ：运行在 minion 节点，负责和节点上的 Docker 交互，例如启停容器，监控运行状态等。

proxy ：运行在 minion 节点，负责为 pod 提供代理功能，会定期从 etcd 获取 service 信息，并根据 service 信息通过修改 iptables 来实现流量转发（最初的版本是直接通过程序提供转发功能，效率较低。），将流量转发到要访问的 pod 所在的节点上去。

etcd ：key-value键值存储数据库，用来存储kubernetes的信息的。

flannel ：Flannel 是 CoreOS 团队针对 Kubernetes 设计的一个覆盖网络（Overlay Network）工具，需要另外下载部署。

我们知道当我们启动 Docker 后会有一个用于和容器进行交互的 IP 地址，如果不去管理的话可能这个 IP 地址在各个机器上是一样的，并且仅限于在本机上进行通信，无法访问到其他机器上的 Docker 容器。

Flannel 的目的就是为集群中的所有节点重镇销新规划 IP 地址的使用规则，从而使得不同节点上的容器能够获得同属一个内网且不重复的 IP 地址，并让属于不同节点上的容器能够直接通过内网 IP 通信。

3. Kubernetes的核心概念

Pod

运行于Node节点上，若干相关容器的组合。Pod内包含的容器运行在同一宿主机上，使用相同的网络命名空间、IP地址和端口，能够通过localhost进行通。

Pod是Kurbernetes进行创建、调度和管理的最小单位，它提供了比容器更高层次的抽象，使得部署和管理更加灵活。一个Pod可以包含一个容器或者多个相关容器。

Replication Controller

Replication Controller用来管理Pod的副本，保证集群中存在指定数量的Pod副敬旅尘本。

集群中副本的数量大于指定数量，则会停止指定数量之外的多余容器数量，反之，则会启动少于指定数量个数的容器，保证数量不变。

Replication Controller是实现弹性伸缩、动态扩容和滚动升级的核心。

Service

Service定义了Pod的逻辑集合和访问该集合的策略，是真实服务的抽象。

Service提供了一个统一的服务访问入口以及服务代理和发现机制，用户不需要了解后台Pod是如何运行。

Label

Kubernetes中的任意API对象都是通过Label进行标识，Label的实质是一系列的K/V键值对。Label是Replication Controller和Service运行的基础，二者通过Label来进行关联Node上运行的Pod。

Node

Node是Kubernetes集群架构中运行Pod的服务节点（或agent）。

Node是Kubernetes集群操作的单元，用来承载被分配Pod的运行，是Pod运行的宿主机。

4. 前置条件设置

三台Centos7系统的虚拟机（1个master+2个node）,三台机器上的防火墙，SELINUX全部关掉。我的实验坏境可以上网，默认的YUM源就可以用。

5. 部署规划

192.168.10.1 # master节点(etcd,kubernetes-master)

192.168.10.2 # node1节点(etcd,kubernetes-node,docker,flannel)

192.168.10.3 # node2节点(etcd,kubernetes-node,docker,flannel)

6. 开始安装

step1：在master上安装

yum install kubernetes-master etcd flannel -y

step2：在node上安装

yum install kubernetes-node etcd flannel -y

step3：etcd集群配置

在master节点上编辑etcd配置文件

在node1节点上编辑etcd配置文件

在node2节点上编辑etcd配置文件

到此etcd集群就部署完了，然后每个节点上启动

systemctl start etcd

step4：验证

step6：启动Master上的三个服务

step7：kubernetes node安装

node2 节点重复上述操作

step8：分别启动kubernetes node服务

7. 网络配置

因为kubernetes集群中网络部分是插件形式安装的，我们这里选用flannel

上述安装步骤已经install 了

为flannel创建分配的网络

8. 执行kubectl 命令检查

在master上执行下面，检查kubernetes的状态

9. 常用排错命令如下

kubernetes控制平面组件：etcd

--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 控制面架构

问题

[img]

查询 k8s 中 etcd 数据库信息

上面的命令将查询 /registry/configmaps/istio-system/istio-sidecar-injector-1-11-2 的配置信和链息碧棚数悔首。

关于etcd数据库和etcm数据库检索方法的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。