etcd

1、环境信息： 本次环境搭建使用VMware Workstation虚拟出3台CentOS7.6虚拟机 节点架构：1个controller节点、1个compute节点、1个cinder块存储节点。 硬件配置信息具体如下： 节点名称 ------------CPU ----- 内存 ----- 操作系统----- 磁盘 controller节点 ----- 4C-------- 4GB ----- CentOS7.6----- 40GB compute节点 ----- 4C ----- 4GB ----- CentOS7.6----- 40GB cinder节点 ------- 4C ----- 4GB---- CentOS7.6----- 40GB系统盘，20GB存储盘 2、网络规划说明： 控制节点、计算节点与存储节点都配置2块网卡。 这里需要特别注意下，compute节点和cinder节点的第一块网卡是用于连接互联网安装部署Oenstack依赖软件包，如果你已经在本地搭建了openstack的yum源，这块网卡可以不需要配置的。 管理网络配置 为仅主机模式，官方解释通过管理网络访问互联网安装软件包，如果搭建的有内部yum源，管理网络是不需要访问互联网的，配置成hostonly模式也是可以的。这里我的管理网与本地网(外部网络)是复用。 隧道网络配置 为仅主机模式

3 月，跳不动了？>>> 作者 | Eric Li (壮怀) 阿里巴巴云原生存储负责人 引言 随着云原生应用对可迁移性、扩展性和动态特性的需求，对云原生存储也带来了相应的密度、速度、混合度的要求，所以对云存储基本能力之上又提出了在效率、弹性、自治、稳定、应用低耦合、GuestOS 优化和安全等方面的诉求。参考 《云原生存储和云存储有什么区别？》 新的企业负载／智能工作负载容器化、迁云、存储方面遇到的性能、弹性、高可用、加密、隔离、可观测性及生命周期等方面的问题，不但需要存储产品层次的改进，还需要在云原生的控制／数据平面的改进，推进云原生存储和云存储的演进。下文将分别介绍一下问题场景及问题，探讨可行的解决方案，最终可以得出云原生存储、云存储目前可以做什么和未来还需要做什么。 存储性能 长时延增加 场景 高性能计算场景中，集中处理批量数据，通过容器集群，同时启动数千 Pod，弹出数百 ECS 对共享性文件系统读写。 问题 重负载终负载下时延增加，高延迟毛刺增多，读写稳定性不足。 解决方案 分散负载到多文件系统，通过容器编排分散 IO 到多文件系统 存储产品的盘古 2.0 改造 集中式高吞吐写对共享存储池冲击 场景 高性能计算场景中，集中处理批量数据，10Gbps 读写请求进入同一存储集群。 问题 同一存储集群中的带宽挤占，造成访问质量下降。 解决方案 分散负载到多文件系统和多个存储集群

一、总体框架图： Master组件： nkube-apiserver Kubernetes API，集群的统一入口，各组件协调者，以HTTP API提供接口服务，所有对象资源的增删改查和监听操作都交给APIServer处理后再提交给Etcd存储。 nkube-controller-manager 处理集群中常规后台任务，一个资源对应一个控制器，而ControllerManager就是负责管理这些控制器的。 nkube-scheduler 根据调度算法为新创建的Pod选择一个Node节点。 Node组件： nkubelet kubelet是Master在Node节点上的Agent，管理本机运行容器的生命周期，比如创建容器、Pod挂载数据卷、 下载secret、获取容器和节点状态等工作。kubelet将每个Pod转换成一组容器。 nkube-proxy 在Node节点上实现Pod网络代理，维护网络规则和四层负载均衡工作。 ndocker或rocket/rkt 运行容器。 第三方服务： netcd 分布式键值存储系统。用于保持集群状态，比如Pod、Service等对象信息。 二、部署的步骤： 1、环境规划 2、安装Docker 3、自签TLS证书 4、部署Etcd集群 5、部署Flannel网络 6、创建Node节点kubeconfig文件 7、获取K8S二进制包 8

