GopherChina2017以讲师身份参会感悟

时光荏苒。2016年北京GopherChina大会的情形还历历在目,2017年上海GopherChina大会又如约而至。

img{512x368}

一、印象

这是我连续第二年参加AstaXie组织举办的GopherChina大会。而且不同于去年的是,这次我是以讲师身份参与的。虽然大会地点不同,我的角色不同,但不变的是和广大Gophers一样的对Go语言的极大热情。

这也是第三届GopherChina大会。随着Go语言自身的快速演进以及Go在国内各个行业应用的快速增长,GopherChina大会在大中华区的影响力与日俱增:既得到了更多圈内赞助商的赞助,也得到了Gophers们的极大关注。有好多Gophers都是GopherChina大会的连续参加者,有些Gopher甚至连续参加了三届,我个人就看到了好多去年在北京大会上遇到的Gophers。这让能容纳近1500名观众的主会场又近乎爆满。举办和参加这样级别的技术大会,无论是对于主办方还是观众都是一种考验。索性的是,在谢大和相关工作人员的不懈努力之下,两天的大会举办的是很是成功,大会紧凑而有序。并且在第一天晚上举办的技术Party上,大胡子Dave Cheney还为我们带来了“Gopher puzzlers”。这让技术party的气氛一下达到了高潮。

二、选题考量

由于本次是以讲师身份参加的大会,因此这里就不打算像去年那样对其他讲师以及其presentation进行点评了(若要看点评,可以移步到知乎上小伙伴开的贴子)。这里我主要来说说我这次参会的选题以及个人对于类似GopherChina这样的技术大会应该讲些什么的理解。

年初,谢大在征集GopherChina的topic的时候问我是否愿意在今年的GopherChina大会上做分享?说实话我非常想去分享,自己也是一个爱分享之人。但是分享什么topic的确是一个问题。自己研究Go较早,但一直没有全职Go,直到去年才开始成为full-time Go。而自己对GopherChina这类技术大会分享的主题也是有自己的想法的,那就是希望大会能像美国丹佛举办的gophercon大会一样,多一些关于Go语言本身的Topic。于是我就有了自己来分享一个关于Go语言自身的topic的想法,和谢大做了沟通后得到了谢大的支持。下面的topic初步描述反映了我当时关于slide的思路规划:

*“2016年Go语言问鼎TIOBE编程语言排行榜的年度语言,证明了Go语言在全世界范围内的蓬勃发展之势,将来会有越来越多的开发人员加入到Gophers行列。Go以语法简单、门槛低、上手快著称。但入门后很多人发现要写出地道的、遵循Go思维的代码却是不易。为此,在本次分享中,作者将结合Go team的talk资料、参考和提炼Go标准库以及主流Go开源项目的精华源码风格和惯用法,和大家一起探讨《go coding in go way》之道。” *

关于这样的一个主题,我的心理也是忐忑的,内心中有种赶脚:这个topic有些大啊!在阅读代码、收集和整理资料方面的工作肯定也不少,于是我早早开始了一些资料收集工作。

最初我的topic是偏向于go idiomatic tricks或best practice这个方向的,但随着准备工作的进行,我的头脑中出现了几个疑问:Go诞生这么多年,go idiomatic tricks或best practice已经为人知晓,但很多问题并无定论,我是否可以探讨一下呢?比如:Go的编程思维到底是如何形成的?为什么Go上手易,写出idiomatic的code难呢?我是否能再上一个层次,将go idiomatic tricks或best practice这些冰山上面的具现事物的底层根源找出来呢?这时恰逢国内上映《降临》这部美国大片,在电影院看完片后,我思考着影片中的理论核心:“萨丕尔-沃夫假说”并陷入沉思。

于是乎那天晚上我就有了一个关于topic的新的想法,那就是探究Go编程思维背后的东西。但考虑到如何应用编程思维去写go代码,我又阅读了大量go stdlib、kubernetes的代码,试图在这些代码中找到”Go语言编程思维”的应用实例并补充的slide中。这样slide的大体结构就出来了:

铺垫
    - “萨丕尔-沃夫假说” 作为引子,说明语言与思维的联系
    - 针对一个问题的三个语言版本实现,说明编程语言对编程思维的影响
    - 提出:语言价值观是语言影响思维的根本(一个示意图阐述模型)

价值观
    - Go语言的价值观的形成和价值观内容
    - 每种价值观下的语言设计
    - 每种价值观主导下的Go编程思维
    - 这写Go编程思维的具体运用实例

而随着资料准备的深入,逐渐完成了价值观(“全面简单”、“正交组合”和“偏好并发”)与编程思维的内容体系构架(大纲):

   Overall Simplicity
        - short naming thought
        - minimal thought

   Orthogonal Composition
        - vertical composition thought
        - small interface thought
        - horizontal composition thought

    Preference in Concurrency
        - concurrency thought

其实在这个资料准备过程,我个人对于Go语言的理解也得到了一定的升华,也更加理解Go的设计者在当初设计语言时做出的一些选择了,并且感觉在面对实际业务问题时、在代码设计时,更加有道可循了。

临近大会,开始写slide。本着present in go way的思路^_^,我首选go present tool支持.slide格式文档,最后形成了近70 pages的文档。我也感觉页数有些多,并且每次自己彩排一遍都超时。但页面之间逻辑紧扣,武断地删除一页又担心思维跳跃,不便于整体理解,于是硬着头皮将所有内容都保留到了最后。

三、Presentation分析

