k8s 基本使用（上）
https://www.jianshu.com/p/8d60ce1587e1
本文将介绍 k8s 中的一些最基本的命令，并辅以解释一些基本概念来方便理解，也就是说，本文是一篇偏向实用性而非学术性的文章，如果你想提前了解一下 k8s 相关的知识的话，可以通过以下链接进行学习：
- 10分钟看懂 Docker 和 K8S
- Kubernetes中文社区 - 从零开始k8s
- k8s官网 - 中文
结构模型
k8s 是经典的一对多模型，有一个主要的管理节点master和许多的工作节点slaver。当然，k8s 也可以配置多个管理节点，拥有两个以上的管理节点被称为 高可用。k8s 包括了许多的组件，每个组件都是单运行在一个docker容器中，然后通过自己规划的虚拟网络相互访问。你可以通过kubectl get pod -n kube-system查看所有节点上的组件容器。
在管理节点中会比工作节点运行更多的 k8s 组件，我们就是靠着这些多出来的组件来对工作节点发号施令。他们都叫什么这里就不详细提了。反正对于”基本使用“来说，这些名字并不重要。
理念
要想理解一个东西就要先明白它的内在理念。通俗点就是，k8s 做了什么？为了提供更加可靠的服务，就要增加服务器的数量，减少每个服务器的体量来平摊负载，而越来越多的虚拟机就会带来越来越高的运维成本。如何让少量的运维人员就可以管理数量众多的服务器及其上的服务呢？这就是 k8s 做的工作。
k8s 把数量众多的服务器重新抽象为一个统一的资源池，对于运维人员来说，他们面前没有服务器1、服务器2的概念，而是一个统一的资源池，增加新的服务器对运维人员来说，只是增加自资源池的可用量。不仅如此，k8s 把所有能用的东西都抽象成了资源的概念，从而提供了一套更统一，更简洁的管理方式。
接下来，我会把每个基本命令当做一节来进行介绍，并辅以介绍一些基本概念。本文介绍的命令涵盖了增删改查四方面，可参加下面表格，因为篇幅较长，我们将create及之后的不那么常用的命令放在下一篇文章 k8s 基本使用（下） 里讲：
| 命令名 | 类型 | 作用 |
|---|---|---|
get |
查 | 列出某个类型的下属资源 |
describe |
查 | 查看某个资源的详细信息 |
logs |
查 | 查看某个 pod 的日志 |
create |
增 | 新建资源 |
explain |
查 | 查看某个资源的配置项 |
delete |
删 | 删除某个资源 |
edit |
改 | 修改某个资源的配置项 |
apply |
改 | 应用某个资源的配置项 |
kubectl get 列出资源！
接下来进入正题，首先来了解一下 k8s 中最最最常用的命令kubectl get，要记住，k8s 把所有的东西都抽象成了资源，而kubectl get就是用来查看这些资源的。最常见的资源就是 pod 。
什么是 pod？
pod(豆荚)。 pod 的概念其实和docker中的容器非常相似。他是 k8s 中的最小工作单位。你可以把 pod 理解成一个一个的小机器人，而 k8s 抽象出来的大资源池就是他们的工厂。
pod和docker容器的关系？pod 将一个或多个
docker容器封装成一个统一的整体进行管理并对外提供服务。
不仅我们自己的服务是要包装成 pod 的，就连 k8s 自己也是运行在一堆 pod 上。接下来就让我们查看一下 k8s 的 pod ：
kubectl get pod -n kube-system
-n参数指定了要查看哪个命名空间下的 pod 。 k8s 所有的 pod 都被放置在kube-system命名空间下。
什么是命名空间？
命名空间
namespace，是 k8s 中”组“的概念，提供同一服务的 pod 就应该被放置同一命名空间下，而不是混杂在一起。k8s 可以用命名空间来做权限控制。如果不指定的话， pod 将被放置在默认的命名空间default下。
执行了kubectl get pod -n kube-system命令后，你就可以看到如下内容：
NAME READY STATUS RESTARTS AGE
coredns-bccdc95cf-69zrw 1/1 Running 1 4d1h
coredns-bccdc95cf-77bg4 1/1 Running 1 4d1h
etcd-master1 1/1 Running 6 4d1h
kube-apiserver-master1 1/1 Running 6 4d1h
kube-controller-manager-master1 1/1 Running 2 4d1h
kube-flannel-ds-amd64-2d6tb 1/1 Running 0 47h
kube-flannel-ds-amd64-kp5xs 1/1 Running 0 47h
kube-flannel-ds-amd64-l9728 1/1 Running 0 47h
kube-flannel-ds-amd64-r87qc 1/1 Running 0 47h
kube-proxy-2lz7f 1/1 Running 0 2d23h
kube-proxy-hqsdn 1/1 Running 4 4d1h
kube-proxy-rh92r 1/1 Running 1 4d1h
kube-proxy-tv4mt 1/1 Running 0 3d2h
kube-scheduler-master1 1/1 Running 2 4d1h
其中每一行就是一个资源，这里我们看到的资源是 pod 。你看到的 pod 数量可能和我的不一致，因为这个列表里包含了 k8s 在所有节点上运行的 pod ，你加入的节点越多，那么显示的 pod 也就越多。我们来一列一列的看：
NAME：第一列是 pod 的名字，k8s 可以为 pod 随机分配一个五位数的后缀。READY：第二列是 pod 中已经就绪的 docker 容器的数量，上文中我们提到了，pod 封装了一个或多个 docker 容器。在这里，1/1的含义为就绪1个容器/共计1个容器。STATUS：第三列是 pod 的当前状态，下面是一些常见的状态：
| 状态名 | 含义 |
|---|---|
Running |
运行中 |
Error |
异常，无法提供服务 |
Pending |
准备中，暂时无法提供服务 |
Terminaling |
结束中，即将被移除 |
Unknown |
未知状态，多发生于节点宕机 |
PullImageBackOff |
镜像拉取失败 |
RESTART：k8s 可以自动重启 pod，这一行就是标记了 pod 一共重启了多少次。AGE：pod 一共存在了多长时间。
kubectl get可以列出 k8s 中所有资源
这里只介绍了如何用kubectl获取 pod 的列表。但是不要把get和pod绑定在一起，pod 只是 k8s 中的一种服务，你不仅可以get pod，还可以get svc(查看服务)、get rs(查看副本控制器)、get deploy(查看部署)等等等等，虽然说kubectl get pod是最常用的一个，但是如果想查看某个资源而又不知道命令是什么，kbuectl get <资源名>就对了。
如果你想看更多的信息，就可以指定-o wide参数，如下：
kubectl get pod -n kube-system -o wide
加上这个参数之后就可以看到资源的所在ip和所在节点node了。
记得加上 -n
-n可以说是kubectl get命令使用最频繁的参数了，在正式使用中，我们永远不会把资源发布在默认命名空间。所以，永远不要忘记在get命令后面加上-n。
小结
kubectl get命令可以列出 k8s 中的资源，而kubectl get pod是非常常用的查看 pod 的命令。而-n参数则可以指定 pod 所在的命名空间。
kubectl describe 查看详情！
kubectl describe命令可以用来查看某一资源的具体信息，他同样可以查看所有资源的详情，不过最常用的还是查看 pod 的详情。他也同样可以使用-n参数指定资源所在的命名空间。
举个例子，我们可以用下面命令来查看刚才 pod 列表中的某个 pod，注意不要忘记把 pod 名称修改成自己的：
kubectl describe pod kube-flannel-ds-amd64-2d6tb -n kube-system
然后你就可以看到很多的信息，咱们分开说，首先是基本属性，你可以在详细信息的开头找到它：
基本属性
# 实例名称
Name: kube-flannel-ds-amd64-2d6tb
# 所处命名空间
Namespace: kube-system
# 所在节点
Node: worker2/192.168.56.22
# 启动时间
Start Time: Wed, 03 Jul 2019 09:31:50 +0000
# 标签
Labels: app=flannel
controller-revision-hash=bfc6b6dd4
pod-template-generation=2
tier=node
# 注解
Annotations:
# 当前状态
Status: Running
# 所在节点 IP
IP: 192.168.56.22
# 由那种资源生成 / 控制
Controlled By: DaemonSet/kube-flannel-ds-amd64
其中几个比较常用的，例如Node、labels和Controlled By。通过Node你可以快速定位到 pod 所处的机器，从而检查该机器是否出现问题或宕机等。通过labels你可以检索到该 pod 的大致用途及定位。而通过Controlled By，你可以知道该 pod 是由那种 k8s 资源创建的，然后就可以使用kubectl get <资源名>来继续查找问题。例如上文DaemonSet/kube-flannel-ds-amd64，就可以通过kubectl get DaemonSet -n kube-system来获取上一节资源的信息。
内部镜像信息
在中间部分你可以找到像下面一样的Containers段落。该段落详细的描述了 pod 中每个 docker 容器的信息，常用的比如Image字段，当 pod 出现 ImagePullBackOff错误的时候就可以查看该字段确认拉取的什么镜像。其他的字段名都很通俗，直接翻译即可。
Containers:
kube-flannel:
Container ID: docker://25d2c4896847bbf53735c57a60c5b3146e2b3a0f86811074bcd28a8291213c18 Image: quay.io/coreos/flannel:v0.11.0-amd64 Image ID: docker://sha256:ff281650a721f46bbe2169292c91031c66411554739c88c861ba78475c1df894 Port: > Host Port: > Command: /opt/bin/flanneld Args: --ip-masq --kube-subnet-mgr --iface=enp0s8 State: Running Started: Wed, 03 Jul 2019 09:31:53 +0000 Ready: True Restart Count: 0 Limits: cpu: 100m memory: 50Mi Requests: cpu: 100m memory: 50Mi Environment: POD_NAME: kube-flannel-ds-amd64-2d6tb (v1:metadata.name) POD_NAMESPACE: kube-system (v1:metadata.namespace) Mounts: /etc/kube-flannel/ from flannel-cfg (rw) /run from run (rw) /var/run/secrets/kubernetes.io/serviceaccount from flannel-token-fsqdv (ro) 事件
在describe查看详情的时候，最常用的信息获取处就是这个Event段落了，你可以在介绍内容的末尾找到它，如下：
Events: > 是的，如果你看到上面这样，没有任何Events的话，就说明该 pod 一切正常。当 pod 的状态不是Running时，这里一定会有或多或少的问题，长得像下面一样，然后你就可以通过其中的信息分析 pod 出现问题的详细原因了：
Events:
Type Reason Age From Message
---- ------ ---- ---- ------- Normal Killing 29m kubelet, worker1 Stopping container kube-flannel Warning FailedCreatePodSandBox 27m (x12 over 29m) kubelet, worker1 Failed create pod sandbox: rpc error: code = Unknown desc = failed to create a sandbox for pod "kube-flannel-ds-amd64-9trbq": Error response from daemon: cgroup-parent for systemd cgroup should be a valid slice named as "xxx.slice" Normal SandboxChanged 19m (x48 over 29m) kubelet, worker1 Pod sandbox changed, it will be killed and re-created. Normal Pulling 42s kubelet, worker1 Pulling image "quay.io/coreos/flannel:v0.11.0-amd64" 小结
kubectl describe <资源名> <实例名>可以查看一个资源的详细信息，最常用的还是比如kubectl describe pod 来获取一个 pod 的基本信息。如果出现问题的话，可以在获取到的信息的末尾看到Event段落，其中记录着导致 pod 故障的原因。
kubectl logs 查看日志！
如果你想查看一个 pod 的具体日志，就可以通过kubectl logs 来查看。注意，这个只能查看 pod 的日志。通过添加-f参数可以持续查看日志。例如，查看kube-system命名空间中某个flannel pod 的日志，注意修改 pod 名称：
kubectl logs -f -n kube-system kube-flannel-ds-amd64-2d6tb
然后就可以看到如下输出：
E0706 06:55:15.848891 1 reflector.go:201] github.com/coreos/flannel/subnet/kube/kube.go:310: Failed to list *v1.Node: Get https://10.96.0.1:443/api/v1/nodes?resourceVersion=0: dial tcp 10.96.0.1:443: connect: connection refused E0706 06:55:16.948058 1 reflector.go:201] github.com/coreos/flannel/subnet/kube/kube.go:310: Failed to list *v1.Node: Get https://10.96.0.1:443/api/v1/nodes?resourceVersion=0: dial tcp 10.96.0.1:443: connect: connection refused E0706 06:55:17.949165 1 reflector.go:201] github.com/coreos/flannel/subnet/kube/kube.go:310: Failed to list *v1.Node: Get https://10.96.0.1:443/api/v1/nodes?resourceVersion=0: dial tcp 10.96.0.1:443: connect: connection refused E0706 06:55:18.954108 1 reflector.go:201] github.com/coreos/flannel/subnet/kube/kube.go:310: Failed to list *v1.Node: Get https://10.96.0.1:443/api/v1/nodes?resourceVersion=0: dial tcp 10.96.0.1:443: connect: connection refused E0706 06:55:19.955267 1 reflector.go:201] github.com/coreos/flannel/subnet/kube/kube.go:310: Failed to list *v1.Node: Get https://10.96.0.1:443/api/v1/nodes?resourceVersion=0: dial tcp 10.96.0.1:443: connect: connection refused E0706 06:55:21.046592 1 reflector.go:201] github.com/coreos