你想要学习k8s吗？如果想要学习k8s就需要了解什么是k8s，这篇文章通过图文形式很好地解释了k8s到底是什么，正所谓众里寻他千百度，蓦然回首，那人却在，灯火阑珊处。只有读到通俗易懂的文章你才不会迷路，下面开始跟随我进入到k8s学习之旅吧。

kubernetes基本结构介绍

Kubernetes（来自希腊语，意为“舵手”或者“飞行员”又称为k8s），它是谷歌开源的容器集群管理系统，是谷歌多年大规模容器管理技术Borg的开源版本。是目前最流行的容器编排技术。

它由谷歌在2014年首次对外宣布 。它的开发和设计都深受谷歌的Borg系统的影响，它的许多顶级贡献者之前也是Borg系统的开发者。在谷歌内部，Kubernetes的原始代号曾经是Seven，即星际迷航中友好的Borg(博格人)角色。Kubernetes标识中舵轮有七个轮辐就是对该项目代号的致意。

Kubernetes v1.0于2015年7月21日发布。随着v1.0版本发布，谷歌与Linux 基金会合作组建了Cloud Native Computing Foundation (CNCF)并把Kubernetes作为种子技术来提供。目前最新的版本是1.20.4版本。（https://github.com/kubernetes/kubernetes）

Kubernetes 的目标旨在消除编排物理/虚拟计算，网络和存储基础设施的负担，并使应用程序运营商和开发人员完全将重点放在以容器为中心的业务上进行自助运营。Kubernetes 也提供稳定、兼容的基础（平台），用于构建定制化的workflows 和更高级的自动化任务。Kubernetes 具备完善的集群管理能力，包括多层次的安全防护和准入机制、多租户应用支撑能力、透明的服务注册和服务发现机制、内建负载均衡器、故障发现和自我修复能力、服务滚动升级和在线扩容、可扩展的资源自动调度机制、多粒度的资源配额管理能力。

Kubernetes 还提供完善的管理工具，涵盖开发、部署测试、运维监控等各个环节。

Kubernetes特性：

自动装箱：构建于容器之上，基于资源依赖和其他约束自动完成容器部署。

自我修复：容器故障后自动重启、节点故障后重新调度容器，以及容器自我修复机制。

水平扩展：通过简单明了实现水平扩展，基于CPU等资源负载率的自动水平扩展。

服务发现和负载均衡：实现内部负载均衡可以实现服务访问负载。

自动发布和回滚：可以自动实现版本的发布和回滚。

密钥和配置管理：对于密码等信息，专门提供了Secert对象为其解耦。

存储编排：支持多种不同类型的存储，包括本地存储、云存储、网络存储等。

批量处理执行：除服务型应用，还支持批处理作业CI（持续集成），如有需要，一样可以实现容器故障后修复。

Kubernetes特点：

可移植: 支持公有云，私有云，混合云，多重云（multi-cloud）

可扩展: 模块化, 插件化, 可挂载, 可组合

自动化: 自动部署，自动重启，自动复制，自动伸缩/扩展

Kubernetes架构组成：

主节点（Master）

Master是集群的控制节点，每个k8s集群中至少需要一个Master节点来维护整个集群的管理和控制，几乎所有的控制命令都是发给它，它负责执行具体的动作。它很重要，如果它不可用，那么我们所有的控制命令都会失效。

Master节点上运行一组关键进程：

API Server API服务器（kube-apiserver）：提供HTTP Rest接口的关键服务，是k8s集群里所有资源的增删查改等操作的唯一入口，也是集群控制的入口进程。并提供认证、授权、访问控制、API注册和发现等机制

Controller Manager控制管理器（kube-controller-manager）：k8s里所有资源对象的自动化控制中心，可以理解为资源对象的“大总管”。运行着所有处理集群日常任务的控制器。包括节点控制器、副本控制器、端点控制器及服务账号

和令牌控制器。负责维护集群的状态，比如故障检测、自动扩展、滚动更新等。

Scheduler调度器（kube-scheduler）：负责资源调度（Pod调度）的进程，相当于“调度室”。按照预定的调度策略将Pod调度到相应的机器上

etcd：集群的数据存储，他存储着集群中所有的资源对象。数据存储采用的是键值对存储。保存了整个集群的状态。

工作节点（Node/Worker）