不过实际presenting过程,我依然超时了:(了,整个presentation过程并不顺利。

  • 首先是大会的屏幕分辨率似乎有些问题,slide的标题部分根本没有显示出来,这直接导致在座的gopher们看不清我的思路体系,内容让人感觉突兀。就像知乎上ezbuy 翁总的“批评”:“不知为何说变量统计”。
  • 其次,不得不承认自己在千人面前speaking,的确紧张紧张紧张啊,尤其是初期,节奏变慢,有些东西没有讲出来,可能会让在座观众感觉思路有跳跃;
  • 再次,也许gopher们更关心编程思维下的具体展现,也就是后面的代码部分,但由于前面节奏控制不好,铺垫部分有些多了,占用了大量时间,而导致后面代码部分讲解非常快。
  • 再再次,每个会场的gopher的关注点不同,一些gopher可能更喜欢像“微服务实战”这样的一些关于他们目前所遇到问题的解决方案的topic。
  • 最后,话题大,不够聚焦。自己准备这类规模大会topic时的经验还是不足。即便讲语言本身,也应该聚焦,就像Dave CheneyFrancesc Campoy的topic那样,只把一个事情的来龙去脉讲透。

纵观前两届gopherchina大会,国人讲关于Go语言自身层面topic的比例较低,甚至可以用凤毛麟角来形容。更多topic集中在某一业务领域的产品、架构、原理和工程上的实践等。我并不是说这些topic不好,毕竟像GopherChina这样规模的大会需要topic的多样性。只是这一届我要挑战一下自己,虽然结果不是那么理想。

不过,即便被吐槽,其实也没什么,说明和优秀的Go讲师相比,自己的确是有差距的。有差距就努力去弥补呗。如果下一届还有机会分享,我还会分享与Go语言相关的topic,只是要吸取经验,更加聚焦。

四、回复吐槽

在这里也回复一下几个gopher的吐槽:

1、”过度吹捧Go”

我真想不出为何这位Gopher能有这种想法。

首先在Gopher大会上,说Go肯定是没问题的。我从来都说Go是一门牛逼的语言,但从来没说Go是最好的语言。
至于所谓的上升到“价值观”的层面,那是对一门编程语言本质上的探讨,是对Go代码设计思维本源的思考,无关吹捧或不吹捧。
任何一门编程语言都有设计者自己背后的理解和选择,都可以上升到价值观。

不过我不能否认的是上升到编程语言价值观这个层次,是需要一定编程语言积累的。所以初学者体会不到也是正常的。慢慢来:)

2、“一些模凝两可的结论”

我不知道这个“吐槽”的原因是否是因为我在talk开始时说了几句谦虚的话。但谦虚并不代表模棱两可。slide中的所有结论都是我思考后的结果,这种东西本身就是主观的,这又不是数学,需要有精密的证明过程。但我在表达这些观点时一直都是坚定的。不知道在这位gopher心中,萨丕尔-沃夫假说是否也算是模棱两可的结论呢?

我的确希望这个topic能作为一次“抛砖引玉”,让广大gopher一起深层次理解语言设计者的初衷以及go设计过程中的一些考虑和认知,能让我们更好的使用Go语言。你可以补充,可以针对某个观点反驳,但你要拿出你的思考过程。如果能说服我,说服大家,那我就认同。这次的分享就是我的思考过程,绝不是模棱两可。

小结

最后,十分感谢AstaXie,没有他就没有GopherChina!希望今后的GopherChina大会越办越好,希望Go基金会越做越大!

gopherchina 2017所有讲师的slide已经放出,可以在这里下载。

我个人的talk slide在这里可以下载。

img{512x368}
GopherChina会场周围的美丽景色

img{512x368}
与GopherChina mascot合影

img{512x368}
演讲中


微博:@tonybai_cn
微信公众号:iamtonybai
github.com: https://github.com/bigwhite

GopherChina讲师专访

今年有幸收到GopherChina大会的组织者、beego开源项目的owner、《Go Web编程》的作者谢孟军童鞋的邀请,以讲师身份参加今年的GopherChina大会。下面是GopherChina对我这个讲师的专访稿^0^。该专访稿将同时被发布在公众号“Go中国(微信号:golangchina)”上面,可点击这里阅读。

1、首先介绍一下自己。

大家好!我叫白明(Tony Bai),目前是东软云科技的一名架构师,专职于服务端开发,日常工作主要使用Go语言。我算是国内较早接触Go语言的程序员兼Advocater了,平时在我的博客微博和微信公众号“iamtonybai”上经常发表一些关于Go语言的文章和Go生态圈内的信息。

在接触Go之前,我主要使用C语言开发电信领域的一些后端服务系统,拥有多年的电信领域产品研发和技术管理经验。我个人比较喜换钻研和分享技术,是《七周七语言》一书的译者之一,并且坚持写技术博客十余年。同时我也算是一个开源爱好者,也在github上分享过自己开发的几个小工具。

目前的主要研究领域包括:GoKubernetesDocker和儿童编程教育等。

2、回忆一下与Golang的渊源。是什么原因决定尝试Golang?自己用Go语言实现的第一个项目是什么?当时 Golang 有什么令人惊喜的表现,又有什么样的小不足,这个不足在Golang已经更新到1.8版本的时候是否已经得到改善?

众所周知,Go语言最初由Robert Griesemer, Ken ThompsonRob Pike在2007年末共同设计和实现,2009年11月份正式发布并开源,并于2012年3月份发布了1.0版本以及Go1规范。我就是在2012年开始接触Go的,那是缘于看到一份由Rob Pike主讲的3-day Go Course资料。从那份资料里,我了解到了Go的设计理念和Go语法。

由于之前浸淫于C语言多年,深知C语言在系统编程以及服务端编程方面的强大,同时也亲身体会到C的语法“陷阱”和C手工内存管理给开发者带来的苦恼。虽然那些年市面上也有其他主流语言可供选择,但在我看来,它们给我带来的心智负担太过沉重,比如:C++“宇宙无敌”的学习和使用复杂性、Java超大的资源消耗和庞大且纷繁芜杂的框架体系、动态语言(rubypython)无静态类型而导致运行时crash时调试的困难、函数式语言(如Haskellclisp)的过于小众和非主流。显然它们都不是我的菜。直到Go的出现,C程序员出身的我一下子就被这门新语言迷住了。

现在想起这件事来,我当时迷上Go应该主要由于以下几点原因:

* 静态类型语言、接近于C的性能(对于C程序员来说,这算是某种天然继承性)
* 简洁的语法
* 内置的并发支持
* GC
* 贯穿整个语言的正交设计和组合编程思路(兼容对OO的支持)
* 工具和功能全面的标准库

而且这几点也是这几年持续支撑我深入学习和使用Go语言的原因。

不过由于Go1刚出来时也十分小众,并且各方面功能还在完善中,我并没有在真实项目中使用Go,这种状况一直持续到2014年末。直到那时,我才在一个小项目中使用Go实现了一个微信公众号的协议接口。当时发现:使用Go实现一些安全协议真是非常方便,因为标准库里内置了很好的支持,比如:各种aes、sha256、tls算法实现。同时,Go内置的testing framework、gofmt、Go pprof工具的表现也是让我感觉用起来十分舒服。

如果非要说当时有什么不足之处的话,那只能是Go对debugging的支持明显不足。即便是到了目前最新的Go 1.8版本,Go在debugging方面虽然有所改善,但和C这样的传统语言来说依然有很大差距。不过好在我们有“print”这个无敌调试武器,Go的这个不足对我影响微乎甚微^0^。

