3-GCP 公司bestPractice
General
Capacity
Beacon with GKE
- instances: 3 node in GKE
- os: 1.25.8-gke.500
- CPU: 8vCPUs(base) + 1vCPU(per ledger)
- RAM: 16GB RAM
- Storage: 10GBs + 500GB(per ledger)
Scalability
- Load balance: Ingress via proxy and NGINX Ingress Controller, load balancing using Kubernetes Service
- Kubernetes hpa.yaml(HorizontalPodAutoscaler) and pdb.yaml(PodDisruptionBudget)
Availability & Recovery
- Resilience approach: 3 control nodes in different data centres. 3 DNS entries pointing to the LB IP.
- Continuity & DR:
- Backup & Recovery:
Operations
- Monitoring & Alerting: Prometheus, alertmanager, grafana
- Operational Automation: Github release tag created for each new version, this prompts ‘Lighthouse’ which watches for changes in Github and triggers Tekton to run pipelines
- Audit & Logging: Google Cloud Logs and Google Cloud Audit Logs
Kubernetes Auto scaling options
Kubernetes中共有三种不同的弹性伸缩策略：HPA（HorizontalPodAutoscaling）、 VPA（VerticalPodAutoscaling）与 CA（ClusterAutoscaler）。其中，HPA 和 VPA 的扩缩容对象是 Pod ，而 CA 的扩缩容对象是 Node 。
- HPA：调度层弹性组件，Kubernetes 内置，Pod 水平伸缩组件，主要面向在线业务。
- VPA：调度层弹性组件，Kubernetes 社区开源，Pod 垂直伸缩组件，主要面向大型单体应用。适用于无法水平扩展的应用，通常是在 Pod 出现异常恢复时生效。
- CA：资源层弹性组件，Kubernetes 社区开源，Node 水平伸缩组件。全场景适用。
HPA 水平伸缩
HPA（Horizontal Pod Autoscaler）是 Kubernetes 的内置组件，也是最常用的 Pod 弹性方案。通过 HPA 可以自动调整 Workload 的副本数。HPA 自动伸缩特性使 Kubernetes 具有非常灵活的自适应能力，能够在用户设定内快速扩容多个 Pod 副本来应对业务负载的急剧飙升，也可以在业务负载变小的情况下根据实际情况适当缩容来节省计算资源给其他的服务，整个过程自动化无需人为干预，适合服务波动较大、服务数量多且需要频繁扩缩容的业务场景。
HPA 适用于 Deployment、StatefulSet 等实现scale接口的对象，不适用于无法扩缩的对象，例如DaemonSet资源。Kubernetes内置有 HorizontalPodAutoscaler 资源，通常是对需要配置水平自动伸缩的 Workload 创建一个HorizontalPodAutoscaler资源，Workload与HorizontalPodAutoscaler相对应 。
VPA 垂直伸缩
VPA（VerticalPodAutoscaling） 是社区开源组件，需要在 Kubernetes 集群上手动部署安装，VPA 提供垂直的 Pod 伸缩的功能。
VPA 会基于 Pod 的资源使用情况自动为 Pod 设置资源占用的限制，从而让集群将 Pod 调度到有足够资源的最佳节点上。VPA 也会保持最初容器定义中资源 request 和 limit 的占比。此外，VPA 可用于向用户推荐更合理的 Request，在保证容器有足够使用的资源的情况下，提升容器的资源利用率。
- 相较于 HPA，VPA 具有以下优势
VPA 可为有状态应用实现扩容，HPA 则不适合有状态应用的水平扩容。有些应用 Request 设置过大，缩容至一个 Pod 时资源利用率仍然很低，此时可以通过 VPA 进行垂直缩容以提高资源利用率。
PDB podDisruptionBudget 限制集群缩容时的服务干扰
一些服务要求至少保持一定数量的pod持续运行，对基于quorum的集群应用而言尤其如此。为此，Kubernetes可以指定下线等操作时需要保持的最少pod数量，通过创建一个podDisruptionBudget资源的方式来利用这一特性。
只要它存在，Cluster Autoscaler与kubectl drain命令都会遵守它；如果疏散一个带有app=kubia标签的pod会导致它们的总数小于3,那这个操作就永远不会被执行。
比方说，如果总共有4个pod,minAvailable像例子中一样被设为3，pod疏散过程就会挨个进行，待ReplicaSet控制器把被疏散的pod换成新的，才继续下一个。
分布式Quorum机制
基于Quorum投票的冗余控制算法
Quorom 机制，是一种分布式系统中常用的，用来保证数据冗余和最终一致性的投票算法，其主要数学思想来源于鸽巢原理。
10只鸽子放进9个鸽笼，那么一定有一个鸽笼放进了至少两只鸽子。
在有冗余数据的分布式存储系统当中，冗余数据对象会在不同的机器之间存放多份拷贝。但是同一时刻一个数据对象的多份拷贝只能用于读或者用于写。
该算法可以保证同一份数据对象的多份拷贝不会被超过两个访问对象读写。
算法来源于[Gifford, 1979][3][1]。 分布式系统中的每一份数据拷贝对象都被赋予一票。每一个操作必须要获得最小的读票数（Vr）或者最小的写票数(Vw）才能读或者写。如果一个系统有V票（意味着一个数据对象有V份冗余拷贝），那么这最小读写票必须满足：
Vr + Vw > V
Vw > V/2
第一条规则保证了一个数据不会被同时读写。当一个写操作请求过来的时候，它必须要获得Vw个冗余拷贝的许可。而剩下的数量是V-Vw 不够Vr，因此不能再有读请求过来了。同理，当读请求已经获得了Vr个冗余拷贝的许可时，写请求就无法获得许可了。
第二条规则保证了数据的串行化修改。一份数据的冗余拷贝不可能同时被两个写请求修改。
算法特点
在分布式系统中，冗余数据是保证可靠性的手段，因此冗余数据的一致性维护就非常重要。一般而言，一个写操作必须要对所有的冗余数据都更新完成了，才能称为成功结束。比如一份数据在5台设备上有冗余，因为不知道读数据会落在哪一台设备上，那么一次写操作，必须5台设备都更新完成，写操作才能返回。
对于写操作比较频繁的系统，这个操作的瓶颈非常大。Quorum算法可以让写操作只要写完3台就返回。剩下的由系统内部缓慢同步完成。而读操作，则需要也至少读3台，才能保证至少可以读到一个最新的数据。
Quorum的读写最小票数可以用来做为系统在读、写性能方面的一个可调节参数。写票数Vw越大，则读票数Vr越小，这时候系统读的开销就大。反之则写的开销就小。