Helm

至少两台机器。推荐4X16。（完全安装KubeSphere会吃掉10G+内存） k8s安装（略1.14.8）可参考我上一篇文章或者基于kubeadmin快速安装 KubeSphere2.1前置条件 1.k8s版本必须小于1.6大于等于1.13 我选择的是1.14.8 2.helm必须大于等于2.10 小于2.16 我选择2.15.2 安装流程： 1.helm安装（master节点） wget https://get.helm.sh/helm-v2.15.2-linux-amd64.tar.gz tar zxvf helm-v2.15.2-linux-amd64.tar.gz cd liniux-amd64 mv helm /usr/local/bin 2.tiller安装（master节点） kubectl -n kube-system create serviceaccount tiller kubectl create clusterrolebinding tiller --clusterrole cluster-admin --serviceaccount=kube-system:tiller helm init --service-account tiller --skip-refresh --tiller-image registry.cn-shanghai

1. 情况说明 使用一台VMWare Workstation虚拟机，4核8G内存，50G磁盘 已安装KubeSphere 2.1 版本，已经按照官方文档的入门必读，示例一创建好相应的账号信息等 KubeSphere 文档地址： https://kubesphere.com.cn/docs/v2.1/zh-CN/introduction/intro/ 2. 实现的效果 kubeapps官方文档地址： https://github.com/kubeapps/kubeapps 想使用kubeapps，通过helm管理部署在k8s集群的应用，部署，升级，回退版本等 同时可以在KubeSphere中查看部署的应用等 3. 步骤 (1).要求 k8s集群版本：1.8+ Helm版本：2.14.0+ 已安装kubectl KubeSphere 2.1 版本安装的k8s集群是1.15.5版本，helm版本是2.14.3，已安装kubectl，符合上述要求 [root@ks-allinone ~]# kubectl version Client Version: version.Info{Major:"1", Minor:"15", GitVersion:"v1.15.5", GitCommit:"20c265fef0741dd71a66480e35bd69f18351daea",

简介： 常言道，startup 有 startup 的好，大厂有大厂的好，那么大厂究竟好在哪呢？拿硅谷老牌大厂们 FLG 来说，如果要问最令人怀念的是什么？Free food 和基础设施(Infrastructure)一定是会上榜的，两者均极大提升了广大应用开发者的幸福指数。那么能不能“让天下没有难做的应用”呢？请大家把目光投向正在兴起的云原生生态。 前言 常言道，startup 有 startup 的好，大厂有大厂的好，那么大厂究竟好在哪呢？拿硅谷老牌大厂们 FLG 来说，如果要问最令人怀念的是什么？Free food 和基础设施(Infrastructure)一定是会上榜的，两者均极大提升了广大应用开发者的幸福指数。那么能不能“让天下没有难做的应用”呢？请大家把目光投向正在兴起的云原生生态。 在云原生生态中，容器服务包括了镜像和容器引擎两个部分。其中容器镜像作为核心的云原生应用制品，打包了完整的操作系统和应用运行环境，应用的迭代也因为使用了这种不可变架构而变得更简单，更频繁。 本文将围绕着容器镜像这一核心，分享它的相关知识和业界的思考与实践。 容器镜像的概念 1）容器镜像 容器镜像有一个官方的类比，"生活中常见的集装箱"，虽然拥有不同的规格，但箱子本身是不可变的（Immutable），只是其中装的内容不同。 对于镜像来说，不变的部分包含了运行一个应用软件（如 mysql

： 你填了吗？10人将获赠CNCF商店$100美元礼券！ 来参与2020年CNCF中国云原生调查 问卷链接（ https://www.wjx.cn/jq/97146486.aspx ） 配置 readiness、liveness 和 startup 探针可以处理不健康的 Pod，本文介绍了三种类型的探针、最佳实践和有关工具，以检测可能存在的配置问题。 作者：Yitaek Hwang 翻译：Bach（才云） 校对：木子（才云） 分 布式系统和微服务体系结构的挑战之一是自动检测不正常的应用程序，并将请求（request）重新路由到其他可用系统，恢复损坏的组件。健康检查是应对该挑战的一种可靠方法。 使用 Kubernetes，可以通过探针配置运行状况检查，以确定每个 Pod 的状态。 默认情况下，Kubernetes 会观察 Pod 生命周期，并在容器从挂起（pending）状态转移到成功（succeeded）状态时，将流量路由到 Pod。Kubelet 会监控崩溃的应用程序，并重新启动 Pod 进行恢复。许多开发人员认为这样的基本设置就足够了，尤其是当 Pod 内的应用程序还配置了守护进程管理器（例如 Node.js 的 PM2）时。 但有一种意外情况，当 Kubernetes 在所有容器启动后，认为 Pod 是健康且可以接受请求时，但应用程序在实际准备就绪之前就已收到流量

