阿里专家带你玩转DevOps

P5-05_多种发布模式实现容器化交付

交付的边界

应用=网络（Services）+服务载体（Pods）+存储（Volumes）

大部分的发布策略都是网络层的变更。

容器的网络分为2大部分：单机网络模型（host、bridge、共享所有命名空间）、跨主机的网络模型（L2 Flat、L3 Flat、Overlay）

host网络一般是利用宿主机的host网卡，相当于容器会绑定宿主机的网卡，通过这种方式实现高性能的网络转发。IP地址、mac地址都是复用宿主机的网络。

这种方式的缺点是没有隔离性。

bridge，通过桥接的方式实现。

容器里最主要的模型，就是L3 Flat和Overlay

在阿里云的环境里，如果是VPC的网络，通常就是L3 Flat模型，而经典网络使用的就是Overlay的网络模型。

比较来说，L3 Flat要比Overlay有更好的性能，因为它们的寻址不需要通过ARP广播实现，而且网络通信可以直接通过路由，而不需要封解包。

kubernetes：Service（LoadBalancer、NodePort、ClusterIP）

常见的发布策略：蓝绿发布、金丝雀发布（灰度发布）、ABTest

蓝绿发布通常被称为热部署

蓝绿发布：在发布过程中用户无感知服务的重启，通常情况下是通过新旧版本并存的方式实现，也就是在发布的流程中，新的版本和旧的版本是相互热备的，通过切换路由权重的方式（非0即100，要么全部访问A，要么全部访问B）实现不同的应用的上线或者下线。

蓝绿发布适合绝大多数的应用场景的发布，能够零宕机更新。缺点是发布时，资源消耗大。

金丝雀发布：

通过在线上运行的服务中，新加入少量的新版本的服务，然后从这少量的新版本中快速获得反馈，根据反馈决定最后的交付形态。金丝雀发布主要面向的场景是功能兼容的新版本验证，可以用最小的代价实现功能验证，且保证主体流量不受影响。缺点是面向场景比较单一，对于开发者要求较高。

如果对接入层的流量没有区分，发布的金丝雀版本没有在接入层对流量进行切分，就属于金丝雀发布。

如果对流量有明确的切分，比如A必须只能访问新的实例，B必须不能访问这个新实例，就是灰度发布。

如果对流量没有指向性，就是金丝雀发布；如果有指向性，就是灰度发布。

灰度发布：

灰度发布是通过切换线上并存版本之间的路由权重，逐步从一个版本切换为另一个版本的过程。

金丝雀发布更倾向于获取快速的反馈，而灰度发布更倾向于从一个版本到另一个版本长时间平稳的切换。

灰度发布是期望在一个非常大的版本之间，有指向性的导流。然后通过这种导流的策略，逐渐把新版本迭代上线。

A/BTest

A/BTest和灰度发布非常像，但是从发布的目的上，可以简单的区分灰度发布与A/BTest，A/BTest侧重的是从A版本或者B版本之间的差异，并根据这个结果进行决策，最终选择一个版本进行部署。因此和灰度发布相比，A/BTest更倾向于去决策，和金丝雀发布相比，A/BTest在权重和流量的切换上更灵活。

A/BTest和灰度发布从原理上讲，没有区别，都能够准确切分流量，有快速验证，可以实现版本并存和发布。

分批发布

分批发布是对发布流程的细粒度控制，并不是一种标准的发布策略。

分批发布和蓝绿发布比较像，也希望通过一种0宕机的发布方式，解决版本更新的问题。但是，蓝绿发布会有大量的资源消耗，分批发布就是要解决资源消耗的问题，它会将应用的副本切分成不同的批次，每次发布会发布其中一个批次，并将新流量直接打入到新的批次上进行快速验证。当验证没有问题会再发布第二个批次、第三个批次……直到所有批次发布完成。

对于分批发布这种流程，如果完全基于k8s来实现，会很复杂。因为这里面不只是有自动的过程，还有手动的过程。因为在验证这个版本是正确，还是错误，实际是需要手动来判断是继续，还是要回滚。这种场景对于k8s来讲，是很难做的。因为k8s里的抽象，大部分都是原子的，比如deployment的抽象、Service的抽象……它们之间是没有办法很好的有机结合在一起，实现一个过程的。

