一 K8S 概览

1.1 K8S 是什么？

K8S官网文档：https://kubernetes.io/zh/docs/home/
K8S 是Kubernetes的全称，源于希腊语，意为“舵手”或“飞行员”，官方称其是：用于自动部署、扩展和管理“容器化（containerized）应用程序”的开源系统。翻译成大白话就是：“K8S 是负责自动化运维管理多个跨机器 Docker 程序的集群”。

1.2 K8S核心特性

• 服务发现与负载均衡：无需修改你的应用程序即可使用陌生的服务发现机制。
• 存储编排：自动挂载所选存储系统，包括本地存储。
• Secret和配置管理：部署更新Secrets和应用程序的配置时不必重新构建容器镜像，且不必将软件堆栈配置中的秘密信息暴露出来。
• 批量执行：除了服务之外，Kubernetes还可以管理你的批处理和CI工作负载，在期望时替换掉失效的容器。
• 水平扩缩：使用一个简单的命令、一个UI或基于CPU使用情况自动对应用程序进行扩缩。
• 自动化上线和回滚：Kubernetes会分步骤地将针对应用或其配置的更改上线，同时监视应用程序运行状况以确保你不会同时终止所有实例。
• 自动装箱：根据资源需求和其他约束自动放置容器，同时避免影响可用性。
• 自我修复：重新启动失败的容器，在节点死亡时替换并重新调度容器，杀死不响应用户定义的健康检查的容器。

pod里装的是docker容器，pod是k8s里部署应用的最小单位（容器是docker里部署应用的最小单位）；一个node下可以部署很多pod容器

1.3 K8S集群安装

参考后边这篇文章里的第二章 k8s集群部署

二 用K8S部署Nginx

在k8s-master机器上执行

# 创建一次deployment部署，最后nginx可以加版本号，如nginx:2.0，不写版本的话就是使用最新版nginx，最终部署到了node节点了，而不是master
kubectl create deployment nginx --image=nginx

kubectl get all

可以看到，已经部署了一个nginx容器

此时外网还不能访问这个nginx，需要做对外的端口映射

#端口映射，即创建一个nginx可以对外访问的端口，生成的端口是随机的（也可以指定端口） --port是service的虚拟ip对应的端口
kubectl expose deployment nginx --port=80 --type=NodePort  

再次执行kubectl get all命令

# 查看Nginx的pod和service信息
kubectl get pod,svc -o wide

访问Nginx地址：
http://任意从节点的ip:图中Nginx的对外映射端口，http://192.168.65.203:30563

主节点ip：端口也能访问，但是需要做配置，后边会讲；

补充：
如果node节点添加进集群失败，可以删除节点重新添加
要删除 k8s­node1 这个节点，首先在 master 节点上依次执行以下两个命令

kubectl drain k8s‐node1 ‐‐delete‐local‐data ‐‐force ‐‐ignore‐daemonsets 

kubectl delete node k8s‐node1

执行后通过 kubectl get node 命令可以看到 k8s­node1 已被成功删除；
接着在 k8s­node1 这个 Node 节点上执行如下命令，这样该节点即完全从 k8s 集群中脱离开来，之后就可以重新执行命令添加到集群

kubeadm reset

三 K8S 核心架构原理

我们已经知道了 K8S 的核心功能：自动化运维管理多个容器化程序。那么 K8S 怎么做到的呢？这里，我们从宏观架构上来学习 K8S 的设计思想。首先看下图：

K8S 是属于主从设备模型（Master-Slave 架构），即有 Master 节点负责核心的调度、管理和运维，Slave 节点则执行用户的程序。但是在 K8S 中，主节点一般被称为Master Node 或者 Head Node，而从节点则被称为Worker Node 或者 Node。

注意：Master Node 和 Worker Node 是分别安装了 K8S 的 Master 和 Woker 组件的实体服务器，每个 Node 都对应了一台实体服务器（虽然 Master Node 可以和其中一个 Worker Node 安装在同一台服务器，但是建议 Master Node 单独部署），所有 Master Node 和 Worker Node 组成了 K8S 集群，同一个集群可能存在多个 Master Node 和 Worker Node。

首先来看Master Node都有哪些组件：

