本文目录一览：
- 1、etcd为python提供哪些api接口
- 2、笔记本etcd什么意思
- 3、如何在Kubernetes中部署一个高可用的PostgreSQL集群环境
- 4、kubernetes的master节点和node节点
- 5、api接口和python库的区别是什么？
etcd为python提供哪些api接口
python有个etcd的库，可以网上搜下看下这个库的使用以及它开发的api接口，
不过之前go使用etcd的时候，是调用etcd本身的rest api，没有使用第三方的etcd的库
etcd的api文档github上有的，搜下这个coreos/etcd
你可以选择自己喜欢的方式
笔记本etcd什么意思
键值存储仓库，用于配置共享和服务发现。
扩展知识：etcd（读作 et-see-dee）是一种开源的分布式统一键值存储，用于分布式系统或计算机集群的共享配置、服务发现和的调度协调。etcd 有助于促进更加安全的自动更新，协调向主机调度的工作，并帮助设置容器的覆盖网络。
etcd 是许多其他项目的核心组件。最值得注意的是，它是 Kubernetes 的首要数据存储，也是容器编排的实际标准系统。使用 etcd， 云原生应用可以保持更为一致的运行时间，而且在个别服务器发生故障时也能正常工作。应用从 etcd 读取数据并写入到其中；通过分散配置数据，为节点配置提供冗余和弹性。
如何在Kubernetes中部署一个高可用的PostgreSQL集群环境
虽然 kubernetes 社区一直在努力使得有状态应用成为一等公民，也推出了 statefulset 控制器支持 pod 的顺序部署，稳定的域名访问和存储访问。但鉴于 MySQL 部署运维的多样性和复杂性，在 kubernetes 上部署 MySQL 仍然要面临众多挑战。
1、业务流量入口的配置方式
传统虚拟机环境下，我们通过虚IP的方式，让业务应用都配置事先定义的一个虚IP为链接数据库的地址，然后由高可用服务保证虚IP始终能被路由到master数据库。在kubernetes中，出现了一层网络插件屏蔽了底层网络拓扑，高可用服务管理虚IP的方式需要随之适应调整，比如通过service结合标签完成虚IP的漂移，但service本身是kubernetes提供的一项功能，其可靠性和性能都取决于kubernetes服务的稳定。以性能来说，service是kubeproxy组件通过配置iptables实现的，当iptables规则较多时不可避免的会产生时延，需要我们针对性的解决。
2、容器隔离带来的监控视野问题
在 kubernetes 中，如果将 MySQL 制作为 container 运行在一个 pod 中，container 会将 MySQL 进程和运行环境隔离在一个单独的 namespace 中。监控组件在获取 MySQL 的一些 metirc 时，可能不得不进入与 MySQL 同一个 namespace 中，在部署和设计监控组件时需要考虑到这些限制。
3、存储在 kubernetes 中，支持配置各种不同的存储。
如果使用本地存储 local persistent volume，则需要绑定 MySQL 在一个固定的节点，这就完全浪费了 kubernetes 灵活调度的天然优势；而如果使用远程共享存储，确实是将 MySQL 进程与其存储完全解耦，使得 MySQL 进程可以在任意节点调度，然而考虑到高 I/O 吞吐量的情况，就不是那么美好了。设计时需要考量远程存储是否能够满足 MySQL 的带宽要求。
4、高可用/备份恢复
kubernetes 提供的 statefulset 控制器只能提供最基本的部署，删除功能，无法实现完善的 MySQL 集群高可用/备份恢复操作。对于有状态应用的部署，仍需要定制开发，所以多数公司提供了定制的 operator 来完成应用容器的管理。比如 etcd operator，MySQL operator，后文将为大家详述我测试使用 MySQL operator 的一些记录。
kubernetes的master节点和node节点
kubernetes集群中的master节点是集群的控制节点， 负责整个集群的管理和控制。执行的控制命令都是发送给master节点。 Master节点上运行的主要组件如下：
Node节点时kubernetes集群中的工作负责节点，Node上的工作负载由master分配， 当某个Node宕机时，Master会将上面的工作负载转移到其他节点上去， Node节点上运行的主要组件如下：
上图为kubernetes中所有组件一起工作时的示意图，由此我们可以得出以下几个通信流程，
根据上面节点通信的介绍我们会产生一个疑问， 这个看起来好复杂的样子。 臣妾看不懂呀。 如果想进一步了解集群中详细的工作流程请移驾 kubectl创建pod背后发生了什么 探索背后的秘密
要求结果为所有的 Kubernetes Master 服务器没有单点故障，任何一台服务器当机均不影响Kubernetes的正常工作。
为了实现没有单点故障的目标，需要为以下几个组件建立高可用方案：
etcd是Kubernetes当中唯一带状态的服务，也是高可用的难点。Kubernetes选用etcd作为它的后端数据存储仓库正是看重了其使用分布式架构，没有单点故障的特性。
虽然单节点的etcd也可以正常运行。但是推荐的部署方案均是采用3个或者5个节点组成etcd集群，供Kubernetes使用。
etcd的高可用基本有三种思路：
一是使用独立的etcd集群，使用3台或者5台服务器只运行etcd，独立维护和升级。甚至可以使用CoreOS的 update-engine 和 locksmith ，让服务器完全自主的完成升级。这个etcd集群将作为基石用于构建整个集群。 采用这项策略的主要动机是etcd集群的节点增减都需要显式的通知集群，保证etcd集群节点稳定可以更方便的用程序完成集群滚动升级，减轻维护负担。
二是在Kubernetes Master上用static pod的形式来运行etcd，并将多台Kubernetes Master上的etcd组成集群。 在这一模式下，各个服务器的etcd实例被注册进了Kubernetes当中，虽然无法直接使用 kubectl 来管理这部分实例，但是监控以及日志搜集组件均可正常工作。在这一模式运行下的etcd可管理性更强。
三是使用CoreOS提出的 self-hosted etcd方案 ，将本应在底层为Kubernetes提供服务的etcd运行在Kubernetes之上。 实现Kubernetes对自身依赖组件的管理。在这一模式下的etcd集群可以直接使用 etcd-operator 来自动化运维，最符合Kubernetes的使用习惯。
这三种思路均可以实现etcd高可用的目标，但是在选择过程中却要根据实际情况做出一些判断。简单来讲预算充足但保守的项目选方案一， 想一步到位并愿意承担一定风险的项目选方案三。折中一点选方案二。各个方案的优劣以及做选择过程中的取舍在这里就不详细展开了，对这块有疑问的朋友可以私下联系交流。
apiserver本身是一个无状态服务，要实现其高可用相对要容易一些，难点在于如何将运行在多台服务器上的apiserver用一个统一的外部入口暴露给所有Node节点。
说是难点，其实对于这种无状态服务的高可用，我们在设计业务系统的高可用方案时已经有了相当多的经验积累。需要注意的是apiserver所使用的SSL证书要包含外部入口的地址，不然Node节点无法正常访问apiserver。
apiserver的高可用也有三种基本思路：
一是使用外部负载均衡器，不管是使用公有云提供的负载均衡器服务或是在私有云中使用 LVS 或者 HaProxy 自建负载均衡器都可以归到这一类。 负载均衡器是非常成熟的方案，在这里略过不做过多介绍。如何保证负载均衡器的高可用，则是选择这一方案需要考虑的新问题。
二是在网络层做负载均衡。比如在Master节点上用 BGP 做 ECMP ，或者在Node节点上用 iptables 做NAT都可以实现。采用这一方案不需要额外的外部服务，但是对网络配置有一定的要求。
三是在Node节点上使用反向代理对多个Master做负载均衡。这一方案同样不需要依赖外部的组件，但是当Master节点有增减时，如何动态配置Node节点上的负载均衡器成为了另外一个需要解决的问题。
从目前各个集群管理工具的选择来看，这三种模式都有被使用，目前还没有明确的推荐方案产生。建议在公有云上的集群多考虑第一种模式，在私有云环境中由于维护额外的负载均衡器也是一项负担，建议考虑第二种或是第三种方案。
这两项服务是Master节点的一部分，他们的高可用相对容易，仅需要运行多份实例即可。这些实例会通过向apiserver中的 Endpoint 加锁的方式来进行leader election， 当目前拿到leader的实例无法正常工作时，别的实例会拿到锁，变为新的leader。
严格来说kube-dns并不算是Master组件的一部分，因为它是可以跑在Node节点上，并用 Service 向集群内部提供服务的。但在实际环境中， 由于默认配置只运行了一份kube-dns实例，在其升级或是所在节点当机时，会出现集群内部dns服务不可用的情况，严重时会影响到线上服务的正常运行。
为了避免故障，请将kube-dns的 replicas 值设为2或者更多，并用 anti-affinity 将他们部署在不同的Node节点上。这项操作比较容易被疏忽，直到出现故障时才发现原来是kube-dns只运行了一份实例导致的故障。
上面介绍了Kubernetes Master各个组件高可用可以采用的策略。其中etcd和kube-apiserver的高可用是整个方案的重点。由于存在多种高可用方案，集群管理员应当根据集群所处环境以及其他限制条件选择适合的方案。
这种没有绝对的通用方案，需要集群建设者根据不同的现状在多个方案中做选择的情况在Kubernetes集群建设过程中频频出现， 也是整个建设过程中最有挑战的一部分。容器网络方案的选型作为Kubernetes建设过程中需要面对的另外一个大问题也属于这种情况，今后有机会再来分享这个话题。
在实际建设过程中，在完成了上述四个组件的高可用之后，最好采取实际关机检验的方式来验证高可用方案的可靠性，并根据检验的结果不断调整和优化整个方案。
此外将高可用方案与系统自动化升级方案结合在一起考虑，实现高可用下的系统自动升级，将大大减轻集群的日常运维负担，值得投入精力去研究。
虽然本篇主要在讲Kubernetes Master高可用的方案，但需要指出的是，高可用也并不是必须的，为了实现高可用所付出的代价并不低， 需要有相应的收益来平衡。对于大量的小规模集群来说，业务系统并没有实现高可用，贸然去做集群的高可用收益有限。这时采用单Master节点的方案，做好etcd的数据备份，不失为理性的选择。
api接口和python库的区别是什么？
API
接口属于一种操作系统或程序接口，而后两者都属于直接用户接口。
有时公司会将
API
作为其公共开放系统。也就是说，公司制定自己的系统接口标准，当需要执行系统整合、自定义和程序应用等操作时，公司所有成员都可以通过该接口标准调用源代码，该接口标准被称之为开放式
API。