当然随着Go在更多规模稍大项目的使用,Go的包管理问题逐渐浮出水面,这也是整个Go社区都想改进的事情。好在目前已经有了专门的Commitee来做这件事,最新的roadmap显示dep工具将在Go 1.10 dev cycle并入Go tools中。

3、2009年诞生至今,Go语言基本统治了云计算,作为最专业的Go语言专家,您认为这是由于它的哪些优雅的特性?Golang未来还会有什么样的改进和突破?

“作为最专业的Go语言专家”,这一称号的确不敢当。我觉得我个人只是国内Gopher普通一员,能为Go语言在国内的发展做点事情就很高兴了^0^。

Go自从1.5版本自举后,随着ssa优化、GC延迟优化的深入,Go在国内外的使用趋势确实是一片大好,尤其是Go问鼎2016年TIOBE编程语言排行榜的年度语言,让更多的程序员知道Go语言、了解Go语言和使用Go语言。在云计算成为当今IT行业常态的今天,Go在这方面已然成为一个重量级选手。从个人对Go的情感角度出发,我个人是希望Go语言能成为”21世纪的C语言”和云平台第一语言的。不过这是一个过程,需要时间,还需要依靠全世界Gopher和Go Community的共同努力才能实现的。

时代不同,语言的成长环境也有所不同。和上一代和两代的语言似乎有所不同,新一代编程语言是否能进入程序员们的法眼,是否值得程序员去投资,“背景”很重要,即所谓的编程语言也进入了“拼爹”时代。Go语言背靠Google这棵大树,又有Robert Griesemer, Ken Thompson, Rob Pike三巨头坐镇,是真正的“牛二代”,它自然就会得到不少程序员的青睐。我想这是Go吸引眼球的场外因素。

至于Go本身的语言特性,在上一个问题中,我已经做了初步阐述了,这里再补充几点:

* Go是一门以解决Google内部生产环境中的问题(大规模并发服务)为目标的、兼顾在语言设计层面解决一些软件工程问题的面向大规模并发服务的编程语言;
* 开发效率较高(对比主流的C、C++和Java),且执行效率与C相比,没有数量级级别的差异;
* 编译速度超快(相对其他需编译的主流语言),无需喝咖啡等待;
* Go1兼容性的承诺。

Go语言到目前已经演进到1.8版本,Go 1.9开发周期已经打开。今年夏天,Go 1.9发布后,Go似乎就到了版本演进的关键节点,是继续Go1兼容(Go 1.10、Go 1.11…),还是诞生Go2规范,目前并没有明确信息。不过未来的改进和突破,我觉得还是应该建立在Go语言设计的初衷和设计原则之上,这些初衷和原则包括:

目标:
 * 高效的静态编译语言
 * 动态语言的易用性
 * 类型安全和内存安全
 * 对并发和通信的良好支持
 * 高效、低/趋于零延迟的GC
 * 高速编译

原则:

 * 保持概念正交
 * 保持语法简单
 * 保持类型系统精炼,无type hierarchy

从这些年Go的发展来看,基本都是遵循以上目标和原则的。即便Go2出来,不符合上述原则的feature,也是很难加入到Go2里面的。

4、之前是否有关注到Gopher China大会,对大会的风格和内容有什么样的印象?

对于中国大陆地区规模最大,最具影响力的Go大会,我是从第一届就开始关注了,虽然第一届因故没能参加^0^。在去年举行的第二届大会,我是作为早鸟观众参与的哦。而本届则有幸成为讲师。

GopherChina从诞生至今,规模日益扩大,据说今年的参会人员可能突破1000人。而且GopherChina大会从第一届就汇聚了国内一线IT厂商的精英技术人员作为讲师,并得到了Go core team的大力支持。在每一届大会都会邀请到Go team中的核心开发人员参会布道,甚至在第一届大会时还邀请到了Go三巨头之一的Robert Griesemer,极大满足了国内Gopher的求知欲。

而且就我观察,每一届GopherChina大会的主题都涵盖:语言、工程、新兴领域应用等多个环节,颇具多样性和全面性。

5、作为讲师也是参会者,对于今年的Gopher China大会的哪些议题有所期待?

GopherChina每一届都是高手云集,这届也不例外。今年大会的每个议题都令我很是期待。

6、现在很多企业项目都在准备转Go,对于这些项目的负责人有没有建议和经验分享?

Go语言以极易上手著称,同时Go也是一门十分简单的语言(相对于其他主流语言),C、Cpp、Java、Python等程序员转型到Go的曲线并不陡峭,因此团队整体转型为Go的门槛并不高。但还是要有几点是项目负责人需要认真考虑的:

(1) 确认Go适合项目的应用场景

Go不是万能的,不能为了用Go而去用Go。但Go从最初定位为一门系统语言(Sytem Programming Language)逐渐演化成为一门通用语言(General Purpose Programming Language),说明其适应性和应用范围已经十分广泛,目前在云计算、Web开发、大数据、游戏、数据库、IDE、容器等领域均有大规模应用案例。但即便这样,仍然在有些领域的应用需要谨慎,比如嵌入式领域、比如mobile开发,虽然在这两个方面Go都做出了很大的努力,但似乎并没有较大的突破。

(2) 以终为始,从开始就参考Go的最佳实践

Go经过若干年的演化发展,逐渐形成了一些最佳实践,包括:项目代码组织、命名、惯用法、测试方法、错误处理、接口使用等。建议多看官方的talks、blog和世界范围内Go大会的presentation video。

(3) 单元测试全程保障

Go内置了单元测试框架,而单元测试是检验代码设计好坏的基础,也是代码重构的先决条件。建议项目从始至终都要优先考虑对代码编写测试代码。

(4) 充分利用标准库

在Go的应用实践中,你会发现Go标准库已经为你提供了大部分你要使用的功能。甚至有一些极端的Go纯粹主义者只愿意标准库中的函数和方法。Go标准库凝聚了Go team以及相关Contributor的Go代码精华,其稳定性绝对值得信赖。充分和广泛利用标准库也便于项目代码组织、构建和迁移。

(5) 基于go tool建立代码metric视图

对于那些性能敏感的系统,建议在内部环境基于go tool建立起代码的metric视图,监控代码变化给系统性能等带来的影响,利于问题诊断。

最后,请及时反馈Go语言自身问题,你的反馈是Go语言演化的动力

7、有没有你觉得很酷的Gopher?可以回答自己哟~

在github.com/golang/go上,我经常关注Russ Cox的代码。众所周知,Russ Cox是Go核心代码提交次数最多的member,他也除三巨头之外,对Go演化影响着最大的人之一。从近两年的Go team开发活动来看,Russ Cox开发效率很高,并且提出的proposal思维之缜密和全面令人叹服。