在k8s里面，通过yaml的方式，只能定义单一一种的抽象。为了解决这个问题，k8s社区推出一种工具——helm。

helm是k8s下的一个包管理工具，它将应用部署包含的多种k8s资源对象整合成单一的对象，这个对象叫做chart，模板提供默认的部署配置，部署时可以进行环境变量的替换修改，具有生命周期的管理能力，可以升级、回滚和版本追踪。

helm听起来很完美，但是也有自己的问题。helm虽然可以很好的定义资源的拓扑、应用的始态和终态，但是对于中间的流程控制是缺乏的。也就是说，helm虽然把拓扑关系都管理起来了，但是没有办法做发布方式。

特别是常用的蓝绿发布、分批发布、灰度发布等场景难以很好的支持。

有没有什么办法来解决这个问题呢？

k8s目前有1个新的概念：CRD来解决这个问题。

CRD（CustomResourceDefinition）是一种扩展定义kubernetes抽象对象的方式，阿里云定义了分批发布的CRD，帮助开发者实现分批次的发布流程控制。

1个分批发布的CRD，包含1个service和1个statefulset

P6-06_开源框架与阿里云容器服务集成

Derrick：构建Dockerfile的自动化工具

这是阿里巴巴开源的工具，中文意思：起重机

Kompose

Kompose=Kubernetes+Compose

把Dockercompose的yaml文件转换成kubernetes需要的yaml格式

helm

中文意思：舵

kubernetes的包管理器

在CentOS安装软件时，都会用到包管理器，比如yum，进行安装软件的过程。

helm可以在kubernetes上，把打包好的资源文件部署到kubernetes集群上并进行管理。

SpringCloud

微服务不限定语言。

https://developer.aliyun.com/article/596889——阿里云Kubernetes SpringCloud 实践进行时(1): 分布式服务注册与发现

Istio

Service Mesh中有1个很重要的概念：Sidecar

Sidecar就是把应用本身，在部署起来的pod里面注入1个新容器，作为sidecar。

Service Mesh的意思，服务网格

https://developer.aliyun.com/article/599874——阿里云Kubernetes Service Mesh实践进行时(1): Istio初体验

P7-07_容器化应用性能测试与调优

C10K

C10M

性能调优：首先要找到现象，然后把现象转换成症状，最后再通过症状找到问题的本质，然后再去解决它。

性能调优有以下几种常见方法：

负载测试：负载测试是用户观点的测试行为。简单说来就是负载测试就是让系统在一定得负载压力下进行正常的工作，观察系统的表现能否满足用户的需求。

a.系统要在稳定的状态运行

b.在满足稳定状态前提的最高压力

压力测试：压力测试的关键字就是“极端”。通过对系统的极端加压，从而观察系统所表现出来的性能问题。再对此性能问题进行分析，从而达到系统优化的目的。所以，压力测试就是一定要让系统出问题，如果系统没有出问题，那么压力测试的手段和方法就肯定存在问题。

压力测试和负载测试之间，它们最大的区别，就是要不要把系统压出问题。

负载测试，是在系统不出问题的情况下测试；压力测试是一定要让系统出问题，再找出问题的原因。

并发测试：验证系统的并发能力。通过一定的并发量观察系统在该并发量的情况下所表现出来的行为特征，确定系统是否满足设计的并发需要。并发测试是系统观点的测试行为。

负载测试和并发测试的区别：

并发测试验证的并发能力和我们所理解的系统对外的承载能力是不同的。比如说，系统的并发能力可能只有300，但是，每天却可以承载几百万人的访问量。这其实是2种不同的维度。

qbs300是系统观点的测试，每天对外服务几百万，是用户观点的测试行为。

大部分的负载测试或压力测试，更多是为了满足用户观点的测试行为。

