etcd

3.Kubernetes 集群 Kubernetes 用于协调高度可用的计算机集群，这些计算机群集被连接作为单个单元工作。 Kubernetes 在一个集群 上以更有效的方式自动分发和调度容器应用程序。 Kubernetes集群由两种类型的资源组成： Master是集群的调度节点 Nodes是应用程序实际运行的工作节点 接下来为大家讲解一下如何快速部署一套Kubernetes集群，K8S集群部署有几种方式：kubeadm 、 minikube和二 进制包。前两者属于自动部署，简化部署操作，我们这里强烈推荐初学者使用二进制包部署，因为自动部署屏蔽了 很多细节，使得对各个模块感知很少，非常不利用学习。 3.1 环境准备与规划 推荐配置2核2G Docker version 17.05.0-ce 查看默认防火墙状态(关闭后显示not running ,开启后显示 running) firewall-cmd --state 关闭防火墙 systemctl stop firewalld.service 禁止firewall开机启动 systemctl disable firewalld.service 获取Kubernetes二进制包 https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG-1.9.md 页面表格中找到Server

原文地址： Role-based access control 总览 身份验证已添加到etcd 2.1中。 etcd v3 API略微修改了身份验证功能的API和用户界面，以更好地适应新的数据模型。本指南旨在帮助用户在etcd v3中设置基本身份验证和基于角色的访问控制。 特殊用户和角色 有一个特殊用户 root ，一个特殊角色 root 。 用户 root 在激活身份验证之前，必须创建对 etcd 具有完全访问权限的 root 用户。 root 用户的想法是出于管理目的：管理角色和普通用户。 root 用户必须具有 root 角色，并且可以在 etcd 中进行任何更改。 角色 root 可以将角色 root 授予除 root 用户之外的任何用户。 具有 root 角色的用户既具有全局读写访问权限，又具有更新集群的身份验证配置的权限。 此外， root 角色授予常规集群维护的特权，包括修改集群成员资格，对存储进行碎片整理以及拍摄快照。 用户的工作方式 etcdctl 的 user 子命令处理与用户帐户有关的所有事情。 可以通过以下方式找到用户列表： $ etcdctl user list 通过以下方式创建新用户： $ etcdctl user add myusername 创建新用户将提示您输入新密码。 当给出选项 --interactive=false 时

原文地址： TLS etcd支持用于客户端到服务器以及对等方（服务器到服务器/集群）通信的自动TLS以及通过客户端证书的身份验证. 要启动并运行，首先要获得一个成员的CA证书和签名密钥对。 建议为集群中的每个成员创建并签名一个新的密钥对。 为了方便起见， cfssl 工具提供了一个简单的接口来生成证书，我们在 此处 提供了使用该工具的示例。 或者，尝试使用本指南 生成自签名密钥对 。 基本设置 etcd通过命令行参数或环境变量采用了几种与证书相关的配置选项： 客户端到服务器的通信： --cert-file=<path> :用于SSL/TLS 与 etcd的连接的证书。设置此选项后，advertise-client-urls可以使用HTTPS模式。 --key-file=<path> :证书的密钥。 必须未加密。 --client-cert-auth :设置此选项后，etcd将检查所有传入的HTTPS请求以查找由受信任CA签名的客户端证书，不提供有效客户端证书的请求将失败。 如果启用了身份验证，则证书将为“公用名”字段指定的用户名提供凭据。 --trusted-ca-file=<path> :受信任的证书颁发机构。 --auto-tls :使用自动生成的自签名证书进行与客户端的TLS连接。 对等节点(服务器到服务器/集群)间的通信： 对等节点选项的工作方式与客户端到服务器的选项相同：