Node是集群的工作节点，运行具体的Pod，当某个Node宕机时，其工作负载会被Master自动转移到其他Node节点上。

默认情况下kubelet会向Master注册自己。一旦Node被纳入集群管理，kubelet进程就会定时向Master节点汇报自身的情况，比如操作系统等信息，这样Master就可以获取每个Node节点的资源使用情况合理的进行调度。如果Node节点在指定时间不上报，那么Master就会认为它“失联”，标记成“Not Ready”状态。

Node节点上运行一组关键进程：

kubelet：主节点代理，负责Pod对应的容器的创建启停等任务，同时与Master节点密切协作，实现集群管理的基本功能。

kube-proxy：它负责节点的网络，在主机上维护网络规则并执行连接转发。它还负责对正在服务的pods进行负载平衡。比如一个服务可能会运行多个副本（Pod），由他来控制具体由哪个Pod提供服务。为Service提供cluster内部的服务发现和负载均衡。

Docker Engine（docker）：docker引擎，负责本机的容器创建和管理工作。

Pod

Pod是一组紧密关联的容器集合，它们共享PID、IPC、Network和UTS namespace，是Kubernetes调度的基本单位。

Pod的设计理念是支持多个容器在一个Pod中共享网络和文件系统，可以通过进程间通信和文件共享这种简单高效的方式 组合完成服务。 每个Pod都有一个特殊的称之为“根容器”的Pause容器。Pause容器对应的镜像属于k8s平台的一部分，除了Pause容器外，每个Pod还包含一个或多个紧急相关的用户业务容器。他为每个业务容器提供如下功能：

①在pod中担任Linux命名空间共享的基础。

②启用pid命名空间，开启init进程。

引入这种方式的原因：

1. 一组容器运行的pod中，很难对整体进行判断，引入pasue作为根容器， 以他的状态代表整个容器组的状态。

2. pod中多个容器共享pasue容器的IP，共享pause容器挂载的volume。 这样简化了密切相连的容器之间的通信，也解决了他们之间文件共享的问题。 k8s为每一个pod都分配唯一的IP地址，称之为pod ip，一个pod中的多个容器共享 pod ip地址。k8s要求底层网络支持集群内任意两个pod之间网络通信，采用虚拟二层技术实现，比如flanne、calico、ovs。k8s中，一个pod的容器与另外主机上的pod 容器能够直接通信。

pod分两种：普通pod和静态pod（static pod）

普通pod：一旦被创建，会被放到etcd中存储，随后被k8s master调度到某个具体的node上并进行绑定，随后该pod被对应的node上的kubelet进程实例化成一组相关的docker容器并启动起来。默认情况下，当pod中的某个容器停止时，K8s会自动检测到这个问题并重新启动这个pod（重启pod里面的所有容器），如果pod所在的node宕机，则会将这个node上的所有pod重新调度到其他节点上。

静态pod：不存储在etcd中，而是存放在某个具体的node上的一个具体文件中，并只在此node上启动运行。每个pod可以设置限额，目前可以设置CPU和内存，cpu的单位为core的数量，是一个绝对值而不是相对值。k8s中是以千分之一为最小单位，一般一个pod设置为100m到300m，也是就是0.1-0.3个cpu。内存是以MB为单位

k8s设置2个参数：

requests:该资源的最小申请量，系统必须满足的要求

limits：该资源的最大允许使用的量，不能被突破，当容器试图使用超过这个量的资源时，有可能会被k8s kill并重启。

Pod对象生命周期

Pod 对象在 Kubernetes 中的生命周期。Pod 生命周期的变化，主要体现在 Pod API 对象的Status 部分。其中pod.status.phase，就是 Pod 的当前状态，它有如下几种可能的情况：

Pending，Running，Succeeded，Failed，Unknown

1.Pending。这个状态意味着，Pod 的 YAML 文件（或通过kubectl命令创建Pod）已经提交给了Kubernetes，API对象已经被创建并保存在Etcd当中。但是，这个 Pod 里有些容器因为某种原因而不能被顺利创建。比如，调度不成功。

2.Running。这个状态下，Pod 已经调度成功，跟一个具体的节点绑定。它包含的容器都已经创建成功，并且至少有一个正 在运行中。

3.Succeeded。这个状态意味着，Pod 里的所有容器都正常运行完毕，并且已经退出了。这种情况在运行一次性任务时最 为常见。