友情提示：全文1000多文字，预计阅读时间5分钟 前言 在当下万物互联的浪潮下，无论企业还是个人，数据上云已经进行的如火如荼。 5G+移动云产品新功能也在不停地迭代发布上线，其中有些产品能力依赖底层虚拟化组件的新功能新特性，比如保证在不中断用户业务的情况下达到虚拟化组件在线升级的目的，为云上产品新功能成功上线提供助力。 面临的问题 目前主流的解决方案是使用虚拟化热迁移技术，但是云环境中虚拟机的热迁移存在迁移周期长，成功率低，运维工作量巨大的问题，因为目前 虚拟机的热迁移技术（libvirt层）仅仅局限于异地迁移，即将虚拟机从一台物理服务器迁移到另一台远端的物理服务器，这样带来的问题就是： 虚拟机的所有数据要通过网络进行传输，给线上网络带宽带来很大压力 当网络带宽成为迁移的瓶颈时，高负载虚机无法完成传输导致迁移失败 针对以上问题，社区主要从减少数据的生成和压缩传输数据两个方向进行了优化，但是对于带宽受限，负载极高的虚机来说，效果基本看不见。就现有环境测试来看，脏页达到250M/s左右时，即便各种优化特性全开，也难逃迁移失败的命运。 因此，面对云上版本升级的迫切诉求： 突破带宽限制，无视虚机负载，尽量保证100%成功迁移 保证迁移成功的同时，大大缩短迁移时间，以减轻运维负担 考虑到版本升级的特殊性（不同于负载均衡必须跨节点），如果有一种方法可以在本地就能完成虚机的版本升级

监控系统是运维体系乃至整个软件产品生命周期中最重要的一环，完善的监控可以帮助我们事前及时发现故障，事后快速追查定位问题。而在以微服务为代表的云原生架构体系中，系统分为多个层次，服务之间调用链路复杂，系统中需要监控的目标非常多，如果没有一个完善的监控系统就难以保证整体服务的持续稳定。 监控对象及分层 在实际场景中监控系统按照监控的对象及系统层次结构，从底向上可以依次划分为基础层、中间层、应用层、业务层等多个层面的监控。具体可如图所示： 基础层监控就是对主机服务器(包括宿主机、容器)及其底层资源进行监控，以保证应用程序运行所依赖的基础环境的稳定运行。基础层监控主要有两个方向： 资源利用：是对像I/O利用率、CPU利用率、内存使用率、磁盘使用率、网络负载等这样的硬件资源进行监控。避免因应用程序本身或其它特殊情况引起的硬件资源耗尽而出现的服务故障。 网络通信：是对服务器之间的网络状态进行监控。网络通信是互联网的重要基石，如果主机之间的网络出现如延迟过大、丢包率高这样的网络问题，将会严重影响业务。 需要说明的是，在基于Kubernetes容器化技术的新型云原生基础设施中，基础层的监控不仅要对宿主机本身进行监控，也要对Kubernetes集群状态及其容器资源使用情况进行监控。这在后面我们构建基于Kubernetes的基础层监控体系时将会具体介绍。 中间层监控主要是指对诸如Nginx、Redis

在过去的几年中，我们已经看到 Kubernetes 被广泛用作容器编排平台。随之而来的还有不同的方式来操作 Kubernetes 集群。一些企业更喜欢一个集群一租户（硬多租户），而另一些企业更喜欢一个集群 n 租户（软多租户）模型。我们已经看到许多企业都采用后一种模型，因为它可以帮助他们减少很多运营工作。对于软多租户模型，明智地提供成本分配租户的可见性非常重要，以便可以相应地向组织收费。 需求 我们正在运行一个软多租户 Amazon EKS 集群。使用 Kubernetes 命名空间可以实现多租户。现在用于成本报告，AWS 提供了成本资源管理器，如果您想对节点，EBS 和整个网络收取费用，这将非常有用。但是不可能使用它来实现共享资源或池化资源的成本分离。我们希望基于租户创建报告，以便可以将其与预算相对应。市场上有许多用于 Kubernetes 成本报告的解决方案，我们一直在寻找开源的东西，最终选择了 Kubecost。在此博客文章中，我将详细说明如何将 Kubecost 用于多租户 EKS 集群，以获得更好的可见性。 Kubecost Kubecost 可帮助您监视和管理 Kubernetes 环境中的成本和容量。- Kubecost 文档（ https://docs.kubecost.com/ ） Kubecost 既可以作为开源产品也可以作为商业产品。该商业产品具有少量附加功能