一、Kubernetes简介      Kubernetes是Google于2014年开源的一个容器编排工具，使用Google自己的go语言编写，由Borg衍生而来。Borg是Google内部已经运行近十年的容器编排工具，由于docker的横空出世，导致Google原本准备作为秘密武器的容器技术胎死腹中。计划被打乱，容器层面已经痛失良机，慢人一步，只有在编排工具层面下手了，Google当机立断，基于Brog的逻辑编写了Kubernetes，开源并捐给了CNCF（云远程计算基金会），由于Google近十年的使用经验，所以Kubernetes一出世就横扫了其它编排工具，时至今日，地位依然稳固。   Kubernetes源于希腊语，有“舵”或“飞行员”的意思。k8s，是由Kubernetes中间的八个字母缩写为数字8得来的。Google采用这个名字的深意就是：既然你docker把自己定位成驮着集装箱在大海上遨游的鲸鱼，那么我就以Kubernetes掌舵大航海时代的话语权，鲸鱼必须按照我设定的路线巡游。   Kubernetes的一大亮点就是自动化，在Kubernetes的解决方案中，一个服务可以自我扩展、自我诊断，并且容易升级，在收到服务扩容的请求后，Kubernetes会触发调度流程，最终在选定的目标节点上启动相应数量的服务实例副本，这些实例在启动成功后会自动加入负载均衡器中并生效

原文地址: HTTP JSON API through the gRPC gateway etcd v3 使用 gRPC 作为消息协议。etcd项目包括一个基于gRPC的 Go客户端 和一个命令行工具， etcdctl ,通过gRPC与etcd集群进行交互.对于没有gRPC支持的语言，etcd提供JSON gRPC网关 ，这个网关提供一个RESTful风格的代理可以将HTTP/JSON请求转换为gRPC消息。 使用 gRPC网关 这个网关接受一个到etcd's buffer协议消息定义的JSON格式的映射,注意 Key 和 Value 字段定义为byte 数组，因此JSON必须使用base64编码,下面的例子使用 curl ,但是每个HTTP/JSON客户端的工作原理都和例子相同。 注意 gRPC网关节点从etcd v3.3发生变化： etcd v3.2以及之前版本只使用 [CLIENT-URL]/v3alpha/* 。 etcd v3.3使用 [CLIENT-URL]/v3beta/* 保持 [CLIENT-URL]/v3alpha/* 使用。 etcd v3.4使用 [CLIENT-URL]/v3/* 保持 [CLIENT-URL]/v3beta/* 使用。 [CLIENT-URL]/v3alpha/* 被抛弃使用。 etcd v3.5以及最新版本只使用 [CLIENT-URL

原文地址: the runtime configuration design 运行时重新配置是分布式系统中最难，最容易出错的部分，尤其是在基于共识(像etcd)的系统中。 阅读并学习关于etcd的运行时重新配置命令设计和如何追溯这些错误. 两阶段配置更新保证集群安全 在etcd中，每一次运行时重新配置安全的原因是由于两阶段更新。例如，添加一个成员，首先将新配置通知集群后启动新的成员。 阶段一 通知集群关于新的配置 添加一个成员到etcd集群中，通过API调用请求将一个新成员添加到集群中。这是将新的成员添加到集群中唯一的方法。当集群同意配置的更新后将返回API的调用。 阶段二 启动一个新的成员 将一个新成员加入到存在的集群中，指定正确的 initial-cluster 和设置 initial-cluster-state 为 existing .当成员启动后，它首先联系已存在的集群并验证当前集群配置是否和期望的 initial-cluster 匹配。当一个新的成员成功启动，集群将获得期望的配置。 用户将过程分为两个阶段需要清楚了解集群成员关系的变化。实际上，这为用户提供了更大的灵活性，并使事情更容易。例如，如果试图添加一个与集群中现有的成员Id相同的新成员到集群中，操作将会立即失败由于阶段一并没有影响到运行中的集群。提供了类似的保护阻止通过错误操作添加新的成员

