周一见 | AWS 瘫痪、Helm 2.0 最后一个稳定版本、软件开发“七宗罪”
新闻
作者:才云 Cailcoud
译者:bot
2019-10-28 18:54

1Helm 发布 2.15.0

Helm 是 Kubernetes 应用的包管理工具,也是云原生技术体系下最受欢迎的开源项目之一。近日,Helm 的核心维护者 Matthew Fisher 宣布发布 Helm 2.15.0。

新版本修复了许多错误,重构了代码库的几个部分,简化了可维护性,提高了可用性

  • 将 Go 更新至 1.13.3;
  • 将 Kubernetes 客户端库更新至 1.15.0;
  • 将 Sprig 更新至 2.20.0;
  • helm init可安装 apiVersion apps/v1的 Tiller Deployment,可兼容 Kubernetes 较新版本;
  • 引入helm test --logs
  • 引入helm template --api-versions用于使用自定义 apiVersion 验证模板;
  • 引入helm test --max以更改可以并行运行的最大测试 hook 数;
  • helm repo listhelm searchhelm install引入--output
  • helm history 可显示图表的应用程序版本字段;
  • --wait 现在等待入口主机准备就绪;
  • --wait 现在在检测到工作负载处于“已暂停”状态时继续;
  • 修正了将数字解析为浮点数的问题;
  • ……

据了解,Helm 2.15.0 将是 Helm 2.0 的最后一个稳定版本。未来,Helm 团队将会转向 Helm 3.0 的开发工作。Helm 2 不再开发新功能,但仍会支持和修复出现的安全问题和错误。

github.com/helm/helm/releases/tag/v2.15.0

2GitLab 如何使用 K8s

上周,GitLab 发文介绍了 K8s 的细节,以及 GitLab 如何使用这个开源工具。在文中,高级解决方案经理 Brendan O'Leary 指出了 GitLab 与 K8s 之间的三个关键结合点。

关键一:GitLab 是一个应用程序,因此可以在 Kubernetes 上运行。如果 GitLab 用户已经在使用云原生环境,那么 GitLab 应用程序就可以被安装在该云原生环境中。

关键二:在 GitLab 中构建其应用程序的用户可以通过 CI/CD 把应用部署到 Kubernetes。GitLab 一直致力于与 Kubernetes 的集成,因此开发人员可以将其应用程序自动部署到 Kubernetes 集群,Auto DevOps 更快、更高效!

关键三:将 GitLab.com 的生产系统移至 Kubernetes 集群。为了把 GitLab.com 这个巨型项目完全迁移到集群,GitLab 特地换了个云服务商,这是他们向 K8s 迈出的重要一步。

about.gitlab.com/blog/2019/10/24/kubernetes-101

3K8s 用例已超越容器编排

在主流观念中,Kubernetes 主要用于帮助 IT 管理员跨集群自动执行容器部署、扩展和调度。近日,外媒的一份调查却显示,与几年前相比,尽管目前 Kubernetes 的主要用例仍然是容器管理和编排,但现在有些企业正将这项技术应用于更广泛的地方。

简化多云管理。Kubernetes 的管理功能正从内部扩展到公共云,包括跨多个公共云。企业可以使用业务流程平台来管理跨越多个云的容器,提高整体弹性。

启用服务发现。通过 Kubernetes,用户可以针对容器化应用程序自动化和自定义服务发现。考虑到 Kubernetes 在微服务和容器管理上的使用非常常规,这一优势正被越来越多管理员使用。

容器集群联合。尽管 Apache Mesos-Marathon 一直是大规模 IT 部署的首选容器联合方法,但 Kubernetes 和第三方工具也正在成为一种越来越普遍的新选择。

下一代 PaaS。借助 Knative 的抽象化基础架构管理,企业的重点可以从平台转移到代码部署。Kubernetes 这种无服务器适应性可能会掀起下一波 PaaS 基础架构浪潮。

4本周 K8s 开源项目推荐

ccheck