• API Server。K8S 的请求入口服务。API Server 负责接收 K8S 所有请求（来自 UI 界面或者 CLI 命令行工具），然后，API Server 根据用户的具体请求，去通知其他组件干活。
• Scheduler。K8S 所有 Worker Node 的调度器。当用户要部署服务时，Scheduler 会选择最合适的 Worker Node（服务器）来部署。
• Controller Manager。K8S 所有 Worker Node 的监控器，解析API Server传过来的命令，解析后存储到下边的etcd库里。Controller Manager 有很多具体的 Controller， Node Controller、Service Controller、Volume Controller 等。Controller 负责监控和调整在 Worker Node 上部署的服务的状态，比如用户要求 A 服务部署 2 个副本，那么当其中一个服务挂了的时候，Controller 会马上调整，让 Scheduler 再选择一个 Worker Node 重新部署服务。
• etcd。K8S 的存储服务。etcd 存储了 K8S 的关键配置和用户配置，K8S 中仅 API Server 才具备读写权限，其他组件必须通过 API Server 的接口才能读写数据。

接着来看Worker Node的组件：

• Kubelet。Worker Node 的监视器，以及与 Master Node 的通讯器。Kubelet 是 Master Node 安插在 Worker Node 上的“眼线”（相当于node的小管家），它会定期向 Master Node 汇报自己 Node 上运行的服务的状态，并接受来自 Master Node 的指示采取调整措施。负责控制所有容器的启动停止，保证节点工作正常。Kubelet上报给msater自己资源的使用情况后，master的调度器Scheduler就能根据每台node机器的实际情况来给各个node分配任务了；
• Kube-Proxy。K8S 的网络代理。Kube-Proxy 负责 Node 在 K8S 的网络通讯、以及对外部网络流量的负载均衡。
• Container Runtime。Worker Node 的运行环境。即安装了容器化所需的软件环境确保容器化程序能够跑起来，比如 Docker Engine运行环境。

在大概理解了上面几个组件的意思后，我们来看下上面用K8S部署Nginx的过程中，K8S内部各组件是如何协同工作的：

我们在master节点执行一条命令，如master部署一个nginx应用(kubectl create deployment nginx --image=nginx:2.0.1)，都经历了哪些流程

• 这条命令首先发到master节点的网关api server，这是matser的唯一入口
• api server将命令请求交给controller mannager进行控制(controller mannager解析命令)
• controller mannager 进行应用部署解析
• controller mannager 会生成一次部署信息，并通过api server将信息存入etcd存储中
• scheduler调度器通过api server从etcd存储中，拿到要部署的应用与node节点的信息，开始调度看哪个节点有资源适合部署
• scheduler把计算出来的调度信息通过api server再放到etcd中
• 每一个node节点的监控组件kubelet，随时和master保持联系（给api-server发送请求不断获取最新数据），拿到master节点存储在etcd中的部署信息
• 假设node2的kubelet拿到部署信息，显示他自己节点要部署某某应用
• kubelet就自己run一个应用在当前机器上，并随时给master汇报当前应用的状态信息
• node和master也是通过master的api-server组件联系的
• 每一个机器上的kube-proxy能知道集群的所有网络，只要node访问别人或者别人访问node，node上的kube-proxy网络代理自动计算进行流量转发

四 K8S 快速实战

4.1 kubectl命令使用

kubectl是apiserver的客户端工具，工作在命令行下，能够连接apiserver实现各种增删改查等操作
kubectl官方使用文档：https://kubernetes.io/zh/docs/reference/kubectl/overview/

K8S的各种命令帮助文档做得非常不错，遇到问题可以多查help帮助

4.2 创建一个Tomcat应用程序

使用 kubectl create deployment 命令可以创建一个应用部署deployment与Pod

#my-tomcat表示pod的名称 --image表示镜像的地址 
kubectl create deployment my-tomcat --image=tomcat:7.0.75-alpine

查看一下deployment的信息

kubectl get deployment
# 或者查看所有资源
kubectl get all
# 或者查看pod资源
kubectl get pod

获取pod的信息，-o wide 表示更详细的显示信息

kubectl get pod -o wide

查看Pod打印的日志

kubectl logs my-tomcat-685b8fd9c9-rw42d(pod名称)

使用 exec 可以在Pod的容器中执行命令，这里使用 env 命令查看环境变量

kubectl exec my-tomcat-685b8fd9c9-rw42d -- env
kubectl exec my-tomcat-685b8fd9c9-rw42d -- ls /   # 查看容器的根目录下面内容

进入Pod容器内部并执行bash命令，如果想退出容器可以使用exit命令

kubectl exec -it my-tomcat-685b8fd9c9-rw42d -- sh

