好雨云

Kubernetes自从 1.6 起便号称可以承载5000个以上的节点，但是从数十到5000的路上，难免会遇到问题。 本片文章即分享Open API在kubernetes 5000之路上的经验，包括遇到的问题、尝试解决问题以及找到真正的问题。 遇到的问题以及如何解决 问题一：1 ~ 500个节点之后 问题： kubectl 有时会出现 timeout（p.s. kubectl -v=6 可以显示所有API细节指令） 尝试解决： 一开始以为是kube-apiserver服务器负载的问题，尝试增加proxy做replica协助进行负载均衡 但是超过10个备份master的时候，发现问题不是因为kube-apiserver无法承受负载，GKE通过一台32-core VM就可以承载500个节点 原因： 排除以上原因，开始排查master上剩下的几个服务(etcd、kube-proxy) 开始尝试调整etcd 通过使用 datadog 查看etcd吞吐量，发现有异常延迟(latency spiking ~100 ms) 通过 Fio 工具做性能评估，发现只用到10%的IOPS(Input/Output Per Second)，由于写入延迟(write latency 2ms)降低了性能 尝试把SSD从网络硬盘变为每台机器有个local temp drive（SSD） 结果从~100ms —>

概述 Minio是建立在云原生的基础上；有分布式和共享存储等功能；旨在多租户环境中以可持续的方式进行扩展的对象存储服务。它最适合存储非结构化数据，如：照片、视频、日志文件、容器/虚拟机/映像等，单次存储对象的大小最大可达5TB。 实现架构 单节点 根据存储是否为远端，可直接使用FS或NFS直接操作存储中的Object 调用S3接口，通过Minio使用FS或NFS来操作Object 多节点 多节点的Minio会根据不同的Access_key及Secret_Key来区分不同租户，每个租户可操作对应Server获取Object。Minio Server间可以通过不同的 进程模型 、容器或是虚拟机来互相隔离。 分布式 分布式Minio在无共享架构中根据需求扩展到尽可能多的服务器，所有节点需要使用相同的Access_key及Secret_key来登录。分布式Minio使用Web负载均衡器或DNS轮循(DNS round-robin)，在各服务器之间实现负载均衡。 功能特性 Amazon S3兼容 Minio使用Amazon S3 v2 / v4 API。可以使用Minio SDK，Minio Client，AWS SDK和AWS CLI访问Minio服务器。 数据保护 Minio使用 Minio Erasure Code 来防止硬件故障。也许会损坏一半以上的driver，但是仍然可以从中恢复

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 概述 pinpoint简介 何为pinpoint： pinpoint是一个分析大型分布式系统的平台，提供解决方案来处理海量跟踪数据，主要面向基于tomcat的Java 应用。 **为何使用它：**和如今相比， 过去的因特网的用户数量相对较小，而因特网服务的架构也没那么复杂。web服务通常使用两层(web 服务器和数据库)或三层（web服务器，应用服务器和数据库）架构。然而在如今，随着互联网的成长，需要支持大量的并发连接，并且需要将功能和服务有机结合，导致更加复杂的软件栈组合。更确切地说，比三层层次更多的n层架构变得更加普遍。系统的复杂度因此提升。系统越复杂，越难解决问题，例如系统失败或者性能问题。在三层架构中找到解决方案还不是太难，仅仅需要分析3个组件比如web服务器，应用服务器和数据库，而服务器数量也不多。但是，如果问题发生在n层架构中，就需要调查大量的组件和服务器。另一个问题是仅仅分析单个组件很难看到大局;当发生一个低可见度的问题时，系统复杂度越高，就需要更长的时间来查找原因。最糟糕的是，某些情况下我们甚至可能无法查找出来。为了解决复杂架构下的拓扑解析与性能分析，pinpoint应运而生。 功能、优势与架构 功能 分布式事务跟踪，跟踪跨分布式应用的消息 自动检测应用拓扑，帮助你搞清楚应用的架构