Dave Cheney是另一个我经常关注的Gopher,他也是第二届GopherChina大会的受邀讲师。他不遗余力的“鼓吹”Go,并从Go 1.6版本开始,发起了Go Global release party ,成为Go Community又一个节日。他不仅是Go community中的意见领袖,同时也为Go社区贡献不少有用的工具和思想,包括:gberrors等。

Dmitry Vyukov,前Intel Black Belt级工程师,现Google员工,虽然他不是专职Go team的人,但他却是Go scheduler当前版本的核心实现者。虽然近两年似乎在golang的投入并不是那么多,但依然成果丰硕,Go Execution Tracergo-fuzz(据说要加入go核心)都是他的杰作。


微博:@tonybai_cn
微信公众号:iamtonybai
github.com: https://github.com/bigwhite

使用Fluentd和ElasticSearch Stack实现Kubernetes的集群Logging

在本篇文章中,我们继续来说Kubernetes

经过一段时间的探索,我们先后完成了Kubernetes集群搭建DNSDashboardHeapster等插件安装,集群安全配置,搭建作为Persistent Volume的CephRBD,以及服务更新探索和实现工作。现在Kubernetes集群层面的Logging需求逐渐浮上水面了。

随着一些小应用在我们的Kubernetes集群上的部署上线,集群的运行迈上了正轨。但问题随之而来,那就是如何查找和诊断集群自身的问题以及运行于Pod中应用的问题。日志,没错!我们也只能依赖Kubernetes组件以及Pod中应用输出的日志。不过目前我们仅能通过kubectl logs命令或Kubernetes Dashboard来查看Log。在没有cluster level logging的情况下,我们需要分别查看各个Pod的日志,操作繁琐,过程低效。我们迫切地需要为Kubernetes集群搭建一套集群级别的集中日志收集和分析设施。

对于任何基础设施或后端服务系统,日志都是极其重要的。对于受Google内部容器管理系统Borg启发而催生出的Kubernetes项目来说,自然少不了对Logging的支持。在“Logging Overview“中,官方概要介绍了Kubernetes上的几个层次的Logging方案,并给出Cluster-level logging的参考架构:

img{512x368}

Kubernetes还给出了参考实现:
– Logging Backend:Elastic Search stack(包括:Kibana)
– Logging-agent:fluentd

ElasticSearch stack实现的cluster level logging的一个优势在于其对Kubernetes集群中的Pod没有侵入性,Pod无需做任何配合性改动。同时EFK/ELK方案在业内也是相对成熟稳定的。

在本文中,我将为我们的Kubernetes 1.3.7集群安装ElasticSearch、Fluentd和Kibana。由于1.3.7版本略有些old,EFK能否在其上面run起来,我也是心中未知。能否像《生化危机:终章》那样有一个完美的结局,我们还需要一步一步“打怪升级”慢慢看。

一、Kubernetes 1.3.7集群的 “漏网之鱼”

Kubernetes 1.3.7集群是通过kube-up.sh搭建并初始化的。按照K8s官方文档有关elasticsearch logging的介绍,在kubernetes/cluster/ubuntu/config-default.sh中,我也发现了下面几个配置项:

// kubernetes/cluster/ubuntu/config-default.sh
# Optional: Enable node logging.
ENABLE_NODE_LOGGING=false
LOGGING_DESTINATION=${LOGGING_DESTINATION:-elasticsearch}

# Optional: When set to true, Elasticsearch and Kibana will be setup as part of the cluster bring up.
ENABLE_CLUSTER_LOGGING=false
ELASTICSEARCH_LOGGING_REPLICAS=${ELASTICSEARCH_LOGGING_REPLICAS:-1}

显然,当初如果搭建集群伊始时要是知道这些配置的意义,可能那个时候就会将elastic logging集成到集群中了。现在为时已晚,集群上已经跑了很多应用,无法重新通过kube-up.sh中断集群运行并安装elastic logging了。我只能手工进行安装了!

二、镜像准备

1.3.7源码中kubernetes/cluster/addons/fluentd-elasticsearch下的manifest已经比较old了,我们直接使用kubernetes最新源码中的manifest文件

k8s.io/kubernetes/cluster/addons/fluentd-elasticsearch$ ls *.yaml
es-controller.yaml  es-service.yaml  fluentd-es-ds.yaml  kibana-controller.yaml  kibana-service.yaml

分析这些yaml,我们需要三个镜像:

 gcr.io/google_containers/fluentd-elasticsearch:1.22
 gcr.io/google_containers/elasticsearch:v2.4.1-1
 gcr.io/google_containers/kibana:v4.6.1-1

显然镜像都在墙外。由于生产环境下的Docker引擎并没有配置加速器代理,因此我们需要手工下载一下这三个镜像。我采用的方法是通过另外一台配置了加速器的机器上的Docker引擎将三个image下载,并重新打tag,上传到我在hub.docker.com上的账号下,以elasticsearch:v2.4.1-1为例:

# docker pull  gcr.io/google_containers/elasticsearch:v2.4.1-1
# docker tag gcr.io/google_containers/elasticsearch:v2.4.1-1 bigwhite/elasticsearch:v2.4.1-1
# docker push bigwhite/elasticsearch:v2.4.1-1

下面是我们在后续安装过程中真正要使用到的镜像:

bigwhite/fluentd-elasticsearch:1.22
bigwhite/elasticsearch:v2.4.1-1
bigwhite/kibana:v4.6.1-1

三、启动fluentd

fluentd是以DaemonSet的形式跑在K8s集群上的,这样k8s可以保证每个k8s cluster node上都会启动一个fluentd(注意:将image改为上述镜像地址,如果你配置了加速器,那自然就不必了)。

# kubectl create -f fluentd-es-ds.yaml --record
daemonset "fluentd-es-v1.22" created

查看daemonset中的Pod的启动情况,我们发现:

kube-system                  fluentd-es-v1.22-as3s5                  0/1       CrashLoopBackOff   2          43s       172.16.99.6    10.47.136.60
kube-system                  fluentd-es-v1.22-qz193                  0/1       CrashLoopBackOff   2          43s       172.16.57.7    10.46.181.146

fluentd Pod启动失败,fluentd的日志可以通过/var/log/fluentd.log查看:

# tail -100f /var/log/fluentd.log

