K8S一 k8s基础知识及实战

一 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节点添加进集群失败，可以删除节点重新添加
要删除 k8snode1 这个节点，首先在 master 节点上依次执行以下两个命令

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

kubectl delete node k8s‐node1

执行后通过 kubectl get node 命令可以看到 k8snode1 已被成功删除；
接着在 k8snode1 这个 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有一个快速的认识。