濮阳做网站的,专业型企业网站有哪些,采购管理软件免费版,竭诚网络网站建设在K8S中#xff0c;最小运行单位为POD,它是一个逻辑概念#xff0c;其实是一组共享了某些资源的容器组。POD是能运行多个容器的#xff0c;Pod 里的所有容器#xff0c;共享的是同一个 Network Namespace#xff0c;并且可以声明共享同一个 Volume。在POD中能够hold住网络… 在K8S中最小运行单位为POD,它是一个逻辑概念其实是一组共享了某些资源的容器组。POD是能运行多个容器的Pod 里的所有容器共享的是同一个 Network Namespace并且可以声明共享同一个 Volume。在POD中能够hold住网络和存储资源的容器就是pause容器它是一个一直循环运行的容器。 首先我们要搞清楚K8S有哪些资源可以看看下面定义
类别名称工作负载型Pod Replicaset ReplicationController Deployments StatefulSets Daemonset Job CronJob服务发现及负载均衡Service Ingress配置与存储Volume、Persistent Volume、CSl 、 configmap、 secret集群资源Namespace Node Role ClusterRole RoleBinding ClusterRoleBinding元数据资源HPA PodTemplate LimitRang 用户一般不直接操作POD,而是通过控制器来在上面的表格中我主要操作的对象就是Replicaset,Deployments ,DaemonSet,Job,Cronjob,StatefulSet.现在我们分别说说这些控制器的应用场景吧。 Replicaset代用户创建指定数量的pod副本数量确保pod副本数量符合预期状态并且支持滚动式自动扩容和缩容功能。但是现在基本被Deployments 取代了.
Deployment工作在ReplicaSet之上用于管理无状态应用目前来说最好的控制器。支持滚动更新和回滚功能还提供声明式配置。
DaemonSet用于确保集群中的每一个节点只运行特定的pod副本通常用于实现系统级后台任务。比如在Calico中的Agent就是用DaemonSet方式运行。DaemonSet是直接共享宿主机的网络还有hostAliases,HostNetwork,hostPID,hostname这些资源的
Job只要完成就立即退出不需要重启或重建。这个用于一次性运行比如大数据中的统计执行任务运行完成了就不用去管了。
Cronjob周期性任务控制像Linux中crontab在某一个时间定时运行程序
StatefulSet管理有状态应用比如数据库基本都是有状态应用的你数据保存在指定的节点那么下次运行时就必须在这个节点去运行这样就是有状态的了。 Deployment为Pod和Replica Set下一代Replication Controller提供声明式更新,现在我们来创建一个简单的Deployment来运行测试。Deployment.yaml范例文件如下:
apiVersion: apps/v1 #aip版本信息
kind: Deployment #资源类型
metadata: #元数据定义name: myapp-deploy #资源的名称namespace: default #资源的命名空间这里是default
spec: #资源的规格replicas: 3 #副本数这里是3个selector: #标签选择器这里是去找相应的pod标签matchLabels: #匹配哪些标签app: myapp #第一个条件是appmyapprelease: canary #第二个条件是releasecanarytemplate: #pod的模板定义metadata: #pod的元数据定义labels: #pod的标签属性app: myapp #pod的一个标签属性release: canary #pod的第二个标签属性spec: #pod的规格定义containers: #容器定义- name: myapp #容器的名称image: ikubernetes/myapp:v2 #容器的镜像ports: #容器暴露端口- name: http #端口名称containerPort: 80 #端口号在编辑好上面的deployment的yaml文件后我们来创建它。 kubectl app -f Deployment.yaml通过kubectl get deploykubectl get pods --show-labels 我们可以查看到已经创建了三个副本的myapp-deploy的deployment资源。我们通过上图中的get pods可以获得三个副本的IP地址由于pod是开放了容器的80端口。我们直接访问可以获得相关内容。
curl 10.42.1.8Deployment资源对象是可以进行回滚的它有一个属性revisionHistoryLimit是一个可选配置项用来指定可以保留的旧的ReplicaSet数量默认保存记录10个。该理想值取决于心Deployment的频率和稳定性。如果该值没有设置的话默认所有旧的Replicaset或会被保留将资源存储在etcd中是用kubectl get rs查看输出。每个Deployment的该配置都保存在ReplicaSet中然而一旦删除的旧的RepelicaSetDeployment就无法再回退到那个revison了。 如果将该值设置为0所有具有0个replica的ReplicaSet都会被删除。在这种情况下新的Deployment rollout无法撤销因为revision history都被清理掉了。可以通过descirbe详细看看deployment当前的配置我们可以看到当前的更新策略是StrategyType:RollingUpdate是滚动更新策略它还有一个策略是Recreate 重建式更新就是删一个建一个。类似于ReplicaSet的更新方式即首先删除现有的Pod对象然后由控制器基于新模板重新创建新版本资源对象。
现在我们通过修改Deployment.yaml文件来进行版本升级。升级的版本配置如下我们把镜像版本改成v1然后升级deployment.
apiVersion: apps/v1
kind: Deployment
metadata:name: myapp-deploynamespace: default
spec:replicas: 3selector:matchLabels:app: myapprelease: canarytemplate:metadata:labels:app: myapprelease: canaryspec:containers:- name: myappimage: ikubernetes/myapp:v1ports:- name: httpcontainerPort: 80
下面可以看到整个deployment升级过程是停止一台升级一台的这种循环。
以下可以看到原的rs作为备份而现在是启动新的rs 通过kubectl rollout history deployment myapp-deployment 查看有多少个历史版本 现在我们可以回滚回原来的版本也就是V2的版本用如下命令
kubectl rollout undo deployment myapp-deploy当然也可以通过如下指令回到指定的版本比如:
#回滚到第一个版本
kubectl rollout undo deployment myapp-deploy --to-revision1 当然也可以通过命令的方式升级pod镜像,
kubectl set image deployment/myapp-deploy myappikubernetes/myapp:v2使用以下命令扩容 Deployment
kubectl scale deployment myapp-deploy --replicas 5#通过打补丁的方式进行扩容
kubectl patch deployment myapp-deploy -p {spec:{replicas:5}}通过打补丁的方式进行修改更新策略 kubectl patch deployment myapp-deploy -p {spec:{strategy:{rollingupdate:{maxsurge:1,maxUnavailable:0}}}}金丝雀发布也就是灰度更新。
#设置maxSurge1maxUnavailable0
kubectl set image deployment myapp-deploy myappikubernetes/myapp:v3 kubectl rollout pause deployment myapp-deploy#观察更新状态
kubectl rollout status deployments myapp-deploy #如果更新的节点没问题然后resume继续剩下的更新
kubectl rollout resume deployment myapp-deploy#查看最后的更新情况
kubectl get pods -l appmyapp -w
