请选择 进入手机版 | 继续访问电脑版

IT运维管理,ITIL,ITSS,ITSM,ISO20000-ITIL先锋论坛

 找回密码
 微信、QQ、手机号一键注册

扫描二维码登录本站

QQ登录

只需一步,快速开始

艾拓先锋
搜索
查看: 61|回复: 0

云原生关于DevOps、容器和编排、微服务和安全的一些思考

[复制链接]
来自- 美国

参加活动:0

组织活动:0

发表于 2018-11-14 09:47:46 | 显示全部楼层 |阅读模式 来自- 美国
本帖最后由 adminlily 于 2018-11-14 09:55 编辑   G0 x2 A: X/ |0 z

1 x7 Q2 \2 [" r( w: W
8 R- a" {7 _7 f. M0 {8 ^

; W2 f- ~+ `  c! p# U# Q
第一部分:定义

+ {+ i: n4 A! F# c( V/ L% a% K* v6 ^/ f
在Craig和我开始打造Heptio的时候,我们做了不少关于我们行业发展方向的思考。我们在Google里呆了很久的时间(两个人加起来的日子有16年了),对于Google构建和管理系统的方式有很深入的理解。但是很可能你没有在Google任职的经历。那么对于一个普通的公司、开发或者运维人员,应该如何理解并应用这些不断演变的新概念呢?
% e+ F! N# s7 U$ s1 F$ |* V
$ s6 M0 P7 p# B7 M1 H8 i8 H/ w  }6 L& C9 |- \4 E
云原生意味着什么,并没有一个固定或死板的定义。实际上,还有一些与之重叠的概念和思想。但在它云原生的核心,是对团队、文化和技术的精心组织,利用自动化和架构的力量来掌控复杂度,突破速度的束缚。在这种模式下的运作,不但是一种技术的扩张方式,更是一种人力的扩张方式。
5 H) q9 n3 W0 r; `) U- C; d7 Z7 l3 I5 n0 F
, n0 x, `* l0 A0 S. {; c
很重要的一点是,不一定要在云环境中运行才能叫“云原生”。这其中的技术可以在恰当的时候叠加地采用,并且帮助向云过渡的过程变得顺畅。
, n! P3 b% A  m6 d( F5 _2 P% @& T
* x% e+ W  K7 A* X4 a3 f: b! z# h
云原生的真正价值所在远不止与之密切相关的一篮子技术。要真正的理解行业的动向,我们需要思考我们能从哪些地方用什么途径让公司、团队和个人更加成功。
( k: S8 |, I6 E! D- o; j) M6 g$ D; g1 R' I9 k0 g$ t; d- a. Q, r- d
2 p0 V; K8 s2 y" ]8 C1 R- p
目前,这些技术已经被那些以技术为中心且眼光高远的公司验证,它们为此做出了努力并投入了大量的资源。想想Google、Netflix或者Facebook。同样也有规模更小,灵活性更高的公司实现了价值。然而,除在这些技术的早期采用者之外,这套哲学理念却少见有利用。 当把目光投射到整个IT领域,我们仍然在这条旅程起点不远的地方。; |, {4 U5 l* }

  t' @/ M9 J- a4 K# R) d" @
7 K% W- C! y0 g2 A) ~随着早期的经验不断被验证和分享,如今都有哪些涌现的主题呢?
& I5 Y0 T( Z! D  s0 n$ [

* r) Z8 C8 h" i4 }2 R( v
( V, Y" k0 s8 J# c5 |2 i4 D; L9 w9 B
  • 更有效率和更开心的团队。云原生的工具让大的问题切分成小的问题,便于分工让更专注和更敏捷的团队来解决。
    - j) i0 {6 n; X( i) D* }3 |

0 V4 T9 m* `5 B8 A& I

: @8 h9 z; M$ S8 y( }
  • 减少枯燥重复的劳动,通过将很多人工操作自动化,也避免了因为手工操作引发的运维上痛苦和停机时间。这一般是通过自愈合的自管理基础设施达成。更多的事情被期望用系统来解决。

    5 t) S4 d8 }$ I7 A. W" b
1 z3 \; ^; j! N- ^/ b9 c: q, H
  • 更可靠的基础设施和应用。构建用来处理一些可预见的故障的自动化流程,通常对不可预见的事件和故障是更好的失效模式。举个例子,如果部署开发的应用只需要一个命令或者点击一下按钮,那在灾难恢复的场景下(通过或手动或自动的方式)进行自动化部署也更加的容易。

    ) B: N4 O) Z* t, r) o& @  t