原文地址: gRPC proxy gRPC代理是在gRPC层（L7）运行的无状态etcd反向代理。代理旨在减少核心etcd群集上的总处理负载。对于水平可伸缩性，它合并了监视和租约API请求。 为了保护集群免受滥用客户端的侵害，它会缓存关键范围请求。 gRPC代理支持多个etcd服务器端点。 代理启动时，它会随机选择一个etcd服务器端点来使用.该端点将处理所有请求，直到代理检测到端点故障为止。 如果gRPC代理检测到端点故障，它将切换到其他端点（如果有）以向其客户端隐藏故障。 将来可能会支持其他重试策略，例如加权轮询。 可扩展的监视 API gRPC代理将同一键或范围上的多个客户端监视程序（c-watcher）合并为连接到etcd服务器的单个监视程序（s-watcher）。 代理将所有事件从S-watcher广播到其c-watcher。 假设N个客户端监视相同的密钥，则一个gRPC代理可以将etcd服务器上的监视负载从N减少到1。用户可以部署多个gRPC代理来进一步分配服务器负载。 在以下示例中，三个客户端监视键A。gRPC代理将三个监视程序合并，从而创建一个附加到etcd服务器的监视程序。 +-------------+ | etcd 服务器 | +------+------+ ^ 监视 key A (s-watcher) | +-------+-----+ | gRPC 代理

原文地址: Experimental features and APIs 大多数情况下，etcd项目是稳定的，但我们仍在快速发展！ 我们相信快速发布理念。 我们希望获得有关仍在开发和稳定中的功能的早期反馈。 因此，存在并且将会有更多的实验性功能和API。 我们计划根据社区的早期反馈来改进这些功能，如果兴趣不足，请在接下来的几个版本中放弃这些功能。 请不要在生产环境中依赖任何实验性功能或API。 当前实验API/特性是： 键值对排序 包装器： 当etcd客户端切换端点时，如果新端点落后于集群的其余部分，则对可序列化读取的响应可能推迟。排序包装器从响应标头缓存当前集群修订版。 如果响应修订版本小于缓存修订版本，则客户端选择另一个端点并重新发出读取。在grpcproxy中启动 --experimental-serializable-ordering . 来源： https://www.cnblogs.com/cbkj-xd/p/11934602.html

原文地址： Configuration flags etcd通过配置文件，多命令行参数和环境变量进行配置， 可重用的配置文件是YAML文件，其名称和值由一个或多个下面描述的命令行标志组成。为了使用此文件，请将文件路径指定为 --config-file 标志或 ETCD_CONFIG_FILE 环境变量的值。如果需要的话 配置文件示例 可以作为入口点创建新的配置文件。 在命令行上设置的选项优先于环境中的选项。 如果提供了配置文件，则其他命令行标志和环境变量将被忽略。例如， etcd --config-file etcd.conf.yml.sample --data-dir /tmp 将会忽略 --data-dir 参数。 参数 --my-flag 的环境变量的格式为 ETCD_MY_FLAG .它适用于所有参数。 客户端请求 官方的etcd端口 为2379,2380是节点通信端口。可以将etcd端口设置为接受TLS流量，非TLS流量，或同时接受TLS和非TLS流量。 要在Linux启动时使用自定义设置自动启动etcd，强烈建议使用 systemd 单元。 成员标记 --name 人类可读的该成员的名字 默认值："default" 环境变量：ETCD_DATA_DIR 该值被该节点吃的 --initial-cluster 参数引用(例如 default=http://localhost

原文地址: System limits 请求大小限制 etcd被设计用来处理小键值对典型的如元数据。较大的请求数据也起作用，但可能会增加其他请求的延迟。默认情况下，任意的请求最大的空间为1.5MiB，这个限制参数可以通过 --max-request-bytes 参数对etcd服务器进行配置。 存储大小限制 默认的存储大小限制为2GB,可以通过参数 --quota-backend-bytes 进行配置。正常环境下8GB是etcd支持的最大存储大小，如果配置的值超过它，etcd将在启动时发出警告。 来源： https://www.cnblogs.com/cbkj-xd/p/11934596.html