2017-03-02 02:27:01 +0000 [info]: reading config file path="/etc/td-agent/td-agent.conf"
2017-03-02 02:27:01 +0000 [info]: starting fluentd-0.12.31
2017-03-02 02:27:01 +0000 [info]: gem 'fluent-mixin-config-placeholders' version '0.4.0'
2017-03-02 02:27:01 +0000 [info]: gem 'fluent-mixin-plaintextformatter' version '0.2.6'
2017-03-02 02:27:01 +0000 [info]: gem 'fluent-plugin-docker_metadata_filter' version '0.1.3'
2017-03-02 02:27:01 +0000 [info]: gem 'fluent-plugin-elasticsearch' version '1.5.0'
2017-03-02 02:27:01 +0000 [info]: gem 'fluent-plugin-kafka' version '0.4.1'
2017-03-02 02:27:01 +0000 [info]: gem 'fluent-plugin-kubernetes_metadata_filter' version '0.24.0'
2017-03-02 02:27:01 +0000 [info]: gem 'fluent-plugin-mongo' version '0.7.16'
2017-03-02 02:27:01 +0000 [info]: gem 'fluent-plugin-rewrite-tag-filter' version '1.5.5'
2017-03-02 02:27:01 +0000 [info]: gem 'fluent-plugin-s3' version '0.8.0'
2017-03-02 02:27:01 +0000 [info]: gem 'fluent-plugin-scribe' version '0.10.14'
2017-03-02 02:27:01 +0000 [info]: gem 'fluent-plugin-td' version '0.10.29'
2017-03-02 02:27:01 +0000 [info]: gem 'fluent-plugin-td-monitoring' version '0.2.2'
2017-03-02 02:27:01 +0000 [info]: gem 'fluent-plugin-webhdfs' version '0.4.2'
2017-03-02 02:27:01 +0000 [info]: gem 'fluentd' version '0.12.31'
2017-03-02 02:27:01 +0000 [info]: adding match pattern="fluent.**" type="null"
2017-03-02 02:27:01 +0000 [info]: adding filter pattern="kubernetes.**" type="kubernetes_metadata"
2017-03-02 02:27:02 +0000 [error]: config error file="/etc/td-agent/td-agent.conf" error="Invalid Kubernetes API v1 endpoint https://192.168.3.1:443/api: 401 Unauthorized"
2017-03-02 02:27:02 +0000 [info]: process finished code=256
2017-03-02 02:27:02 +0000 [warn]: process died within 1 second. exit.

从上述日志中的error来看:fluentd访问apiserver secure port(443)出错了:Unauthorized! 通过分析 cluster/addons/fluentd-elasticsearch/fluentd-es-image/build.sh和td-agent.conf,我们发现是fluentd image中的fluent-plugin-kubernetes_metadata_filter要去访问API Server以获取一些kubernetes的metadata信息。不过未做任何特殊配置的fluent-plugin-kubernetes_metadata_filter,我猜测它使用的是kubernetes为Pod传入的环境变量:KUBERNETES_SERVICE_HOST和KUBERNETES_SERVICE_PORT来得到API Server的访问信息的。但API Server在secure port上是开启了安全身份验证机制的,fluentd直接访问必然是失败的。

我们找到了fluent-plugin-kubernetes_metadata_filter项目在github.com上的主页,在这个页面上我们看到了fluent-plugin-kubernetes_metadata_filter支持的其他配置,包括:ca_file、client_cert、client_key等,显然这些字眼非常眼熟。我们需要修改一下fluentd image中td-agent.conf的配置,为fluent-plugin-kubernetes_metadata_filter增加一些配置项,比如:

// td-agent.conf
... ...
<filter kubernetes.**>
  type kubernetes_metadata
  ca_file /srv/kubernetes/ca.crt
  client_cert /srv/kubernetes/kubecfg.crt
  client_key /srv/kubernetes/kubecfg.key
</filter>
... ...

这里我不想重新制作image,那么怎么办呢?Kubernetes提供了ConfigMap这一强大的武器,我们可以将新版td-agent.conf制作成kubernetes的configmap资源,并挂载到fluentd pod的相应位置以替换image中默认的td-agent.conf。

需要注意两点:
* 在基于td-agent.conf创建configmap资源之前,需要将td-agent.conf中的注释行都删掉,否则生成的configmap的内容可能不正确;
* fluentd pod将创建在kube-system下,因此configmap资源也需要创建在kube-system namespace下面,否则kubectl create无法找到对应的configmap。

# kubectl create configmap td-agent-config --from-file=./td-agent.conf -n kube-system
configmap "td-agent-config" created

# kubectl get configmaps -n kube-system
NAME              DATA      AGE
td-agent-config   1         9s