导语 送给正在快速学习Kubernetes的同学。 正文 当云还处于发展初期时，开发人员发现使用原子的、最小的Linux映像编写应用程序很方便，这些映像可以与运行服务器共享资源。从技术上讲，这些小的环境定义基于内核名称空间，被称为容器。 随着容器的激增，系统管理员很快意识到开发一种工具不仅可以帮助他们管理容器，还可以管理下面的虚拟化基础架构。这就是Kubernetes诞生的时候。 Kubernetes是用于容器管理的可扩展开源平台。它可以帮助管理员和开发人员管理容器周围的工作负载、服务和流程。它有助于配置和简便的自动化。在其相对较短的寿命中，它通过许多公司和项目提供的服务，支持和工具，建立了一个快速增长的生态系统。 如果您想更好地了解 Kubernetes 这项重要的云原生技术，这里有个观点可以帮助您深入研究。 1. 用Kubernetes遏制容器的混乱 2016年，我们发表了《用Kubernetes遏制容器的混乱》，这是Terry Ryan的介绍性文章，内容涉及Kubernetes如何帮助管理员和建筑师解决容器问题。如果您需要从根本上介绍容器的功能以及Kubernetes如何使它变得容易，那么这是本文的第一篇。它不带任何先验知识，并解释所有最重要的概念，因此您可以快速入门。另外，如果您要深入了解内核级别发生的变化，请阅读Jessica

Helm v3.0.0 Alpha 1 is coming! Helm 作为 Kubernetes 体系的包管理工具，已经逐渐成为了事实上的应用分发标准。根据 2018 年 CNCF 的一项云原生用户调研，超过百分之六十八用户选择 Helm 来作为应用打包交付方式。在开源社区中，越来越多的软件被搬迁到 Kubernetes 集群上，它们中的绝大部分都是通过 Helm 来进行交付的。 Helm 当前的稳定版本为 v2.14.0 ，最新发布的测试版本为 v3.0.0-alpha.1 。v3.x 的 alpha 版本可谓千呼万唤始出来，它带来了非常多的新特性及优化改进，让人无比兴奋，因此作此文以总结安利一番。 架构性变化 - 去除了 Tiller 在 Helm 2 中，一次基于 Helm 的软件交付会涉及到多个组件： 在 Helm 2 中，Tiller 是作为一个 Deployment 部署在 kube-system 命名空间中，很多情况下，我们会为 Tiller 准备一个 ServiceAccount ，这个 ServiceAccount 通常拥有集群的所有权限。用户可以使用本地 Helm 命令，自由地连接到 Tiller 中并通过 Tiller 创建、修改、删除任意命名空间下的任意资源。 然而在多租户场景下，这种方式也会带来一些安全风险，我们即要对这个 ServiceAccount

《Istio Helm Chart 详解》系列的第五篇，介绍 Chart SidecarInjectorWebhook，负责对工作负载进行自动注入。 前言 这个 Chart 负责 Istio Sidecar 的自动注入操作相关配置。 关于自动注入操作的相关内容，可以参考官方文档中的相应章节，简单说来自动注入的两个先决条件： Kubernetes 版本大于 1.9。 启用了 MutatingAdmissionWebhook 和 ValidatingAdmissionWebhook 。 还有一点，在 Kubernetes 1.10 版本中的 AlwaysPullImage 会和自动注入功能冲突 代码中可以看到，这一 Chart 生成了自动注入所需的 Deployment、Service，运行依赖的 RBAC 资源，以及自定义资源。 这个 Chart 会生成 MutatingWebhookConfiguration 类型的自定义资源，根据对命名空间以及 Pod 注解的监控对新生成的 Pod 进行注入。可以通过对这一自定义资源的修改，结合 ConfigMap istio-sidecar-injector 的内容对注入行为进行控制，后面将会进行讲解。 values.yaml 中的变量定义 sidecarInjectorWebhook: enabled: true replicaCount: