Helm

云原生技术生态近几年狂飙猛进，现已成为互联网公司的主流服务端技术栈。公司要快速响应市场变化和需求变更，就离不开自动化流水线进行编译、打包和部署，如何基于Kubernetes落地CI/CD就是DevOps团队需要解决的首要问题之一，同时也是衡量公司DevOps能力成熟度的重要指标之一。本文主要分享iHerb在Kubernetes技术栈中CI/CD落地的情况和实施过程中的一些经验总结。 背景 本人目前就职于一家全球电商公司，公司总部设在美国， 自1997年开办公司发展到现在，已经面向包括中国在内全球170多个国家和地区开放了线上购物电商业务。 对于这样的业务体量，在国内云应用才刚起步的时候公司早以开始使用一些大型云平台诸如AWS和GCP等来部署生产环境了。 而当Kubernetes问世之后，公司就开始尝试着使用Kubernetes来部署应用，并在这几年将一些原本用VM部署的应用迁移到了Kubernetes上，以适应更快的市场变化，以及以更快的速度开辟新的市场。 对于Kubernetes的特性、优点和优势在此就不做赘述了，本文着重论要论述的是我们在Kubernetes环境上的CI/CD落地和实践。 持续集成与持续交付 首先我们来温习一下CI/CD的理念。 持续集成是一种编码理念和一系列实践，可以促使开发团队实施小的更新并经常将代码检入版本控制存储库

作者： Michael Haigh (NUTANIX), Rahul Dabke (D2iQ) 本文由D2iQ负责整理翻译 大多数时候，企业在Kubernetes上部署有状态的数据服务是需要人工干预的，所以常常会出现一些问题。Operators正是解决这些问题非常有效的模式，而且Operators还可以协助管理应用的生命周期，将Kubernetes的协调水平提升至新的层次。 为了打造一个满足生产水平的Operator，开发者常常要编写数万行的代码。编写、管理，然后实施大量的代码是非常繁重而艰苦的工作。编写一个Operator要求对底层服务和Kubernetes有深入的理解。尽管Kubernetes的数据服务Operators和底层服务有共通之处，但是由于不同的编排也使实施具有显著的差别。企业需要的是一套打包好的Operator，用来简化对任何Kubernetes集群的部署和管理。 // 用Helm还是不用Helm？ // Helm是首个在Kubernetes上运行的应用包管理器，可以解决在Kubernetes安装服务的需求，但却不包括全生命周期管理。Helm Chart仅为打包工作负载和部署提供基本的功能。大多数的开发者在刚开始使用时会觉得很好用，但对于规模较大的环境就会发现Helm Chart难以管理，也不适用于有状态数据服务的部署。相反，Operator包含了应用的整个生命周期

今天，我们兴奋地宣布作为迄今为止最强大的Linkerd版本，Linkerd 2.9已经正式推出！此版本将Linkerd的零配置双向TLS（mTLS）支持扩展到所有TCP连接当中，使得Linkerd在集群安装完成之后即可透明加密并验证集群中的全部TCP连接。2.9版本还增加了对ARM架构的支持，包括引入新的多核代理运行时以提高吞吐量，同时支持Kubernetes服务拓扑等。 此版本源自50多位贡献者的不懈努力，在这里感谢Abereham G Wodajie，Alexander Berger，Ali Ariff，Arthur Silva Sens，Chris Campbell，Daniel Lang，David Tyler，Desmond Ho，Dominik Münch，George Garces，Herrmann Hinz，Hu Shuai，Jeffrey N. Davis，Joakim Roubert，Josh Soref，Lutz Behnke，MaT1g3R，Marcus Vaal，Markus，Matei David，Matt Miller，Mayank Shah，Naseem，Nil，OlivierB，Olukayode Bankole，Paul Balogh，Rajat Jindal，Raphael Taylor-Davies，Simon Weald，Steve

