1.1我们先来了解一下paas到底是什么？
PaaS是Platform-as-a-Service的缩写，意思是平台即服务，首先，在了解Paas之前需要知道什么是云计算，云计算是指基于互联网网络，通过虚拟化（xenOpenStack）统一管理和调度计算，国内厂商如：阿里云/aws/ucloud/等等目前云计算三大类：
1.基础设施即服务（IaaS）2.平台即服务（PaaS）3.软件即服务（SaaS）
1.2企业为什么需要一个PaaS？
平台即服务（PaaS）PaaS提供应用服务引擎，将软件研发测试和运维的平台作为一种服务提供，应用程序接口，开发人员基于这些服务构建业务应用。从运维和开发角度来说，这意味着无需运维搭建环境，开发也不会因为不同平台兼容性方面遇到困扰。
2.1平台简介
2.2Dashboard
2.3应用服务
2.4定时任务
2.5配置中心
2.6CI/CD
2.7资源审计监控
2.8高级功能
我们team在高并发业务场景下做了哪些优化
选择比较适合的实例规格或机器型号.云服务器需支持多队列网卡
3.2系统层面优化
操作系统优化：支持大并发，单集群2000节点K8s&容器层面优化：支持大并发，基础镜像制作优化等等Principle：最小权限，优先跑满容器资源限制docker宿主目录直接跑在默认/var/lib/docker下长期跑下来会导致系统盘异常。导致down机等。因此我们做了一下调整，自定义镜像（lvm)增加可扩展性
3.3内核参优化docker进程异常Dead状态atcentos7.4*增加fs.may_detach_mounts
总结：我们做了大量业务压测，以及云平台slb、ecsidc机器做了大量的性能调优，对业务的优化，配合开发同学做了大量的debug才使得我们业务能在容器稳定的运行
在某某天一个凌晨4点，突然接到短信报警，此时大家都在深睡，早上八点起床后发现收到了两条报警，一条是磁盘80%的告警，一条是磁盘恢复的报警，我们可以想象一下哈，如果你业务部署到了服务器，将会发生什么，4-8点完全可以吧机器磁盘空间写满，导致业务异常。机器oom为什么容器会自动恢复呢。原因和简单，kubernetes自带有异常的pod自动驱逐，当磁盘空间大于百分之80他会判定这个pod是有问题的。
解释：本地磁盘是一个BestEffort资源，kubelet会在DiskPressure的情况下，kubelet会按照QoS进行评估。如果Kubelet判定缺乏inode资源，就会通过驱逐最低QoS的Pod的方式来回收inodes。如果kubelet判定缺乏磁盘空间，就会通过在相同QoS的Pods中，选择消耗最多磁盘空间的Pod进行驱逐。
4.1要说到kubernetes，就一定要聊聊etcd，他存储了于整个kubernetes的信息
etcd是一个高可用的键值存储系统，主要用于共享配置和服务发现。etcd是由CoreOS开发并维护的，灵感来自于ZooKeeper和Doozer，它使用Go语言编写，并通过Raft一致性算法处理日志复制以保证强一致性。etcd可以用于配置共享和服务发现。
4.2etcd主要分为四个部分：
HTTPServer：用于处理用户发送的API请求以及其他etcd节点的同步与心跳信息请求
Store：存储，用于处理etcd支持的各类功能的事务，包括数据索引，节点状态变更，事件处理与执行等。它是etcd对用于提供的大多数API功能的具体实现
Raft：Raft强一致算法的具体实现，是etcd的核心
WAL：WriteAheadLog(日志先行)，WAL是一种实现事务日志的标准方法。etcd通过WAL进行持久化存储，所有的数据在提交之前都会事先记录日志a.Snapshot:防止数据过多而进行的状态快照b.Entry:存储的具体的日志内容
4.3etcd中的术语：
4.4Raft状态机
Raft集群中的每个节点都处于一种基于角色的状态机中。具体来说，Raft定义了节点的三种角色：Follower、Candidate和Leader。
这三种角色状态之间的转换，如下图：
一个Raft集群包含若干个服务器节点；通常是5个，这允许整个系统容忍2个节点的失效。在任何时刻，每一个服务器节点都处于这三个状态之一：领导人、跟随者或者候选人。在通常情况下，系统中只有一个领导人并且其他的节点全部都是跟随者。跟随者都是被动的：他们不会发送任何请求，只是简单的响应来自领导者或者候选人的请求。领导人处理所有的客户端请求（如果一个客户端和跟随者联系，那么跟随者会把请求重定向给领导人）
每次成功选举，新的Leader的Term(任届)值都会比之前的Leader增加1。当集群中由于网络或者其他原因出现分裂后又重新合并的时候，集群中可能会出现多于一个的Leader节点。此时，Term值更高的节点才会成为真正的Leader。
4.5etcdclient
主要包含以下几个功能：
4.6.etcd运维、与备份
二、添加节点
1.准备新机器,将上一步生成的配置文件变量，写到新节点，尤其是集群状态为existing。(目标节点的数据目录要清空)
2.生成用于集群节点通信的SSL证书
3.生成用于客户端和节点通信的证书
4.启动并检查
三、生产环境建议
建议采取多台etcd集群至5台，保证多个节点挂掉不会影响使用
四、etcd备份
配合cronjobnfs或云共享储存建议分钟级别保留
4.7.etcd监控
推荐promtheus+grafana可自定义promtheusetcd报警规则，或grafanaalert插件报警等等
监控是整个运维环节，乃至整个产品生命周期中最重要的环、事前及时预警发现故障、事后提供数据追查定位问题，分析业务指标等等坚持业务指标采集是代码的部分原则不不动摇，提高指标覆盖率监控方式和指标要标准化。
5.1.定制容器基础监控规则、规范。比如cpu阀值、内存阀值、磁盘阀值等等、高峰期robot自动巡检报告5.2.监控选型：promtheus、zabbix等等
一个kubernetes集群的dashborad基本信息
指定podcpumem监控
5.4pod自动扩容提醒和异常pod（crashloopbackoff）报警（钉钉报警）
5.5业务监控、podcpu内存监控高峰期自动钉钉发送无人值守
6.1案例一
异常：authentication.k8s.io:0xc820374f50]isalreadyregisteredkubectlthrowinggroupisalreadyregisterederror原因：kubectl版本与Kubernetes版本不一致导致的解决：选择相应的kubectl版本重新安装
6.2案例二异常：kubelet:E052917:40:11.74109514358fs.go:418]Statfsfailed.Error:nosuchfileordirectory
原因：由于安装docker时宿主目录被软链overlayfs清理container不完整导致的
解决：安装kubernetes集群时docker需要配置好宿主目录不要软链
6.3案例三
异常：svcip变化导致无法访问，1.9.4之前的惊天大BUG
解决：升级kubernetes至1.9.3或更高1.9.2的bug
6.4案例四异常：做线上cordon节点的时候服务不可以用，导致某云slb无法转发到节点的容器业务服务
原因：一般设置cordon的之后就会drain做排水调度，在ServiceController里面确实会将unschedulable的节点从service上移除，这个是目前kubernetes的机制
解决：做cordon操作时选择在业务低峰期，比如凌晨操作，分批操作不要一下子全部cordon
常用技巧
查看TCP/UDPsockets状态ss-an|grepLISTENnetstat-sEST,CLOSE-WAIT,TIME-WAIT,SYN_RECV发送TCPRST可以避免进入TIME-WAIT状态Tcpdump网络抓包，网络故障分析tcpdump-vv-ieth0portxx-X-s0tcpdump-vv-s0-ieth0portxx-w/tmp/xx.pcap