etcd

上一章：二进制部署K8s集群第10节Master节点之部署四层反向代理 架构图 目录 1、架构 2、创建生成kubelet服务端证书csr的json配置文件 3、生成拷贝kubelet证书文件 4、下载pause镜像打tab 5、创建kubeconfig配置 6、拷贝配置 7、创建资源配置文件 8、应用查看资源配置 9、创建kubelet启动脚本 10、创建supervisor配置 11、启动检查打标签 1、架构 2、创建生成kubelet服务端证书csr的json配置文件 在hdss7-200.host.com上操作 cd /opt/certs/ cat > kubelet-csr.json <<eof { "CN": "k8s-kubelet", "hosts": [ "127.0.0.1", "10.4.7.10", "10.4.7.21", "10.4.7.22", "10.4.7.23", "10.4.7.24", "10.4.7.25", "10.4.7.26", "10.4.7.27", "10.4.7.28" ], "key": { "algo": "rsa", "size": 2048 }, "names": [ { "C": "CN", "ST": "beijing", "L": "beijing", "O": "od", "OU": "ops" } ] }

最近一直在忙618大促的全链路压测&稳定性保障相关工作，结果618还未开始，生产环境就出了几次生产故障，且大多都是和系统稳定性、性能相关的bad case。 生产全链路压测终于告一段落，抽出时间将个人收集的稳定性相关资料整理review了一遍，顺带从不同的维度，谈谈稳定性相关的“务虚”认知和思考。。。 一、SLA! 在开始谈稳定性保障之前，我们先来聊聊业内经常提及的一个Topic： SLA！ 业内喜欢用SLA （服务等级协议，全称：service level agreement）来衡量系统的稳定性，对互联网公司来说就是网站服务可用性的一个保证。 9越多代表全年服务可用时间越长服务越可靠，停机时间越短。就以一个标准99.99%为例，停机时间52.6分钟，平均到每周也就是只能有差不多1分钟的停机时间， 也就是说网络抖动这个时间可能就没了。保证一个系统四个9或者更高的五个9，需要一套全体共识严格标准的规章制度，没有规矩不成方圆。创建的规范有如下几种： 1、研发规范、自身稳定； 2、事务中不能包含远程调用； 3、超时时间和重试次数要合理； 4、表数据操作必须double check，合理利用索引，避免出现慢查询、分库分表不走分表键； 5、没有有效的资源隔离， 避免不同业务共用一个线程池或连接池； 6、合理的系统拓扑，禁止不合理的服务依赖，能去依赖就去依赖，否则同步依赖尽量改成异步弱依赖；

