Helm

用过类 Unix 系统中 Unix shell(Shell/Bash/Zsh) 的同学都应该对 TAB 键印象深刻，因为它可以帮忙补全或提示后续的命令，用户不用记住完整的命令，只需输入前几个字符，按 TAB 键，就会提示后续的命令供用户选择，用户体验极佳。目前流行的一些使用 Go 语言开发的 CLI 工具，如 kubectl 和 helm ，他们也都有 completion 也就是命令自动补全功能，通过将 source <(kubectl completion zsh) 加入 .zshrc 文件中，就可以在每次启动 shell 时自动加载自动补全脚本，之后就可以体验到与原生 shell 相同的自动补全功能了。这些 CLI 工具，都是基于 Cobra 库开发，命令自动补全功能也是该库提供的一个功能，本篇文章就来讲讲如何使用 Cobra 实现命令自动补全的。 Cobra 可以作为一个 Golang 包，用来构建功能强大的命令行程序；同时也可以作为 CLI 工具，用来生成应用程序和命令文件。 由于文本主要介绍 Cobra 的命令自动补全功能，更多内容请查阅官网。 #一、基础用法 Cobra 当前的最新版本为 v1.0.0，支持生成多种 Shell 的自动补全脚本，目前支持： ·Bash ·Zsh ·Fish ·PowerShell 如上所述，Cobra 不但是一个功能强大的 Golang

作者 | 李国强 阿里云资深产品专家 本文整理自《Serverless 技术公开课》， 关注“Serverless”公众号，回复“入门”，即可获取 Serverless 系列文章 PPT。 今天来讲，在 Serverless 这个大领域中，不只有函数计算这一种产品形态和应用类型，而是面向不同的用户群体和使用习惯，都有其各自适用的 Serverless 产品。例如面向函数的函数计算、面向应用的 Serverless 应用引擎、面向容器的 Serverless Kubernetes，用户可以根据自己的使用习惯、使用场景或者应用类型，去选择使用什么样的 Serverless 产品。下面通过本文给大家介绍一下，阿里云都有哪些可供大家选择的 Serverless 产品。 Serverless 产品及分层 众所周知，最早提出 Serverless 的是 AWS，其在 Serverless 领域的旗舰产品是 function compute。同样阿里云也有函数计算的产品，帮助用户构建 Serverless 函数。但 Serverless 不仅仅是函数，如下图所示，其实用户会期望在应用、容器等层面也能够享受到 Serverless 的好处，包括按量付费、极致弹性等，这样也更符合用户原有的使用习惯。 在上图中，大家能够看到，阿里云针对函数、应用和容器都推出了对应的 Serverless 产品

一、定义 　　设计模式是一套被反复使用、多数人知晓的、经过分类编目的、代码设计经验的总结。使用设计模式是 为了可重用代码、让代码更容易被他人理解、保证代码可靠性、程序的重用性。 二、产生背景 　　肯特·贝克和沃德·坎宁安在1987年利用克里斯托佛·亚历山大在建筑设计领域里的思想开发了设计模式并把此思想应用在Smalltalk中的图形用户接口的生成中。一年后Erich Gamma在他的苏黎世大学博士毕业论文中开始尝试把这种思想改写为适用于软件开发。与此同时James Coplien 在1989年至1991 年也在利用相同的思想致力于C++的开发，而后于1991年发表了他的著作Advanced C++ Idioms。就在这一年Erich Gamma 得到了博士学位，然后去了美国，在那与Richard Helm, Ralph Johnson ,John Vlissides合作出版了Design Patterns - Elements of Reusable Object-Oriented Software 一书，在此书中共收录了23个设计模式。这四位作者在软件开发领域里也以他们的匿名著称Gang of Four(四人帮，简称GoF),并且是他们在此书中的协作导致了软件设计模式的突破。有时这个匿名GoF也会用于指代前面提到的那本书。 三、学习的意义 　　设计模式的本质是面向