深入理解 etcd：etcd 性能优化实践 本文将主要分享以下五方面的内容： etcd 前节课程回顾复习； 理解 etcd 性能； etcd 性能优化 -server 端； etcd 性能优化 -client 端。 etcd 前节课程回顾复习 etcd 诞生于 CoreOs 公司，使用 Golang 语言开发，是一个分布式 KeyValue 存储引擎。我们可以利用 etcd 来作为分布式系统元数据的存储数据库，存储系统里面重要的元信息。etcd 同样也被各大公司广泛使用。 下图为 etcd 的基本架构： 如上所示，一个集群有三个节点：一个 Leader 和两个 Follower。每个节点通过 Raft 算法同步数据，并通过 boltdb 存储数据。当一个节点挂掉之后，另外的节点会自动选举出来一个 Leader，保持整个集群的高可用特性。Client 可以通过连接任意一个节点完成请求。 理解 etcd 性能 首先我们来看一张图： 上图是一个标准的 etcd 集群架构简图。可以将 etcd 集群划分成几个核心的部分：例如蓝色的 Raft 层、红色的 Storage 层，Storage 层内部又分为 treeIndex 层和 boltdb 底层持久化存储 key/value 层。它们的每一层都有可能造成 etcd 的性能损失。 首先来看 Raft 层，Raft 需要通过网络同步数据，网络

3 月，跳不动了？>>> 一、前言 本周本来要写MapReduce中的执行细节的，但是这两天看Raft资料的时候觉得Raft中的很多思想在Redis中都有对应的设计和应用，于是就先插队两篇关于Raft的文章。第一篇我们对比Raft和Redis中一致性协议的相同与不同， 第二篇我们主要看Raft在ETCD中的实现。同样，本文假定读者对Raft和Redis集群是了解的。如果不了解Redis集群的话，推荐看下我的这篇文章 大龙：Redis集群（终篇）——故障自动检测与自动恢复（附优质Redis资源汇总） ​ zhuanlan.zhihu.com 如果不了解Raft的话， 有如下资料可以去参考。 同时需要事先申明的是，下文中的Redis统一指的是Redis集群。 首先是Raft作者的博士论文： CONSENSUS: BRIDGING THEORY AND PRACTICE 然后是MIT的课程视频，老师讲的很好。 Raft Demo网站 ， 做的也很清晰，但的确少了很多细节。适合初学的时候看 《ETCD技术内幕》 这本书中的Raft介绍部分写的还比较清晰。 分布式系统的一致性和性能常常是鱼和熊掌不可兼得。追求高的一致性，必然会带来性能的损失，而想要追求高的性能，也只能妥协于一定程度的非一致性。以下图中的数据写入为例，不同的一致性级别要求写入的节点个数是不同的， 写入节点个数越多

一、介绍 Kubernetes 是当先炙手可热的技术,它已然成为可开源界的PASS管理平台的标准，当下文章对大多数是对X86平台搭建Kubernetes平台，下面笔者进行在LinuxONE上搭建开源的Kubernetes平台。 搭建K8S 平台主流的有两种方法， 第一种是基于二进制的搭建，通过一步一步的搭建可以加深对K8S各个服务的理解。 官方推荐的自动化部署工具 kubeadm 本次使用官方推荐的Kubeadm 的搭建方法， kubedm 把K8S 自身的服务都被K8S自身的pod，除此之外事先的基础服务是用system服务的方式运行。 master节点安装组件： docker、kubelet、kubeadm 基于本地的system服务运行 kube-proxy 是 动态的可被k8s 管理的pod api-server、kube-controller、etcd、 是托guan在pod node节点组件 docker、kubelet 基于本地的system服务运行 kube-proxy 是 动态的可被k8s 管理的pod flannel 是 动态的可被k8s 管理的pod 二、安装 1. 环境 系统版本 IP地址 主机名 ubuntu1~18.04.1 172.16.35.140 master ubuntu1~18.04.1 woker-1 2.安装docker 安装基础的包