4.Failed。这个状态下，Pod 里至少有一个容器以不正常的状态（非 0 的返回码）退出。这个状态的出现，意味着你得想办 法 Debug 这个容器的应用，比如查看 Pod 的 Events 和日志。

5.Unknown。这是一个异常状态，意味着 Pod 的状态不能持续地被 kubelet 汇报给 kube-apiserver，这很有可能是主从节点（Master 和 Kubelet）间的通信出现了问题。 更进一步地，Pod 对象的Status 字段，还可以再细分出一组 Conditions。这些细分状态的值包括：PodScheduled、 Ready、Initialized，以及 Unschedulable。它们主要用于描述造成当前Status 的具体原因是什么。比如，Pod 当前的 Status 是 Pending，对应的 Condition 是 Unschedulable，这就意味着它的调度出现了问题。 Pod 的这些状态信息，是我们判断应用运行情况的重要标准，尤其是 Pod 进入了非“Running”状态后，你一定要能迅速做出反应，根据它所代表的异常情况开始跟踪和定位，而不是去手忙脚乱地查阅文档。

Label（标签）

Lable是一个key-value键值对，由用户自己制定。可以附加在各种资源上，比如node 、pod、svc、rc等，一个对象资源可以定义任意数量的Lable，同时一个lable也可以被添加到任意数量的资源对象上去，Lable可以在资源对象定义时确定，也可以在对象创建后动态添加和删除。

我们可以使用指定的资源对象绑定一个或者多个不同的lable来实现多维度的资源分组管理功能，以便于灵活、方便的对资源进行分配、调度、配置、部署等工作。

Lable就是给资源对象打一个标签，然后通过Label Secletor（标签选择器）查询和筛选拥有某些Label的资源对象，k8s通过这种方式实现了类似SQL的简单和通用的对象查询机制。

标签选择器可以类比SQL语句中的where查询条件，例如name=redis-salve 表示只查询名字为redis-salve的资源对象。

env != production: 匹配所有不具有标签 env = production 的资源对象。

name in（redis-master，redis-salve）：匹配所有带有标签name=master或者name=salve的资源

name not in （php）：匹配所有不具有标签name=php的资源对象也可以多个条件一起使用。

标签和标签选择器共同构成了k8s系统中最核心的应用模型，使得被管理对象能够被精细的分组管理，同时实现了整个集群的高可用性。

RC

RC Replication Controller（副本管理器）和RS（Replica Set）： RC定义了一个期望的场景，即声明某种Pod的副本数量在任意时刻都符合某个预期值。

RC包含如下几部分：

Pod期待的副本数（replicas）

用于筛选目标Pod的Label Selector

当Pod的副本数量小于预期数量的时候，用于创建新Pod的Pod模板（template）

当定义一个RC之后，master节点的controller manager组件就得到通知，定期巡检系统中存活的目标pod，并确保目标pod实例的数量刚好等于此rc的期望值，如果有过多pod运行，系统就会停掉一些，否则会创建一些。通过rc， kubenetnes实现了用户应用集群的高可靠性，并大大减少了很多运维工作。

Replication Controller在k8s 1.2版本之后升级成了新的概念，Replica Set（下一代RC），Replicas Set支持基于集合的标签选择器，而RC只支持基于等式的标签选择器。

Replicas Set的一些作用和特性：

1.大多数情况下，我们通过定义一个RC实现Pod的创建过程及副本数量的自动控制

2.RC里面包含完整的Pod定义模板

3.RC通过标签选择器机制实现对Pod的自动控制

4.通过改变RC中的Pod副本数量，可以实现Pod的扩容和缩容功能

5.通过改变RC中的Pod模板中的镜像版本，可以实现Pod的滚动升级功能

Deployment（部署）

部署是一个比RS（Replica Set）应用模式更广的API对象，可以是创建一个新的服务，更新一个新的服务，也可以是滚动升级一个服务。滚动升级一个服务，实际是创建一个新的RS，然后逐渐将新RS中副本数增加到理想状态，将旧RS中的副本数减小到0的复合操作；这样一个复合操作用一个RS是不太好描述的，所以用一个更通用的Deployment来描述。 以K8s的发展方向，未来对所有长期伺服型的的业务的管理，都会通过Deployment来管理。 Deployment的几个使用场景：

1.创建一个Deployment 对象来生产对应的Replicas Set并完成Pod副本的创建过程。

