Kubernetes项目脱胎于Google内部的大规模集群管理工具Borg
##2.1. K8s (Kubernetes)是什么？
本文转自维基百科：https://zh.wikipedia.org/wiki/Kubernetes
Kubernetes（常简称为K8s）是用于自动部署、扩展和管理容器化（containerized）应用程序的开源系统。该系统由Google设计并捐赠给Cloud Native Computing Foundation（今属Linux基金会）来使用。
它旨在提供“跨主机集群的自动部署、扩展以及运行应用程序容器的平台”。 它支持一系列容器工具, 包括Docker等。CNCF于2017年宣布首批Kubernetes认证服务提供商（KCSPs），包含IBM、华为、MIRANTIS、inwinSTACK迎栈科技等[5]服务商。
历史
Google Container Engine简报
Kubernetes（在希腊语意为“舵手”或“驾驶员”）由Joe Beda、Brendan Burns和Craig McLuckie创立，并由其他谷歌工程师，包括Brian Grant和Tim Hockin等进行加盟创作，并由谷歌在2014年首次对外宣布 。 该系统的开发和设计都深受谷歌的Borg系统的影响，其许多顶级贡献者之前也是Borg系统的开发者。在谷歌内部，Kubernetes的原始代号曾经是Seven，即星际迷航中的Borg(博格人)。Kubernetes标识中舵轮有七个轮辐就是对该项目代号的致意。
Kubernetes v1.0于2015年7月21日发布。 随着v1.0版本发布，谷歌与Linux 基金会合作组建了Cloud Native Computing Foundation (CNCF)[并将Kubernetes作为种子技术来提供。
Rancher Labs在其Rancher容器管理平台中包含了Kubernetes的发布版。Kubernetes也在很多其他公司的产品中被使用，例如Red HatOpenShift， CoreOS的Tectonic， 以及IBM的IBM私有云产品，以及 VMware的PKS等等。
设计
Kubernetes在设计结构上定义了一系列的构建模块，其目的是为了提供一个可以共同提供部署、维护和扩展应用程序的机制。组成Kubernetes的组件设计概念为松耦合和可扩展的，这样可以使之满足多种不同的工作负载。可扩展性在很大程度上由Kubernetes API提供，此API主要被作为扩展的内部组件以及Kubernetes上运行的容器来使用。
Pod
Kubernetes的基本调度单元称为“pod”。通过该种抽象类别可以把更高级别的抽象内容增加到容器化组件。一个pod一般包含一个或多个容器，这样可以保证它们一直位于主机上，并且可以共享资源。Kubernetes中的每个pod都被分配一个唯一的（在集群内的）IP地址这样就可以允许应用程序使用同一端口，而避免了发生冲突的问题。 Pod可以定义一个卷，例如本地磁盘目录或网络磁盘，并将其暴露在pod中的一个容器之中。pod可以通过Kubernetes API手动管理，也可以委托给控制器来实现自动管理。
标签和选择器
Kubernetes使客户端（用户或内部组件）将称为“标签”的键值对附加到系统中的任何API对象，如pod和节点。相应地，“标签选择器”是针对匹配对象的标签的查询方法。
标签和选择器是Kubernetes中的主要分组机制，用于确定操作适用的组件。
例如，如果应用程序的Pods具有系统的标签 tier (比如"front-end"、"back-end") 和一个 release_track (比如"canary"、"production")，那么对所有"back-end" 和 "canary" 节点的操作可以使用如下所示的标签选择器：
tier=back-end AND release_track=canary
控制器
控制器是通过管理一组pod来实现来将实际集群状态转移到所需集群状态的对帐循环机制。一种控制器指的是一组具有相同特征的“复制控制器”，控制器通过在集群中运行指定数量的pod副本来处理复制和缩放。在基础节点出现故障的情况下，它还可以用于处理创建替换pod。[22]其它控制器也是核心Kubernetes系统的一部分，包括“DaemonSet控制器”为每台机器（或机器的一些子集）上运行的单个pod，和用于运行pod的“作业控制器”。 控制器管理的pod组由作为控制器定义的部分的标签选择器来确定。
服务
Kubernetes服务本质是一组协同工作的pod，类同多层架构应用中的一层。构成服务的pod组通过标签选择器来定义。Kubernetes通过给服务分配静态IP地址和域名来提供服务发现机制，并且以轮循调度的方式将流量负载均衡到能与选择器匹配的pod的IP地址的网络连接上（即使是故障导致pod从一台机器移动到另一台机器）。 默认情况下，服务任务会暴露在集群中（例如，多个后端pod可能被分组成一个服务，前端pod的请求在它们之间负载平衡）；除此以外，服务任务也可以暴露在集群外部（例如，从客户端访问前端pod）。
建构
Kubernetes遵循主从式架构设计。Kubernetes的组件可以分为管理单个的 node 组件和控制平面部分的组件。
Kubernetes Master是集群的主要控制单元，其用于管理其工作负载并指导整个系统的通信。Kubernetes控制平面由各自的进程组成，每个组件都可以在单个主节点上运行，也可以在支持high-availability clusters的多个主节点上运行。是Kubernetes控制平面的各种组件如下：
etcd
etcd 是由CoreOS开发，用于可靠地存储集群的配置数据的一种持久性，轻量型的，分布式的键-值数据存储组件。该组件可表示在任何给定时间点处的集群的整体状态。其他组件在注意到存储的变化之后，会变成相应的状态。
API服务器
API服务器是一个关键组件 并使用 Kubernetes API 和 JSON over HTTP来提供了Kubernetes的内部和外部接口。 API服务器处理和验证 REST请求并更新 API 对象的状态etcd，从而允许客户端在Worker节点之间配置工作负载和容器。
调度器
T调度程序是可插拔式组件，其基于资源可用性来选择未调度的pod（由调度程序管理的基本实体）应该运行哪个节点。调度程序跟踪每个节点上的资源利用率，以确保工作负载不会超过可用资源。为此，调度程序必须知道资源需求，资源可用性以及各种其他用户提供的约束和策略指令，例如服务质量，亲和力/反关联性要求，数据位置等。实质上，调度程序的作用是将资源“供应”与工作负载“需求”相匹配以维持系统的稳定和可靠。
控制器管理
控制器管理器是核心Kubernetes控制器，其包括DaemonSet控制器和复制控制器等。该控制器可与API服务器进行通信以在需要时创建，更新和删除他们管理的资源（pod，服务端点等）
Kubernetes 节点
Node也称为Worker或Minion，是部署容器（工作负载）的单机器（或虚拟机）。集群中的每个节点都必须具备容器的运行环境（runtime） ——比如 Docker，以及下面提到的其他组件，以便与这些容器的网络配置进行通信。
Kubelet
Kubelet负责每个节点的运行状态（即确保节点上的所有容器都正常运行）。它按照控制面板的指示来处理启动，停止和维护应用程序容器（按组织到pod中）。
Kubelet会监视pod的状态，如果不处于所需状态，则pod将被重新部署到同一个节点。节点状态每隔几秒就会传递消息至中继主机。主控器检测到节点故障后，复制控制器将观察此状态更改，并在其他健康节点上启动pod。[来源请求]
容器
容器从属于pod。在运行应用、库及其依赖的微服务中，容器是最低层级的。通过绑定一个外部IP，容器可以被外网访问。
Kube代理
Kube代理是网络代理和负载均衡的实现，支持服务抽象以及其他网络操作。根据传入请求的IP和端口，该组件会将流量转发到指定的合适的容器中。
cAdvisor
cAdvisor 是监视和收集例如每个节点上的容器的CPU，内存，文件和网络使用情况等的资源使用情况和性能指标的代理组件。
##2.2. K8s中的对象
1. k8s中的对象
K8s中常用的对象分类有以下几种：
workload类，即工作负载类对象
pod
controller
deployment
stateful
daemonset
job
discovery & loadbalance类，与网络传输相关的对象
service
endpoint
ingress
config&storage，数据存储、配置存储类型的对象
configmap
secret
volume
persistentVolumeClaim
cluster，集群类对象
Node
namespace
persitenceVolume
clusterRole
ClusterRoleVindeing
ResoruceQuota
工作负载，以pod为中心
pod是一个容器集合。
Pod是集群中可以创建和部署的最小且最简单的Kubernetes对象的单元。
Pod也是一种封装。它封装了应用容器，存储资源、独立的网络IP以及决定容器如何运行的策略选项。
每个pod中预置了一个Pause容器，其namespace、IPC资源、网络和存储资源被pod内其它容器共享。Pod中的所有容器紧密协作，并且作为一个整体被管理、调度和运行。
2. Pod
pod是一个非持久化实体。
pod有以下几个生命周期：
pending，即挂起，即pod对象已经被kubernetes所接受，等待创建。
running，运行中，pod已经绑定到node上，所有pod中所有容器已经创建。
succeed，成功状态，pod的所有的容器已经成功终止。
failed，失败状态，即有最少又一个容器正常退出。
3. service
pod是一个非持久化的实体随时都有可能被销毁掉或者重新创建，所以pod的所在节点是不确定的，而service就是用于将pod固定在某一个ip上，
servie是与云原生应用中“微服务”概念一一对应。
kubernetes集群为每一个service分配一个集群唯一的IP地址，在 service的生命周期内，该ip地址不变；在内部DNS指出下，轻松实现服务发现机制。
service通过label selector关联到实际支撑业务运行的pod上，并通过集群内置的服务负载均衡分发到后端pod上。
通过nodeport或者设置loadbalance机制实现集群外部对service的访问。
##2.3. Pod生命周期
本文转自：https://juejin.im/post/5cc008745188250a9c356107
简述
Kubernetes 是一种用于在一组主机上运行和协同容器化应用程序的系统，提供应用部署、规划、更新维护的机制。应用运行在 kubernetes 集群之上，实现服务的扩容、缩容，执行滚动更新以及在不同版本的应用程序之间调度流量以测试功能或回滚有问题的部署。Kubernetes 实现管理服务的各项功能是通过定义各种类型的资源来实现的，如 deployment、pod、service、volume 等。下面通过该文章来简述 pod 的基础信息并详述 pod 的生命周期。
Pod简介
Pod 是 kubernetes 系统的基础单元，是由用户创建或部署的最小组件，也是 kubernetes 系统上运行容器化应用的资源对象。Kubernetes 集群中其他资源对象都是为 pod 这个资源对象做支撑来实现 kubernetes 管理应用服务的目的。
Kubernetes 集群组件主要包括主节点组件API Server、Controller Manager、Scheduler 以及子节点组件 kubelet、container Runtime（如docker）、kube-proxy 等。从与集群各组件交互角度讲述 pod 的创建、运行、销毁等生命周期，Pod 生命周期中的几种不同状态包括pending、running、succeeded、failed、Unknown。
与API Server交互
API Server 提供了集群与外部交互的接口，通过 kubectl 命令或者其他 API 客户端提交 pod spec 给 API Server 作为pod创建的起始。
Pod 与 API Server 交互的主要流程如下：
API Server 在接收到创建pod的请求之后，会根据用户提交的参数值来创建一个运行时的pod对象。
根据 API Server 请求的上下文的元数据来验证两者的 namespace 是否匹配，如果不匹配则创建失败。
Namespace 匹配成功之后，会向 pod 对象注入一些系统数据，如果 pod 未提供 pod 的名字，则 API Server 会将 pod 的 uid 作为 pod 的名字。
API Server 接下来会检查 pod 对象的必需字段是否为空，如果为空，创建失败。
上述准备工作完成之后会将在 etcd 中持久化这个对象，将异步调用返回结果封装成 restful.response，完成结果反馈。
至此，API Server 创建过程完成，剩下的由 scheduler 和 kubelet 来完成，此时 pod 处于 pending 状态。
与scheduler交互
当提交创建 pod 的请求与 API Server 的交互完成之后，接下来由 scheduler 进行工作，该组件主要是完成 pod 的调度来决定 pod 具体运行在集群的哪个节点上。注意，此处声明一点，API Server 完成任务之后，将信息写入到 etcd 中，此时 scheduler 通过 watch 机制监听到写入到 etcd 的信息然后再进行工作。
Scheduler 读取到写入到 etcd 中的 pod 信息，然后基于一系列规则从集群中挑选一个合适的节点来运行它，调度时主要通过三步来确定 pod 运行节点：
节点预选：基于一系列预选规则（如 PodFitsResource 和 MatchNode-Selector 等）对每个节点进行检查，将不符合的节点过滤掉从而完成节点预选。
节点优选：对预选出的节点进行优先级排序，以便选出最适合运行 pod 对象的节点。
从优先级结果中挑选出优先级最高的节点来运行 pod 对象，当此类节点多个时则随机选择一个。
注：如果有特殊 pod 资源需要运行在特殊节点上，此时可以通过组合节点标签以及 pod 标签和标签选择器等来实现高级调度，如 MatchInterPodAffinity、MatchNodeSelector 和 PodToleratesNodeTaints 等预选策略，他们为用户提供自定义 Pod 亲和性或反亲和性、节点亲和性以及基于污点及容忍度的调度机制。
预选策略
预选策略就是节点过滤器，例如 MathNodeSelector 实现的规则，以及 PodFitsResources 实现的规则等。执行预选操作时，如果不存在适合的节点，此时 pod 会一直处于 pending 状态，直到至少有一个可用节点。
支持的预选策略列举一下（1.10版本）：
CheckNodeCondition
General
NoDiskConflict
PodToleratesNodeTaintsPodToleratesNodeNoExecuteTaints
CheckServiceAffinity
MaxEBsVolumeCount
MaxGCEPDVolumeCount
MaxAzureDiskVolumeCount
CheckVolumeBinding
NoVolumeZoneConflict
CheckNodeMemoryPressure
CheckNodePIDPressure
CheckNodeDiskPressure
MatchInterPodAffinity
简单介绍几种：
CheckNodeCondition：检查是否可以在节点报告磁盘、网络不可用或未准备好的情况下将 pod 对象调度其上。
NoDiskConflict：检查 pod 对象请求的存储卷在此节点上是否可用，若不存在冲突则通过检查。
MathNodeSelector：若 pod 对象定义了 spec.NodeSelector 属性，则检查节点标签是否能匹配此属性值。
优选函数
常用优选函数：
BalancedResourceAllocation
LeaastRequstedPriority
NodePreferAvoidPodsPriority
NodeAffinityPriority
TaintTolerationPriority
InterPodAffinityPriority
SelectorSpreadPriority
NodeLabelPriority
MostRequestedPriority
ImageLoccalityPriority
此外调度器支持为每个优选函数指定一个简单的整数值表示权重，进行节点优先级分值的计算，计算公式如下：
FinalScoreNode = (weight1 * priorityFunc1) + (weight2 * priorityFunc2)+ ....
列举说明几个优选函数：
TaintToleraionPriority：基于Pod资源对节点的污点容忍调度偏好进行其优先级的评估，它将 Pod 对象的 tolerations 列表与节点的污点进行匹配度检查，成功匹配的条目越多，则节点得分越低。
NodeAffinityPriority：基于节点亲和性调度偏好进行优先级评估，它将根据 Pod 资源中的 nodeSelector 对给定节点进行匹配度计算，成功匹配到的条目越多则节点得分越高。
对于上述节点调度中还包括一些节点亲和度：硬亲和度和软亲和性、资源亲和调度。硬亲和调度和软亲和调度以及反亲和调度、污点容忍度等，都是 pod 调度的策略，不一一详述。
当 scheduler 通过一系列策略选定 pod 运行节点之后将结果信息更新至 API Server，由 API Server 更新至 etcd 中，并由 API Server 反映调度结果，接下来由 kubelet 在所选定的节点上启动 pod。
Kubelet组件启动pod
kubelet 组件的作用不单单是创建 pod，另外还包括节点管理、cAdvisor 资源监控管理、容器健康检查等功能。
启动pod流程分析
kubelet 通过 API Server 监听 etcd 目录，同步 pod 列表。如果发现有新的 pod 绑定到本节点，则按照 pod 清单要求创建 pod，如果是发现 pod 被更新，则做出相应更改。
读取到 pod 的信息之后，如果是创建和修改 pod 的任务，则做如下处理：
为该 pod 创建一个数据目录
从 API Server 读取该 pod 清单
为该 pod 挂载外部卷
下载 pod 所需的 Secret
检查已经运行在节点中 pod，如果该 pod 没有容器或者 Pause 容器没有启动，则先停止pod里所有的容器进程。
使用 pause 镜像为每个pod创建一个容器，该容器用于接管 Pod 中所有其他容器的网络。
为 pod 中的每个容器做如下处理：1.为容器计算一个 hash 值，然后用容器的名字去查询对于 docker 容器的 hash 值。若查找到容器，且两者的 hash 值不同，则停止 docker 中容器中进程，并停止与之关联的 pause 容器，若相同，则不做处理。若容器被终止了，且容器没有指定的重启策略，则不做任何处理调用 docker client 下载容器镜像，并启动容器。
详述pod声明周期中的重要行为
除了创建应用容器（主容器及辅助容器之外，注意，如果集群中部署了 istio，则会在 pod 启动的时候注入一个新的和 istio 相关的容器，那是另一个美好故事的开端），还可以为 pod 对象定义其声明周期中的多种行为，如初始化容器、容器探测以及就绪性探测等。
容器生命周期的几种行为
初始化容器
初始化容器即 pod 内主容器启动之前要运行的容器，主要是做一些前置工作，初始化容器具有以下特征：
初始化容器必须首先执行，若初始化容器运行失败，集群会一直重启初始化容器直至完成，注意，如果 pod 的重启策略为 Never，那初始化容器启动失败后就不会重启。
初始化容器必须按照定义的顺序执行，初始化容器可以通过 pod 的 spec.initContainers 进行定义。
声明周期钩子函数
Kubernetes 为容器提供了两种生命周期钩子：
Poststart:于容器创建完成之后立即运行的钩子程序。
preStop:容器终止之前立即运行的程序，是以同步方式的进行，因此其完成之前会阻塞 删除容器的调用
备注：钩子程序的执行方式有“Exec”和“HTTP”两种。
容器探测
容器探测分为存活性探测和就绪性探测容器探测是kubelet对容器健康状态进行诊断，容器探测的方式主要以下三种：
ExecAction：在容器中执行命令，根据返回的状态码判断容器健康状态，返回0即表示成功，否则为失败。
TCPSocketAction: 通过与容器的某TCP端口尝试建立连接进行诊断，端口能打开即为表示成功，否则失败。
HTTPGetAction：向容器指定 URL 发起 HTTP GET 请求，响应码为2xx或者是3xx为成功，否则失败。
Pod终止过程
终止过程主要分为如下几个步骤：
用户发出删除 pod 命令
Pod 对象随着时间的推移更新，在宽限期（默认情况下30秒），pod 被视为“dead”状态
将 pod 标记为“Terminating”状态
第三步同时运行，监控到 pod 对象为“Terminating”状态的同时启动 pod 关闭过程
第三步同时进行，endpoints 控制器监控到 pod 对象关闭，将pod与service匹配的 endpoints 列表中删除
如果 pod 中定义了 preStop 钩子处理程序，则 pod 被标记为“Terminating”状态时以同步的方式启动执行；若宽限期结束后，preStop 仍未执行结束，第二步会重新执行并额外获得一个2秒的小宽限期
Pod 内对象的容器收到 TERM 信号
宽限期结束之后，若存在任何一个运行的进程，pod 会收到 SIGKILL 信号
Kubelet 请求 API Server 将此 Pod 资源宽限期设置为0从而完成删除操作
此外 kubelet 除了启动之外，kubelet 中还有 cAdvisor，用于收集容器 CPU、内存、文件系统和网络使用情况等信息，与 prometheus 结合实现对集群内 pod 监控。
此外，除了上述三个组件在创建 pod 过程中的交互，还有 controller-manager 来保证 pod 处于用户期望状态（即保证 pod 永远处于存活状态）等功能以及 proxy 用于集群内 pod 之间通信等。
##2.4. Helm是什么
本文转自：https://juejin.im/entry/5b4f09035188251ac446ded1
Helm介绍
在Kubernetes中部署容器云的应用也是一项有挑战性的工作，Helm就是为了简化在Kubernetes中安装部署容器云应用的一个客户端工具。通过helm能够帮助开发者定义、安装和升级Kubernetes中的容器云应用，同时，也可以通过helm进行容器云应用的分享。在Kubeapps Hub中提供了包括Redis、MySQL和Jenkins等参见的应用，通过helm可以使用一条命令就能够将其部署安装在自己的Kubernetes集群中。
helm的整体架构如下图所示，Helm架构由Helm客户端、Tiller服务器端和Chart仓库所组成；Tiller部署在Kubernetes中，Helm客户端从Chart仓库中获取Chart安装包，并将其安装部署到Kubernetes集群中。
Helm是管理Kubernetes包的工具，Helm能提供下面的能力：
创建新的charts
将charts打包成tgz文件
与chart仓库交互
安装和卸载Kubernetes的应用
管理使用Helm安装的charts的生命周期
在Helm中，有三个需要了解的重要概念：
chart：是创建Kubernetes应用实例的信息集合；
config：创建发布对象的chart的配置信息
release：chart的运行实例，包含特定的config
Helm组件
在Helm中有两个主要的组件，既Helm客户端和Tiller服务端：
Helm客户端，这是一个供终端用户使用的命令行工具，客户端负责以下的工作：
本地chart开发
管理仓库
与Tiller服务器交互
发送需要被安装的charts
请求关于发布版本的信息
请求更新或者卸载已安装的发布版本
Tiller服务端： Tiller服务部署在Kubernetes集群中，Helm客户端通过与Tiller服务器进行交互，并最终与Kubernetes API服务器进行交互。 Tiller服务器负责如下的工作：
监听来自于Helm客户端的请求
组合chart和配置来构建一个发布
在Kubernetes中安装，并跟踪后续的发布
通过与Kubernetes交互，更新或者chart
客户端负责管理chart，服务端负责管理发布。
Helm技术实现
Helm客户端是使用Go语言编写的，它通过gRPC协议与Tiller服务器交互。
Tiller服务器也是使用Go语言编写的，它使用Kubernetes客户端类库与Kubernetes进行通讯。
Tiller服务器通过Kubernetes的ConfigMap存储信息，因此本身没有用于存储数据库。
##2.4. Helm的使用
1. helm下载安装
下载地址为：
https://github.com/helm/helm/releases
helm分为服务端与客户端，服务端为Tiller，客户端为helm。
解压后，将helm添加到PATH量里，方便执行。
服务端安装的话，需要有一个k8s集群，同时本地能访问该集群（即kubectl工具能正常使用）
安装Tiller
helm init --stable-repo-url=https://burdenbear.github.io/kube-charts-mirror --tiller-namespace=kube-system --skip-refresh=true --service-account=tiller
由于防火墙的存在，helm自带的仓库被墙，stable-repo-url是为了将默认仓库替换为国内可访问的一个镜像地址。
tiller-namespaces是指将tiller安装于相应的k8s namespace。
service-account指定相应的k8s serviceAccount，比较重要。
若对镜像有要求，可以通过tiller-image指定镜像。
更多参数，请参考
helm init help
将以下内容，保存成一个文件，比如helm-sa.yaml
kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: tiller
namespace: kube-system
subjects:
- kind: ServiceAccount
name: tiller
namespace: kube-system
roleRef:
kind: ClusterRole
name: cluster-admin
apiGroup: rbac.authorization.k8s.io
---
apiVersion: v1
kind: ServiceAccount
metadata:
name: tiller
namespace: kube-system
labels:
kubernetes.io/cluster-service: "true"
执行：
kubectl apply -f helm-sa.yaml
服务端安装完成，可以通过以下命令来验证：
kubectl get pod -n kube-system | grep tiller
安装helm客户端
helm init -c --stable-repo-url=https://burdenbear.github.io/kube-charts-mirror
通过以下命令验证：
helm version
若一切正常，可以看到服务端与本地客户端的版本信息。同时意味着，连接服务端已成功。
2. 使用helm安装一个nginx
helm install stable/nginx
该命令的意思是：安装（install）stable仓库里的nginx
提示成功后，可以通过以下命令查看相应的Release状态
helm list
相关参数的使用帮助，都可以通过help命令来获取。
比如:
helm help
helm install help
helm repo help
helm package help
3. helm仓库
什么是chart包：chart包是helm描述相关应用信息的一种格式文件，可以认为是一个安装程序，类似yum的rpm文件。
什么是helm仓库：helm仓库其实为chart仓库。是存放chart包的地方。
前面安装nignx的时候，我们用到helm自带的chart仓库stable。
通过以下命令，可以查看当前仓库列表：
helm repo list
由于大部分公开的chart仓库，并不支持上传，或者有严格的审核制度，因此大部分情况，我们都需要自己创建一个私有的chart仓库。推荐使用ChartMuseum作为自己的私有仓库。（也可以直接使用harbor1.6.0+）
这边假设我们已经安装好，并且相应的仓库地址为：http://my.repo.com/maybeStable
在helm客户端这边将此远程仓库添加到本地：
helm repo add myRepoName http://my.repo.com/maybeStable
并执行来更新相应的chart仓库索引：
helm repo update
之后，便可以使用该仓库里的所有chart包了。
官方维护的stable的chart项目：（可搜索相关项目）
https://github.com/helm/charts/tree/master/stable
图形化界面：
官方仓库：
google提供的：（google自家用的，不保证对外可用，但是大部分是可用的）
stable仓库：
https://console.cloud.google.com/storage/browser/kubernetes-charts
incubator仓库：
https://console.cloud.google.com/storage/browser/kubernetes-charts-incubator
kubeapps提供：
非图形化，直接获取index.yaml
https://charts.bitnami.com/bitnami/index.yaml
此文件为该仓库所有charts的索引文件，可以找到对应的chart包下载地址。
大部分仓库都可以通过获取index.yaml来获取该仓库的索引文件，进而获取相关的chart。
index.yaml的地址，一般为：仓库地址+/index.yaml
比如bitnami这边的仓库地址为：https://charts.bitnami.com/bitnami，对应的index.yaml地址即为https://charts.bitnami.com/bitnami/index.yaml
4. 创建自己的chart包
使用命令：
helm create myChart
即可创建一个默认模板的chart包，在此模板基础上进行自己的chart内容配置即可。
5. 打包一个chart包
在chart包的上级目录，（即当前目录可看到myChart文件夹），执行以下命令：
helm package myChart
根据chart包里面的配置文件（Chart.yaml）生成对应版本，对应名称的tgz包（即chart包）
6. 上传chart包到远程仓库
若使用网宿的容器服务，可以直接通过容器服务的"本地仓库"里面的上传功能。
若使用harbor，可直接在harbor的界面上进行操作。
若使用ChartMuseum，可以使用以下push插件。
https://github.com/chartmuseum/helm-push
将本地chart，push到对应的仓库，这边用push一个目录(myChart)的方式来举例：
helm push myChart/ myRepoName
该命令的意思是，将myChart这个目录，打包成对应的chart包，并且上传到myRepoName这个远程仓库里。myRepoName是前面添加的仓库。