export ETCDCTL_API=3 ENDPOINTS=localhost:2379 etcdctl --endpoints=${ENDPOINTS} role add root etcdctl --endpoints=${ENDPOINTS} role grant-permission root readwrite foo etcdctl --endpoints=${ENDPOINTS} role get root etcdctl --endpoints=${ENDPOINTS} user add root etcdctl --endpoints=${ENDPOINTS} user grant-role root root etcdctl --endpoints=${ENDPOINTS} user get root etcdctl --endpoints=${ENDPOINTS} auth enable # now all client requests go through auth etcdctl --endpoints=${ENDPOINTS} --user=root:123 put foo bar etcdctl --endpoints=${ENDPOINTS} get foo etcdctl --endpoints=${ENDPOINTS} --user=root

3 月，跳不动了？>>> 这篇文章将会介绍 etcd 的实现原理，其中包括 Raft 协议、存储两大模块，在最后我们也会简单介绍 etcd 一些具体应用场景。 etcd 的官方将它定位成一个可信赖的分布式键值存储服务，它能够为整个分布式集群存储一些关键数据，协助分布式集群的正常运转。 我们可以简单看一下 etcd 和 Zookeeper 在定义上有什么不同： etcd is a distributed reliable key-value store for the most critical data of a distributed system… ZooKeeper is a centralized service for maintaining configuration information, naming, providing distributed synchronization, and providing group services. 其中前者是一个用于存储关键数据的键值存储，后者是一个用于管理配置等信息的中心化服务。 etcd 的使用其实非常简单，它对外提供了 gRPC 接口，我们可以通过 Protobuf 和 gRPC 直接对 etcd 中存储的数据进行管理，也可以使用官方提供的 etcdctl 操作存储的数据。 service KV { rpc

3 月，跳不动了？>>> etcd raft介绍 etcd raft是目前使用最广泛的raft库，如果想深入了解raft请直接阅读论文 “In Search of an Understandable Consensus Algorithm”( https:// raft.github.io/raft.pdf ), etcd raft在etcd, Kubernetes, Docker Swarm, Cloud Foundry Diego, CockroachDB, TiDB, Project Calico, Flannel等分布式系统中都有应用，在生成环境得到了验证。 传统raft库的实现都是单体设计(集成了存储层、消息序列化、网络层等), etcd raft继承了简约的设计理念，只实现了最核心的raft算法, 这样更加的灵活。etcd将网络、日志存储、快照等功能分开，通过独立的模块实现，用户可以在需要时调用。etcd自身实现了自己的一套raft配套库:etcd-wal(用于存储日志)，snap(用于存储快照)，MemoryStorage(用于存储当前日志、快照、状态等信息以供raft核心程序使用)。 etcd wal介绍 WAL是write ahead log的缩写，etcd使用wal模块来完成raft日志的持久化存储，etcd对wal的所有实现都放在wal目录中。 wal数据结构

环境说明： # 工作系统： win 10 on linux # 操作系统：centos7 # docker版本：19.03.5 # rancher版本： latest # rke 版本： v1.0.4 # K8S master 节点IP：192.168.2.175，192.168.2.176，192.168.2.177 # K8S worker节点IP： 192.168.2.175，192.168.2.176，192.168.2.177，192.168.2.185，192.168.2.187 # K8S etcd 节点IP：192.168.2.175，192.168.2.176，192.168.2.177 # helm 版本：v3.0.2 部署准备： # 操作在所有节点进行 # 修改内核参数： 关闭swap vim /etc/sysctl.conf vm.swappiness=0 net.ipv4.ip_forward = 1 net.bridge.bridge-nf-call-ip6tables = 1 net.bridge.bridge-nf-call-iptables = 1 sysctl -p 临时生效 swapoff -a && sysctl -w vm.swappiness=0 # 修改 fstab 不在挂载 swap vi /etc/fstab # /dev