2.检查Deployment 的状态看部署动作是否完成。

3.更新Deployment 以创建新的Pod（比如镜像升级）。

4.如果当前Deployment 不稳定，则回滚到一个早先的Deployment版本。

5.挂起或者恢复一个Deployment。

Service（服务）

Service也是k8s里核心的资源对象之一，k8s里面的每个Service就是我们提起的“微服务”，之前所介绍的Pod、RC等资源都是为Service做“嫁衣”的。

Service定义了一个服务的访问入口地址，前端的应用（Pod）通过这个入口地址访问其背后的一组由Pod副本组成的集群实例，Service与其后端Pod副本集群之间是通过Label Selector来实现“无缝对接”的。而RC的作用实际上是保证Service的服务能力和服务质量始终处于预期的标准。通过分析、识别并建模系统中的所有服务的微服务，最终我们的系统由多个提供不同业务功能而又彼此独立的微服务单元所组成，服务之间通过TCP/IP进行通信，从而形成了我们强大而又灵活的弹性网络，拥有了强大的分布式能力、弹性扩展能力、容错能力。

每一个pod都会被分配一个单独的IP地址，每个Pod都提供一个独立的Endpoint（Pod IP+ContainerPort）能被客户端访问，那么现在多个副本组成一个集群来提供服务，那么客户端是如何来访问它们呢？一般的做法是部署一个负载均衡器（软件或者硬件），为这组Pod开启一个对外的服务端口如8080端口，并且将这些Pod的EndPoint列表加入到8080的转发列表中，服务端就可以通过负载均衡器的对外IP+服务端口号访问此服务，而客户端的请求最后会转发到哪个Pod，是由负载均衡器的算法所决定。

运行在Node节点上的kube-proxy进程其实就是一个智能的负载均衡器，他负责把Service的请求转发到后端的某个Pod实例上，并在内部实现服务的负载均衡与会话保持机制。

但是Service不是共用一个负载均衡器的IP地址，而是每个Service分配了一个全局唯一的虚拟IP地址，这个虚拟IP地址成为Cluster IP。这样一来，每个服务就变成了具备唯一IP地址的“通信节点”，服务调用就变成了最基础的TCP/IP网络通信问题。Service一旦创建，k8s就会自动为其分配一个可用的Cluster IP，而且在Service的整个生命周期内，他的Cluster IP不会发生改变。只要用Service的Name与Service的Cluster IP地址做一个DNS域名映射即可完成服务发现。

k8s通过Add-On增值包的方式引入了DNS系统，把服务名作为DNS域名，这样程序就可以直接使用服务名来建立通信连接了。

理解k8s系统里面的三种IP：

Node IP：Node节点的IP地址

Pod IP： Pod的IP地址

Cluster IP： Service的IP地址。

Node IP是k8s集群中每个节点的物理网卡IP地址，他是一个真实存在的物理网络，所有属于这个网络的服务器之间都 能通过这个网络直接通信，不管他们中是否有部分节点不属于这个k8s集群，这个也表明k8s集群之外的节点访问k8s集群 内的某个节点或者TCP/IP服务时，必须使用Node IP进行通信。

Pod IP是每一个Pod的IP，他是Docker Engine根据docker0网桥的IP地址进行分配的，通常是一个虚拟的二层网络。 k8s位于不同Node上的Pod能够直接通信，所以k8s里的一个Pod里面容器访问另一个Pod里面的容器，就是通过Pod IP 所在的虚拟二层网络实现通信的，而真实的TCP/IP流量则是通过Node IP所在的物理网卡流出的。

Cluster IP：他也是一个虚拟的IP，更像一个“伪造”的IP地址。

Job（任务）

Job是K8s用来控制批处理型任务的API对象。批处理业务与长期伺服业务的主要区别是批处理业务的运行有头有尾，而长期伺服业务在用户不停止的情况下永远运行。Job管理的Pod根据用户的设置把任务成功完成就自动退出了。成功完成的标志根据不同的spec.completions策略而不同：单Pod型任务有一个Pod成功就标志完成；定数成功型任务保证有N 个任务全部成功；工作队列型任务根据应用确认的全局成功而标志成功

HPA Horizontal Pod Autoscaler（横向自动扩容）

它属于k8s的资源对象，通过追踪分析RC控制的所有目标Pod的负载变化情况，来确定是否需要针对性地调整Pod的副本数，这是HPA的实现原理。