基准测试：基准测试要有1个基准点，也就是说供比较基点。当软件系统中增加1个新的模块的时候，需要做基准测试，以判断新模块对整个软件系统的性能影响。按照基准测试的方法，需要打开/关闭新模块至少各做一次测试。关闭模块之前的系统各个性能指标记下来作为基准，然后与打开模块状态下的系统性能指标作比较，以判断模块对系统性能的影响。

一些大型软件在上线新功能模块的时候，会做这种测试。这种测试目前不是很多。

一些传统项目做的相对多一点，在互联网的产品里，基准测试相对做的比较少。

稳定性测试：长时间的负载测试，确定系统的稳定性。

稳定性测试和负载测试基本是一样的东西，只是稳定性测试需要比较长时间的保留。因此，稳定性测试的阈值会比负载测试低一些。

可恢复性测试：测试系统能否快速地从错误状态中恢复到正常状态。比如，在1个配有负载均衡的系统中，主机承受了压力无法正常工作后，备份机是否能够快速地接管负载。可恢复测试通常结合压力测试一起来做。

全链路测试：在大型互联网公司中提出的包含系统上下游的全链路压力测试与稳定性测试方式，通过模拟近似真实的用户流量和用户行为来仿真线上流量，是目前大型活动前或者大版本演进上线前的一种非常有效的保障措施。

容器性能分析——Linux命名空间

容器性能分析——Cgroup

容器性能分析——网络损耗

容器性能分析——文件IO损耗

容器性能分析——框架语言性能降低

容器性能分析——不同镜像的性能差异

容器性能分析——内核参数差异

docker对于/proc是只读挂载，因此对于内核参数的修改会在主机级别共享，这可能会造成同一台主机不同的容器之间存在对内核参数的相互影响，从而造成性能差异。例如：1个长连接的应用和1个短连接的应用在同1个节点运行，他们对于内核的参数会有所不同的要求，从而造成性能差异。对这样的节点进行参数调优时，就需要兼顾长连接场景和短连接场景的差异，这种差异很多时候都是不可调节的。必须通过调度，或者其他方式去解决。

常用容器性能调优工具与使用：10个常用的主机调试工具

uptime --> load averages（负载）

dmesg | tail --> kernel errors

vmstat 1 --> overall stats by time

mpstat -P ALL 1 --> CPU balance

pidstat 1 --> process usage

iostat -xz 1 --> disk I/O

free -m --> memory usage

sar -n DEV 1 --> network I/O

sar -n TCP,ETCP 1 --> TCP stats

top --> check overview

容器压测工具

WRK：适合常规的压力测试和稳定性测试的场景，支持连接数、线程、时间等基础参数，支持脚本、header头（短连接）等场景。但是，压测工具的压测指标一定要选择1个适当的压测时间长度，最好在5分钟以上，因为对于压测量级比较大的场景（上千、上万的并发），WRK存在预热的问题（压测第1分钟的流量可能非常少，因为在建立connect的时候，需要比较长的时间），过短的压测时间，可能会造成压测结果不准确的问题。

PTS：全链路压测工具，通过脚本编写可以模拟真实的流量、参数以及用户行为。目前服务于逻辑思维、懂球帝等多家客户。

资源概览工具

对于容器调优的场景，第1件事要看有没有内存泄露、文件连接数泄露的问题。以上场景，比较常用的是资源概览工具

ctop：它是专门为容器开发的，可用于容器层级间监控进程。底层的实现，是通过读取cgroup的信息实现top的能力。

htop：ctop能够帮助查看容器的实时监控指标，但是，主机上的一些性能争抢的场景，并不一定就是容器之间的互相争抢，可能是主机上的进程和容器进行争抢。这时候，htop就非常重要了，它可以在主机上帮助我们查看进程级的抢占情况。

CPU Memory性能工具

perf

strace

磁盘性能

大部分的IO问题，都是因为使用特定的分布式存储（比如，对象存储OSS、文件存储NAS）。这2种存储可以通过阿里云上的云监控查看监控指标即可。

常规的磁盘监控，推荐的工具是iotop和iosnoop

iotop可以找到IO比较高的进程，然后再根据这个进程进行分析。在分析的时候，就需要用到iosnoop。