相信大家一定都（没）有使用过Facebook的经验，一定对他的快速改版私毫不陌生，可能早上醒来时发现「赞」的图案突然从实心变从空心，或是开始多了一些缤纷酷炫的功能(像是直播、限时动态..等等)，但你能想像一下吗?在过去十年前，大部份软件服务上的版本更新，都只能像是Office每年的一期一会来做推陈出新，但新的功能可能没解决到用户的痛处，反而增添了更多不必要的麻烦。 所以在快速变迁的时代里，这种快速、持续发布新版本的特性，俨然成为了适性生存的不二法则。你能想像Flicker每天至少会有10次以上的服务发布吗?如果在传统的开发方式，一旦有新功能的释出，如果使用者体验不好需要改进就算了，但如果有BUG的话，却需要等待一个月或一整年的时间才能解决，这样的产品你还会想用吗? 所以与传统开发方法那种大规模的、低频繁的发布，敏捷方法为基础的DevOps，目的就是为了提升了发布频率的速度与效率，从过去的「年」、「季」，提升到「月」、「周」，甚至是「日」。 但快速发布的概念，并非是「开发团队」的步调快速紧凑起来就可以达到的方式，因为每一个新版本的Release，除了靠开发团队的努力外，也需要「维运团队」、「测试团队」的努力，才有办法相辅相成，但通常在公司里「开发」和「维运」都是隶属于不同的部门的业务，开发目标是推陈出新，但维运部门在乎的是系统稳定性及可靠性，在这样两者恒相冲突的状况下

Service Mesh（服务网格）会是今年微服务生态的主角吗？从趋势来看，众多企业正在将这项理微服务复杂性的技术/工具，搬进他们的IT“火药库”之中。 什么是Service Mesh？ 根据Linkerd CEO William Morgan定义，Service Mesh是用于处理服务间通信的基础设施层，用于在云原生应用复杂的服务拓扑中实现可靠的请求传递。在实践中，Service Mesh通常是一组与应用一起部署，但对应用透明的轻量级网络代理。 Service Mesh与传统基础设施层不同之处在于，它形成了一个分布式的互连代理网络，以sidecar形式部署在服务两侧，服务对于代理无感知，且服务间所有通信都由代理进行路由。 为什么需要Service Mesh？ “Smart endpoint and dumb pipes”是微服务架构在集成服务时采用的一个核心理念，这一理念改变了过去臃肿集中的ESB（企业服务总线），无疑是正确方向上的一大进步，但同时也给我们出了一些难题——多智能才不会过于智能，而服务轻重大小的程度如何拿捏？我们应该如何处理微服务系统中服务间交互的复杂性？放在服务内部还是外部？如果是内部，如何处理业务逻辑关系，或者应该与基础设施更为相关？如果是外部，如何避免重蹈ESB的覆辙？ 皮的不谈，先来看看处理服务间通信时需要关注的点： 服务发现 负载均衡 路由 流量控制

Ben Sears Kubernetes是时下最流行的管理和编排工具，它提供了一个配置驱动的框架，让我们可以通过定义和操作获得整个网络、磁盘和应用，并以可伸缩且易于管理的方式进行。 如果我们还没有完成应用容器化，那么把应用转移到Kubernetes上会是一件高强度的工作，本文目的则是介绍应用与Kubernetes集成的方法。 Step 1 — 将应用容器化 容器是可以独立运行的基本操作单元，不同于传统虚拟机依赖模拟操作系统，容器利用各种内核特性来提供与主机隔离的环境。 对于有经验的技术人员来说，整个容器化过程不算复杂——使用docker，定义一个包含安装步骤和配置（下载包、依赖等等）的dockerfile，最后构建一个可以让开发人员使用的镜像即可。 Step 2 — 采用一个多实例架构 在我们把应用迁移到Kubernetes之前，需要确认向最终用户交付的方式。 传统web应用的多租户结构，是所有用户共享单个数据库实例和应用实例，这种形式在Kubernetes中工作没什么问题，但我们建议考虑把应用改造成多实例架构，以充分利用Kubernetes和容器化应用的优势特性。 采用多实例架构的好处包括: 稳定性 ——单点故障，不影响其他实例； 可伸缩 ——通过多实例架构，扩展也就是增加计算资源的事；而对于多租户架构，需要创建集群应用体系结构的部署可能会有些麻烦； 安全性 —