1 前言 Helm 是优秀的基于 Kubernetes 的包管理器。利用 Helm ，可以快速安装常用的 Kubernetes 应用，可以针对同一个应用快速部署多套环境，还可以实现运维人员与开发人员的职责分离。现在让我们安装并体现一下，如何通过 Helm 安装 MongoDB 吧。 Kubernetes 环境搭建可参考： Mac上使用Docker Desktop启动Kubernetes，踩坑后终于搞掂 2 Helm相关概念 包管理是一种复用理念， Helm 与 Kubernetes 的关系，就像是 yum 与 CentOS ， pip 于 python ， npm 于 JavaScript 。 Helm 的作用有以下几点： 快速安装常用应用：许多大公司都有 helm 仓库，为我们提供了许多优秀的应用，可以直接拉取安装，如快速部署 Redis 集群、安装 Jenkins 等。 多环境部署：通常我们需要多套环境，如开发环境、测试环境、生产环境等， helm 可以通过 模板+变量 的形式实现快速部署； 运维与开发隔离：运维人员管理 k8s 资源，写部署模板及默认配置；开发人员只需要提供少量配置即可，把精力专注在业务开发上。 在使用 helm 之前，以下概念应该要搞懂： helm 客户端：安装在能连上 kubernetes 集群的机器都行，用于安装、卸载应用等。 tiller ：这是

“攻城狮”之痛 痛一：最“可爱”的产品经理，这些人一天到晚提需求，而且毫无愧意改来改去。 每一个需求背后都是一大串的代码，每一次需求的变更，意味着相对应的每一个环节都要变更，而这些，都是“攻城狮”一个一个代码敲上去的。所谓杀掉一个“攻城狮”，不用枪、刀、剑、斧，多提需求以及需求变更就够，大概就是这样子的吧。 产品经理们，摸过你们长在左心房的良心吗？而且，说好的下午茶、大餐呢？ 痛二：最“要命”的老板，这些人老是有这周想到下周就要的系统。 996已经司空见惯，跟谁学更是提倡“996变为007”，鼓励员工尽量住在公司，所谓“不畏加班不念下班”，虽然不确定真假，但这个应该是每一个老板的内心想法。项目工作量需要30人/天，老板要求10人/天，这就是现实！ 老板们，你有考虑过我们“攻城狮”所剩无几的头发兄弟的感受吗？你有想过我们“攻城狮”也想有时间去大学城找女朋友吗？ 痛三：最费头发的事儿——修Bug，这些“兄弟”最讨人烦，但无奈它天天光顾。 在公司/机构里，老师绝对是最受宠的那类人，天天都有人围着。 我们这些“攻城狮”则天天围着Bug，当真是一个Bug一时爽，一打Bug头发光。如果是自己写的代码倒还好，最坑的是公司/机构里有N多不知道哪儿来的“系统”，甚至还没有说明文档。 痛四：最憋屈的事儿——修复“罢工”系统，这些家伙不来则已，一来惊天动地。 每年招生高峰期，大大小小的活动肯定是少不了

环境 traefik 2.2+，k8s 1.8+ 需求：自动获得证书，使用aliyun dns方式获证书，暴露给外网访问 参考官方网站： https://docs.traefik.io/user-guides/crd-acme/ 首先安装helm, k8s的一个类似yum包管理器。 参考 https://helm.sh/docs/intro/install/ Download your desired version Unpack it ( tar -zxvf helm-v3.0.0-linux-amd64.tar.gz ) Find the helm binary in the unpacked directory, and move it to its desired destination ( mv linux-amd64/helm /usr/local/bin/helm ) traefik有二种模式: 1. 使用 Traefik CRD 配置路由规则（IngressRoute），2. 使用 Kubernetes Ingress 配置路由规则（Ingress） IngressRoute Definition，拷贝 https://docs.traefik.io/user-guides/crd-acme/#ingressroute-definition 里面的yaml文件并应用

Harbor 简介 Harbor是由VMware公司中国团队为企业用户设计的 Registry server开源项目，包括了权限管理(RBAC)、LDAP、审计、管理界面、自我注册、HA、RESTful API等企业必需的功能，属于Cloud Native Computing Foundation（CNCF，云原生计算基金会）的毕业项目。 我们建议使用2.0以后的版本，Harbor在2.0以后的版本使Harbor成为第一个符合OCI（Open Container Initiative，开放容器倡议）标准的开源Registry server，能够存储大量云原生组件，例如container images、Helm Chart、OPAs、CNAB、Singularity等。 目前，Harbor最新稳定版本为2.1，本文使用此版本部署。 部署 1,我们的需求如下 提供registey服务的域名为registry.myk8s.com 我们需要把域名解析到有外网ip的nginx上，然后nginx给Harbor做代理 我们给Harbor单独提供一个分区挂载到了/data1目录 2,现在准备docker环境： # yum install docker-ce -y # yum install docker-compose -y # systemctl start docker 3

