K8S一 k8s基础知识及实战
一 K8S 概览https://i-blog.csdnimg.cn/blog_migrate/9e8ea657a016883415e64ae7b368863d.png
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容器
https://i-blog.csdnimg.cn/blog_migrate/03c0712e6ef24e44ac5bdc10f151ed4d.png
此时外网还不能访问这个nginx，需要做对外的端口映射
#端口映射，即创建一个nginx可以对外访问的端口，生成的端口是随机的（也可以指定端口） --port是service的虚拟ip对应的端口
kubectl expose deployment nginx --port=80 --type=NodePort
再次实行kubectl get all
命令
https://i-blog.csdnimg.cn/blog_migrate/7df54c1f43da89619419462b412bf5af.png
# 查看Nginx的pod和service信息
kubectl get pod
,svc -o wide
https://i-blog.csdnimg.cn/blog_migrate/e5c5137ca345cff92c0ca588e7f5679b.png
访问Nginx地点：
http://任意从节点的ip:图中Nginx的对外映射端口，http://192.168.65.203:30563
https://i-blog.csdnimg.cn/blog_migrate/3c84814a12f69b4ebbce2fd511889b47.png
主节点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 的计划思想。首先看下图：
https://i-blog.csdnimg.cn/blog_migrate/dbd9a012991baf18ef593039444c4fe1.png
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网络署理主动计算进行流量转发
https://i-blog.csdnimg.cn/blog_migrate/cd60890e811f01f05e11f873e1290de5.png
四 K8S 快速实战
4.1 kubectl命令使用
kubectl是apiserver的客户端工具，工作在命令行下，能够毗连apiserver实现各种增删改查等利用
kubectl官方使用文档：https://kubernetes.io/zh/docs/reference/kubectl/overview/
https://i-blog.csdnimg.cn/blog_migrate/5e3e25e4e676e36025554ef40a89bfa9.png
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
https://i-blog.csdnimg.cn/blog_migrate/308379de6fa35458d4300376e7441941.png
查看一下deployment的信息
kubectl get deployment# 或者查看所有资源kubectl get all
# 或者查看pod资源kubectl get pod
https://i-blog.csdnimg.cn/blog_migrate/5c26dc391d46963c5d707fbc937befef.png
获取pod的信息，-o wide 表现更详细的显示信息
kubectl get pod
-o wide
https://i-blog.csdnimg.cn/blog_migrate/474dcffc3173a00e5ca2449d812dc928.png
查看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 / # 查看容器的根目录下面内容
https://i-blog.csdnimg.cn/blog_migrate/b1c67c34142d7575c939f388def67c81.png
https://i-blog.csdnimg.cn/blog_migrate/bb58f6ceeb3159840160021996e4da54.png
进入Pod容器内部并实行bash命令，假如想退出容器可以使用exit命令
kubectl exec -it my-tomcat-685b8fd9c9-rw42d -- sh
https://i-blog.csdnimg.cn/blog_migrate/6a5bf8f4a339284fd28a37320b2c713d.png
https://i-blog.csdnimg.cn/blog_migrate/066c4cb6987ff138531b1575880bfe29.png
这个ip与docker容器里的ip一样，重启服务器后是会变的，但是对我们没影响，因为这个ip是容器内部用的，我们用不到；
访问一下这个tomcat pod
集群内访问（在集群里任一node节点都可以访问）
curl 10.244.36.69:8080
https://i-blog.csdnimg.cn/blog_migrate/c01068a0407d40bd50ea3dbd34d9cbe7.png
集群外部访问
https://i-blog.csdnimg.cn/blog_migrate/fb73ac1dcd073314cfa225d93185927a.png
当我们在集群之外访问是发现无法访问，那么集群之外的客户端如何才能访问呢？这就需要我们的service服务了，下面我们就创建一个service，使外部客户端可以访问我们的pod；
4.3 创建一个service
# 最后边的--type=NodePort代表映射的外网（宿主机）端口随机，容器内部的端口是8080
kubectl expose deployment my-tomcat --name=tomcat --port=8080 --type=NodePort
https://i-blog.csdnimg.cn/blog_migrate/42c41409269b2324234d03970af2b974.png
#查看service信息，port信息里冒号后面的端口号就是对集群外暴露的访问接口
kubectl get svc -o wide
https://i-blog.csdnimg.cn/blog_migrate/078b23ffead8b98c72b707964667892c.png
上边结果里的32224就是对外暴露的端口，即容器内部的8080与宿主机的32224端口对应；
集群外部访问
使用集群worker节点的ip加上暴露的端口就可以访问
https://i-blog.csdnimg.cn/blog_migrate/f938cadd9dcd9b392b49491c2edec6c1.png
service服务有个特点，假如端口暴露类型为NodePort，那么可以通过集群内所有worker主机加暴露的端口进行访问
如今我们来删除刚刚添加的pod，看看会发生什么
#查看pod信息，-w意思是一直等待观察pod信息的变动
kubectl get pod
-w
https://i-blog.csdnimg.cn/blog_migrate/6517078fdde50ca0443d05fc4ef4d92e.png
开另外一个命令窗口实行如下命令，同时观察之前命令窗口的厘革环境
kubectl delete pod my-tomcat-685b8fd9c9-rw42d
https://i-blog.csdnimg.cn/blog_migrate/dcbc17a6e1caf5807ead90e576dcbd57.png
pending：等待中；
我们可以看到之前那个tomcat的pod被销毁，但是又重新启动了一个新的tomcat pod，这是k8s的服务自愈功能，不需要运维职员干预
查看下deployment和service的状态
https://i-blog.csdnimg.cn/blog_migrate/5c5bd6a801644088a464b3a0d62cbe86.png
再一次访问service地点，依然可以访问乐成
https://i-blog.csdnimg.cn/blog_migrate/b38a6982c9e05301b17bb67c98b632a8.png
一个service端口对应多个tomcat，这个service会主动去做负载均衡；
4.4 对my-tomcat这个deployment进行扩缩容
# 扩容到5个pod
kubectl scale --replicas=5 deployment my-tomcat
查看pod信息，发现已经有5个tomcat的pod
kubectl get pod
https://i-blog.csdnimg.cn/blog_migrate/04d247bcbf5be3af0706a71569ae933e.png
缩容
# 扩容到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在创建
https://i-blog.csdnimg.cn/blog_migrate/55e9e0161e686bc4802cf9db7179ec52.png
查看pod信息
kubectl get pod
https://i-blog.csdnimg.cn/blog_migrate/3d0dae67e1a0ddb0d5c775cbbccbf8d9.png
查看某个pod的详细信息，发现pod里的镜像版本已经升级了
kubectl describe pod my-tomcat-547db86547-4btmd
https://i-blog.csdnimg.cn/blog_migrate/9b14f4e7759b358910b71f305e5b6d5c.png
访问下tomcat，看到版本也已经升级
https://i-blog.csdnimg.cn/blog_migrate/68c866a285d7e2d387c8013ddddcb2a3.png
版本回滚：
查看历史版本
kubectl rollout history deploy my-tomcat
https://i-blog.csdnimg.cn/blog_migrate/76a6732a79fc46a3c98aa2aee3131ea3.png
再次访问tomcat，发现版本已经回退
https://i-blog.csdnimg.cn/blog_migrate/dfcdbeb476f17ac9cdf83082de89ba78.png
4.6 标签的使用
通过给资源添加Label，可以方便地管理资源（如Deployment、Pod、Service等）。
查看Deployment中所包罗的Label
kubectl describe deployment my-tomcat
https://i-blog.csdnimg.cn/blog_migrate/0a35cd8ae919302c8a1eff0d880d2bdf.png
通过Label查询Pod
kubectl get pod
s -l app=my-tomcat https://i-blog.csdnimg.cn/blog_migrate/023e62abc4697c14a2d6d35b34497dff.png
通过Label查询Service
kubectl get services -l app=my-tomcat
https://i-blog.csdnimg.cn/blog_migrate/9164d3eab1f72a0a93394301468e1764.png
给Pod添加Label
kubectl label podversion=v1
查看Pod的详细信息，可以查看Label信息：
kubectl describe pods my-tomcat-685b8fd9c9-lrwst
https://i-blog.csdnimg.cn/blog_migrate/af478dec1616d42f051b1f9849eef89e.png
通过Label查询Pod
kubectl get pod
s -l version=v1 https://i-blog.csdnimg.cn/blog_migrate/7b7db6fbd9eb5a4dbda9db7a0791ac22.png
通过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有一个快速的认识。
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。
页:
[1]