Kubernetes

etcd 原理解析：读《etcd 技术内幕》这篇文章主要是原理性的内容，本文主要是实践角度，谈谈平时用到的一些操作和监控 高可用 etcd 是基于 raft算法的分布式键值数据库，生来就为集群化而设计的，由于Raft算法在做决策时需要超半数节点的投票，所以etcd集群一般推荐奇数节点，如3、5或者7个节点构成一个集群。 以上是etcd集群部署的基础概念，但是还需要注意以下问题： 选主过程 etcd 是高可用的，允许部分机器故障，以标准的3 节点etcd 集群，最大容忍1台机器宕机，下面以最简单的leader宕机来演示raft 的投票逻辑，以实际的运行日志来验证并理解。更多的场景可以看之前的原理解析 场景：正常运行的三台etcd：100、101、102。当前任期为 7，leader 为 101机器。现在使101 宕机 宕机前：101 为 leader，3 个 member 宕机后：102 成为新 leader，2 个 member 过程： 将 101 机器的 etcd 停止，此时只剩 2 台，但总数为 3 101停止etcd 的运行 102(91d63231b87fadda) 收到消息，发现101(8a4bb0af2f19bd46)心跳超时，于是发起了新一轮选举，任期为 7+1=8 91 d63231b87fadda [term 7 ] received MsgTimeoutNow

2018年12月 etcd 作为孵化项目 CNCF（云原生计算基金会），几天前 CNCF 宣布 etcd 正式毕业，成为 CNCF 顶级项目。CNCF 官方表示 etcd 项目的采用率持续增加，也有稳定的治理流程，功能已达一定成熟度。 etcd 已经被许多公司用于实际生产，其中包括亚马逊、百度、思科、EMC、谷歌、阿里、华为、IBM、Red Hat、Uber、Verizon 等；而且其身影也出现在包括 Kubernetes、CoreDNS、M3、Rook 以及 TiKV 等项目当中。 前面的系列 etcd 文章已经部分介绍了 etcd。本文将会做一个快速入门的介绍，带领大家十分钟快速入门云原生存储组件 etcd，主要内容如下（本文较长，建议收藏）： etcd 简介，以及其应用场景 etcd 的多种安装模式及高可用运维 etcd v3 的架构解析 etcdctl 的实践应用 1 etcd 介绍 2013 年 6 月，CoreOS 发起了 etcd 项目。etcd 使用 Go 语言实现，是分布式系统中重要的基础组件，目前最新版本为 V3.4.9。etcd 可以用来构建高可用的分布式键值数据库，根据官网介绍，总结来说有如下的特点： 简单：etcd 的安装简单，且为用户提供了 HTTP API，用户使用起来也很简单 存储：etcd 的基本功能，数据分层存储在文件目录中

导读： 美国时间 2019 年 6 月 19 日，Kubernetes发布了今年第二大版本 Kubernetes 1.15 ，此次版本共更新加强了 25 个相关功能，其中 2 个升级到 GA 版本， 13 个升级到 beta 版， 10 个 alpha 版。 1.15 版本的发布主题是：持续改进和可扩展性。 持续改进： 项目可持续性不仅仅与功能有关。许多SIG一直致力于提高测试覆盖率，确保基础功能持续可靠，核心功能持续稳定。 可扩展性： Kubernetes 社区一直致力于支持可扩展性。 1.15 版本发布周期中包含更多关于CRD和 API Machinery 的工作。此次周期中的大多数增强功能来自SIG API Machinery及相关领域。 更深入了解此次版本主要功能： 围绕核心 Kubernetes API的可扩展性 在 CRD 新开发的主题是围绕者数据一致性和原生性。用户考虑重点不会放在是CustomResource还是使用 Golang 原生资源。在下个版本或后续版本中，将会升级 CRD 和 admissio webhooks 到 GA 版本。 在这个方向上，社区重新考虑了CRD中基于 OpenAPI 的验证模式，并且从 1.15 开始，我们根据称为“ structural schema ”的限制检查每个资源

作者 | tengshe789 来 源 | https://juejin.im/post/5c0ba2bef265da614d08fefe 微服务的概念最早在 2012 年提出，在 Martin Fowler 的大力推广下，微服务在 2014 年后得到了大力发展。 今天我们通过一组手绘图来梳理下微服务的核心架构。 什么是微服务？ 微服务 Microservices 之父，马丁.福勒，对微服务大概的概述如下： 就目前而言，对于微服务业界并没有一个统一的、标准的定义（While there is no precise definition of this architectural style ) 。 但通常在其而言，微服务架构是一种架构模式或者说是一种架构风格，它提倡将单一应用程序划分成一组小的服务，每个服务运行独立的自己的进程中，服务之间互相协调、互相配合，为用户提供最终价值。 服务之间采用轻量级的通信机制互相沟通（通常是基于 HTTP 的 RESTful API ) 。 每个服务都围绕着具体业务进行构建，并且能够被独立地部署到生产环境、类生产环境等。 另外，应尽量避免统一的、集中式的服务管理机制，对具体的一个服务而言，应根据业务上下文，选择合适的语言、工具对其进行构建，可以有一个非常轻量级的集中式管理来协调这些服务。 可以使用不同的语言来编写服务，也可以使用不同的数据存储。

作者：tengshe789 juejin.im/post/5c0ba2bef265da614d08fefe 微服务的概念最早在 2012 年提出，在 Martin Fowler 的大力推广下，微服务在 2014 年后得到了大力发展。 今天我们通过一组手绘图来梳理下微服务的核心架构。 什么是微服务？ 微服务 Microservices 之父，马丁.福勒，对微服务大概的概述如下： 就目前而言，对于微服务业界并没有一个统一的、标准的定义（While there is no precise definition of this architectural style ) 。 但通常在其而言，微服务架构是一种架构模式或者说是一种架构风格，它提倡将单一应用程序划分成一组小的服务，每个服务运行独立的自己的进程中，服务之间互相协调、互相配合，为用户提供最终价值。 服务之间采用轻量级的通信机制互相沟通（通常是基于 HTTP 的 RESTful API ) 。 每个服务都围绕着具体业务进行构建，并且能够被独立地部署到生产环境、类生产环境等。 另外，应尽量避免统一的、集中式的服务管理机制，对具体的一个服务而言，应根据业务上下文，选择合适的语言、工具对其进行构建，可以有一个非常轻量级的集中式管理来协调这些服务。 可以使用不同的语言来编写服务，也可以使用不同的数据存储。 根据马丁.福勒的描述