kubectl学习

1、什么是kubectl

kubectl是在进行Kubernetes管理的过程中使用的主要命令行工具。将kubectl看作Kubernetes的SSH有助于理解其作用。kubectl有Linux、macOS和Windows版本。

作为主要的命令行工具，kubectl的次版本号与集群的次版本号的数字差距应不大于1。例如，如果集群中运行的是Kubernetes 1.16.x，那么所使用的kubectl版本应介于1.15.x和1.17.x之间。

kubectl的作用是将对用户友好的命令转换成API Server所能理解的JSON格式。它基于一个配置文件来决定将其POST到哪个集群的API Server。

2、kubectl配置文件

kubectl的配置文件位于$HOME/.kube/config

配置文件包含三部分;

clusters部分是kubectl可以连接的多个集群的列表，当用户需要管理多个集群时会非常有用。每个集群的定义都包含名字、证书信息和API Server端口。

contexts部分定义的是集群和相关用户的组合，并用易于记忆的名字来代指。本图片中，配置中有名为kubernetes的context，它将名为kubernetes-admin的用户凭证和名为kubernetes的集群定义组合起来。此时如果基于这个context使用kubectl，那么该命令将会以kubernetes-admin用户的身份发送至集群kubernetes的API Server。

users（凭证）部分用于定义不同的用户以及对不同集群的不同级别的权限。例如，配置中可能有dev用户和ops用户，它们分别具有不同的权限。每一个用户的定义都有一个易于记忆的名字（name）、一个账号（username）和一系列凭证信息，本例中，用户为：kubernetes-admin

2.1、命令查看kubectl的配置：kubectl config view ----此处问题：通过命令查看kubectl配置和直接查看具体的配置文件，两者有什么关系，为什么展示方式不一样？

2.2、命令行查看current-contex：kubectl config current-context

2.3、使用kubectl config use-context来改变当前的context：kubectl config use-context '修改后的context'

3、kubectl与API Server

Kubernetes API是管理各种资源对象的唯一入口，它提供了一个RESTful风格的CRUD（Create、Read、Update和Delete）接口用于查询和修改集群状态，并将结果存储在集群状态存储系统etcd中。事实上，API Server也是用于更新etcd中资源对象状态的唯一途径，Kubernetes的其他所有组件和客户端都要通过它完成查询或修改操作

4、kubectl操作方式：kubectl的核心功能在于通过API Server操作Kubernetes的各种资源对象，它支持3种操作方式，其中直接命令式使用最为简单

4.1　kubectl命令常用操作

          1. 创建资源对象：

Kubernetes系统的大部分资源都隶属于名称空间级别，默认的名称空间为default，若需要获取指定Namespace对象中的资源对象的信息，则需要使用-n或--namespace指明其名称。直接通过kubectl命令及相关的选项创建资源对象的方式即直接命令式操作。例如，在下面的命令中，第一条命令创建了名为dev的Namespace对象，后两条命令在dev名称空间中分别创建了名为demoapp的Deployment控制器资源对象和名为demoapp的Service资源对象。

~$ kubectl create namespace dev ~$ kubectl create deployment demoapp --image="ikubernetes/demoapp:v1.0" -n dev ~$ kubectl create service clusterip demoapp --tcp=80 -n dev

若要直接运行一个自主式Pod对象，也可使用kubectl run命令实现。例如下面第一条命令创建了一个名为demoapp的Pod对象，内部容器由指定的镜像运行，而第二条命令创建的Pod对象则在前台改为运行由用户指定的命令，且退出后将被自动删除。

~$ kubectl run demoapp --image="ikubernetes/dmeoapp:v1.0" ~$ kubectl run demoapp-$RANDOM --image="ikubernetes/demoapp:v1.0" --rm -it \ --command -- /bin/sh

另外，我们也可以根据资源清单创建资源对象，即采用“命令式对象配置文件”管理方式。例如，假设存在定义了Deployment对象的deployment-demoapp.yaml文件，以及定义了Service对象的service-demoapp.yaml文件，使用kubectl create命令即可进行基于命令式对象配置文件的创建操作：

~$ kubectl create -f deployment-demoapp.yaml -f service-demoapp.yaml

甚至还可以将创建交由kubectl自行确定，用户只需要声明期望的状态，这种方式称为声明式对象配置。仍以deployment-demoapp.yaml和service-demoapp.yaml文件为例，使用kubectl apply命令即可实现声明式配置：

~$ kubectl apply -f deployment-demoapp.yaml -f service-demoapp.yaml

       2. 查看资源对象

运行着实际负载的Kubernetes系统上通常会存在多种资源对象，用户可分类列出感兴趣的资源对象及其相关的状态信息，kubectl get正是完成此类功能的命令。例如下面的命令能够列出系统上所有的Namespace资源对象。

~$ kubectl get namespaces

我们也可以一次查看多个资源类别下的资源对象，例如，列出默认名称空间内的所有Pod和Service对象，并输出额外信息。可以使用如下形式的kubectl get命令实现。

~$ kubectl get pods,services -o wide

使用类似如下命令列出kube-namespace名称空间中拥有k8s-app标签名称的所有Pod对象。

~$ kubectl get pods -l k8s-app -n kube-system

kubectl get命令支持多种不同的输出格式，例如wide、yaml、json、custom-columns、jsonpath和go-template等，每一种格式都以不同的输出格式打印资源对象的信息。例如，下面的命令能够取出kube-system名称空间中带有k8s-app=kube-dns标签的Pod对象的资源名称。

~$ kubectl get pods -l k8s-app=kube-dns -n kube-system -o jsonpath="{.items[0].metadata.name}"

     3. 打印资源对象的详细信息

