Kubernetes社区版本最新动态
当前Kubernetes正在准备发布v1.15版本，已经进入Code Freeze阶段。受此影响Kubernetes社区主仓库Master版本合入Pull Request数量减少到 34个，按照Kind分类数量和占比如上图所示。包括了4个API-Change的Pull Request，Feature相关的修改只有1个，Bug和Cleanup所占百分比依旧较高，两项合计达到64%，其中支持Windows相关的Bug较多。
API-Change相关的Pull Request
#78309 API新增Json、Protobuf、Yaml样例文件，用于校验版本的向后兼容性。
#78713从ETCD解码非结构化对象时设置期望的内存版本。
#78553 Remaining Item Count用于返回List请求的剩余资源个数，这里添加Feature Gate。
#78815 在Customer Resource中支持x-kubernetes-int-or-string类型。
Feature相关的部分Pull Request
# 77755 发布Beta版本的卷扩容功能。
Bug相关的部分Pull Request
#78594 修复在Windows上获取容器Metrics时未关闭容器导致的Kubelet内存泄漏。
#78612 解决在Windows上Kube Proxy未检测到HNS网络时Crash的问题。
#78704 删除Windows本地EndPoint的支持，并允许Kubelet在不受支持的操作系统上启动。
#78692 通过暴露两个Flags修复kubeadm upgrade node命令的问题。
#78725 修复ObjectPerPod资源的Replicas数量计算错误的Bug。
云原生一周精选
01
Kubernetes官方发布五周年回顾
截止到2019年6月6号，kubernetes已经诞生了五周年，kubernetes官方发布了关于五周年的回顾，我们一起看一下：
五年前Kubernetes诞生，当时它还很小，功能有限，只有少数人参与到它的创建。现在，五年之后，kubernetes已经获得了长足的发展，如果是孩子的话，五岁的时候可能才刚上幼儿园，但是kubernetes已经作为工作负载的核心为从初创公司到全球金融机构各种各样的领域提供服务。
kubernetes的成功离不开成千上万贡献者的帮助，kubernetes社区从诞生之初的少数开发者到如今数千名贡献者，只用了短短五年的时间。而如果我们将meetup，文档，版本管理，以及更广泛的社区支持囊括进来的话，贡献者会更多。当然，随着项目的迅速发展壮大，社区也在积极的变更组织方式，以支持其继续取得成功。一个项目能够达到这样的规模并且能继续成功运作，这是一项了不起的成就。
五年后，值得思考kubernetes取得的成就，它是最大的开源项目之一，它在数千名来自不同公司的工程师团队中保持快速发展，它已经合并了成千上万的commit且依旧保持高质量版本的定期发布。能做到这一点，对一个公司来说也是不小的成就，更难能可贵的是，这是由来在来自不同公司的成千上万开发者（其中许多人甚至还在学校）的驱动下完成的。这是社区所有人努力的结果，他们每天辛苦工作，以确保所有ci都是绿色的，版本能够得到修补，安全能够得到维护。对于很多人来说，这项工作通常是乏味的，有时是情绪化的工作，每一位贡献者都应该得到我们最深切的敬意。
当然，kubernetes的故事不只是一个社区的故事，它还是一个技术的故事。kubernetes已经成为组织向云原生技术进行数字化转型的催化剂。它已经成为整个项目和产品生态系统开发的关键点和支撑平台，为开发人员和运营商提供了强大的云原生功能。通过为应用开发提供通用的可扩展的控制平面，Kubernetes成功地提供了一整类更高级别的抽象接口和工具。
kubernetes最重要的一个方面就是知道它的边界在哪里，这从一开始就是该项目的核心原则。虽然kubernetes仍在继续增长，但是它已经接近极限，正因为如此，在核心api之上之外还有一个繁荣的生态系统。从包管理到自动化运维，从workflow到ai，kubernetes api已经成为一个充满活力的云原生生态的基础。
随着kubernetes年满五岁，我们自然会展望未来，并思考如何让它继续蓬勃发展。在庆祝所取得的成果的同时，还必须指出，总有改进的余地。虽然我们的社区庞大而令人惊叹，但是多元化和包容性的社区是一个旅程，而不是目的，我们仍需不断的投入。同时，虽然有云原生技术的承诺，构建可靠的，可扩展的服务仍是一件很困难的事情，在将来，这些是必须进行持续投入以确保持续成功的核心领域。
这是惊人的五年，在你的帮助下，接下来的五年会更加惊人，谢谢。
02
微软和甲骨文整合云计算业务
分析师称是对 AWS 的一次挑战
6 月 5 日，微软和 Oracle 宣布成为云互操作合作伙伴关系，客户能够跨 Microsoft Azure 和 Oracle Cloud 迁移和运行任务关键型企业工作负载。企业现在可以将 Azure 服务（如 Analytics 和 AI）无缝连接到 Oracle 云，可以在 Azure 中运行工作负载的一部分，并在 Oracle 云中运行相同工作负载的另一部分。甲骨文一位架构师在社交平台表示：“这对企业级用户来讲，绝对是个好消息。”
根据双方在官方网站发布的公开声明：该合作伙伴关系可提供高度优化、最佳的云端体验。总而言之，Azure 和 Oracle 云为客户提供一站式服务，可以运行整个业务所需的所有云服务和应用程序。
通过网络和身份互操作性连接 Azure 和 Oracle Cloud，可以无缝提升和改进迁移。这种合作伙伴关系在两个云之间提供直接、快速和高度可靠的网络连接，同时继续提供企业期望从两家公司获得的客户服务和支持。除了原有软件的互操作性，该合作还支持创新的方案，例如在 Azure 上运行 Oracle E-Business Suite 或 Oracle JD Edwards 等。
由于这种合作关系，以下是值得注意的新功能：
无缝连接 Azure 和 Oracle Cloud，允许客户将其本地数据中心扩展到两个云平台。这种直接互连从合作之日开始在Ashburn（北美）和 Azure US East 提供，计划在未来扩展到其他地区。
统一身份和访问管理，通过统一的单点登录体验和自动化用户配置，管理 Azure 和 Oracle Cloud 中的资源。Oracle 应用程序也可以在早期预览版中使用 Azure Active Directory 作为身份提供程序和条件访问。
支持在 Azure 上部署自定义应用程序和打包的 Oracle 应用程序（JD Edwards EnterpriseOne，E-Business Suite，PeopleSoft，Oracle Retail，Hyperion），并在 Oracle Cloud 中部署 Oracle 数据库（RAC，Exadata，自治数据库）。相同的 Oracle 应用程序也将通过 Oracle 云中的 Oracle 数据库认证在 Azure 上运行。
协作支持模型，帮助 IT 组织部署这些新功能，同时使他们能够利用现有客户支持关系和流程。
Oracle 数据库将继续通过认证在各种操作系统（包括 Windows Server 和 Oracle Linux）上运行 Azure。
美国科技市场研究公司高德纳 (Gartner) 的分析师埃德·安德森 (EdAnderson)表示：“微软和甲骨文的结盟举动显然是对亚马逊云计算部门的一次‘进攻（jab）’，甲骨文视亚马逊云计算为数据库市场的主要竞争对手，这已不是秘密。
03
谷歌云故障
YouTube、Gmail、Snapchat 等均受影响
近日，谷歌云被曝发生故障，不少网站和服务因此遭到破坏，其中包括谷歌旗下服务以及非谷歌服务。据不完全统计，Snapchat、Vimeo、Shopify、Discord、Pokemon GO，以及谷歌的大部分服务，比如 YouTube、Gmail、谷歌搜索、G Suite 等均受到影响。
据了解，美国东海岸用户率先报告了这个问题，但宕机监控器 DownDetector 的报告表明，可能有更多地区受此影响。随后，一些欧洲用户也报告了这一问题，但北美地区用户受到的影响最大。DownDetector 发布的谷歌云平台声明中，称其 Google Compute Engine 遇到了多区域问题。
谷歌员工在 HackerNews 中表示，本次故障非常严重，以至于谷歌内部工程师相互沟通的工具也受到了影响，这让恢复工作变得更加困难。
从目前曝光的信息来看，本次故障可能与Level 3中断有关，这是一家总部位于美国的 ISP，为谷歌数据中心提供连接和各种其他服务。
04
AWS 发生故障
多处光缆被挖断，历经 11 小时完全修复
北京时间6月2日凌晨 2:00，AWS 多个可用区发生故障，相关用户无法连接 Internet。随后，AWS 发表声明表示：“由于 CN-NORTH-1 区域有多处光纤在昨晚的道路施工中被挖断，导致该区域的第一个可用区中 EC2 实例不能访问，同时不能在整个 CN-NORTH-1 区域中新建 EC2 实例。维修团队已找到具体断点，正在尽力恢复。”
据网友爆料，受事故波及影响，三星服务器全线崩溃。用户登录三星部分服务器时，页面报错且无法显示正常状态。打开 Bixy 的时候只会显示 LOGO 然后就闪退，根本无法进入 Bixby，三星商店则一直处于网络错误状态。此外，国内也有多家公司的服务受到影响，VIPKID 通过官方微博表示：“目前已经启动替代方案，受影响区域的线上课程正在陆续恢复，受此影响未能正常完成的课程不会消耗您的课时。”
对于云服务故障，企业需要明白，无论是传统环境还是云环境，都不能做到绝对的“持续可用”。大部分情况下，云环境的可用性和可靠性都比传统环境要高，这主要是因为云平台的运维更加专业。既然任何环境都有出现故障的可能，那么需要重视的问题就是“发生故障时，应该怎么办”。
接受风险，这一点很重要。对于现阶段国内的云计算发展进程来看，上云是不可避免的，在这种情况下，企业应该保持正确的心理，毕竟只要是系统，都会发生故障。国内主流云计算厂商已经投入了大量精力和成本在可用性和可靠性层面，这肯定要优于不少技术能力不足、成本有限的企业自建服务器。如果出现这种情况，那么走应急预案，用非系统的方式尽量降低风险。
