东莞seo网站排名优化,建工社微课程官网,淄博周村网站建设哪家好,企业微信crmkubectl 一、陈述式资源管理1. 陈述式资源管理方法2. 基本信息查看3. 项目周期管理3.1 创建 kubectl create 命令3.2 发布 kubectl expose命令3.3 更新 kubectl set3.4 回滚 kubectl rollout3.5 删除 kubectl delete 4. kubectl 的发布策略4.1 蓝绿发布4.2 红黑发布4.3 灰度发布… kubectl 一、陈述式资源管理1. 陈述式资源管理方法2. 基本信息查看3. 项目周期管理3.1 创建 kubectl create 命令3.2 发布 kubectl expose命令3.3 更新 kubectl set3.4 回滚 kubectl rollout3.5 删除 kubectl delete 4. kubectl 的发布策略4.1 蓝绿发布4.2 红黑发布4.3 灰度发布金丝雀发布4.4 滚动发布 二、声明式资源管理1. 声明式管理方法2. 资源管理 总结1. k8s 资源管理方式2. service 的四种类型3. service 的端口4. 应用的发布策略 一、陈述式资源管理
1. 陈述式资源管理方法
kubernetes 集群管理集群资源的唯一入口是通过相应的方法调用 apiserver 的接口kubectl 是官方的CLI命令行工具用于与 apiserver 进行通信将用户在命令行输入的命令组织并转化为 apiserver 能识别的信息进而实现管理 k8s 各种资源的一种有效途径kubectl 的命令大全
kubectl --help
k8s中文文档http://docs.kubernetes.org.cn/683.html对资源的增、删、查操作比较方便但对改的操作就不容易了
#查看版本信息/
kubectl version#查看资源对象简写
kubectl api-resources#查看集群信息
kubectl cluster-info#配置kubectl自动补全此命令只在当前命令界面生效如果想要永久生效可以在.bashrc或者/etc/bashrc文件中添加
source (kubectl completion bash)#node节点查看日志
journalctl -u kubelet -f2. 基本信息查看
#获取资源的相关信息
kubectl get resource [-o wide|json|yaml] [-n namespace] --------------------------------------------------------------
#-n 指定命令空间-o 指定输出格式
#resource可以是具体资源名称如pod nginx-xxx也可以是资源类型如pod或者all(仅展示几种核心资源并不完整)
#--all-namespaces 或 -A 表示显示所有命名空间
#--show-labels 显示所有标签
#-l app 仅显示标签为app的资源
#-l appnginx 仅显示包含app标签且值为nginx的资源#查看 master 节点状态
kubectl get componentstatuses
kubectl get cs#查看命名空间
kubectl get namespace
kubectl get ns
#命令空间的作用用于允许不同 命名空间 的 相同类型 的资源 重名的即在同一个命名空间下不能有同名的资源#指定查看kubernetes-dashboard命名空间下下的资源
kubectl get -n kubernetes-dashboard svc#查看kubernetes-dashboard命名空间的所有资源
kubectl get all -n kubernetes-dashboard#查看kubernetes-dashboard命名空间下资源 信息
kubectl get -n kubernetes-dashboard pods -o wide#根据标签查看kubernetes-dashboard命名空间下资源信息
kubectl get pods -A -l appflannel#查看只包含k8s-app键值对的资源信息
kubectl get pods -A -l k8s-app#指定查看某个键值对的资源信息
kubectl get pods -A -l k8s-appkubernetes-dashboard --show-labels#创建命名空间app
kubectl create ns app
kubectl get ns#删除命名空间app
kubectl delete namespace app
kubectl get ns #在命名空间kube-public 创建副本控制器deployment来启动Podnginx-test
kubectl create deployment nginx-test --imagenginx -n kube-public#描述某个资源的详细信息
kubectl describe deployment nginx-test -n kube-public
kubectl describe pod -n kube-public nginx-test-795d659f45-pvdx9#查看命名空间kube-public 中的pod 信息
kubectl get pods -n kube-public
NAME READY STATUS RESTARTS AGE
nginx-test-795d659f45-pvdx9 1/1 Running 0 11m#kubectl exec可以跨主机登录容器docker exec 只能在容器所在主机上登录
kubectl exec -it nginx-test-795d659f45-pvdx9 bash -n kube-public#删除重启pod资源由于存在deployment/rc之类的副本控制器删除pod也会重新拉起来
kubectl delete pod nginx-test-795d659f45-pvdx9 -n kube-public#若pod无法删除总是处于terminate状态则要强行删除pod
kubectl delete pod pod-name -n namespace --force --grace-period0
#grace-period表示过渡存活期默认30s在删除pod之前允许pod慢慢终止其上的容器进程从而优雅退出0表示立即终止pod#扩缩容
kubectl scale deployment nginx-test --replicas2 -n kube-public # 扩容
kubectl scale deployment nginx-test --replicas1 -n kube-public # 缩容#删除副本控制器
kubectl delete deployment nginx-test -n kube-public
kubectl delete deployment/nginx-test -n kube-public3. 项目周期管理 项目的生命周期创建–发布–更新–回滚–删除 3.1 创建 kubectl create 命令 创建并运行一个或多个容器镜像。 创建一个 deployment 或 job 来管理容器。 #启动 nginx 实例暴露容器端口 80设置副本数 3
kubectl create deployment nginx --imagenginx:1.14 --port80 --replicas3kubectl get pods
kubectl get all3.2 发布 kubectl expose命令 将资源暴露为新的 Service。 kubectl expose --help#为deployment的nginx创建service并通过Service的80端口转发至容器的80端口上Service的名称为nginx-service类型为NodePort
kubectl expose deployment nginx --port80 --target-port80 --namenginx-service --typeNodePort------------------------------------------------------------------------------------------
Kubernetes 之所以需要 Service一方面是因为 Pod 的 IP 不是固定的Pod可能会重建另一方面则是因为一组 Pod 实例之间总会有负载均衡的需求。
Service 通过 Label Selector 实现的对一组的 Pod 的访问。
对于容器应用而言Kubernetes 提供了基于 VIP虚拟IP 的网桥的方式访问 Service再由 Service 重定向到相应的 Pod。service 的 type 类型功能ClusterIP提供一个集群内部的虚拟IP以供Pod访问service默认类型)NodePort在每个Node上打开一个端口以供外部访问Kubernetes将会在每个Node上打开一个端口并且每个Node的端口都是一样的通过 NodeIp:NodePort 的方式Kubernetes集群外部的程序可以访问Service。每个端口只能是一种服务默认端口范围只能是 30000-32767。LoadBalance使用外接负载均衡器完成到服务的负载分发注意此模式需要外部云环境支持。借助第三方的云负载均衡器将请求分发到所有的Node上其底层还是NodePortLoadBalancer和NodePort很相似目的都是向外部暴露一个端口区别在于LoadBalancer会在集群的外部再来做一个负载均衡设备而这个设备需要外部环境支持的外部服务发送到这个设备上的请求会被设备负载之后转发到集群中。externalName将service名称映射到一个DNS域名上相当于DNS服务的CNAME记录用于让Pod去访问集群外部的资源它本身没有绑定任何的资源。 #查看pod网络状态详细信息和 Service暴露的端口
kubectl get pods,svc -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
pod/nginx-d9d8cf5c7-kfgh5 1/1 Running 0 9m41s 10.244.2.5 node02 none none
pod/nginx-d9d8cf5c7-pjjg4 1/1 Running 0 9m41s 10.244.1.4 node01 none none
pod/nginx-d9d8cf5c7-w4rzc 1/1 Running 0 9m41s 10.244.1.5 node01 none noneNAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE SELECTOR
service/kubernetes ClusterIP 10.96.0.1 none 443/TCP 5h20m none
service/nginx-service NodePort 10.96.221.68 none 80:31233/TCP 3m29s appnginx#查看关联后端的节点
kubectl get endpoints#查看 service 的描述信息
kubectl describe svc nginx#在 node01 节点上操作查看负载均衡端口
yum install ipvsadm -y
ipvsadm -Ln
#外部访问的IP和端口
TCP 192.168.145.12:31233 rr- 10.244.1.4:80 Masq 1 0 0 - 10.244.1.5:80 Masq 1 0 0 - 10.244.2.5:80 Masq 1 0 0
#pod集群组内部访问的IP和端口
TCP 10.96.221.68:80 rr- 10.244.1.4:80 Masq 1 0 0 - 10.244.1.5:80 Masq 1 0 0 - 10.244.2.5:80 Masq 1 0 0 #在 node02 节点上操作同样方式查看负载均衡端口
yum install ipvsadm -y
ipvsadm -Ln
TCP 192.168.145.13:31233 rr- 10.244.1.4:80 Masq 1 0 0 - 10.244.1.5:80 Masq 1 0 0 - 10.244.2.5:80 Masq 1 0 0 TCP 10.96.221.68:80 rr- 10.244.1.4:80 Masq 1 0 0 - 10.244.1.5:80 Masq 1 0 0 - 10.244.2.5:80 Masq 1 0 0 curl 10.96.221.68
curl 192.168.145.11:6443
#在master01操作 查看访问日志
kubectl logs nginx-d9d8cf5c7-kfgh5
kubectl logs nginx-d9d8cf5c7-pjjg4
kubectl logs nginx-d9d8cf5c7-w4rzc 3.3 更新 kubectl set 更改现有应用资源一些信息。 kubectl set --help#获取修改模板
kubectl set image --help
Examples:# Set a deployments nginx container image to nginx:1.9.1, and its busybox container image to busybox.kubectl set image deployment/nginx busyboxbusybox nginxnginx:1.9.1#查看当前 nginx 的版本号
curl -I http://192.168.145.11:31233
curl -I http://192.168.145.12:31223#将nginx 版本更新为 1.15 版本
kubectl set image deployment/nginx nginxnginx:1.15#处于动态监听 pod 状态由于使用的是滚动更新方式所以会先生成一个新的pod然后删除一个旧的pod往后依次类推
kubectl get pods -w---------------------------------------------------------------------------------------------
#滚动更新详解
kubectl get all
DESIRED表示期望的状态是 10 个 READY 的副本
CURRENT表示当前副本的总数: 即8 个日副本 5 个新副本
UP_TO-DATE表示当前已经完成更新的副本数: 即 5个新副本
AVAILABLE表示当前处于 READY 状态的副本数: 即8个日副本。kubectl describe deployment/nginx
滚动更新通过参数 maxSurge 和 maxUnavailable 来控制副本替换的数量
maxSurge此参数控制滚动更新过程中副本总数的超过 DESIRED 的上限。maxSurge 可以是具体的整数比如 3也可以是百分百向上取整。maxSurge 默认值为 25%。
例如DESIRED 为 10那么副本总数的最大值为 10 10 * 25% 13即 CURRENT 为 13。maxUnavailable此参数控制滚动更新过程中不可用的副本相占 DESIRED 的最大比例。maxUnavailable 可以是具体的整数比如 3也可以是百分百向下取整。 maxUnavailable 默认值为 25%。
例如DESIRED 为 10那么可用的副本数至少要为 10 - 10 * 25% 8即 AVAILABLE 为 8。因此 maxSurge 值越大初始创建的新副本数量就越多maxUnavailable 值越大初始销毁的旧副本数量就越多。理想情况下DESIRED 为 10 的滚动更新的过程应该是这样的
首先创建 3 个新副本使副本总数达到 13 个。
然后销毁 2 个旧副本使可用的副本数降到 8 个。
当这 2 个旧副本成功销毁后可再创建 2 个新副本使副本总数保持为 13 个。
当新副本通过 Readiness 探测后会使可用副本数增加超过 8。
进而可以继续销毁更多的旧副本使可用副本数回到 8。
旧副本的销毁使副本总数低于 13这样就允许创建更多的新副本。
这个过程会持续进行最终所有的旧副本都会被新副本替换滚动更新完成。
---------------------------------------------------------------------------------------------#再看更新好后的 Pod 的 ip 会改变
kubectl get pods -o wide#再看 nginx 的版本号
curl -I http://192.168.145.11:30574
curl -I http://192.168.145.12:305743.4 回滚 kubectl rollout 对资源进行回滚管理 #查看历史版本
kubectl rollout history deployment/nginx #执行回滚到上一个版本
kubectl rollout undo deployment/nginx#执行回滚到指定版本
kubectl rollout undo deployment/nginx --to-revision1#检查回滚状态
kubectl rollout status deployment/nginx3.5 删除 kubectl delete
#删除副本控制器
kubectl delete deployment/nginx#删除service
kubectl delete svc/nginx-servicekubectl get all4. kubectl 的发布策略
4.1 蓝绿发布 概念定义蓝绿发布是一种以最小的停机时间做服务升级的策略。需要维护的两个版本的环境分别称为 “蓝环境” 和 “绿环境”。一般当前生产流量指向环境为绿环境而在蓝环境上部署新版本短时间内作为测试环境。 发布流程首先将一半的服务流量从负载均衡列表中移除并且更新服务版本验证新版本没有问题后将生产流量指向蓝环境然后对于老版本的绿环境进行版本升级最后将所有服务流量加回负载均衡。 特点
升级过程无需停机用户感知小升级过程一半资源提供服务升级/回滚速度快如果出了问题影响面较广
4.2 红黑发布 概念定义与蓝绿发布类似红黑发布也是通过两个环境完成软件版本的升级将当前生产流量指向的环境称为红环境新版本环境称为黑环境。 发布流程需申请新资源用于部署黑环境在黑环境部署新版本的服务黑环境部署完成后一次性将生产流量指向黑环境释放红环境的资源。 特点
升级过程无需停机用户感知小短时间内需要使用双倍资源 与蓝绿发布相比红黑发布充分利用了云计算的弹性伸缩的优势实现
简化发布流程避免在升级的过程中由于只有一半资源提供服务而导致的系统过载问题
4.3 灰度发布金丝雀发布 Deployment控制器支持自定义控制更新过程中的滚动节奏如“暂停(pause)”或“继续(resume)”更新操作。比如等待第一批新的Pod资源创建完成后立即暂停更新过程此时仅存在一部分新版本的应用主体部分还是旧的版本。然后再筛选一小部分的用户请求路由到新版本的Pod应用继续观察能否稳定地按期望的方式运行。确定没问题之后再继续完成余下的Pod资源滚动更新否则立即回滚更新操作。这就是所谓的金丝雀发布。 1更新deployment的版本并配置暂停deployment
kubectl set image deployment/nginx nginxnginx:1.14 kubectl rollout pause deployment/nginxkubectl rollout status deployment/nginx #观察更新状态2监控更新的过程可以看到已经新增了一个资源但是并未按照预期的状态去删除一个旧的资源就是因为使用了pause暂停命令
kubectl get pods -w curl [-I] 10.0.0.189
curl [-I] 192.168.145.11:448473确保更新的pod没问题了继续更新
kubectl rollout resume deployment/nginx4查看最后的更新情况
kubectl get pods -w curl [-I] 10.0.0.189
curl [-I] 192.168.145.11:448474.4 滚动发布 在金丝雀发布基础上的进一步优化改进是一种自动化程度较高的发布方式用户体验比较平滑是目前成熟型技术组织所采用的主流发布方式。
二、声明式资源管理
1. 声明式管理方法
适合于对资源的修改操作声明式资源管理方法依赖于资源配置清单文件对资源进行管理
资源配置清单文件有两种格式yaml人性化易读json易于api接口解析对资源的管理是通过事先定义在统一资源配置清单内再通过陈述式命令应用到k8s集群里 语法格式kubectl create/apply/delete -f xxxx.yaml
2. 资源管理
#查看资源配置清单
kubectl get deployment nginx -o yaml#解释资源配置清单
kubectl explain deployment.metadatakubectl get service nginx -o yaml
kubectl explain service.metadata#修改资源配置清单并应用
离线修改
修改yaml文件并用 kubectl apply -f xxxx.yaml 文件使之生效
注意当apply不生效时先使用delete清除资源再apply创建资源kubectl get service nginx -o yaml nginx-svc.yaml
vim nginx-svc.yaml #修改port: 8080
kubectl delete -f nginx-svc.yaml
kubectl apply -f nginx-svc.yaml
kubectl get svc在线修改
直接使用 kubectl edit service nginx 在线编辑资源配置清单并保存退出即时生效如port: 888
#PS此修改方式不会对yaml文件内容修改#删除资源配置清单
陈述式删除
kubectl delete service nginx声明式删除
kubectl delete -f nginx-svc.yaml总结
1. k8s 资源管理方式
#陈述式资源管理
kubectl create 资源类型 资源名称 -n 命名空间 [选项]--image镜像 --replicas副本数 --port容器端口kubectl get 资源类型|all [资源名称] -n 命名空间 -o wide|yaml|json -wkubectl describe 资源类型 资源名称 -n 命名空间kubectl delete 资源类型 资源名称|--all -n 命名空间 [--force --grace-period0]立即终止Pod运行强制删除资源kubectl exec -it -n 命名空间 Pod资源名称 [-c 容器名称] sh|bashkubectl logs -n 命名空间 Pod资源名称 [-c 容器名称] [-p]kubectl scale -n 命名空间 deployment 资源名称 --replicas副本数 kubectl expose -n 命名空间 deployment 资源名称 --name 自定义svc资源名称 --port clusterIP的端口 --target-port 容器的端口 --type svc的类型
kubectl create svc svc资源类型 资源名称 --tcpclusterIP的端口:容器的端口kubectl set image deployment 资源名称 容器名镜像名kubectl rollout history deployment 资源名称
kubectl rollout undo deployment 资源名称 [--to-revision ]
kubectl rollout status deployment 资源名称#声明式资源管理
kubectl apply|create -f XXX.yaml
kubectl delete -f XXXmlkubectl edit 资源类型 资源名称kubectl explain 资源类型.字段1.字段22. service 的四种类型
ClusterIp #默认的service资源的类型提供clusterIP供K8S集群内部访问。
NodePort #会在每个Node节点上开启一个端口K8S集群内部和外部的用户可以通过NodeIP:NodePot访问service以及关联的Pod。
LoadBalancor #使用公有云的LB服务和service做映射用户可以使用公有云LB服务的IP地址即可将请求转发到Node节点再通过NodeIP:NodePort访问service以及其关联的Pod。
ExternaName #相当于给一个域名或IP做别名Pod可以通过这个service访问相关的外部服务。3. service 的端口
prot #service 资源的 clusterIp 所使用的端口
nodePort #在 NodePort 类型的 service 所定义的在每个node节点上开启的端口默认范围30000~32767
targePort #service 将 port 或 nodeport 转发到的后端 Pod 的容器端口containerPort #创建 Pod 时所指定的容器端口K8S集群内部 http://clusterIP:port --- podIP:containerPort
K8S集群外部 http://nodeIP:nodeport --- podIP:containerPort4. 应用的发布策略
蓝绿发布
滚动发布
灰度发布/金丝雀发布
kubectl set image deployment 资源名称 容器名镜像名 kubectl rollout pause deployment 资源名称
kubectl rollout resume deployment 资源名称25% max unavailable 滚动更新过程中销毁的Pod数量不超过期望副本数的25%向下取整
25% max surge 滚动更新过程中新增的Pod数量不超过期望副本数的25%向上取整期望的Pod副本数是10个销毁的数量2新增3 整个更新过程中Pod的数量会一致保持在 8 ~ 13