- ?4 t/ q) [! ^; L
. ]0 s8 t. o8 A0 E" z
  • 可审计,可察视,可调试。复杂的系统会变的非常晦涩难懂。云原生使用的工具,通常能让人对应用内部发生的事情有清楚的了解。
    6 k, I8 p- r1 a- d
8 T' d, k& Z' ~% }7 t7 w

4 V0 w8 E3 s2 F3 e! O2 T4 s* B! |" {
  • 深度的安全性。如今很多IT系统的外壳都很坚固,但内在都很脆弱。现代的系统默认情况下应该有安全防护,采取最小信任(least trust)策略。云原生让应用开发者能在应用安全方面扮演重要的角色。
    - a3 X! f* o3 u

/ x" n4 S# B1 @% a, T
  • 资源的更高效的利用。应用和服务的自动化式的、类云环境的部署及管理方式,开启了采用各种算法的自动化的机遇。比如,一个集群调度器/编排器可以自动完成工作负载的安放,而不需要运维团队用类似excel的方式进行管理。

    & r/ W' w% F# @0 N
6 F4 R7 ]# \/ w0 R
在Heptio,我们特别兴奋我们能帮助把云原生的恩惠带到更广阔的IT领域。在接下来的部分,我们将讨论与已有的系统进行整合,DevOps,容器和编排,微服务和安全。
$ }7 a) i5 ?- i( [0 ~% I' j1 l
$ F/ f0 e& N1 u

* H2 p) U$ c% Q: I4 Z) q/ A
第二部分:实践

5 I( I. O) p2 \/ M# }5 }3 q6 e1 H9 f; r, l8 v7 K/ B3 d3 d( X
与任何正在经历变革的领域一样,云原生世界中有繁杂的概念。上一个部分列举的概念,不是每人个人都清楚应该如何恰当地利用。同时,很多关键的项目,要么太庞大,要么太重要,不适合重头重写。因此,我们觉得最好把这些新的结构用在新的项目或者老项目的新部件中。在系统老的部件得到了改善后,然后再花时间合理地学习并采用其他新技术。寻找把新的特性或者系统分解成微服务的方式。% D& E0 E7 M+ l4 B. E
5 L6 X2 ?% k; O
# \3 R( v5 a/ |1 e* X( _7 D' A2 l
没有硬性的规则。每一个机构都是不同的。软件开发的实践必须要根据身边的团队和项目来做出调整。理想不同于现实。有的项目经得起实验折腾,但是很多非常重要的项目应该采取更加谨慎的态度。还有一些场景是介于两者之间的,一些技术即使已经被验证过,但仍需要规范化并且经过大规模的测试,之后才能应用到核心系统上。3 H0 G; w& ]4 \, ^! @
% S% d; Y; u4 X
" v, @* B" F1 ?) d* k, h& e5 s/ D
云原生的定义中离不开的更好的工具和系统。没有这些工具链,每一个新部署在生产环境的服务都会有很高的运维成本。监控,跟踪,配置等等都增加了一个处理的负担。这个额外的开销是对微服务大小的切分应该合理的主要原因之一。开发团队的速率和在生产环境中运行更多(服务)的成本,这两者的利弊需要权衡。类似的,新的技术和语言引入,尽管可能新鲜刺激,也必须仔细考虑其风险和代价。关于这个话题,Charity Majors有一个非常好的演讲。. g9 E" F$ @# V  o8 h+ H

