网站群建设项目招标公告,做网站推广哪家好,236企业邮箱登录入口,南昌网站网站建设一 K8S 概览 1.1 K8S 是什么#xff1f;
K8S官网文档#xff1a;https://kubernetes.io/zh/docs/home/ K8S 是Kubernetes的全称#xff0c;源于希腊语#xff0c;意为“舵手”或“飞行员”#xff0c;官方称其是#xff1a;用于自动部署、扩展和管理“容器化#xff08…一 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 --imagenginxkubectl get all可以看到已经部署了一个nginx容器 此时外网还不能访问这个nginx需要做对外的端口映射
#端口映射即创建一个nginx可以对外访问的端口生成的端口是随机的也可以指定端口 --port是service的虚拟ip对应的端口
kubectl expose deployment nginx --port80 --typeNodePort 再次执行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 --imagenginx: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访问别人或者别人访问nodenode上的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 --imagetomcat: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
# 最后边的--typeNodePort代表映射的外网宿主机端口随机容器内部的端口是8080
kubectl expose deployment my-tomcat --nametomcat --port8080 --typeNodePort#查看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-rw42dpending等待中
我们可以看到之前那个tomcat的pod被销毁但是又重新启动了一个新的tomcat pod这是k8s的服务自愈功能不需要运维人员干预
查看下deployment和service的状态 再一次访问service地址依然可以访问成功 一个service端口对应多个tomcat这个service会自动去做负载均衡
4.4 对my-tomcat这个deployment进行扩缩容
# 扩容到5个pod
kubectl scale --replicas5 deployment my-tomcat查看pod信息发现已经有5个tomcat的pod
kubectl get pod缩容
# 扩容到3个pod
kubectl scale --replicas3 deployment my-tomcat4.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 tomcattomcat: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 appmy-tomcat通过Label查询Service
kubectl get services -l appmy-tomcat给Pod添加Label
kubectl label pod versionv1查看Pod的详细信息可以查看Label信息
kubectl describe pods my-tomcat-685b8fd9c9-lrwst通过Label查询Pod
kubectl get pods -l versionv1通过Label删除服务
kubectl delete service -l apptest-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有一个快速的认识。