github.com/brendanjryan/ccheck这是一个命令行应用程序,目的是检查 Kubernetes 配置文件,但可以扩展以支持其他文件类型。

kube-owasp-zap

github.com/zee-ahmed/kube-owasp-zap这是 Kubernetes owasp-zap 的解决方案。它允许你使用 Kubernetes 作为平台在主机上执行漏洞分析。

imago

github.com/philpep/imago该项目旨在简化 Kubernetes 集群中 Docker 镜像的持续交付。它是 insect 的最后阶段,得名于 image 和 Go。

tidb-operator

github.com/pingcap/tidb-operator这个工具允许用户在 Kubernetes 上管理 TiDB 集群并自动执行与操作 TiDB 集群相关的任务。它使 TiDB 成为真正的云原生数据库。

kr8

github.com/apptio/kr8这个工具用于为众多 Kubernetes 集群呈现 jsonnet 清单。它被设计为像简单的配置管理框架一样工作,允许用户为多个集群中的组件指定配置。

stash

github.com/stashed/stash这是围绕 restic 构建的 Kubernetes CRD 控制器,可实现快速、高效、安全备份。

5软件开发“七宗罪”

上周,有 20 年从业经验的计算机故障排除专家、高级技术编辑 Stephen J. Bigelow 梳理了软件开发团队在工作中应避免的七种不良行为。他指出:尽管这些错误实践已被证明会影响项目和团队,但它们依然经常出现

第一宗罪:文档差。文档是代码可维护性和可重用性的关键部分,但有时开发人员会沉迷于写代码,而忘了对其进行记录,或写的文档只有自己能读懂。

第二宗罪:糟糕的架构。为了赶 deadline,有的开发人员会急着开始写代码,而忘了精心设计的架构可以理清如何分离特征和功能,从而使任务分配更顺畅、编码效率更高。

第三宗罪:代码差。开发人员要确保自己是按团队的统一标准写代码的,这样的代码集成更容易、可读性更好并且错误率更低。定期的代码审查有助于完善和执行这些标准。

第四宗罪:解决问题的能力差。开发人员几乎不可避免地会在项目中遇到问题,比如某个功能没有达到预期效果,这时,许多人只会采取临时性的补救措施,不会在事后提出永久性的解决方案,这样的后果是项目终有一天会因技术债务受到影响。

第五宗罪:时间管理差。任何时候,不要低估创建特征或功能所需的时间,多与其他经验丰富的开发人员交流。定期计划和代码审查对于保持开发项目的正常进行至关重要。

第六宗罪:糟糕的假设。由于很难在软件设计文档中确定每个细节,有些开发人员会对某些功能或细节做出假设,这些假设往往会导致不必要的补丁和返工。

第七宗罪:不参与测试。随着软件对开源代码、API 和其他外部资源的依赖越来越大,软件测试的重要性和复杂性也与日俱增。尽管测试通常依赖于自动化工具和专业人员,但开发人员也应在此过程中发挥积极作用。

6AWS 瘫痪 15 小时

北京时间 10 月 23 日凌晨,云服务巨头亚马逊遭遇 DDoS 攻击,该攻击持续了 15 个小时,造成 AWS 部分服务瘫痪。

据媒体报道,此次攻击引发大量数据包阻塞亚马逊的 DNS 系统。由于其中一些合法的域名请求会被释放以缓解问题,网站和应用在尝试联系后端亚马逊托管的系统(如 S3 存储桶)时可能会失败,导致用户看到出错信息或空白页面。

而除了 S3,受影响的服务还包括 AWS 关系数据库服务(RDS)、简单队列服务(SQS)、CloudFront、弹性计算云(EC2)和弹性负载均衡(ELB)等。这些都是处理访客、处理客户信息的重要服务。

由于攻击时间正好是工作日的上班时间,这次攻击造成了巨大损失和恶劣社会影响。考虑到去年 AWS 也曾遭受过长达 8 个小时的 DDoS 攻击,许多人认为,这次事故为 DNS 服务器安全再次敲响了警钟

800 comCount 0