# kubectl get configmaps td-agent-config -o yaml
apiVersion: v1
data:
  td-agent.conf: |
    <match fluent.**>
      type null
    </match>

    <source>
      type tail
      path /var/log/containers/*.log
      pos_file /var/log/es-containers.log.pos
      time_format %Y-%m-%dT%H:%M:%S.%NZ
      tag kubernetes.*
      format json
      read_from_head true
    </source>
... ...

fluentd-es-ds.yaml也要随之做一些改动,主要是增加两个mount: 一个是mount 上面的configmap td-agent-config,另外一个就是mount hostpath:/srv/kubernetes以获取到相关client端的数字证书:

  spec:
      containers:
      - name: fluentd-es
        image: bigwhite/fluentd-elasticsearch:1.22
        command:
          - '/bin/sh'
          - '-c'
          - '/usr/sbin/td-agent 2>&1 >> /var/log/fluentd.log'
        resources:
          limits:
            memory: 200Mi
          #requests:
            #cpu: 100m
            #memory: 200Mi
        volumeMounts:
        - name: varlog
          mountPath: /var/log
        - name: varlibdockercontainers
          mountPath: /var/lib/docker/containers
          readOnly: true
        - name: td-agent-config
          mountPath: /etc/td-agent
        - name: tls-files
          mountPath: /srv/kubernetes
      terminationGracePeriodSeconds: 30
      volumes:
      - name: varlog
        hostPath:
          path: /var/log
      - name: varlibdockercontainers
        hostPath:
          path: /var/lib/docker/containers
      - name: td-agent-config
        configMap:
          name: td-agent-config
      - name: tls-files
        hostPath:
          path: /srv/kubernetes

接下来,我们重新创建fluentd ds,步骤不赘述。这回我们的创建成功了:

kube-system                  fluentd-es-v1.22-adsrx                  1/1       Running    0          1s        172.16.99.6    10.47.136.60
kube-system                  fluentd-es-v1.22-rpme3                  1/1       Running    0          1s        172.16.57.7    10.46.181.146

但通过查看/var/log/fluentd.log,我们依然能看到“问题”:

2017-03-02 03:57:58 +0000 [warn]: temporarily failed to flush the buffer. next_retry=2017-03-02 03:57:59 +0000 error_class="Fluent::ElasticsearchOutput::ConnectionFailure" error="Can not reach Elasticsearch cluster ({:host=>\"elasticsearch-logging\", :port=>9200, :scheme=>\"http\"})!" plugin_id="object:3fd99fa857d8"
  2017-03-02 03:57:58 +0000 [warn]: suppressed same stacktrace
2017-03-02 03:58:00 +0000 [warn]: temporarily failed to flush the buffer. next_retry=2017-03-02 03:58:03 +0000 error_class="Fluent::ElasticsearchOutput::ConnectionFailure" error="Can not reach Elasticsearch cluster ({:host=>\"elasticsearch-logging\", :port=>9200, :scheme=>\"http\"})!" plugin_id="object:3fd99fa857d8"
2017-03-02 03:58:00 +0000 [info]: process finished code=9
2017-03-02 03:58:00 +0000 [error]: fluentd main process died unexpectedly. restarting.

由于ElasticSearch logging还未创建,这是连不上elasticsearch所致。

四、启动elasticsearch

启动elasticsearch:

# kubectl create -f es-controller.yaml
replicationcontroller "elasticsearch-logging-v1" created

# kubectl create -f es-service.yaml
service "elasticsearch-logging" created

get pods:

kube-system                  elasticsearch-logging-v1-3bzt6          1/1       Running    0          7s        172.16.57.8    10.46.181.146
kube-system                  elasticsearch-logging-v1-nvbe1          1/1       Running    0          7s        172.16.99.10   10.47.136.60

elastic search logging启动成功后,上述fluentd的fail日志就没有了!

不过elastic search真的运行ok了么?我们查看一下elasticsearch相关Pod日志:

# kubectl logs -f elasticsearch-logging-v1-3bzt6 -n kube-system
F0302 03:59:41.036697       8 elasticsearch_logging_discovery.go:60] kube-system namespace doesn't exist: the server has asked for the client to provide credentials (get namespaces kube-system)
goroutine 1 [running]:
k8s.io/kubernetes/vendor/github.com/golang/glog.stacks(0x19a8100, 0xc400000000, 0xc2, 0x186)
... ...
main.main()
    elasticsearch_logging_discovery.go:60 +0xb53

[2017-03-02 03:59:42,587][INFO ][node                     ] [elasticsearch-logging-v1-3bzt6] version[2.4.1], pid[16], build[c67dc32/2016-09-27T18:57:55Z]
[2017-03-02 03:59:42,588][INFO ][node                     ] [elasticsearch-logging-v1-3bzt6] initializing ...
[2017-03-02 03:59:44,396][INFO ][plugins                  ] [elasticsearch-logging-v1-3bzt6] modules [reindex, lang-expression, lang-groovy], plugins [], sites []
... ...
[2017-03-02 03:59:44,441][INFO ][env                      ] [elasticsearch-logging-v1-3bzt6] heap size [1007.3mb], compressed ordinary object pointers [true]
[2017-03-02 03:59:48,355][INFO ][node                     ] [elasticsearch-logging-v1-3bzt6] initialized
[2017-03-02 03:59:48,355][INFO ][node                     ] [elasticsearch-logging-v1-3bzt6] starting ...
[2017-03-02 03:59:48,507][INFO ][transport                ] [elasticsearch-logging-v1-3bzt6] publish_address {172.16.57.8:9300}, bound_addresses {[::]:9300}
[2017-03-02 03:59:48,547][INFO ][discovery                ] [elasticsearch-logging-v1-3bzt6] kubernetes-logging/7_f_M2TKRZWOw4NhBc4EqA
[2017-03-02 04:00:18,552][WARN ][discovery                ] [elasticsearch-logging-v1-3bzt6] waited for 30s and no initial state was set by the discovery
[2017-03-02 04:00:18,562][INFO ][http                     ] [elasticsearch-logging-v1-3bzt6] publish_address {172.16.57.8:9200}, bound_addresses {[::]:9200}
[2017-03-02 04:00:18,562][INFO ][node                     ] [elasticsearch-logging-v1-3bzt6] started
[2017-03-02 04:01:15,754][WARN ][discovery.zen.ping.unicast] [elasticsearch-logging-v1-3bzt6] failed to send ping to [{#zen_unicast_1#}{127.0.0.1}{127.0.0.1:9300}]
SendRequestTransportException[[][127.0.0.1:9300][internal:discovery/zen/unicast]]; nested: NodeNotConnectedException[[][127.0.0.1:9300] Node not connected];
... ...
Caused by: NodeNotConnectedException[[][127.0.0.1:9300] Node not connected]
    at org.elasticsearch.transport.netty.NettyTransport.nodeChannel(NettyTransport.java:1141)
    at org.elasticsearch.transport.netty.NettyTransport.sendRequest(NettyTransport.java:830)
    at org.elasticsearch.transport.TransportService.sendRequest(TransportService.java:329)
    ... 12 more

总结了一下,日志中有两个错误:
- 无法访问到API Server,这个似乎和fluentd最初的问题一样;
- elasticsearch两个节点间互ping失败。

要想找到这两个问题的原因,还得回到源头,去分析elastic search image的组成。

通过cluster/addons/fluentd-elasticsearch/es-image/run.sh文件内容:

/elasticsearch_logging_discovery >> /elasticsearch/config/elasticsearch.yml

chown -R elasticsearch:elasticsearch /data

/bin/su -c /elasticsearch/bin/elasticsearch elasticsearch

我们了解到image中,其实包含了两个程序,一个为/elasticsearch_logging_discovery,该程序执行后生成一个配置文件: /elasticsearch/config/elasticsearch.yml。该配置文件后续被另外一个程序:/elasticsearch/bin/elasticsearch使用。

我们查看一下已经运行的docker中的elasticsearch.yml文件内容:

# docker exec 3cad31f6eb08 cat /elasticsearch/config/elasticsearch.yml
cluster.name: kubernetes-logging

node.name: ${NODE_NAME}
node.master: ${NODE_MASTER}
node.data: ${NODE_DATA}

transport.tcp.port: ${TRANSPORT_PORT}
http.port: ${HTTP_PORT}

path.data: /data

network.host: 0.0.0.0

discovery.zen.minimum_master_nodes: ${MINIMUM_MASTER_NODES}
discovery.zen.ping.multicast.enabled: false

这个结果中缺少了一项:

discovery.zen.ping.unicast.hosts: ["172.30.0.11", "172.30.192.15"]

这也是导致第二个问题的原因。综上,elasticsearch logging的错误其实都是由于/elasticsearch_logging_discovery无法访问API Server导致 /elasticsearch/config/elasticsearch.yml没有被正确生成造成的,我们就来解决这个问题。

我查看了一下/elasticsearch_logging_discovery的源码,elasticsearch_logging_discovery是一个典型通过client-go通过service account访问API Server的程序,很显然这就是我在《在Kubernetes Pod中使用Service Account访问API Server》一文中提到的那个问题:默认的service account不好用。

解决方法:在kube-system namespace下创建一个新的service account资源,并在es-controller.yaml中显式使用该新创建的service account。

创建一个新的serviceaccount在kube-system namespace下:

//serviceaccount.yaml
apiVersion: v1
kind: ServiceAccount
metadata:
  name: k8s-efk

# kubectl create -f serviceaccount.yaml -n kube-system
serviceaccount "k8s-efk" created

# kubectl get serviceaccount -n kube-system
NAME      SECRETS   AGE
default   1         139d
k8s-efk   1         17s

在es-controller.yaml中,使用service account “k8s-efk”:

//es-controller.yaml
... ...
spec:
  replicas: 2
  selector:
    k8s-app: elasticsearch-logging
    version: v1
  template:
    metadata:
      labels:
        k8s-app: elasticsearch-logging
        version: v1
        kubernetes.io/cluster-service: "true"
    spec:
      serviceAccount: k8s-efk
      containers:
... ...

重新创建elasticsearch logging service后,我们再来查看elasticsearch-logging pod的日志:

# kubectl logs -f elasticsearch-logging-v1-dklui -n kube-system
[2017-03-02 08:26:46,500][INFO ][node                     ] [elasticsearch-logging-v1-dklui] version[2.4.1], pid[14], build[c67dc32/2016-09-27T18:57:55Z]
[2017-03-02 08:26:46,504][INFO ][node                     ] [elasticsearch-logging-v1-dklui] initializing ...
[2017-03-02 08:26:47,984][INFO ][plugins                  ] [elasticsearch-logging-v1-dklui] modules [reindex, lang-expression, lang-groovy], plugins [], sites []
[2017-03-02 08:26:48,073][INFO ][env                      ] [elasticsearch-logging-v1-dklui] using [1] data paths, mounts [[/data (/dev/vda1)]], net usable_space [16.9gb], net total_space [39.2gb], spins? [possibly], types [ext4]
[2017-03-02 08:26:48,073][INFO ][env                      ] [elasticsearch-logging-v1-dklui] heap size [1007.3mb], compressed ordinary object pointers [true]
[2017-03-02 08:26:53,241][INFO ][node                     ] [elasticsearch-logging-v1-dklui] initialized
[2017-03-02 08:26:53,241][INFO ][node                     ] [elasticsearch-logging-v1-dklui] starting ...
[2017-03-02 08:26:53,593][INFO ][transport                ] [elasticsearch-logging-v1-dklui] publish_address {172.16.57.8:9300}, bound_addresses {[::]:9300}
[2017-03-02 08:26:53,651][INFO ][discovery                ] [elasticsearch-logging-v1-dklui] kubernetes-logging/Ky_OuYqMRkm_918aHRtuLg
[2017-03-02 08:26:56,736][INFO ][cluster.service          ] [elasticsearch-logging-v1-dklui] new_master {elasticsearch-logging-v1-dklui}{Ky_OuYqMRkm_918aHRtuLg}{172.16.57.8}{172.16.57.8:9300}{master=true}, added {{elasticsearch-logging-v1-vjxm3}{cbzgrfZATyWkHfQYHZhs7Q}{172.16.99.10}{172.16.99.10:9300}{master=true},}, reason: zen-disco-join(elected_as_master, [1] joins received)
[2017-03-02 08:26:56,955][INFO ][http                     ] [elasticsearch-logging-v1-dklui] publish_address {172.16.57.8:9200}, bound_addresses {[::]:9200}
[2017-03-02 08:26:56,956][INFO ][node                     ] [elasticsearch-logging-v1-dklui] started
[2017-03-02 08:26:57,157][INFO ][gateway                  ] [elasticsearch-logging-v1-dklui] recovered [0] indices into cluster_state
[2017-03-02 08:27:05,378][INFO ][cluster.metadata         ] [elasticsearch-logging-v1-dklui] [logstash-2017.03.02] creating index, cause [auto(bulk api)], templates [], shards [5]/[1], mappings []
[2017-03-02 08:27:06,360][INFO ][cluster.metadata         ] [elasticsearch-logging-v1-dklui] [logstash-2017.03.01] creating index, cause [auto(bulk api)], templates [], shards [5]/[1], mappings []
[2017-03-02 08:27:07,163][INFO ][cluster.routing.allocation] [elasticsearch-logging-v1-dklui] Cluster health status changed from [RED] to [YELLOW] (reason: [shards started [[logstash-2017.03.01][3], [logstash-2017.03.01][3]] ...]).
[2017-03-02 08:27:07,354][INFO ][cluster.metadata         ] [elasticsearch-logging-v1-dklui] [logstash-2017.03.02] create_mapping [fluentd]
[2017-03-02 08:27:07,988][INFO ][cluster.metadata         ] [elasticsearch-logging-v1-dklui] [logstash-2017.03.01] create_mapping [fluentd]
[2017-03-02 08:27:09,578][INFO ][cluster.routing.allocation] [elasticsearch-logging-v1-dklui] Cluster health status changed from [YELLOW] to [GREEN] (reason: [shards started [[logstash-2017.03.02][4]] ...]).

elasticsearch logging启动运行ok!

五、启动kibana

有了elasticsearch logging的“前车之鉴”,这次我们也把上面新创建的serviceaccount:k8s-efk显式赋值给kibana-controller.yaml:

//kibana-controller.yaml
... ...
spec:
      serviceAccount: k8s-efk
      containers:
      - name: kibana-logging
        image: bigwhite/kibana:v4.6.1-1
        resources:
          # keep request = limit to keep this container in guaranteed class
          limits:
            cpu: 100m
          #requests:
          #  cpu: 100m
        env:
          - name: "ELASTICSEARCH_URL"
            value: "http://elasticsearch-logging:9200"
          - name: "KIBANA_BASE_URL"
            value: "/api/v1/proxy/namespaces/kube-system/services/kibana-logging"
        ports:
        - containerPort: 5601
          name: ui
          protocol: TCP
... ...

启动kibana,并观察pod日志:

# kubectl create -f kibana-controller.yaml
# kubectl create -f kibana-service.yaml
# kubectl logs -f kibana-logging-3604961973-jby53 -n kube-system
ELASTICSEARCH_URL=http://elasticsearch-logging:9200
server.basePath: /api/v1/proxy/namespaces/kube-system/services/kibana-logging
{"type":"log","@timestamp":"2017-03-02T08:30:15Z","tags":["info","optimize"],"pid":6,"message":"Optimizing and caching bundles for kibana and statusPage. This may take a few minutes"}

kibana缓存着实需要一段时间,请耐心等待!可能是几分钟。之后你将会看到如下日志:

# kubectl logs -f kibana-logging-3604961973-jby53 -n kube-system
ELASTICSEARCH_URL=http://elasticsearch-logging:9200
server.basePath: /api/v1/proxy/namespaces/kube-system/services/kibana-logging
{"type":"log","@timestamp":"2017-03-02T08:30:15Z","tags":["info","optimize"],"pid":6,"message":"Optimizing and caching bundles for kibana and statusPage. This may take a few minutes"}
{"type":"log","@timestamp":"2017-03-02T08:40:04Z","tags":["info","optimize"],"pid":6,"message":"Optimization of bundles for kibana and statusPage complete in 588.60 seconds"}
{"type":"log","@timestamp":"2017-03-02T08:40:04Z","tags":["status","plugin:kibana@1.0.0","info"],"pid":6,"state":"green","message":"Status changed from uninitialized to green - Ready","prevState":"uninitialized","prevMsg":"uninitialized"}
{"type":"log","@timestamp":"2017-03-02T08:40:05Z","tags":["status","plugin:elasticsearch@1.0.0","info"],"pid":6,"state":"yellow","message":"Status changed from uninitialized to yellow - Waiting for Elasticsearch","prevState":"uninitialized","prevMsg":"uninitialized"}
{"type":"log","@timestamp":"2017-03-02T08:40:05Z","tags":["status","plugin:kbn_vislib_vis_types@1.0.0","info"],"pid":6,"state":"green","message":"Status changed from uninitialized to green - Ready","prevState":"uninitialized","prevMsg":"uninitialized"}
{"type":"log","@timestamp":"2017-03-02T08:40:05Z","tags":["status","plugin:markdown_vis@1.0.0","info"],"pid":6,"state":"green","message":"Status changed from uninitialized to green - Ready","prevState":"uninitialized","prevMsg":"uninitialized"}
{"type":"log","@timestamp":"2017-03-02T08:40:05Z","tags":["status","plugin:metric_vis@1.0.0","info"],"pid":6,"state":"green","message":"Status changed from uninitialized to green - Ready","prevState":"uninitialized","prevMsg":"uninitialized"}
{"type":"log","@timestamp":"2017-03-02T08:40:06Z","tags":["status","plugin:spyModes@1.0.0","info"],"pid":6,"state":"green","message":"Status changed from uninitialized to green - Ready","prevState":"uninitialized","prevMsg":"uninitialized"}
{"type":"log","@timestamp":"2017-03-02T08:40:06Z","tags":["status","plugin:statusPage@1.0.0","info"],"pid":6,"state":"green","message":"Status changed from uninitialized to green - Ready","prevState":"uninitialized","prevMsg":"uninitialized"}
{"type":"log","@timestamp":"2017-03-02T08:40:06Z","tags":["status","plugin:table_vis@1.0.0","info"],"pid":6,"state":"green","message":"Status changed from uninitialized to green - Ready","prevState":"uninitialized","prevMsg":"uninitialized"}
{"type":"log","@timestamp":"2017-03-02T08:40:06Z","tags":["listening","info"],"pid":6,"message":"Server running at http://0.0.0.0:5601"}
{"type":"log","@timestamp":"2017-03-02T08:40:11Z","tags":["status","plugin:elasticsearch@1.0.0","info"],"pid":6,"state":"yellow","message":"Status changed from yellow to yellow - No existing Kibana index found","prevState":"yellow","prevMsg":"Waiting for Elasticsearch"}
{"type":"log","@timestamp":"2017-03-02T08:40:14Z","tags":["status","plugin:elasticsearch@1.0.0","info"],"pid":6,"state":"green","message":"Status changed from yellow to green - Kibana index ready","prevState":"yellow","prevMsg":"No existing Kibana index found"}

接下来,通过浏览器访问下面地址就可以访问kibana的web页面了,注意:Kinaba的web页面加载也需要一段时间。

https://{API Server external IP}:{API Server secure port}/api/v1/proxy/namespaces/kube-system/services/kibana-logging/app/kibana#/settings/indices/

下面是创建一个index(相当于mysql中的一个database)页面:

img{512x368}

取消“Index contains time-based events”,然后点击“Create”即可创建一个Index。

点击页面上的”Setting” -> “Status”,可以查看当前elasticsearch logging的整体状态,如果一切ok,你将会看到下图这样的页面:

img{512x368}

创建Index后,可以在Discover下看到ElasticSearch logging中汇聚的日志:

img{512x368}

六、小结

以上就是在Kubernetes 1.3.7集群上安装Fluentd和ElasticSearch stack,实现kubernetes cluster level logging的过程。在使用kubeadm安装的Kubernetes 1.5.1环境下安装这些,则基本不会遇到上述这些问题。

另外ElasticSearch logging默认挂载的volume是emptyDir,实验用可以。但要部署在生产环境,必须换成Persistent Volume,比如:CephRBD




这里是Tony Bai的个人Blog,欢迎访问、订阅和留言!订阅Feed请点击上面图片

如果您觉得这里的文章对您有帮助,请扫描上方二维码进行捐赠,加油后的Tony Bai将会为您呈现更多精彩的文章,谢谢!

如果您希望通过比特币或以太币捐赠,可以扫描下方二维码:

比特币:


以太币:


如果您喜欢通过微信App浏览本站内容,可以扫描下方二维码,订阅本站官方微信订阅号“iamtonybai”;点击二维码,可直达本人官方微博主页^_^:



本站Powered by Digital Ocean VPS。

选择Digital Ocean VPS主机,即可获得10美元现金充值,可免费使用两个月哟!

著名主机提供商Linode 10$优惠码:linode10,在这里注册即可免费获得。

阿里云推荐码:1WFZ0V立享9折!

View Tony Bai's profile on LinkedIn


文章

评论

  • 正在加载...

分类

标签

归档











更多