写在前面
本文组织方式：
Kubernetes是什么，即作用和目的。涉及Kubernetes架构的整理，Master和Node之间的关系，以及Kubernetes几个重要的组件：APIServer、Scheduler、Controller、etcd等。
Kubernetes的重要概念，即Kubernetes的API对象，也就是常常听到的Pod、Deployment、Service等。
如何配置kubectl，介绍kubectl工具和配置办法。
如何用kubectl部署服务。
如何用kubectl查看、更新/编辑、删除服务。
如何用kubectl排查部署在Kubernetes集群上的服务出现的问题。
1.Kubernetes概览
1.1Kubernetes是什么？
先看官方介绍：
Kubernetesisanopensourcesystemformanagingcontainerizedapplicationsacrossmultiplehosts.Itprovidesbasicmechanismsfordeployment,maintenance,andscalingofapplications.用于自动部署、扩展和管理“容器化(containerized)应用程序”的开源系统。
翻译成大白话就是：“Kubernetes是负责自动化运维管理多个Docker程序的集群”。那么问题来了：Docker运行可方便了，为什么要用Kubernetes，它有什么优势？
插一句题外话：
为什么Kubernetes要叫Kubernetes呢？维基百科已经交代了(老美对星际是真的痴迷)：
Kubernetes(在希腊语意为“舵手”或“驾驶员”)由JoeBeda、BrendanBurns和CraigMcLuckie创立，并由其他谷歌工程师，包括BrianGrant和TimHockin等进行加盟创作，并由谷歌在2014年首次对外宣布。该系统的开发和设计都深受谷歌的Borg系统的影响，其许多顶级贡献者之前也是Borg系统的开发者。在谷歌内部，Kubernetes的原始代号曾经是Seven，即星际迷航中的Borg(博格人)。Kubernetes标识中舵轮有七个轮辐就是对该项目代号的致意。
为什么Kubernetes的缩写是K8S呢？我个人赞同WhyKubernetesisAbbreviatedk8s[1]中说的观点“嘛，写全称也太累了吧，不如整个缩写”。其实只保留首位字符，用具体数字来替代省略的字符个数的做法，还是比较常见的。
1.2为什么是Kubernetes？
试想下传统的后端部署办法：把程序包(包括可执行二进制文件、配置文件等)放到服务器上，接着运行启动脚本把程序跑起来，同时启动守护脚本定期检查程序运行状态、必要的话重新拉起程序。
有问题吗？显然有!最大的一个问题在于：如果服务的请求量上来，已部署的服务响应不过来怎么办？传统的做法往往是，如果请求量、内存、CPU超过阈值做了告警，运维马上再加几台服务器，部署好服务之后，接入负载均衡来分担已有服务的压力。
问题出现了：从监控告警到部署服务，中间需要人力介入!那么，有没有办法自动完成服务的部署、更新、卸载和扩容、缩容呢？
这，就是Kubernetes要做的事情：自动化运维管理Docker(容器化)程序。
1.3Kubernetes怎么做？
Kubernetes是属于主从设备模型(Master-Slave架构)，即有Master节点负责核心的调度、管理和运维，Slave节点则在执行用户的程序。但是在Kubernetes中，主节点一般被称为MasterNode或者HeadNode(本文采用MasterNode称呼方式)，而从节点则被称为WorkerNode或者Node(本文采用WorkerNode称呼方式)。
要注意一点：MasterNode和WorkerNode是分别安装了Kubernetes的Master和Woker组件的实体服务器，每个Node都对应了一台实体服务器(虽然MasterNode可以和其中一个WorkerNode安装在同一台服务器，但是建议MasterNode单独部署)，所有MasterNode和WorkerNode组成了Kubernetes集群，同一个集群可能存在多个MasterNode和WorkerNode。
首先来看MasterNode都有哪些组件：
APIServer，Kubernetes的请求入口服务。APIServer负责接收Kubernetes所有请求(来自UI界面或者CLI命令行工具)，然后，APIServer根据用户的具体请求，去通知其他组件干活。
Scheduler，Kubernetes所有WorkerNode的调度器。当用户要部署服务时，Scheduler会选择最合适的WorkerNode(服务器)来部署。
etcd，Kubernetes的存储服务。etcd存储了Kubernetes的关键配置和用户配置，Kubernetes中仅APIServer才具备读写权限，其他组件必须通过APIServer的接口才能读写数据(见KubernetesWorksLikeanOperatingSystem[3])。
Kubelet，WorkerNode的监视器，以及与MasterNode的通讯器。Kubelet是MasterNode安插在WorkerNode上的“眼线”，它会定期向MasterNode汇报自己Node上运行的服务的状态，并接受来自MasterNode的指示采取调整措施。
Kube-Proxy，Kubernetes的网络代理。私以为称呼为Network-Proxy可能更适合？Kube-Proxy负责Node在Kubernetes的网络通讯、以及对外部网络流量的负载均衡。
LoggingLayer，Kubernetes的监控状态收集器。私以为称呼为Monitor可能更合适？LoggingLayer负责采集Node上所有服务的CPU、内存、磁盘、网络等监控项信息。
总结来看，Kubernetes的MasterNode具备：请求入口管理(APIServer)，WorkerNode调度(Scheduler)，监控和自动调节(ControllerManager)，以及存储功能(etcd);而Kubernetes的WorkerNode具备：状态和监控收集(Kubelet)，网络和负载均衡(Kube-Proxy)、保障容器化运行环境(ContainerRuntime)、以及定制化功能(Add-Ons)。
到这里，相信你已经对Kubernetes究竟是做什么的，有了大概认识。接下来，再来认识下Kubernetes的Deployment、Pod、ReplicaSet、Service等，但凡谈到Kubernetes，就绕不开这些名词，而这些名词也是最让Kubernetes新手们感到头疼、困惑的。
2.Kubernetes重要概念
2.1Pod实例
官方对于Pod的解释是：
Pod是可以在Kubernetes中创建和管理的、最小的可部署的计算单元。
这样的解释还是很难让人明白究竟Pod是什么，但是对于Kubernetes而言，Pod可以说是所有对象中最重要的概念了!因此，我们必须首先清楚地知道“Pod是什么”，再去了解其他的对象。
同样的，Pod就是Kubernetes中一个服务的闭包。这么说的好像还是有点玄乎，更加云里雾里了。简单来说，Pod可以被理解成一群可以共享网络、存储和计算资源的容器化服务的集合。再打个形象的比喻，在同一个Pod里的几个Docker服务/程序，好像被部署在同一台机器上，可以通过localhost互相访问，并且可以共用Pod里的存储资源(这里是指Docker可以挂载Pod内的数据卷，数据卷的概念，后文会详细讲述，暂时理解为“需要手动mount的磁盘”)。笔者总结Pod如下图，可以看到：同一个Pod之间的Container可以通过localhost互相访问，并且可以挂载Pod内所有的数据卷;但是不同的Pod之间的Container不能用localhost访问，也不能挂载其他Pod的数据卷。
对Pod有直观的认识之后，接着来看Kubernetes中Pod究竟长什么样子，具体包括哪些资源？
Kubernetes中所有的对象都通过yaml来表示，笔者从官方网站摘录了一个最简单的Pod的yaml：
apiVersion:v1
kind:Pod
metadata:
name:memory-demo
namespace:mem-example
spec:
containers:
-name:memory-demo-ctr
image:polinux/stress
resources:
limits:
memory:"200Mi"
requests:
memory:"100Mi"
command:["stress"]
args:["--vm","1","--vm-bytes","150M","--vm-hang","1"]
volumeMounts:
-name:redis-storage
mountPath:/data/redis
volumes:
emptyDir:{}
看不懂不必慌张，且耐心听下面的解释：
apiVersion记录Kubernetes的APIServer版本，现在看到的都是v1，用户不用管。
kind记录该yaml的对象，比如这是一份Pod的yaml配置文件，那么值内容就是Pod。
metadata记录了Pod自身的元数据，比如这个Pod的名字、这个Pod属于哪个namespace(命名空间的概念，后文会详述，暂时理解为“同一个命名空间内的对象互相可见”)。
spec记录了Pod内部所有的资源的详细信息，看懂这个很重要：
containers记录了Pod内的容器信息，containers包括了：name容器名，image容器的镜像地址，resources容器需要的CPU、内存、GPU等资源，command容器的入口命令，args容器的入口参数，volumeMounts容器要挂载的Pod数据卷等。可以看到，上述这些信息都是启动容器的必要和必需的信息。
volumes记录了Pod内的数据卷信息，后文会详细介绍Pod的数据卷。
2.2Volume数据卷
Kubernetes支持很多类型的Volume数据卷挂载，具体请参见Kubernetes卷[5]。前文就“如何理解Volume”提到：“需要手动mount的磁盘”，此外，有一点可以帮助理解：数据卷Volume是Pod内部的磁盘资源。
其实，单单就Volume来说，不难理解。但是上面还看到了volumeMounts，这俩是什么关系呢？
Volume是Kubernetes的对象，对应一个实体的数据卷;而volumeMounts只是container的挂载点，对应container的其中一个参数。但是，volumeMounts依赖于Volume，只有当Pod内有Volume资源的时候，该Pod内部的container才可能有volumeMounts。
2.3Container容器
本文中提到的镜像Image、容器Container，都指代了Pod下的一个container。关于Kubernetes中的容器，在2.1Pod章节都已经交代了，这里无非再啰嗦一句：一个Pod内可以有多个容器container。
在Pod中，容器也有分类，对这个感兴趣的同学欢迎自行阅读更多资料：
标准容器(ApplicationContainer)。
初始化容器(InitContainer)。
边车容器(SidecarContainer)。
临时容器(EphemeralContainer)。
一般来说，我们部署的大多是标准容器(ApplicationContainer)。
2.4Deployment和ReplicaSet(简称RS)
除了Pod之外，Kubernetes中最常听到的另一个对象就是Deployment了。那么，什么是Deployment呢？官方给出了一个要命的解释：
翻译一下：Deployment的作用是管理和控制Pod和ReplicaSet，管控它们运行在用户期望的状态中。哎，打个形象的比喻，Deployment就是包工头，主要负责监督底下的工人Pod干活，确保每时每刻有用户要求数量的Pod在工作。如果一旦发现某个工人Pod不行了，就赶紧新拉一个Pod过来替换它。
新的问题又来了：那什么是ReplicaSets呢？
ReplicaSet的目的是维护一组在任何时候都处于运行状态的Pod副本的稳定集合。因此，它通常用来保证给定数量的、完全相同的Pod的可用性。
再来翻译下：ReplicaSet的作用就是管理和控制Pod，管控他们好好干活。但是，ReplicaSet受控于Deployment。形象来说，ReplicaSet就是总包工头手下的小包工头。
笔者总结得到下面这幅图，希望能帮助理解：
新的问题又来了：如果都是为了管控Pod好好干活，为什么要设置Deployment和ReplicaSet两个层级呢，直接让Deployment来管理不可以吗？
回答：不清楚，但是私以为是因为先有ReplicaSet，但是使用中发现ReplicaSet不够满足要求，于是又整了一个Deployment(有清楚Deployment和ReplicaSet联系和区别的小伙伴欢迎留言啊)。
但是，从Kubernetes使用者角度来看，用户会直接操作Deployment部署服务，而当Deployment被部署的时候，Kubernetes会自动生成要求的ReplicaSet和Pod。在Kubernetes官方文档中也指出用户只需要关心Deployment而不操心ReplicaSet：
ThisactuallymeansthatyoumayneverneedtomanipulateReplicaSetobjects:useaDeploymentinstead,anddefineyourapplicationinthespecsection.这实际上意味着您可能永远不需要操作ReplicaSet对象：直接使用Deployments并在规范部分定义应用程序。
补充说明：在Kubernetes中还有一个对象——ReplicationController(简称RC)，官方文档对它的定义是：
ReplicationController确保在任何时候都有特定数量的Pod副本处于运行状态。换句话说，ReplicationController确保一个Pod或一组同类的Pod总是可用的。
怎么样，和ReplicaSet是不是很相近？在Deployments,ReplicaSets,andpods[6]教程中说“ReplicationController是ReplicaSet的前身”，官方也推荐用Deployment取代ReplicationController来部署服务。
2.5Service和Ingress
吐槽下Kubernetes的概念/对象/资源是真的多啊!前文介绍的Deployment、ReplicationController和ReplicaSet主要管控Pod程序服务;那么，Service和Ingress则负责管控Pod网络服务。
我们先来看看官方文档中Service的定义：
将运行在一组Pods上的应用程序公开为网络服务的抽象方法。使用Kubernetes，您无需修改应用程序即可使用不熟悉的服务发现机制。Kubernetes为Pods提供自己的IP地址，并为一组Pod提供相同的DNS名，并且可以在它们之间进行负载均衡。
翻译下：Kubernetes中的服务(Service)并不是我们常说的“服务”的含义，而更像是网关层，是若干个Pod的流量入口、流量均衡器。
那么，为什么要Service呢？
私以为在这一点上，官方文档讲解地非常清楚：
KubernetesPod是有生命周期的。它们可以被创建，而且销毁之后不会再启动。如果您使用Deployment来运行您的应用程序，则它可以动态创建和销毁Pod。每个Pod都有自己的IP地址，但是在Deployment中，在同一时刻运行的Pod集合可能与稍后运行该应用程序的Pod集合不同。这导致了一个问题：如果一组Pod(称为“后端”)为群集内的其他Pod(称为“前端”)提供功能，那么前端如何找出并跟踪要连接的IP地址，以便前端可以使用工作量的后端部分？
补充说明：Kubernetes集群的网络管理和拓扑也有特别的设计，以后会专门出一章节来详细介绍Kubernetes中的网络。这里需要清楚一点：Kubernetes集群内的每一个Pod都有自己的IP(是不是很类似一个Pod就是一台服务器，然而事实上是多个Pod存在于一台服务器上，只不过是Kubernetes做了网络隔离)，在Kubernetes集群内部还有DNS等网络服务(一个Kubernetes集群就如同管理了多区域的服务器，可以做复杂的网络拓扑)。
此外，笔者推荐Kubernetes外网如何访问业务应用对于Service的介绍，不过对于新手而言，推荐阅读前半部分对于service的介绍即可，后半部分就太复杂了。我这里做了简单的总结：
但是，Service主要负责Kubernetes集群内部的网络拓扑。那么集群外部怎么访问集群内部呢？这个时候就需要Ingress了，官方文档中的解释是：
Ingress是对集群中服务的外部访问进行管理的API对象，典型的访问方式是HTTP。Ingress可以提供负载均衡、SSL终结和基于名称的虚拟托管。
翻译一下：Ingress是整个Kubernetes集群的接入层，复杂集群内外通讯。
最后，笔者把Ingress和Service的关系绘制网络拓扑关系图如下，希望对理解这两个概念有所帮助：
2.6namespace命名空间
和前文介绍的所有的概念都不一样，namespace跟Pod没有直接关系，而是Kubernetes另一个维度的对象。或者说，前文提到的概念都是为了服务Pod的，而namespace则是为了服务整个Kubernetes集群的。
那么，namespace是什么呢？
上官方文档定义：
Kubernetes支持多个虚拟集群，它们底层依赖于同一个物理集群。这些虚拟集群被称为名字空间。
翻译一下：namespace是为了把一个Kubernetes集群划分为若干个资源不可共享的虚拟集群而诞生的。
#位于名字空间中的资源
kubectlapi-resources--namespaced=true
#不在名字空间中的资源
kubectlapi-resources--namespaced=false
不在namespace下的对象有：
在namespace下的对象有(部分)：
2.7其他
Kubernetes的对象实在太多了，2.1-2.6介绍的是在实际使用Kubernetes部署服务最常见的。其他的还有Job、CronJob等等，在对Kubernetes有了比较清楚的认知之后，再去学习更多的Kubernetes对象，不是难事。
3.配置kubectl
3.1什么是kubectl？
官方文档中介绍kubectl是：
Kubectl是一个命令行接口，用于对Kubernetes集群运行命令。Kubectl的配置文件在$HOME/.kube目录。我们可以通过设置KUBECONFIG环境变量或设置命令参数--kubeconfig来指定其他位置的kubeconfig文件。
也就是说，可以通过kubectl来操作Kubernetes集群，基本语法：
使用以下语法kubectl从终端窗口运行命令：
kubectl[command][TYPE][NAME][flags]
其中command、TYPE、NAME和flags分别是：
command：指定要对一个或多个资源执行的操作，例如create、get、describe、delete。
TYPE：指定资源类型。资源类型不区分大小写，可以指定单数、复数或缩写形式。例如，以下命令输出相同的结果：
kubectlgetpodpod1
kubectlgetpodspod1
kubectlgetpopod1
NAME：指定资源的名称。名称区分大小写。如果省略名称，则显示所有资源的详细信息kubectlgetpods。
在对多个资源执行操作时，您可以按类型和名称指定每个资源，或指定一个或多个文件：
要按类型和名称指定资源：
要对所有类型相同的资源进行分组，请执行以下操作：TYPE1name1name2name<#>。例子：kubectlgetpodexample-pod1example-pod2
分别指定多个资源类型：TYPE1/name1TYPE1/name2TYPE2/name3TYPE<#>/name<#>。例子：kubectlgetpod/example-pod1replicationcontroller/example-rc1
用一个或多个文件指定资源：-ffile1-ffile2-ffile<#>
使用YAML而不是JSON因为YAML更容易使用，特别是用于配置文件时。例子：kubectlget-f./pod.yaml
flags：指定可选的参数。例如，可以使用-s或-server参数指定KubernetesAPI服务器的地址和端口。
就如何使用kubectl而言，官方文档已经说得非常清楚。不过对于新手而言，还是需要解释几句：kubectl是Kubernetes的命令行工具，并不需要kubectl安装在Kubernetes集群的任何Node上，但是，需要确保安装kubectl的机器和Kubernetes的集群能够进行网络互通。
接下来，一起看看怎么使用kubectl吧，切身感受下kubectl的使用。
请注意，如何安装kubectl的办法有许多非常明确的教程，比如《安装并配置kubectl[7]》，本文不再赘述。
3.2怎么配置kubectl？
第一步，必须准备好要连接/使用的Kubernetes的配置文件，笔者给出一份杜撰的配置：
clusters:
-cluster:
certificate-authority-data:thisisfakecertifcateauthoritydata00000000000
name:cls-dev
contexts:
-context:
cluster:cls-dev
user:kubernetes-admin
name:kubernetes-admin@test
current-context:kubernetes-admin@test
kind:Config
preferences:{}
users:
-name:kubernetes-admin
user:
token:thisisfaketoken00000
解读如下：
clusters记录了clusters(一个或多个Kubernetes集群)信息：
name是这个cluster(Kubernetes集群)的名称代号
server是这个cluster(Kubernetes集群)的访问方式，一般为IP+PORT
users记录了访问cluster(Kubernetes集群)的账号信息：
name是用户账号的名称代号
user/token是用户的token认证方式，token不是用户认证的唯一方式，其他还有账号+密码等。
contexts是上下文信息，包括了cluster(Kubernetes集群)和访问cluster(Kubernetes集群)的用户账号等信息：
name是这个上下文的名称代号
cluster是cluster(Kubernetes集群)的名称代号
user是访问cluster(Kubernetes集群)的用户账号代号
current-context记录当前kubectl默认使用的上下文信息
kind和apiVersion都是固定值，用户不需要关心
preferences则是配置文件的其他设置信息，笔者没有使用过，暂时不提。
第二步，给kubectl配置上配置文件。
--kubeconfig参数。第一种办法是每次执行kubectl的时候，都带上--kubeconfig=${CONFIG_PATH}。给一点温馨小提示：每次都带这么一长串的字符非常麻烦，可以用alias别名来简化码字量，比如aliask=kubectl--kubeconfig=${CONFIG_PATH}。
KUBECONFIG环境变量。第二种做法是使用环境变量KUBECONFIG把所有配置文件都记录下来，即exportKUBECONFIG=$KUBECONFIG:${CONFIG_PATH}。接下来就可以放心执行kubectl命令了。
$HOME/.kube/config配置文件。第三种做法是把配置文件的内容放到$HOME/.kube/config内。具体做法为：
如果$HOME/.kube/config不存在，那么cp${CONFIG_PATH}$HOME/.kube/config即可;
如果如果$HOME/.kube/config已经存在，那么需要把新的配置内容加到$HOME/.kube/config下。单单只是cat${CONFIG_PATH}>>$HOME/.kube/config是不行的，正确的做法是：KUBECONFIG=$HOME/.kube/config:${CONFIG_PATH}kubectlconfigview--flatten>$HOME/.kube/config。解释下这个命令的意思：先把所有的配置文件添加到环境变量KUBECONFIG中，然后执行kubectlconfigview--flatten打印出有效的配置文件内容，最后覆盖$HOME/.kube/config即可。
请注意，上述操作的优先级分别是1>2>3，也就是说，kubectl会优先检查--kubeconfig，若无则检查KUBECONFIG，若无则最后检查$HOME/.kube/config，如果还是没有，报错。但凡某一步找到了有效的cluster，就中断检查，去连接Kubernetes集群了。
第三步：配置正确的上下文。
按照第二步的做法，如果配置文件只有一个cluster是没有任何问题的，但是对于有多个cluster怎么办呢？到这里，有几个关于配置的必须掌握的命令：
kubectlconfigget-contexts。列出所有上下文信息。
kubectlconfigcurrent-context。查看当前的上下文信息。其实，命令1线束出来的*所指示的就是当前的上下文信息。
kubectlconfiguse-context${CONTEXT_NAME}。更改上下文信息。
kubectlconfigset-context${CONTEXT_NAME}|--current--${KEY}=${VALUE}。修改上下文的元素。比如可以修改用户账号、集群信息、连接到Kubernetes后所在的namespace。
关于该命令，还有几点要啰嗦的：
configset-context可以修改任何在配置文件中的上下文信息，只需要在命令中指定上下文名称就可以。而--current则指代当前上下文。
上下文信息所包括的内容有：cluster集群(名称)、用户账号(名称)、连接到Kubernetes后所在的namespace，因此有configset-context严格意义上的用法：
kubectlconfigset-context[NAME|--current][--cluster=cluster_nickname][--user=user_nickname][--namespace=namespace][options]
备注：[options]可以通过kubectloptions查看。
综上，如何操作kubectl配置都已交代。
？？？？？？4.kubectl部署服务
？？？？？？
Kubernetes核心功能就是部署运维容器化服务，因此最重要的就是如何又快又好地部署自己的服务了。本章会介绍如何部署Pod和Deployment。
4.1如何部署Pod？
通过kubectl部署Pod的办法分为两步：1).准备Pod的yaml文件;2).执行kubectl命令部署。
第一步：准备Pod的yaml文件。关于Pod的yaml文件初步解释，本文已经有了初步介绍，这里再复习下：
继续解读：
metadata，对于新入门的同学来说，需要重点掌握的两个字段：
name，这个Pod的名称，后面到Kubernetes集群中查找Pod的关键字段。
namespace，命名空间，即该Pod隶属于哪个namespace下，关于Pod和namespace的关系，之前内容已经交代了。
spec记录了Pod内部所有的资源的详细信息，这里我们重点查看containers下的几个重要字段：
name，Pod下该容器名称，后面查找Pod下的容器的关键字段。
image，容器的镜像地址，Kubernetes会根据这个字段去拉取镜像。
resources，容器化服务涉及到的CPU、内存、GPU等资源要求。可以看到有limits和requests两个子项，那么这两者有什么区别吗，该怎么使用？在What'sthedifferencebetweenPodresources.limitsandresources.requestsinKubernetes[8]回答了：limits是Kubernetes为该容器至多分配的资源配额;而requests则是Kubernetes为该容器至少分配的资源配额。打个比方，配置中要求了memory的requests为100M，而此时如果Kubernetes集群中所有的Node的可用内存都不足100M，那么部署服务会失败;又如果有一个Node的内存有16G充裕，可以部署该Pod，而在运行中，该容器服务发生了内存泄露，那么一旦超过200M就会因为OOM被kill，尽管此时该机器上还有15G+的内存。
command，容器的入口命令。对于这个笔者还存在很多困惑不解的地方，暂时挖个坑，有清楚的同学欢迎留言。
args，容器的入口参数。同上，有清楚的同学欢迎留言。
volumeMounts，容器要挂载的Pod数据卷等。请务必记住：Pod的数据卷只有被容器挂载后才能使用!
第二步：执行kubectl命令部署。有了Pod的yaml文件之后，就可以用kubectl部署了，命令非常简单：kubectlcreate-f${POD_YAML}。
随后，会提示该命令是否执行成功，比如yaml内容不符合要求，则会提示哪一行有问题：
修正后，再次部署：
4.2如何部署Deployment？
第一步：准备Deployment的yaml文件。首先来看Deployment的yaml文件内容：
apiVersion:extensions/v1beta1
kind:Deployment
name:rss-site
replicas:2
template:
labels:
app:web
emory:"200Mi"
继续来看几个重要的字段：
metadata同Pod的yaml，这里提一点：如果没有指明namespace，那么就是用kubectl默认的namespace(如果kubectl配置文件中没有指明namespace，那么就是default空间)。
spec，可以看到Deployment的spec字段是在Pod的spec内容外“包了一层”，那就来看Deployment有哪些需要注意的：
metadata，新手同学先不管这边的信息。
spec，会发现这完完全全是上文提到的Pod的spec内容，在这里写明了Deployment下属管理的每个Pod的具体内容。
replicas，副本个数。也就是该Deployment需要起多少个相同的Pod，如果用户成功在Kubernetes中配置了n(n>1)个，那么Deployment会确保在集群中始终有n个服务在运行。
template。
第二步：执行kubectl命令部署。Deployment的部署办法同Pod：kubectlcreate-f${DEPLOYMENT_YAML}。由此可见，Kubernetes会根据配置文件中的kind字段来判断具体要创建的是什么资源。
这里插一句题外话：部署完Deployment之后，可以查看到自动创建了ReplicaSet和Pod，如下图所示：
还有一个有趣的事情：通过Deployment部署的服务，其下属的RS和Pod命名是有规则的。读者朋友们自己总结发现哦。
综上，如何部署一个Pod或者Deployment就结束了。
5.kubectl查看、更新/编辑、删除服务
作为Kubernetes使用者而言，更关心的问题应该是本章所要讨论的话题：如何通过kubectl查看、更新/编辑、删除在Kubernetes上部署着的服务。
5.1如何查看服务？
通过kubectl查看服务的基本命令是：
$kubectlget|describe${RESOURCE}[-o${FORMAT}]-n=${NAMESPACE}
#${RESOURCE}有:pod、deployment、replicaset(rs)
在此之前，还有一个需要回忆的事情是：Deployment、ReplicaSet和Pod之间的关系——层层隶属;以及这些资源和namespace的关系是——隶属。如下图所示：
因此，要查看一个服务，也就是一个Pod，必须首先指定namespace!那么，如何查看集群中所有的namespace呢？kubectlgetns：
于是，只需要通过-n=${NAMESPACE}就可以指定自己要操作的资源所在的namespace。比如查看Pod：kubectlgetpod-n=oona-test，同理，查看Deployment：kubectlgetdeployment-n=oona-test。
问题又来了：如果已经忘记自己所部属的服务所在的namespace怎么办？这么多namespace，一个一个查看过来吗？
kubectlgetpod--all-namespaces
这样子就可以看到所有namespace下面部署的Pod了!同理，要查找所有的命名空间下的Deployment的命令是：kubectlgetdeployment--all-namespaces。
于是，就可以开心地查看Pod：kubectlgetpod[-owide]-n=oona-test，或者查看Deployment：kubectlgetdeployment[-owide]-n=oona-test。
哎，这里是否加-owide有什么区别吗？实际操作下就明白了，其他资源亦然：
哎，我们看到之前部署的Pod服务memory-demo显示的“ImagePullBackOff”是怎么回事呢？先不着急，我们慢慢看下去。
5.2如何更新/编辑服务？
两种办法：1).修改yaml文件后通过kubectl更新;2).通过kubectl直接编辑Kubernetes上的服务。
方法一：修改yaml文件后通过kubectl更新。我们看到，创建一个Pod或者Deployment的命令是kubectlcreate-f${YAML}。但是，如果Kubernetes集群当前的namespace下已经有该服务的话，会提示资源已经存在：
通过kubectl更新的命令是kubectlapply-f${YAML}，我们再来试一试：
备注：命令kubectlapply-f${YAML}也可以用于首次创建一个服务哦。
方法二：通过kubectl直接编辑Kubernetes上的服务。命令为kubectledit${RESOURCE}${NAME}，比如修改刚刚的Pod的命令为kubectleditpodmemory-demo，然后直接编辑自己要修改的内容即可。
但是请注意，无论方法一还是方法二，能修改的内容还是有限的，从笔者实战下来的结论是：只能修改/更新镜像的地址和个别几个字段。如果修改其他字段，会报错：
ThePod"memory-demo"isinvalid:spec:Forbidden:podupdatesmaynotchangefieldsotherthanspec.containers[].image,spec.initContainers[].image,spec.activeDeadlineSecondsorspec.tolerations(onlyadditionstoexistingtolerations)
如果真的要修改其他字段怎么办呢？恐怕只能删除服务后重新部署了。
5.3如何删除服务？
在Kubernetes上删除服务的操作非常简单，命令为kubectldelete${RESOURCE}${NAME}。比如删除一个Pod是：kubectldeletepodmemory-demo，再比如删除一个Deployment的命令是：kubectldeletedeployment${DEPLOYMENT_NAME}。但是，请注意：
如果只部署了一个Pod，那么直接删除该Pod即可;
如果是通过Deployment部署的服务，那么仅仅删除Pod是不行的，正确的删除方式应该是：先删除Deployment，再删除Pod。
关于第二点应该不难想象：仅仅删除了Pod但是Deployment还在的话，Deployment定时会检查其下属的所有Pod，如果发现失败了则会再拉起。因此，会发现过一会儿，新的Pod又被拉起来了。
另外，还有一个事情：有时候会发现一个Pod总也删除不了，这个时候很有可能要实施强制删除措施，命令为kubectldeletepod--force--grace-period=0${POD_NAME}。
6.kubectl排查服务问题
上文说道：部署的服务memory-demo失败了，是怎么回事呢？本章就会带大家一起来看看常见的Kubernetes中服务部署失败、服务起来了但是不正常运行都怎么排查呢？
首先，祭出笔者最爱的一张Kubernetes排查手册，来自博客《KubernetesDeployment故障排除图解指南》：
哈哈哈，对于新手同学来说，上图还是不够友好，下面我们简单来看两个例子：
6.1Kubernetes上部署服务失败了怎么排查？
请一定记住这个命令：kubectldescribe${RESOURCE}${NAME}。比如刚刚的Pod服务memory-demo，我们来看：
拉到最后看到Events部分，会显示出Kubernetes在部署这个服务过程的关键日志。这里我们可以看到是拉取镜像失败了，好吧，大家可以换一个可用的镜像再试试。
6.2Kubernetes上部署的服务不正常怎么排查？
如果服务部署成功了，且状态为running，那么就需要进入Pod内部的容器去查看自己的服务日志了：
查看Pod内部某个container打印的日志：kubectllog${POD_NAME}-c${CONTAINER_NAME}。
进入Pod内部某个container：kubectlexec-it[options]${POD_NAME}-c${CONTAINER_NAME}[args]，嗯，这个命令的作用是通过kubectl执行了dockerexecxxx进入到容器实例内部。之后，就是用户检查自己服务的日志来定位问题。
显然，线上可能会遇到更复杂的问题，需要借助更多更强大的命令和工具。
写在后面
最后，小编给您推荐，金山毒霸“C盘瘦身专家”，快速释放系统空间。