HPA可以通过以下两种方式作为Pod负载的度量指标：

1. CPUUtilizationPercentage ，目标Pod所有副本自身的CPU利用率的平均值。比如设置Pod Request为0.4，当前为 0.2，那么就是50%。比如如果所有的超过了80% ，那么就自动创建Pod。高峰过去之后自动减少Pod

2. 应用程序自定义的度量指标，比如服务每秒内的相应的请求数（TPS或QPS）

DaemonSet（后台支撑服务集）

长期伺服型和批处理型服务的核心在业务应用，可能有些节点运行多个同类业务的Pod，有些节点上又没有这类Pod 运行；而后台支撑型服务的核心关注点在K8s集群中的节点（物理机或虚拟机），要保证每个节点上都有一个此类Pod运行。节点可能是所有集群节点也可能是通过nodeSelector选定的一些特定节点。典型的后台支撑型服务包括，存储，日 志和监控等在每个节点上支撑K8s集群运行的服务。

Volume（存储卷）

K8s集群中的存储卷跟Docker的存储卷有些类似，只不过Docker的存储卷作用范围为一个容器，而K8s的存储卷的生命周期和作用范围是一个Pod。每个Pod中声明的存储卷由Pod中的所有容器共享。K8s支持非常多的存储卷类型，特别的，支持多种公有云平台的存储，包括AWS，Google和Azure云；支持多种分布式存储包括GlusterFS和Ceph；也支持较容易使用的主机本地目录hostPath和NFS。K8s还支持使用Persistent Volume Claim即PVC这种逻辑存储，使用这种存储，使得存储的使用者可以忽略后台的实际存储技术（例如AWS，Google或GlusterFS和Ceph），而将有关存储实际技术的配置交给存储管理员通过Persistent Volume来配置。

Persistent Volume，PV（持久存储卷）和Persistent Volume Claim，PVC（持久存储卷声明）

PV和PVC使得K8s集群具备了存储的逻辑抽象能力，使得在配置Pod的逻辑里可以忽略对实际后台存储技术的配置， 而把这项配置的工作交给PV的配置者，即集群的管理者。存储的PV和PVC的这种关系，跟计算的Node和Pod的关系是非 常类似的；PV和Node是资源的提供者，根据集群的基础设施变化而变化，由K8s集群管理员配置；而PVC和Pod是资源 的使用者，根据业务服务的需求变化而变化，由K8s集群的使用者即服务的管理员来配置。 PV可以理解成k8s集群找那个的某个网络存储对应的一块存储，与Volume很类似，但有以下区别：

①PV只能提供网络存储，不属于任何Node，但可以在每个Node上访问

②PV并不是定义在Pod之上的，而是独立于Pod之外定义。

③PV目前只有几种类型：GCE Persistent Disks、NFS、RBD、iSCSI、AWS ElasticBlockStore、GlusterFS PV的accessModes属性有以下几类：

ReadWriteOnce：读写权限、并且只能被单个Node挂载

ReadOnlyMany：只读权限，允许被多个Node挂载

ReadWriteMany：读写权限，允许被多个Node挂载

PV的有如下几种状态：

Avaliable（空闲状态）

Bound（已经绑定到某个PVC上）

Release（对应的PVC已经删除，但资源还没有被集群收回）

Failed（PV自动回收失败）

NameSpace（命名空间）

命名空间用于实现多租户的资源隔离。Namespace通过将集群内部的资源对象分配到不同的Namespace中，形成逻辑上分组的不同项目、小组或用户组，便于不同的分组在共享使用整个集群的资源的同时还能被分别管理。 命名空间为K8s集群提供虚拟的隔离作用，K8s集群初始有两个名字空间，分别是默认名字空间default和系统名字空 间kube-system，除此以外，管理员可以创建新的名字空间满足需要。

资源限制

Kubernetes通过cgroups提供容器资源管理的功能，可以限制每个容器的CPU和内存使用，比如对于刚才创建的 deployment，可以通过下面的命令限制nginx容器最多只用50%的CPU和128MB的内存：

$ kubectl set resources deployment nginx-app -c=nginx --limits=cpu=500m,memory=128Mi deployment "nginx" resource requirements updated

Yaml文件中可以通过配置实现相同的效果：

apiVersion: v1

kind: Pod