GitHub Octoverse数据以及专家们的一致看好印证了一个事实：开了香槟的Kubernetes并不打算放慢成功的脚步！ 人们在很久以前就展现出了对于Kubernetes的热情，然而这份爱在最近几年急剧升温并且愈演愈烈。过去一年中各路专家的表态也证明了，Kubernetes在管理容器化工作负载和服务方面的领先地位。 大家都在学习Kubernetes，甚至思考KaaS的可能（Kubernetes as an infrastructure），Kubernetes想必会成为我们的“通用语（Lingua Franca）” ——Erkan Yanar, freelance consultant Kubernetes已经在容器编排工具对决中胜出了，它为我们提供了一致、开发、独立的管理和运行工作负载的方式。 ——Nicki Watt, CTO at OpenCredo 除了专家的表态，GitHub Octoverse 2017中的数据也进一步表明，2017年对于Kubernetes来说是一个非常充实和成功的一年。 准确地说，在讨论热度和review榜单中，有三个项目是与Kubernetes相关的。 在社群讨论方面，开发者们在Kubernetes项目中发表了超过388,000条讨论，帮助K8s以巨大优势摘得桂冠。亚军属于另一个基于Kubernetes的项目——Openshift

在过去的一年多时间了里，我们深入了解了容器编排工具，引导团队构建并发布了可以部署在kubernetes上的cloud native GitLab helm chart。对于正在考虑上手Kubernetes的朋友，我们有以下6点建议： 在网上查看文档、在线课程和演示 不要闭门造车，去看看网上的文档和视频演示，这是都是可以让我们快速熟悉和了解Kubernetes的好渠道。我们其实没必要为了用K8s而去煞有介事的参加一整套课程，但是对于某些技术细节，专业的讲解和经验分享无疑是极有帮助的。 当然学以致用的最佳途径还是实际的测试演练，有很多PaaS平台或者Kubernetes工具都有免费的资源或者免费试用期，我们可以在其之上建立并部署一个小集群，尝试、配置、更改……随便玩吧！ 搞明白为什么用Kubernetes 使用Kubernetes的最大挑战之一是想清楚我们要做什么——是作为一个测试round、一个临时环境，还是用于生产？ 仅仅用于开发环境并不复杂，只需要了解一些基本的概念，比如namespace，以及了解什么是secret、什么是configuration、什么是deployment等等，这些概念将在我们的使用过程中贯穿始终。 在Kubernetes上更进一步时，我们需要了解一些之前不存在的东西，比如基于角色的访问控制、RBAC等等。这些功能一年前还没有，但现在正在变得越来越重要

文章来源 Senraの小窝 ，Rainbond团队感谢支持！ 一.介绍 和之前介绍的Crane不同，来自好雨云(GoodRain)的云帮( CloudHelp 目前已改名RainBond)是基于K8S的，说实话，感觉比Crane的开源态度更好点，看得出来是认真在弄的。Crane我发的issue至今无人回复，感觉应该是凉了 关于云帮的定位，可以参考下官方的FAQS Q: 云帮开源版的定位是什么？ A: 中小企业CI/CD平台，生产环境的应用管理平台。云帮不是拉近开发和运维的距离，而是让开发和运维做他们本来应该做的事情。开发对程序和业务负责，运维对资源负责，云帮作为开发和运维的助手。 Q: 发布开源版的目的是什么？ A: 希望能有更多的企业和个人爱好者享受到容器及云计算技术所带来的高效与便利。通过社区版让广大的用户了解云帮产品的设计理念。 Q: 开源版发展规划 A: 云帮是个平台级的产品，即使是开源版我们首要关注的是稳定性，产品设计会本着 功能简洁够用 的原则，降低使用门槛，让用户以最简单的方式来体验容器技术带来的红利。 Q: 云帮企业版是否有生产环境运行的案例？开源版是不是只是演示和测试的“玩具”？ A: 说到这个问题，我想需要明确一下大家判断一项技术或产品在“生产环境” 运行的标准是什么。只有对这个标准或定义明确了，讨论这个问题才有意义。咱们从稳定性、可维护性、扩展性