【03】Kubernets：K8S 操做入门

写在前面的话

 

通过上一节，咱们顺利将 K8S 集群搭建了起来，在其中我也简单的谈了一下关于 K8S 的网络。那么这一节咱们主要谈谈如何来简单的使用 K8S 的命令。固然这些命令有不少，咱们只是经过一个小例子来操做讲解。是不全面的。

可是其实更多的目的是为了介绍一种方法。在后期的应用中，咱们也会和 docker 同样，慢慢的摒弃掉这种纯手敲命令的形式，并且换成更为直观的资源清单（yaml 文件）的形式。

并且本章节咱们会好好谈谈在 K8S 中很是重要的几个概念中的一部分，主要包括：Pod 和 Service 部分。

至于控制器 Controller 这些内容，咱们会在更后边的时候详讲。

 

 

关于 Pod

 

咱们一直都在说，Pod 是 K8S 可以调度的最小单元。那啥是 Pod？

Pod 实际上是一个容器集，由 1 个甚至多个容器组成，它们的关系属于紧密到不宜分割。一个 Pod 内的全部容器都运行在同一个节点上。

咱们能够作个比喻，把一个学校比做 K8S，咱们每一个人就像一个容器，那么一个班就是一个 Pod，同专业多个班一块儿组成 Service，学校通常调度都是调度的专业，固然他也能够调度某个班。但咱们能够假设他不会有事没事专门去调度某个学生。

同一组的 Pod 共享 networks / uts / storage / volumes，经过 IPC 机制进行通信。跨 Pod 的容器须要外部网络插件实现通讯，每个 Pod 有一个属于本身的 IP，此时容器就再也不有本身的 IP 了。

对于 K8S 而言，最初和最终的目的都是为了运行 Pod，至于其余一些组件，其目的仍是为了服务运行 Pod。

Pod 能够分为两类：自主式 Pod 和控制器管理的 Pod。

此时咱们再回头来看用户访问 K8S 的服务就能够这样理解：

用户访问的实际上是某个提供服务的 Pod，请求先是到达宿主机（Node IP）的对应端口，而后将其转发给指定的 Service（Cluster IP），而后经过 kube-proxy 的 ipvs 规则再度将其转发到指定的 Pod（Pod IP）。固然到达 Pod 仍然会有相应的规则访问到 Pod 内的指定容器。

在咱们使用集群的时候，仍是建议在 K8S 集群外部再度加一层做为 Load Balance，同时辅以 Keepalive 实现高可用。

至于若是咱们想隔离 Pod，只须要采用不一样的名称空间（Namespace）就行。

 

 

关于 Service

 

当请求到达宿主机（Node IP）的时候，请求是没法直接到达 Pod 的，并且还多是多个 Pod 的状况。

因此咱们须要在这一个或者多个 Pod 前面再给它加一层，用来提供一个固定的访问端点（Cluster IP）。

经过标签选择器（Label selector）让 Pod 和这个访问端点（Service）进行绑定，就能实现 Service 网络和 Pod 网络的通讯。

但咱们最终目的仍是实现宿主机 Node 网络和 Service 网络通讯，这就须要 K8S 一个附件（DNS）来实现。具体细节就很少讲，咱们大体知道这些原理就行。

你可能会有学习 docker 容器时同样的疑问，后端 Pod 说不定就重构了，IP 变了，岂不意味这咱们须要关注 Service 的配置？

这是彻底没有必要的，咱们提到了 Service 网络到 Pod 网络是经过 Label selector 标签选择器绑定，这意味着，只要你标签不变，不管怎么更新，Service 上面的解析地址永远是对的。

同理，咱们在 Node 上访问 Service 网络也不须要有这些担忧，由于这里也不是直接经过 IP 访问，并且经过特定的名称。

最后须要记住，每组 Pod 应用都该拥有本身单独的 Service 进行调度。

 

 

关于 Controller

 

