开放分布式系统追踪

分布式运维系统的挑战

开放和工程团队因为系统组件水平扩展、开放团队小型化、敏捷开放、CD（持续集成）、解耦等各种需求，正在使用现代的微服务架构替换老旧的单机系统。 也就是说，当一个生产系统面对真正的高并发，或者解耦成大量微服务时，以前很容易实现的重点任务变得困难了。过程中需要面临一系列问题：用户体验优化、后台真实错误原因分析，分布式系统内各组件的调用情况等。

Pod限额（LimitRange）

ResourceQuota对象是限制某个namespace下所有Pod(容器)的资源限额

LimitRange对象是限制某个namespace单个Pod(容器)的资源限额

LimitRange对象用来定义某个命名空间下某种资源对象的使用限额，其中资源对象包括：Pod、Container、PersistentVolumeClaim。

Knative 是什么

Knative 基于Kubernetes的平台，用来构建、部署和管理现代serverless工作负载。
该框架试图将开发云原生应用在三个领域的最佳实践结合起来，这三个领域指的是构建容器（和函数）、为工作负载提供服务（和动态扩展）以及事件。
Knative是由谷歌与Pivotal、IBM、Red Hat 和SAP紧密协作开发的。

etcd raft选举机制

etcd 是一个分布式的k/V存储系统。核心使用了RAFT分布式一致性协议。一致性这个概念，它是指多个服务器在状态达成一致，但是在一个分布式系统中，因为各种意外可能，有的服务器可能会崩溃或变得不可靠，它就不能和其他服务器达成一致状态。这样就需要一种Consensus协议，一致性协议是为了确保容错性，也就是即使系统中有一两个服务器当机，也不会影响其处理过程。

为了以容错方式达成一致，我们不可能要求所有服务器100%都达成一致状态，只要超过半数的大多数服务器达成一致就可以了，假设有N台服务器，N/2 +1 就超过半数，代表大多数了。

raft协议核心要点：

• Leader选举（Leader Election）
• 日志同步 （Log Replication）
  • leader收到client的更新请求后，会讲更新的内容同步给所有follower。
• 集群状态的正确性 （Safety）
  • 保证日志的一致性
• 保证选举的正确性

Federation 概述

Federation(集群联邦)是kubernetes社区中的多云管理项目，可以方便地跨地区跨服务商管理多个Kubernetes集群。其最初在1.3版本中被引入，后从主库迁移到独立repo(v1版本)，由于v1版本存在的若干问题，现已切换到v2版本。v1、v2版本虽然架构有较大差异，但共同目标都是使管理多个集群更为简单，主要实现了以下俩个模型：

跨集群的资源同步与伸缩(Sync and Scale resources across clusters)：提供在多个集群中保持资源同步与伸缩的功能，例如确保一个Deployment可以运行在多个集群中，并根据负载情况在集群间合理伸缩。
跨级群的服务发现(Cross cluster discovery)：提供自动配置DNS服务的功能，实现应用跨集群服务发现的能力，例如在某一集群中可以访问另一集群的应用。

节点配额和内核参数调整

对于公有云上的 Kubernetes 集群，规模大了之后很容器碰到配额问题，需要提前在云平台上增大配额。这些需要增大的配额包括

• 虚拟机个数
• vCPU 个数
• 内网 IP 地址个数
• 公网 IP 地址个数
• 安全组条数
• 路由表条数
• 持久化存储大小

参考gce随着node节点的增加master节点的配置：

• 1-5 nodes: n1-standard-1
• 6-10 nodes: n1-standard-2
• 11-100 nodes: n1-standard-4
• 101-250 nodes: n1-standard-8
• 251-500 nodes: n1-standard-16
• more than 500 nodes: n1-standard-32

将etcd从3.2升级到3.3

在一般情况下，从etcd 3.2升级到3.3可以是零停机，滚动升级：

• 一个接一个，停止etcd v3.2进程并用etcd v3.3进程替换它们（一个升级之后，等待集群状态正常之后再升级下一个）
• 运行所有v3.3进程后，群集可以使用v3.3中的新功能

什么是CSI

Container Storage Interface是面向容器编排系统的存储接口规范，定义了容器编排系统和各种存储之间如何交互。

CSI并不是kubernetes专有的技术或者规范，整个容器社区（包括Mesos、Docker、Kubernetes等）都在推进和定义该规范。理论上，一个遵从CSI规范的实现，能够运行在所有的容器编排系统上。

背景

Kubernetes服务简化了K8S集群的创建、升级和手动扩缩容。然而使用Kubernetes集群经常问到的一个问题是，我应该保持多大的节点规模来满足应用需求呢？ Autoscaler的出现解决了这个问题，它可以自动的根据部署的应用所请求的资源量来动态的伸缩集群

名词解释

cluster-autoscaler (简称CA)是用来弹性伸缩kubernetes集群的。我们在使用kubernetes集群经常问到的一个问题是，我应该保持多大的节点规模来满足应用需求呢？ cluster-autoscaler的出现解决了这个问题，它可以自动的根据部署的应用所请求的资源量来动态的伸缩集群。

Cluster AutoScaler源码梳理

功能总结:

1. 删除nodegroup中15分钟没有注册到kube的node
2. 获取未调度的Pod列表，计算需要资源（limit之内）
3. 获取comingnode（在nodegroup内，但是未注册kube集群，启动中）+node模版，计算（base，binpacking）的需要的node数
4. 根据expander(random,most-pods,price,least-waste)进行scaleup
5. 更新nodegroup的currentsize