% B5 i, [$ x" k, m8 ^( F9 i) l4 ~' @8 Q. K$ `5 F( x% f3 s- i
要降低构建和运行新服务中的运维成本,自动化是关键。像Kubernetes、容器、CI/CD、监控等等这样的系统,都有一个相同的重要目标 - 让应用开发和运维团队的效率更高行动更快,让打造的产品更可靠。. e6 v' _3 W' d/ u

; e: v6 g% _. c- N/ F5 C! d/ _2 T
( N$ s' ]! A0 X* h0 U要达到云原生的愿景,最好使用新一代的工具和系统,而不是传统的配置管理工具,因为它们有助于分解问题然后分工给不同的团队处理。通常来讲,新的工具通常能让独立的开发和运维团队拥有自主权,然后通过自服务(self service IT)提高生产力。
# |. l& T" M& W4 y$ J$ q& L  T# }( Z6 B+ j
& E+ ?: P! G8 J* X
第三部分:DevOps
) |) R, |- y+ S& `# T  \$ X
) Q& p. k& K! S' Y9 ~* w/ ~+ z
不妨将DevOps看成一种文化的转型,开发者现在需要关心他们的应用是怎样在生产环境中运行的。而运维也对应用的运作机制有了认识并且授予了知情权,从而可以在帮助打造可靠应用方面发挥重要作用。增进这些团队之间的理解和建立同理心是关键。
9 I" I( U: {8 C# I; b& p( i9 B1 h  F$ Z( u, [9 V+ X- H
: ?  c8 [5 ~) E
但是可以更进一步。如果我们重新思考我们的应用的构建过程和运维团队的结构组成,我们能进一步加深这种关系。: }; @3 s) ^, C3 W1 i

# u6 Q* l# A: q4 D
6 s$ q& e4 K5 K2 x0 UGoogle没有传统意义的运维团队。相反,Google定义了一种新的叫做SRE(Site Reliability Engineer,网站可靠性工程师)的工程师。他们是技能扎实的工程师(报酬同其他的工程师处同一个水平)他们不但随时保持在线,同时得到授权并被赋予通过自动化来在推动应用变得更加稳固方面扮演至关重要角色的重望。
$ ?/ s- g% c$ I4 o
" K# |. ?+ N+ \
8 ?& K. o1 ~% ?0 B, S! i5 Q当在凌晨两点报警触发的时候,任何响应该报警的人都会做同一件事情 - 努力弄清出了什么问题,好早点回去继续睡觉。真正定义一个SRE的地方是第二天早上10点钟发生的事情。运维组的人是否只会抱怨,还是会和开发团队一起协作保证同样的报警不会再次出现?在让应用变得尽可能稳定可靠方面,SRE和开发团队有一样追求。结合不追责的的事后剖析,可以保持项目的健康,不让技术债务堆积。0 ~! Q) H0 H9 E6 d4 h% F

- `. u* t: W- B. s. ]7 T# d# {9 E( ~1 B) v, q
SRE在Google是最被看重的人群之一。在实际中,很多项目在没有SRE参与启动的时候,开发团队肩负了让他们的产品在生产环境中运行起来的期望。引入SRE团队的流程,通常需要开发团队向SRE团队证明他们的产品已经准备到位。开发团队需要已经做好了所有的准备工作,包括设置好监控和报警,报警的应对策略和发布流程。开发团队要能显示出报警的情况已经达到了最少的程度,并且绝大多数的问题已经被自动化了。0 f$ d0 s: Z7 R/ @+ ~5 f' l

+ `; T2 W1 P+ e; c4 i) `3 h, a6 Y/ L
随着运维的角色参与程度更深,与特定的应用相关度更高,让一个运维团队掌控整个运维栈变得不合理。这引出运维规范

' K! h2 R/ Q# u* z
(Operations Specialization)的问题。从某种意义来说这是一种“反DevOps(anti-devops)”的做法。让我们来自下而上的看:
1 \% C* _6 R" F9 k* a

8 a8 {4 y# e0 U% e0 U1 N8 P8 d

1 M1 K7 s" ]+ H; `
  • 硬件运维。这一层很显然可以分离出来。实际上,很容易把云IaaS看成是“硬件运营即服务(Hardware Ops as a Service)”。
    + H& F& g9 j: D1 ]0 k* V
2 H3 u! I# V2 j  R% q; n

5 T0 B+ c7 B$ {/ [; U; q
  • 操作系统运维。必须有人保证机器能够顺利启动,并且有一个好的内核。将这一部分从应用的依赖管理中分离出来也反映出了用来托管容器的操作系统发行版(CoreOS, Red Hat Project Atomic, Ubuntu Snappy, Rancher OS, VMWare Photon, Google Container Optimized OS)的最小化趋势。

    ' `4 T$ _9 w! S" s0 i; {
! u- }6 O: @. H0 H  g% `
  • 集群运维。在容器化的世界中,一个计算的集群变成了一个逻辑上的基础设施平台。集群系统(Kubernetes)提供了一组原语能让很多传统的运维任务自服务化。
    2 N) ?. L7 ~5 W+ n# d

; K+ H+ i" y6 B" y
  • 应用运维。每一个应用现在可以根据需要拥有一个专门的应用团队。若有必要,开发团队有能力并且应该担任起这个角色。这种运维团队应该更深入应用,因为他们不需要在其他的层次上专研太深。比如,在Google,AdWords的前端SRE团队会和AdWords Frontend的开发团队交流很多,超过他们与集群团队之间的交流。这能带来更好的成果。

    ( `; Z3 S- h$ M* n0 a' C! O

  }# D4 C0 p# g9 ?8 w  z很可能还有其他专业性的SRE团队的空间。例如,存储服务可能会划分成单独的服务,或者根据某种政策,可能有团队来负责验证所有团队使用的基础容器镜像。