iosnoop可以进行进程跟踪，找到对应写入磁盘的事件。从而查找是不是代码里有写入瓶颈的症状。

网络性能

sar：其他大部分性能调试工具是在使用的时候采集（实时采集或者单次采集）。而sar工具在linux可以记录和分析历史数据。

性能调优时，最担心没有办法复现问题，或者不确定这个问题是在这台机器上出现过，以及什么时候会再次复现。而sar工具可以定位这些问题：比如可以定位tcp的重传。

netstat：实时网络诊断工具，通常会用这个命令检查tcp协议栈的网络状态。

通常情况下，在容器的场景里，网络性能的调优很多时候会变成内核参数的调优。但是，并不建议在没有性能瓶颈的情况下，还做内核调优。因为内核目前还没有办法进行抽象和可编程，这会造成系统配置很难管理。

网络诊断

结合tcpdump和wireshark，可以对数据包进行分析。

因为tcpdump很难看到上下游的跟踪状态，数据的输出太快。但是，在wireshark可以通过可视化的方式，定位问题。

大杀器

sysdig是sysdig cloud出品的基于lua语言开发的超强工具，它相当于strace+tcpdump+lsof+htop+iftop，还有其他工具的合集。除此之外，它还支持对容器，如docker、CoreOS、LXC进行监控。sysdig的优势在于融合多款工具，在1个软件中完成所有的调优工作。

相对而言，sysdig的使用方式比较复杂，安装方法也不是太友好。对开发者而言，需要掌握更多的知识。

如果希望专门做容器的调优或者系统调优方向，建议能够了解、掌握这个工具。

以上的调优工具都是被动调优工具，这里的“被动”，是要求使用者要有一些基础条件，比如要知道排查的问题是网络方向的，还要清楚使用的strace工具，输出的信息都是什么意思。

但是，更多情况是，开发者并不知道在排查问题时，要寻找那个方向，要使用那个工具（什么时候应该使用iotop？什么时候应该使用sysdig？什么时候应该使用free……）我们就需要一款主动性能调优和诊断机制。

snout就是一款主动性能调优工具，只需要把它拷贝到宿主机上，直接执行snout命令即可。它会探测系统里可能隐藏的问题，比如会检查网络协议栈、磁盘利用率……定位可能存在的某些问题。

发现这些问题后，会给我们一些建议并输出。

P8-08_容器化应用问题诊断、监控与运维

kubernetes常见问题——etcd稳定性问题

kubernetes常见问题——网络链路

kubernetes常见问题——核心组件

99%的情况下，核心组件都是异常稳定的，而且基于k8s内部的实现机制，删除重新部署是恢复的最佳方式。

对于k8s核心组件的故障排查和恢复，是即简单又复杂。

因为如果想完整排查出是什么问题，对于大部分开发者是有难度的。因为这要对k8s的核心组件非常了解，要知道日志每行信息代表的内容是什么，产生的原因可能要到代码里查找。但是，对于大部分开发者来说，只需要知道，当发现问题时，如何恢复它即可。对于这种场景，k8s对开发者是非常友好的。因为它的实现是基于状态机。那么，对于状态机这种机制来讲，只需要能够全量同步一次基本就能解决问题。所以，对于核心组件的问题，杀掉相应的pod，由上层的Deployment直接拉起，并进行全量的基于状态级别的恢复。

kubernetes常见问题——pod异常

kubernetes诊断问题流程——判断故障的等级

1.kubectl get componentstatus（核心组件的健康状态）

2.kubectl get nodes

kubectl describe node [node_name]

kubectl top node [node_name]（节点的健康状态）

kubernetes诊断问题流程——缩小故障排查范围

核心管控故障：

排查顺序：资源是否足够-->etcd-->apiserver-->dns-->其他核心组件

负载节点故障：

排查顺序：资源-->系统日志（dmsg）-->kubelet日志-->网络通畅是否有问题

负载故障：

排查顺序：负载本身状态标志-->负载事件信息-->负载自身日志-->负载相关资源权限与状态

kubernetes诊断问题流程——获取信息转换“现象”为“症状”

kubernetes诊断问题流程——处理问题验证结果

kubernetes监控方案