metadata:

labels:

app: nginx

name: nginx

spec:

containers:

- image: nginx

name: nginx

resources:

limits: cpu: "500m"

memory: "128M

资源对象分类

Kubernetes常见命令介绍

kubectl是k8s客户端CLI工具，可以让用户通过命令行的方式对k8s集群进行操作。

kubectl命令行语法：

kubectl [command] [TYPE] [NAME] {flags}

command:子命令，用于操作k8s集群的资源对象的命令，例如create、delete、describe、get、apply等。

TYPE： 资源对象的类型，区分大小写，能以单数、复数或者简写形式表示。比如Pod可以使用pod、pods、pd

NAME：资源对象的名称，区分大小写，如果不指定名称，则系统返回属于TYPE的全部对象列表，比如kubectl get pods将返回所有Pod的列表

Flags：kubectl子命令的可选参数，例如使用“-s”指定apiserver的URL地址而不用默认值。

1.创建资源对象，使用yaml配置文件一次性创建service和rc

kubectl create –f myservice.yaml –f my-rc.yaml

根据目录下所有的.yaml、yml、json文件的定义进行创建

kubectl create –f <directory>

2. 查看资源对象

kubectl get pods

kubectl get rc，service,node

3.描述资源对象的详细信息（定位问题时需要用到，请重点掌握）

kubectl describe nodes <node-name>

kubectl describe pod <pod-name>

kubectl describe <rc-name>

4. 删除资源对象

kubectl delete –f pod.yaml （删除pod.yaml定义的名称删除Pod）

kubectl delete pods，services –l name=<label-name> （删除所有包含某个标签的pod和service）

kubectl delete pods –all （删除所有的Pod）

注意：如果不先删除RC，直接删除Pod，删除之后，RC又自动去创建这个Pod，就相当于重启这个Pod

5. 执行容器的命令

kubectl exec <pod-name> date 执行Pod的date命令，默认使用Pod的第一个容器

kubectl exec <pod-name> -c <container-name> date 指定Pod中的某个容器执行date命令

kubectl exec –it <pod-name> -c <container-name> /bin/bash 登录进某个Pod的某个容器

6.查看容器的日志

kubectl logs <pod-name> 查看某个pod的日志

kubectl logs –f <pod-name> -c <container-name> 跟踪容器的日志，相当于tail –f

7. 在线修改pod的副本数量

kubectl scale rc <rc-name> --replicas=2 将某个rc的副本数修改为2

注意：修改不会影响yaml文件。

8. 基于一个镜像在k8s集群上启动一个Deployment

kubectl run mytestbusy --image=busybox

9. 将已经存在的一个RC、Service、Deployment或者Pod暴露为一个新的Service

kubectl expose deployment/kubernetes-bootcamp –type=“NodePort”—port 8080

10 滚动更新，在线修改当前运行Pod的镜像

Kubectl set image deployments/kubernetes-bootcamp kubernetes-bootcamp=jocatalin/kubernetesbootcamp:v2

常用技巧

推荐操作之前执行这样一个脚本文件： source /opt/bin/common/tool.sh

这个脚本文件的内容如下，他的作用是对我们常用的命令做了一系列alias别名，比如pod就相当于=‘/opt/bin/kubectl--server=127.0.0.1:8888 get --all-namespaces pod -o wide，让我们更方便快速地执行命令

#!/bin/bash

alias pod='/opt/bin/kubectl --server=127.0.0.1:8888 get --all-namespaces pod -o wide'

alias rc='/opt/bin/kubectl --server=127.0.0.1:8888 get --all-namespaces rc'

alias svc='/opt/bin/kubectl --server=127.0.0.1:8888 get --all-namespaces svc'

alias desc_pod='/opt/bin/kubectl --server=127.0.0.1:8888 describe pod'

alias desc_rc='/opt/bin/kubectl --server=127.0.0.1:8888 describe rc'

alias desc_svc='/opt/bin/kubectl --server=127.0.0.1:8888 describe svc'

alias dimg='docker images'

alias dps='docker ps|grep -v gcr'

alias mtx_log='tailf /opt/matrix/logs/application.log |grep Call'

alias etcd-health='/opt/bin/etcdctl cluster-health'

alias etcd-ls='/opt/bin/etcdctl ls --recursive'

alias kubectl='/opt/bin/kubectl --server=127.0.0.1:8888'