每个资源对象都有用户期望的状态（Spec）和现有的实际状态（Status）两种状态信息，kubectl get -o {yaml|josn}可分别以YAML或JSON格式打印资源对象的规范，而kubectl describe命令则能够打印出指定资源对象的详细描述信息。例如，查看kube-system名称空间中API Server相关Pod对象的资源配置清单（期望的状态）及当前的状态信息，并输出为YAML格式：

~$ kubectl get pods kube-apiserver-k8s-master01.ilinux.io -o yaml -n kube-system

而kubectl describe命令还能显示当前对象相关的其他资源对象，如Event或Controller等。例如，查看kube-system名称空间中拥有标签component=kube-apiserver的Pod对象的详细描述信息，可以使用下面的命令：

~$ kubectl describe pods -l component=kube-apiserver -n kube-system

这两个命令都支持以TYPE NAME或TYPE/NAME的格式指定具体的资源对象，例如pods kube-apiserver-master.ilinux.io或pods/kube-apiserver-master.ilinux.io，以了解特定资源对象的详细属性信息及状态信息。

   4. 打印容器中的日志信息

通常一个应用容器中仅会运行一个进程（及其子进程），该进程作为1号进程接收并处理信号，同时负责将日志直接输出至容器终端中，因此容器日志信息的获取一般要通过容器控制台进行。kubectl logs命令可打印Pod对象内指定容器的日志信息，命令格式为kubectl logs [-f] [-p] (POD | TYPE/NAME) [-c CONTAINER][options]。若Pod对象内仅有一个容器，则-c选项及容器名可选。例如，下面的命令先取出kube-system名称空间中带有指定标签的一个Pod对象，而第二条命令则能够查看该Pod对象的日志。

~$ DNS_POD=$(kubectl get pods -l k8s-app=kube-dns -n kube-system \ -o jsonpath="{.items[0].metadata.name}") ~$ kubectl logs $DNS_POD -n kube-system

为上面的命令添加-f选项，还能用于持续监控指定容器中的日志输出，其行为类似于使用了-f选项的tail命令。

   5. 在容器中执行命令

容器的隔离属性使得对其内部信息的获取变得不再直观，这在用户需要了解容器内进程的运行特性、文件系统上的文件及路径布局等信息时需要穿透其隔离边界进行。kubectl exec命令便是在指定的容器运行其他应用程序的命令，例如在kube-system名称空间中的Pod对象kube-apiserver-master.ilinux.io上的唯一容器中运行ps命令：

~$ kubectl exec kube-apiserver-master.ilinux.io -n kube-system -- ps

类似于logs命令，若Pod对象中存在多个容器，需要以-c选项指定容器后才能运行指定的命令，而指定的命令程序也必须在容器中存在才能成功运行。

5. 删除资源对象

kubectl delete命令能够删除指定的资源对象，例如下面的命令可删除default名称空间中名为demoapp-svc的Service资源对象：

~$ kubectl delete services demoapp-svc

而下面的命令可删除kube-system名称空间中带有k8s-app=kube-proxy标签的所有Pod对象（危险操作，切勿在生产集群中测试执行）：

~$ kubectl delete pods -l k8s-app=kube-proxy -n kube-system

若要删除指定名称空间中的所有某类对象，可以使用类似kubectl delete TYPE --all -n NS格式的命令。例如，下面的命令可删除kube-public名称空间中的所有Pod对象：

~$ kubectl delete pods --all -n kube-public

另外，有些资源类型支持优雅删除的机制，它们有着默认的删除宽限期，例如Pod资源的默认宽限期为30秒，但用户可在命令中使用--grace-period选项或--now选项来覆盖默认的宽限期。下面的命令就用于强制删除指定的Pod对象，但这种删除操作可能会导致相关容器无法终止并退出。

~$ kubectl delete pods demoapp --force --grace-period=0

需要特别说明的是，对于受控于控制器的对象来说，仅删除受控对象自身，其控制器可能会重建出类似的对象，例如Deployment控制器下的Pod对象被删除时即会被重建。

4.2　kubectl插件

kubectl插件是指能够由kubectl调用的外部独立应用程序，这类应用程序都以kubectl-$plugin_name格式命名，表现为kubectl的名字是$plugin_name的子命令。例如，应用程序/usr/bin/kubectl-whoami就是whoami插件，我们可以使用kubectl whoami的格式来运行它。因此，可为kubectl插件添加新的可用子命令，丰富kubectl的功能。插件程序能够从kubectl继承环境信息，但kubectl的插件机制并不会在该程序及调用的外部程序之间传递任何信息，它仅仅提供了调用外部程序的一个统一接口，于是我们可以使用任何熟悉的脚本语言或编程语言来开发kubectl插件，但最终的脚本或程序文件需要以“kubectl-”为名称前缀。而安装插件的过程，也不过是将插件程序的可执行文件移动到系统的PATH环境变量上，指向任一路径即可。事实上，kubectl plugin list命令可遍历PATH环境变量指向的每一个路径，搜索并列出每一个以“kubectl-”为前缀的可执行程序文件路径。

Kubernetes SIG CLI社区还提供了一个插件管理器——Krew，它能够帮助用户打包、分发、查找、安装和管理kubectl插件，项目地址为Krew – kubectl plugin manager。Krew以跨平台的方式打包和分发插件，因此单一打包格式即能适配主流的系统平台（Linux、Windows或macOS等）。为了便于插件分发，Krew还维护有一个插件索引，以方便用户发现主流的可用插件。

Krew自身也表现为kubectl的一个插件，需要以手动方式独立安装。

4.3kubectl命令列表