日益激烈的市场竞争和不断增长的客户期望促进企业业务的发展。与此同时，采用DevOps对一些企业来说可能是一个挑战，因为它包括调整实践和更新基础设施。尽管工程资源可能很少，但是无服务器提供了解决DevOps挑战的解决方案。从改进的物联网设备到经济高效的机器学习应用程序，无服务器生态系统正在促进企业采用DevOps。 为什么无服务器对DevOps有利? DevOps加快了企业开发速度，同时减少停机时间，从而为企业提供了竞争优势，在特性和功能方面加快了产品成熟度，并改善了客户体验。尽管DevOps具有吸引人的优点，但采用DevOps成本高昂并且耗时。无服务器能够以更低的成本和更高的回报克服障碍，并支持DevOps解决方案的实施。 无服务器技术提供了一种按需付费模式，允许企业为使用的资源付费。例如使用AWS Lambda，企业可以根据调用的次数和持续时间支付费用，从而有可能降低成本。功能即服务(FaaS)的价格可能会比容器更昂贵，具体取决于流量体验。流量越高，一致性越强，无服务器工具的成本就越高，并且这些成本可能会比容器成本上升得更高。 由于无服务器技术具有自动扩展性和完全可管理性，它允许团队专注于DevOps基础设施实际构建的业务逻辑，而不必花费大量时间来维护DevOps架构。 可用性和性能监控 诸如AWS Lambda或Azure Functions之类的功能即服务(FaaS

日益激烈的市场竞争和不断增长的客户期望促进企业业务的发展。与此同时，采用DevOps对一些企业来说可能是一个挑战，因为它包括调整实践和更新基础设施。尽管工程资源可能很少，但是无服务器提供了解决DevOps挑战的解决方案。从改进的物联网设备到经济高效的机器学习应用程序，无服务器生态系统正在促进企业采用DevOps。 为什么无服务器对DevOps有利? DevOps加快了企业开发速度，同时减少停机时间，从而为企业提供了竞争优势，在特性和功能方面加快了产品成熟度，并改善了客户体验。尽管DevOps具有吸引人的优点，但采用DevOps成本高昂并且耗时。无服务器能够以更低的成本和更高的回报克服障碍，并支持DevOps解决方案的实施。 无服务器技术提供了一种按需付费模式，允许企业为使用的资源付费。例如使用AWS Lambda，企业可以根据调用的次数和持续时间支付费用，从而有可能降低成本。功能即服务(FaaS)的价格可能会比容器更昂贵，具体取决于流量体验。流量越高，一致性越强，无服务器工具的成本就越高，并且这些成本可能会比容器成本上升得更高。 由于无服务器技术具有自动扩展性和完全可管理性，它允许团队专注于DevOps基础设施实际构建的业务逻辑，而不必花费大量时间来维护DevOps架构。 可用性和性能监控 诸如AWS Lambda或Azure Functions之类的功能即服务(FaaS

导读 日益激烈的市场竞争和不断增长的客户期望促进企业业务的发展。与此同时，采用DevOps对一些企业来说可能是一个挑战，因为它包括调整实践和更新基础设施。尽管工程资源可能很少，但是无服务器提供了解决DevOps挑战的解决方案。从改进的物联网设备到经济高效的机器学习应用程序，无服务器生态系统正在促进企业采用DevOps。 为什么无服务器对DevOps有利? DevOps加快了企业开发速度，同时减少停机时间，从而为企业提供了竞争优势，在特性和功能方面加快了产品成熟度，并改善了客户体验。尽管DevOps具有吸引人的优点，但采用DevOps成本高昂并且耗时。无服务器能够以更低的成本和更高的回报克服障碍，并支持DevOps解决方案的实施。 无服务器技术提供了一种按需付费模式，允许企业为使用的资源付费。例如使用AWS Lambda，企业可以根据调用的次数和持续时间支付费用，从而有可能降低成本。功能即服务(FaaS)的价格可能会比容器更昂贵，具体取决于流量体验。流量越高，一致性越强，无服务器工具的成本就越高，并且这些成本可能会比容器成本上升得更高。 由于无服务器技术具有自动扩展性和完全可管理性，它允许团队专注于DevOps基础设施实际构建的业务逻辑，而不必花费大量时间来维护DevOps架构。 可用性和性能监控 诸如AWS Lambda或Azure Functions之类的功能即服务(FaaS

Kubernetes/K8s架构师实战集训营【2020最新】 下载地址： 百度云盘 这门课上线有 2 年多了，目前进行到 第11期，已有 800 多位学习，并实现了加薪和提升技能的目标，得到学员一致好评，好评率达99%！ 为满足不同需求，这个架构课分为初中级和中高级两个阶段，也可根据需要选择学习。 虽说今年的大环境不是很好，但是从拉钩网招聘数据来看，K8s岗位薪资不降反而上涨不少！工作5年，薪资范围普遍 30k~40k 主要还是因为K8s大势所趋，大公司已经完成落地，正在不断迭代，需要这方面人才来支撑，小公司正在为迁移筹备，也需要这方面人才做主导；而K8s又是一个功能强大、生态完善的容器云平台，运维这个平台就需要具备非常强的专业能力，也就是说不是随便找个高级开发或者架构师就能替代该岗位的！ 章节目录： 01 开班仪式 【回放】开班仪式：行情分析、内容综述及学习建议(7月28日 21:00-22:30) 02 赠送视频 【录播】搭建一个生产级K8S高可用集群（1）(33分钟) 【录播】搭建一个生产级K8S高可用集群（2）(95分钟) 【录播】搭建一个生产级K8S高可用集群（3）(106分钟) 【录播】搭建一个生产级K8S高可用集群（4）(36分钟) 【录播】Ansible入门（基本使用）(126分钟) 【录播】Ansible入门（Playbook&Roles详解）(147分钟) 03

这是《Istio Helm Chart 详解》系列的第四篇，对 Gateways Chart 进行一些介绍，并讲解一下使用 Helm 创建 Istio Gateway 的方法。 前言 前面提到过，Istio 的 Helm Chart，除去用于安装之外，还有部分对 Istio 部署进行调整的能力。Gateways 一节内容，就包含了定制 Istio Ingress/Egress Gateway 的能力。 这个 Chart 的文件结构和其他组件类似，不同的在于内容，它通过对 values.yaml 中定义的 Gateways 相关内容的循环遍历，生成不同的 Gateway 单元，下面将会进行讲解和试验。 values.yaml 中的变量定义： gateways: enabled: true istio-ingressgateway: enabled: true labels: app: istio-ingressgateway istio: ingressgateway replicaCount: 1 autoscaleMin: 1 autoscaleMax: 5 resources: {} # limits: # cpu: 100m # memory: 128Mi #requests: # cpu: 1800m # memory: 256Mi cpu:

参考 fleeto/sleep fleeto/flaskapp 1. istio 配置变更示例 Helm 的 --set 参数可以变更默认配置，如： cd istio-1.1.7 helm template install/kubernetes/helm/istio \ --name istio --namespace istio-system \ --set sidecarInjectorWebhook.enabled=false istio 的 Sidecar 自动注入功能是通过 Kubernetes 的 mutating 控制器完成； 如果启用了自动生效的 istio 安装清单，就会生成1个名为 istio-sidecar-injector 的 mutatingwebhookconfiguration 对象，其中保存的就是自动注入的配置； 根据 Helm 与 Kubernetes 的工作原理，重复执行 kubectl apply 命令不会执行删除操作，因此通过上面操作生成的清单如果被提交，后果就是 mutating 控制器继续使用 istio-sidecar-injector 的配置进行工作； 所以此方式只针对 新增或修改 操作生效，对于 删除操作无效 。 2. 使用 istio dashboard 2.1 启用 Grafana # istion 默认没有启用 grafana

开源镜像仓库 Harbor 2.0 正式发布了！从 2017 年 4 月发布 1.1 版本算起，经过整整 3 年，Harbor 的版本号终于 “升” 到 2.x 了。当然了，Harbor 2.0 不仅仅是大版本数字跃升那么简单，还给带来了众多重要更新，涉及代码多项重构，凝聚了项目组艰辛的付出。Harbor 2.0 成为符合 OCI（Open Container Initiatives）规范的开源镜像仓库，能够存储多种云原生工件（Artifacts），例如，容器镜像、Helm Chart、OPA、Singularity 等等。 关于OCI 先说说什么是 OCI ，然后看看 Harbor 2.0 的新功能意味着什么。 成立于 2015 年的 OCI 是 Linux 基金会旗下的合作项目，以开放治理的方式制定操作系统虚拟化（特别是 Linux 容器）的开放工业标准。 OCI 已经制定了业界的容器运行时（runtime）规范和容器镜像规范，还有一个正在讨论的镜像分发（distribution）规范。OCI 的指导思想是先有工业的实践，再总结成技术规范，例如，像 Docker 镜像格式已经广泛被用户接受之后，OCI 在此基础上制定了容器镜像格式的规范。 （本文来自公众号：亨利笔记, henglibiji ） 总体上说，OCI 提出的两个规范（镜像和运行时）是互相关联的。镜像规范定义镜像的组成