0 J2 m* \* i. U# k% {8 ?- S( l7 Y; b6 p3 D+ k& Y( _
1 \. r5 R: d9 J
第四部分:容器和集群
9 I: S' `6 L* K) y9 n

+ Q* E, J& g# c( M
有很多人对于容器相关技术兴奋不已。了解为什么大家如此兴奋的的根本原因是有益处的。在我看来,有三个原因:
) G2 n( a: s5 V, M( u9 _: z

, |* k* J) v2 H
3 M. I/ L2 ?& w3 R9 b0 ?4 j2 S8 Y
1.打包和移植性
3 j, g+ e0 n" C% H: Z; c
& |) a) ~  o, L; S+ l( j$ t) y- Z: }- O3 \$ o
2.效率
  o4 f! U3 W) |5 Q1 j3 I  Q3 Z6 S) o  {* [
+ o/ W' {" `' r9 O" k
3.安全性% O: j0 Q$ v2 K9 b6 d0 ~" ^8 F
; r" T; s# ]( G+ C, x6 b- e

. C# p8 e5 B, J) g( p; i, F! h让我们依次地来看。# I, l, w' }$ T$ P9 C
' A8 N+ m% Z, i
( y; J1 g$ Y2 V/ [( h* A4 x
首先,容器提供了一种打包机制。这能让系统的构建从这部署流程中分离开来。另外,构建的成品和镜像比传统的方式如虚拟机移植性更好。最后,部署变得更加的原子化。传统的配置管理系统(Puppet,Chef,Salt,Ansible)很容易让系统处于一种配置不完整的、很难调试的状态。也很容易有版本不可知的、不易被发现,存在机器中,而。
. i/ Z2 l. \4 N( V0 w) m! j% _; i/ \  A3 o" ]
4 X, i$ y0 S1 E. t5 o. b/ P
第二,容器更轻量化,使得资源利用率增加。这是当Google引入cgroups(容器底层的主要核心技术之一)时的一个主要原因。通过共享一个内核,并且允许更流体化的过量使用(fluid overcommit),容器更容易让系统资源每一部分都不浪费(“use every part of the cow”)。随着时间的推移,有望看到更加复杂的用来均衡单个主机上共存容器需求的方式,杜绝吵闹邻居问题。0 h$ ?; T1 z# `  ~5 F1 b
* i9 ]& w$ l. [% K
- ^- A- m4 X! x
最后,很多用户把容器看做是一个安全性界限。尽管容器可以比一个简单的Unix进程更安全,当把它们看做是一个硬的安全性边界的时候还是要注意。Linux命名空间提供的安全保证对于那些运行半信任工作量的“软”多租户环境来说合适,但对于那些运行充满敌意的工作量的硬多租户环境却不适用。/ d; A* ?* j4 I" j9 ^, k
: H6 d: |$ H, m# X0 a' y8 e
  F. {1 ^$ H" Q
有从很多方面的努力来在模糊容器和虚拟机的界限。一些早期研究如unikernel很有意思,但是很多年内尚不能应用于生产。+ U, m1 |5 G! ]9 B3 l
2 A. F6 k+ g: s2 h" _+ r

/ s6 h2 s( F+ O5 M: k要达到上述目标,容器尽管是一条简单的途径,但却不是必要的途径。例如,Netflix,传统以来一直运行一个非常现代化的技术栈,它们以类似使用容器的方式,来打包并使用虚拟机镜像。4 K( y5 n: f& f

$ Y/ B9 u, Q! t/ [( u8 k5 n* ^6 t
( R9 r4 {3 N2 }2 o尽管绝大多数围绕着容器的努力集中于在单个节点上管理软件,使之更加可靠和可预测,这个改革的下一步集中于集群(通常也被称作编排器)。给定一批节点然后把他们和自动化系统绑定起来,为开发和运维团队提供了一组逻辑基础设施的自服务。
; _$ G: e, V9 H9 r" a& m  ^! q1 ?* \4 q7 ]& g* H1 a9 G# L' O

, [' Z/ `& x" c3 G$ J+ i% T- M, j集群能帮助消除运维中枯燥乏味。有了容器集群我们让计算机来接管工作,决定负载应该由哪台机器来处理。集群也会默默的在硬件失效的时候修复问题,而不是需要去通知某人。
5 \9 y0 `0 [2 s: Q5 ?8 u; l
" h. \* D  S. n# D9 z5 o' I# w
7 ?# G8 h# P! x. R! Z5 o4 S- b集群的第一个好处就是它启用了运维的规范(见第三部分)可以让应用运维作为一个单独的学科来努力。通过定义个以良好的集群接口,应用开发者们能集中于解决应用自身的一些问题。
) c# R6 C- N6 Y, L, l  {% y8 Z2 j$ C5 C1 w& g  E

1 a: B; d) ^  F8 I& o集群的第二个好处是它让启动并管理更多的服务成为可能。从而允许使用能为开发团队高速率的架构(通过下一部分介绍的微服务)。4 s7 p" i5 |7 h" U4 j( @9 a
( e; z* ~/ O3 B5 M+ X- o

( M" L- ]# s  x: P# z5 n- R
第五部分:微服务

* W; t. a5 Q0 \/ U" n0 Z2 \
6 N8 b) G# I6 g5 Y& P) _+ ?' p
微服务是一个已经存在很久的概念的一个新名称。基本上,它是一种将一个大的应用进行切分的方法,使得他们能独立地进行开发和管理。让我们看看此处相关的关键概念:
" t2 J) M; ]% `) j) X1 H& N7 Y% u
8 e! O2 G# c% \/ a
8 D2 [$ X, }2 W9 l6 ?
  • 强大和清晰的接口。服务之间的紧耦合必须避免。配套了清晰文档和有版本管理的接口有助于强化这种协定,对于这些服务的消费者和生产者同时又都能保有一定的自由度。
    ' m- ~- N! y! J; N  Q& y

, {9 g8 s+ k$ ?2 k* N) H! S

6 \" b% N3 _8 j' B6 r
  • 独立的部署和管理。微服务应该能够单个更新,无需和其他的服务一起同步进行。同时,大家也都很希望能够轻松地回滚一个微服务的版本。这意味着部署的二进制文件必须在API上和任何数据格式方面保持向前和向后兼容。这可以作为检验运维和开发团队之间的合作和沟通程度的试金石。

    / B5 G; m4 w$ U! C3 X+ y6 n
2 ]" r- M. E" _) M$ b
  • 由内打造的耐受性。微服务应该构建成为并经测试验证有独立的耐受性的。在消费的服务不可用或者异常的时候,那些消费一个服务的代码应该要努力保持正常工作并且做出合理响应。同样的,那些提供的服务应该对于未曾预料的负载和异常输入做好防护。

    $ w( x  v, `" T% Y
; p* n/ `0 ^2 N3 B8 S6 M
确定微服务的大小是一个很难做对的事情。我的意见是要避免选择小的过分的服务(pico-services),反之将服务按照自然的边界(编程语言,异步队列,伸缩的要求)进行切分,同时保持团队大小合理(例如:两个披萨团队)。
3 {! u+ R8 }$ j  U- H
7 t2 @" e9 h! f/ s( I3 `
7 @/ I( n2 P" u5 @0 b2 y) _应用的架构应该能允许以一种切合实际并且自然的方式增长。与其以20个微服务开始,不如从2到3个开始,然后随着该领域复杂度再对服务进行拆分。经常对一个应用的架构的认识直到应用在处于开发阶段才会变得透彻。这也说明了很少有已经竣工完成的应用,他们都总是一个正在施工的工程。2 T! n4 Y$ s! J1 s  n) E
) E3 f) r2 C; G% x7 k

( E1 c0 _$ v- \' @) V: A微服务是一个新概念吗? 非也。这其实是另外一种类型的软件组件化(software componentization)。我们过去把代码切分成库。这只是把“链接器”从一个构建阶段的概念转变成了一个运行时的概念(实际上,Buoyant有一个有意思的项目叫做linkerd,其基于Twitter Finagle系统。)。这与多年前的SOA潮很相似,只是不见了各种样式的XML。数据库从另外一个角度看,一直以来几乎是一个微服务,因为它实现和部署的方式都满足上面列的点。