这个ip与docker容器里的ip一样，重启服务器后是会变的，但是对我们没影响，因为这个ip是容器内部用的，我们用不到；

访问一下这个tomcat pod

集群内访问（在集群里任一node节点都可以访问）

curl 10.244.36.69:8080

集群外部访问

当我们在集群之外访问是发现无法访问，那么集群之外的客户端如何才能访问呢？这就需要我们的service服务了，下面我们就创建一个service，使外部客户端可以访问我们的pod；

4.3 创建一个service

# 最后边的--type=NodePort代表映射的外网（宿主机）端口随机，容器内部的端口是8080
kubectl expose deployment my-tomcat --name=tomcat --port=8080 --type=NodePort

#查看service信息，port信息里冒号后面的端口号就是对集群外暴露的访问接口
kubectl get svc -o wide

上边结果里的32224就是对外暴露的端口，即容器内部的8080与宿主机的32224端口对应；

集群外部访问
使用集群worker节点的ip加上暴露的端口就可以访问

service服务有个特点，如果端口暴露类型为NodePort，那么可以通过集群内所有worker主机加暴露的端口进行访问

现在我们来删除刚刚添加的pod，看看会发生什么

#查看pod信息，-w意思是一直等待观察pod信息的变动
kubectl get pod -w

开另外一个命令窗口执行如下命令，同时观察之前命令窗口的变化情况

kubectl delete pod my-tomcat-685b8fd9c9-rw42d

pending：等待中；

我们可以看到之前那个tomcat的pod被销毁，但是又重新启动了一个新的tomcat pod，这是k8s的服务自愈功能，不需要运维人员干预

查看下deployment和service的状态

再一次访问service地址，依然可以访问成功

一个service端口对应多个tomcat，这个service会自动去做负载均衡；

4.4 对my-tomcat这个deployment进行扩缩容

# 扩容到5个pod
kubectl scale --replicas=5 deployment my-tomcat

查看pod信息，发现已经有5个tomcat的pod

kubectl get pod

缩容

# 扩容到3个pod
kubectl scale --replicas=3 deployment my-tomcat

4.5 滚动升级与回滚

对my-tomcat这个deployment进行滚动升级（一台一台升级）和回滚，将tomcat版本由tomcat:7.0.75-alpine升级到tomcat:8.0.41-jre8-alpine，再回滚到tomcat:7.0.75-alpine

滚动升级：

kubectl set image deployment my-tomcat tomcat=tomcat:8.0.41-jre8-alpine

可以执行 kubectl get pod -w 观察pod的变动情况，可以看到有的pod在销毁，有的pod在创建

查看pod信息

kubectl get pod

查看某个pod的详细信息，发现pod里的镜像版本已经升级了

kubectl describe pod my-tomcat-547db86547-4btmd

访问下tomcat，看到版本也已经升级

版本回滚：

查看历史版本

kubectl rollout history deploy my-tomcat

再次访问tomcat，发现版本已经回退

4.6 标签的使用

通过给资源添加Label，可以方便地管理资源（如Deployment、Pod、Service等）。

查看Deployment中所包含的Label

kubectl describe deployment my-tomcat

通过Label查询Pod

kubectl get pods -l app=my-tomcat

通过Label查询Service

kubectl get services -l app=my-tomcat

给Pod添加Label

kubectl label pod  version=v1

查看Pod的详细信息，可以查看Label信息：

kubectl describe pods my-tomcat-685b8fd9c9-lrwst

通过Label查询Pod

kubectl get pods -l version=v1

通过Label删除服务

kubectl delete service -l app=test-service

比如新启动了一些pod，想要与之前的pod是一批，那么就可以把这些pod的标签改为一样的就行；

小总结

kubectl create deployment       #创建一个deployment来管理创建的容器
kubectl get       #显示一个或多个资源，可以使用标签过滤，默认查看当前名称空间的资源
kubectl expose    #将一个资源暴露为一个新的kubernetes的service资源，资源包括pod (po)， service (svc)， replicationcontroller (rc)，deployment(deploy)， replicaset (rs)
kubectl describe  #显示特定资源或资源组的详细信息
kubectl scale     #可以对Deployment, ReplicaSet, Replication Controller, 或者StatefulSet设置新的值，可以指定一个或多个先决条件
kubectl set       #更改现有的应用程序资源
kubectl rollout   #资源回滚管理

以上就是kubectl命令行下一些简单的操作，主要是让我们对kubernetes有一个快速的认识。