咱们这里只是简单的先让你们知道有控制器这个东西，至于更加详细的关于各类控制器的功能，会在以后特定的资源清单的时候详解。

那么，啥是控制器（Controller）？

咱们以前在第一节讲 Master 组成的时候说过，Master 由 Controller-manager / Scheduler / APIServer 组成，那时候说过，Controller-manager 是集群中进行统一资源管理的东西。那么 Controller 的做用就是管理 Pod 的运行规则。

在 K8S 中常见的 Controller 有如下几种：

1. ReplicationController

2. RelicaSet

3. Deployment（咱们当前用的最多的，也是默认的）

4. StatefulSet

5. DeamonSet

6. Job,Cronjob

 

 

K8S 命令提示不全 

 

这里单独提一下，当咱们手敲 K8S 命令的时候，不少时候须要去 --help 看参数命令，这显然不方便，咱们这里提供一个可以让咱们 tab 键提示命令的配置。注意，第一配置后须要登出再次登陆让环境生效。

yum install -y bash-completion
source /usr/share/bash-completion/bash_completion
source <(kubectl completion bash)
echo "source <(kubectl completion bash)" >> ~/.bashrc

 

 

K8S 命令 

 

咱们能够经过 kubectl -h 查看到 K8S 支持的命令，这里我作个简单的整理说明：

参数	说明
create	从文件或者输入建立
run	在集群中运行一个指定的镜像（几乎没用了）
expose	建立 Service
set	给对象设置一个指定的特征
explain	查看资源的文档（重要，帮助查参数）
get	获取资源信息（用的最多）
edit	直接编辑资源运行状态
delete	经过文件或者其余删除资源
rollout	主要用于版本升级和版本回滚（重要）
scale	直接更新资源的副本数量
autoscale	自动调整资源的副本数量
certificate	修改 certificate 资源
cluster-info	显示集群信息
top	显示系统资源使用状况
cordon	标记 node 为 unschedulable
uncordon	标记 node 为 schedulable
taint	更新 node 的 taints
describe	显示指定资源的详情（实用）
logs	输出容器在 pod 中的日志（重要，用于排错）
attach	进入到一个运行中的 container
exec	在一个 container 中执行一个命令
port-forward	端口转发
proxy	运行一个 proxy 到 Kubernetes API server
cp	复制
auth	Inspect authorization
diff	Diff live version against would-be applied version
apply	经过文件名或输入对资源进行配置（很是重要）
patch	更新资源的 field(s)
replace	经过文件或者输入换一个资源
wait	Experimental: Wait for a specific condition on one or many resources
convert	在不一样的 API versions 转换配置文件
kustomize	Build a kustomization target from a directory or a remote url
label	更新在这个资源上的标签
annotate	更新一个资源的注解
completion	Output shell completion code for the specified shell (bash or zsh)
api-resources	Print the supported API resources on the server
api-versions	Print the supported API versions on the server, in the form of "group/version"
config	修改 kubeconfig 文件
plugin	Provides utilities for interacting with plugins
version	输出 client 和 server 的版本信息

有些没有翻译或者标记的，要么用的比较少，要么现阶段意义不大。

 

 

示例：增删查改一个 Nginx Pod

 

咱们经过一个示例，看看整个过程当中咱们用到了那些命令。

【1】建立一个 Nginx Pod：

kubectl run nginx-demo --image=nginx:1.14-alpine --port=80 --replicas=1

结果如图：

这里简单的对命令进行一个说明：

咱们经过 run 运行一个 deployment 控制器取名为 nginx-demo，并经过 --image 指定了镜像版本，--port 说明了服务端口，只是说明，并不能暴露端口，--replicas 指明了副本运行数量。

在命令执行过程当中会有一个提示，不用在乎，咱们只须要看到下面 created，代表这个服务是建立成功的。

 

【2】查看 deployment 信息：

# 获取存在的 deployment
kubectl get deployment