1. 前言 2. Net Core项目本身的准备 2.1 dockerfile 2.2 创建kubernetes用于helm的chart包 2.2.1 说明 2.2.2 chart文件目录和文件组成 3. Azure Devops创建仓库的pipeline 3.1 前言 3.2 使用azure devops准备操作 3.3 创建service connections 3.4 新建pipeline流水线 3.5 创建部署shell脚本 4. 触发pipeline部署流水线 5. 关于均衡负载 1. 前言 前前后后学习kubernetes也有一个来月了，关于kubernetes的博客也写了有十多篇。但是技术如果无法落地到实际的应用场景终归是纸上谈兵，所以就有了这一出：通过结合 kubernetes 和 azure devops 实现项目的 CI/CD 以及均衡负载 写完这篇后 kubernetes 的相关学习也暂时告一段落了，有种终于闯关成功了啊的感觉，当然这是题外话了。 注1 ： 以下只是以Net Core项目为例，实际运用场景中，除了dockfile的编写有差别，剩下整个自动化部署链条中的技术也好，工具也好，都可以复用，与语言和语言框架本身无关。 注2 ： 本文演示的也只是其中一种简便的方式，具体的自动化流程中，由于自由度非常高，所以实际的流程可能会更加复杂，这里就不做赘述了

如今，云原生被企业和开发者奉为一种标准，并被认为是云计算的未来。 严格来说， 云原生并不是一个产品的名称，而是一套技术体系和一套方法论，它包括 DevOps、持续交付、微服务、容器、敏捷基础设施等内容。 云原生（Cloud Native）概念在 2013 年被首次提出，在云原生技术全面爆发之前，我们开发的应用可以被称为非云原生应用，非云原生应用并没有考虑到应用的弹性和规模性，甚至很多都不具备扩展性，当业务规模扩大时，特别依赖硬件的升级，进而带来了很多问题。 京东在每年的 618、11.11 都会面临海量数据和流量增长，从前端网站、订单、结算、支付、搜索、推荐，到后端的仓储、配送、客服、售后各种业务系统都面临着前所未有的挑战。因此，京东自然需要一个灵活的、有弹性的、可规模化扩展的平台，这也决定了京东从很早开始就拥抱云原生。 京东目前运营着全球 最大规模的 Docker 集群、Kubernetes 集群 ，以及最复杂的 Vitess 集群之一，基本实现了“All in Containers”，是目前全球容器化最彻底的互联网企业之一。 京东作为容器技术先行者，早在 2014 年，就率先将 Docker 容器技术大规模应用至生产环境。在 2016 年初开始实践 Kubernetes，在2017年初基于 Vitess 构建起弹性数据库，并且自研京东“阿基米德”调度系统

作者 | 王夕宁 阿里云高级技术专家 导读 ：本文摘自于阿里云高级技术专家王夕宁撰写的《Istio 服务网格技术解析与实战》一书，讲述了如何使用 Istio 进行多集群部署管理来阐述服务网格对多云环境、多集群即混合部署的支持能力。 前文详情： 《如何使用 Istio 进行多集群部署管理：单控制平面 VPN 连接拓扑》 《如何使用 Istio 进行多集群部署管理：单控制平面 Gateway 连接拓扑》 在多控制平面拓扑的配置中，每个 Kubernetes 集群都会安装相同的 Istio 控制平面，并且每个控制平面只会管理自己集群内的服务端点。通过使用 Istio 网关、公共根证书颁发机构（CA）以及服务条目 ServiceEntry，可以将多个集群配置组成一个逻辑上的单一服务网格。这种方法没有特殊的网络要求，因此通常被认为是在 Kubernetes 集群之间没有通用网络连接时的一种最简单方法。 在这种拓扑配置下，Kubernetes 跨集群通信需要服务之间的双向 TLS 连接，要在集群之间启用双向 TLS 通信，每个集群的 Citadel 将配置由共享的根 CA 生成的中间 CA 证书，如图所示。 （多控制平面） 部署控制平面 从共享的根 CA 为每个集群的 Citadel 生成中间 CA 证书，共享的根 CA 启用跨不同集群的双向 TLS 通信。为了便于说明，我们将 samples