系列文章说明 本系列文章,可以基本算是 老男孩2019年王硕的K8S周末班课程 笔记,根据视频来看本笔记最好,否则有些地方会看不明白 需要视频可以联系我 k8s概念入门 目录 系列文章说明 k8s概念入门 1 四组基本概念 1.1 POD和POD控制器 1.2 Name/Namespace 1.3 Lable/Label选择器 1.4 Service/Ingress 2 核心组件与核心附件 2.1 核心组件功能 2.2 K8S的三条网络 3 K8S流程图 [K8S中文社区]( http://docs.kubernetes.org.cn/ 1 四组基本概念 Pod/Pod控制器 Name/Namespace Lable/Label选择器 Service/Ingress 1.1 POD和POD控制器 kubernetes 的pod控制器 Pod k8s里能够被运行的 最小逻辑单元 1个POD里面可以运行多个容器(SideCar 边车模式) POD中的容器共享 UTS/NAT/IPC 名称空间 POD和容器颗粒理解为豌豆荚和豌豆 Pod控制器 Pod控制器是Pod启动的一种模板 用来保证在K8S里启动的Pod始终按预期运行 包括副本数\生命周期\健康检查等 常用的Pod控制器: 控 度器名称 用途简述 Deployment 用于管理无状态应用,支持滚动更新和回滚 DaemonSet

作者：李毓 k8s的adm安装方式有一个巨坑，就是证书过期问题。其中涉及到的证书有apiserver,kubelet,etcd,proxy等等证书。这个问题在二进制安装方式是不存在的，因为可以手动更改证书。但是由于adm是自动安装，所以需要后期处理。 目前的解决方式一般有三种，第一种是集群升级，通过升级k8s，间接的把证书也升级了。第二种是修改源代码，也就是对kubeadm重新编译。第三种就是重新生成证书。 由于k8s1.18.8版本刚刚更新了。所以我想趁着这次机会演绎一下集群升级和证书更新的一石二鸟操作。 约定： 三台机器，一台master，二台server。版本是1.18.6 [root@adm-master ~]# kubectl get nodes NAME STATUS ROLES AGE VERSION adm-master Ready master 37d v1.18.6 adm-node1 Ready <none> 37d v1.18.6 adm-node2 Ready <none> 37d v1.18.6 查看一下证书的有效期 [root@adm-master ~]# openssl x509 -in /etc/kubernetes/pki/apiserver.crt -noout -text |grep ' Not ' Not Before: Aug 1 13

etcd的下载地址： https://github.com/etcd-io/etcd/releases 当前最新的v3.4.9，我之前用的时候包括目前京东热key线上都是用的3.4.6，下面主要是看一下如何搭建etcd集群。 如果是本地测试单点的话，就在上面链接下载对应的操作系统版本，打开后 直接启动etcd就算本地启动成功了，启动后就可以用etcdctl控制台进行操作，或者用代码操作etcd即可。 集群的话，以linux 3节点集群为例。 创建一个sh脚本，如下 #!/bin/bash if [ -z $NAME ];then NAME=my-etcd-1 fi #if [ -z $DATADIR ];then #DATADIR=/export/etcd_data #fi if [ -z $MYHOST ];then MYHOST=http://127.0.0.1 fi if [ -z $PORT ];then PORT=2379 fi if [ -z $CLUSTER_PORT ];then CLUSTER_PORT=2380 fi if [ -z $CLUSTER ];then CLUSTER=my-etcd-1=http://localhost:2380,my-etcd-2=http://localhost:2382,my-etcd-3=http://localhost

Flannel是 CoreOS 团队针对 Kubernetes 设计的一个覆盖网络（Overlay Network）工具，其目的在于帮助每一个使用 Kuberentes 的 CoreOS 主机拥有一个完整的子网。 简介 Flannel是一种基于overlay网络的跨主机容器网络解决方案，也就是将TCP数据包封装在另一种网络包里面进行路由转发和通信，Flannel是CoreOS开发,专门用于docker多机互联的一个工具,让集群中的不同节点主机创建的容器都具有全集群唯一的虚拟ip地址，Flannel使用go语言编写。 Flannel实现原理 原理说明 Flannel为每个host分配一个subnet，容器从这个subnet中分配IP，这些IP可以在host间路由，容器间无需使用nat和端口映射即可实现跨主机通信 每个subnet都是从一个更大的IP池中划分的，flannel会在每个主机上运行一个叫flanneld的agent，其职责就是从池子中分配subnet Flannel使用etcd存放网络配置、已分配 的subnet、host的IP等信息 Flannel数据包在主机间转发是由backend实现的，目前已经支持UDP、VxLAN、host-gw、AWS VPC和GCE路由等多种backend 数据转发流程 容器直接使用目标容器的ip访问，默认通过容器内部的eth0发送出去。

作者：李志鹏， Github账号：Lzp0412,开源社区爱好者，Nacos Committer，Nacos-SDK-go作者，现就职于阿里云云原生应用平台，主要参与服务发现、CoreDNS、ServiceMesh相关工作，负责推动Nacos Go微服务生态建设。 近几年，随着Go语言社区逐渐发展和壮大，越来越多的公司开始尝试采用Go搭建微服务体系，也涌现了一批Go的微服务框架，如go-micro、go-kit、Dubbo-go等，跟微服务治理相关的组件也逐渐开始在Go生态发力，如Sentinel、Hystrix等都推出了Go语言版本，而作为微服务框架的核心引擎--注册中心，也是必不可缺少的组件，市面已经有多款注册中心支持Go语言，应该如何选择呢？我们可以对目前主流的支持Go语言的注册中心做个对比。 根据上表的对比我们可以从以下几个维度得出结论： 生态: 各注册中心对Go语言都有支持，但是Nacos、 Consul、Etcd 社区活跃，zookeeper和Eureka社区活跃度较低； 易用性： Nacos、Eureka、Consul都有现成的管控平台，Etcd、zookeeper本身作为kv存储，没有相应的管控平台，Nacos支持中文界面，比较符合国人使用习惯； 场景支持： CP模型主要针对强一致场景，如金融类，AP模型适用于高可用场景，Nacos可以同时满足两种场景，Eureka

作者 | 李志鹏 近几年，随着 Go 语言社区逐渐发展和壮大，越来越多的公司开始尝试采用 Go 搭建微服务体系，也涌现了一批 Go 的微服务框架，如 go-micro、go-kit、Dubbo-go 等，跟微服务治理相关的组件也逐渐开始在 Go 生态发力，如 Sentinel、Hystrix 等都推出了 Go 语言版本，而作为微服务框架的核心引擎--注册中心，也是必不可缺少的组件，市面已经有多款注册中心支持 Go 语言，应该如何选择呢？我们可以对目前主流的支持 Go 语言的注册中心做个对比。 图 1 根据上表的对比我们可以从以下几个维度得出结论： 生态 ：各注册中心对 Go 语言都有支持，但是 Nacos、 Consul、Etcd 社区活跃，zookeeper 和 Eureka 社区活跃度较低； 易用性 ：Nacos、Eureka、Consul 都有现成的管控平台，Etcd、zookeeper 本身作为 kv 存储，没有相应的管控平台，Nacos 支持中文界面，比较符合国人使用习惯； 场景支持 ：CP 模型主要针对强一致场景，如金融类，AP 模型适用于高可用场景，Nacos 可以同时满足两种场景，Eureka 主要满足高可用场景，Consul、Zookeepr、Etcd 主要满足强一致场景，此外 Nacos 支持从其它注册中心同步数据，方便用户注册中心迁移； 功能完整性

毫不犹豫的说，现代高速发展的互联网造就了一批又一批的网络红人，这一批批网红又极大的催生了特定平台的一大波流量，但是留给了程序员却是一地鸡毛，无论是运维还是开发，每天都会担心服务器崩溃，程序down机。还是怀念以前那些单机结构呀，甚至有点嫉妒那些做内网几乎没有访问量的应用的程序员，不用加班，不用提心吊胆，更不用每年买霸王洗发露。 提到单机架构，在互联网应用中肯定是吃不开的，流量高峰冲击的你可以怀疑人生。单机升级集群，带来的不止是技术上的挑战，在顶住流量高峰，迎合业务的同时，也引入了配置的复杂性。这也是我今天要谈的主题：配置管理。在单机时代，无论是什么语言，java也好，c#也罢，一个配置文件足以。随着所谓微服务这个看似能解决一切问题的方案诞生，同时也引入了更加复杂的配置问题：服务的信息，服务的各种参数，配置更新问题等。可想而知，假如你的服务有100台服务器，修改一个配置项，利用单体架构逐个更新的方式是一个多么蛋疼的事情，传统的配置文件方式已经无法满足开发人员对于配置管理的要求： 安全性。配置信息如果随代码一起发布，容易造成配置泄露。 实时性。修改配置，传统的单机架构必须重启服务才能生效。 局限性。无法支持动态调整，像最普通的日志开关功能，也不能做到。 环境区分。传统的配置文件方式，很难区分生产，开发，测试环境。 配置修改记录问题。静态配置文件方式，很难追踪这个配置文件的修改记录。

作者 | 宿何 阿里巴巴高级开发工程师 Sentinel 是阿里巴巴开源的，面向分布式服务架构的流量控制组件，主要以流量为切入点，从限流、流量整形、熔断降级、系统自适应保护等多个维度来帮助开发者保障微服务的稳定性。Sentinel 承接了阿里巴巴近 10 年的 双11 大促流量的核心场景，例如秒杀、冷启动、消息削峰填谷、集群流量控制、实时熔断下游不可用服务等，是保障微服务高可用的利器，原生支持 Java/Go/C++ 等多种语言，并且提供 Istio/Envoy 全局流控支持来为 Service Mesh 提供高可用防护的能力。 近期， Sentinel Go 0.3.0 正式发布，带来了 熔断降级特性支持 ，可以针对 Go 服务中的不稳定调用进行自动熔断，避免出现级联错误/雪崩，是保障服务高可用重要的一环。结合 Sentinel Go 已经提供的 gRPC、Gin、Dubbo 等框架组件的适配模块，开发者可以快速在 Web、RPC 调用层面配置熔断降级规则来保护自身服务的稳定性。同时 0.3.0 版本也带来了 etcd 动态数据源模块，开发者可以方便地通过 etcd 来动态调整熔断降级策略。 Sentinel Go 项目地址： https://github.com/alibaba/sentinel-golang 为什么需要熔断降级 一个服务常常会调用别的模块