# 查看指定 deployment 信息
kubectl get deployment nginx-demo -o wide

# 查看指定 deployment 详细的信息
kubectl describe deployment nginx-demo

结果如图：

这里有两个点须要知道，一是 -o wide，这个是显示更多信息，除此以外还有 -w，这个是动态显示，有点像 linux 的 top 命令。

另一个就是 describe 命令的做用，该命令可以帮我排查启动过程当中的错误，很是实用。

 

【3】查看 Pod 信息同理：

# 查看有哪些  pod
kubectl get pods

# 查看指定 pod
kubectl get pods nginx-demo-549b77b6c5-5nwhz -o wide

# 查看指定 pod 详细信息
kubectl describe pods nginx-demo-549b77b6c5-5nwhz

结果如图：

咱们可以看到该 Pod 运行的节点与分配到的 IP 地址。

 

【4】集群内访问测试 Pod：

curl 10.1.2.2

结果如图：

能够看到集群内部是能够直接访问到 Pod 网段并访问到 Pod 的服务的。可是集群外部不行。

 

【5】让外部网络也能访问到 Nginx：

以前咱们说过，想让外部访问，咱们必须把在 Pod 外面再套一层 Service，让 Service 和宿主机之间作 DNS 解析。

因此咱们来建立一个 Service：

kubectl expose deployment nginx-demo --name=nginx-svc --port=80 --target-port=80 --type=NodePort

这个命令能够当作，咱们将名为 nginx-demo 的 deployment 的 80 端口暴露出去，并给这个 service 取名为 nginx-svc。

至于 type 的意义，后面咱们会详细的讲解。

 

【6】查看建立的 Service：

# 查看有哪些 Service
kubectl get svc

# 查看指定 Service
kubectl get svc nginx-svc -o wide

咱们这里把 services 简写成 svc，方便使用。这种事情在 K8S 中很常见。结果如图：

能够看到，咱们的服务被映射成为 32118 端口，这个端口是一个大于 30000 的随机端口。

可使用集群中任意节点 IP + 32118 端口访问到 Nginx：

 

【7】查看日志：

kubectl logs nginx-demo-549b77b6c5-5nwhz

结果如图：

 

【8】集群管理（扩容和缩减）

# 扩容成3个
kubectl scale deployment nginx-demo --replicas=3

# 查看
kubectl get deployment nginx-demo -o wide

结果如图：

同理，若是要减小节点数，只须要将 replicas 减少就行。

 

【9】版本升级与回滚：

首先来看下版本升级，其实际就是将镜像的版本作变动：

kubectl set image deployment nginx-demo nginx-demo=nginx:1.15-alpine --record

查看更新后结果：

kubectl describe deployment nginx-demo

结果如图：

此时，咱们能够查看咱们升级过的版本：

kubectl rollout history deployment nginx-demo

结果如图：

由于有了这个东西，咱们回滚版本就有了两种选择，一是回滚上个版本，一是回滚指定版本：

# 回滚上个版本
kubectl rollout undo deployment nginx-demo

# 回滚指定版本
kubectl rollout undo deployment nginx-demo --to-revision=2

--to-reversion 指定的数字就是经过 history 看到的编号。 

 

【10】最后就是删除操做：

删除 Pod：

kubectl delete pod nginx-demo-76844fcc4d-49hf2

结果如图：

能够看到删除成功了，可是并无意义，由于 K8S 会再给我启动一个新的，这就是 K8S 的自愈能力。

 

删除 deployment：

kubectl delete deployment nginx-demo

结果如图：

获得的结论是，deployment 删除，pod 也就跟着删除。

 

删除 Service：

kubectl delete svc nginx-svc

结果如图：

 

 

小结

 

咱们这里提到的其实就是一小部分命令和参数，后续还会有不少，这得再以后用到的时候才方便详细讲解，后面也不会再以命令为主。

但这并不意味着这些基础的命令咱们能够不知道，这些属于咱们学习 K8S 的基础。