企业网站建设对网络营销有哪些影响,wordpress群发文章,班级网站建设方案,WordPress多重筛选功能一、资源管理
1.概述
说到k8s中的pod#xff0c;即荚的意思#xff0c;就不得不先提到k8s中的资源管理#xff0c;k8s中可以用以下命令查看我们的资源#xff1a;
kubectl api-resources 比如我们现在需要使用k8s开启一个东西#xff0c;那么k8s通过apiserver去对比etc…一、资源管理
1.概述
说到k8s中的pod即荚的意思就不得不先提到k8s中的资源管理k8s中可以用以下命令查看我们的资源
kubectl api-resources 比如我们现在需要使用k8s开启一个东西那么k8s通过apiserver去对比etcd里面的数据并且去调用scheduler来确定我这个东西要放在哪台主机上还需要调用managecontroller(控制器)去控制pod开启的数量和时间以及监控pod的状态 而我们的pod有Deployment,CronJob,DaemonSet,ReplicaSet,Job,StatefulSet,Hpa,通过我们的控制器开启pod开启pod之后pod中的数据即程序便运行起来了程序运行了之后不能像docker一样通过暴露端口的方式直接被访问还需要service微服务对端口进行暴露最终我们通过service微服务来访问pod中的数据。而pod中的数据持久化是通过建立volume卷再把pod中的目录挂载到宿主机上这样pod中的数据就能持久化到宿主机上了。
2.资源管理方式
命令式对象管理直接使用命令去操作kubernetes资源 kubectl run nginx-pod --imagenginx:latest --port80 命令式对象配置通过命令配置和配置文件去操作kubernetes资源 kubectl create/patch -f nginx-pod.yml 声明式对象配置通过apply命令和配置文件去操作kubernetes资源 kubectl apply -f nginx-pod.yml 类型适用环境优点缺点命令式对象管理测试简单只能操作活动对象无法审计、跟踪命令式对象配置开发可以审计、跟踪项目大时配置文件多操作麻烦声明式对象配置开发支持目录操作意外情况下难以调试kubectl是kubernetes集群的命令行工具通过它能够对集群本身进行管理并能够在集群上进行容器化应用的安装部署
kubectl命令的语法如下: kubectl [command] [type] [name] [flags] comand:指定要对资源执行的操作例如create、get、deletetype:指定资源类型比如deployment、pod、servicename:指定资源的名称名称大小写敏感flags:指定额外的可选参数 查看所有pod
kubectl get pod
查看某个pod
kubectl get pod pod_name
查看某个pod,以yaml格式展示结果
kubectl get pod pod_name o yaml
显示集群版本
kubectl version 显示集群信息
kubectl cluster-info 创建一个webcluster控制器控制器中pod数量为2
kubectl create deployment webcluster --image nginx/nginx:latest --replicas 2 查看资源帮助
kubectl explain deployment 查看控制器参数帮助
kubectl explain deployment.spec
编辑控制器配置
kubectl patch deployments.apps webcluster -p {spec: {replicas:4}} 删除资源
kubectl delete deployments.apps webcluster 运行和调试命令示例
运行pod
kubectl run testpod --image nginx/nginx:latest 端口暴露
kubectl run testpod --image nginx/nginx:latest kubectl expose pod testpod --port 80 --target-port 80 查看资源详细信息
kubectl describe pods testpod
查看资源日志
kubectl logs pods/testpod
运行交互pod
ctrlpq退出不停止pod
kubectl run -it testpod --image busybox 进入到已经运行的容器且容器有交互环境
kubectl attach pods/testpod -it 在已经运行的pod中运行指定命令
kubectl exec -it pods/testpod1 /bin/bash 拷贝文件到pod中
kubectl cp testpod1.yml testpod1:/
kubectl exec -it pods/testpod1 /bin/bash 复制pod中的文件到本机
kubectl cp testpod1:/testpod1.yml testpod1.yml 运行非交互pod
kubectl run nginx --image nginx/nginx:latest 高级命令示例
利用命令生成yaml模板文件
kubectl create deployment --image nginx/nginx:latest webcluster --dry-runclient -o yaml webcluster.yml
kubectl apply -f webcluster.yml 管理标签
kubectl run nginx --image nginx/nginx:latest
kubectl get pods --show-labels
kubectl label pods nginx appkarl
kubectl get pods --show-labels 更改标签
kubectl label pods nginx appwebcluster --overwrite
删除标签
kubectl label pods nginx app-
二、pod
1.手动建立pod生产不推荐
Kubernetes Pod 是 Kubernetes 中最小的可部署单元它代表集群中运行的单个实例。Pod 包含一个或多个紧密相关的容器这些容器共享存储和网络资源并且总是作为一个整体进行调度和管理。Kubernetes Pod 是 Kubernetes 中的基本构建块用于封装和管理应用程序的容器。通过共享网络和存储资源Pod 提供了一种灵活和高效的方式来部署和管理应用程序。理解 Pod 的概念和使用方法是掌握 Kubernetes 的基础。
查看所有pods
kubectl get pods
建立一个名为revkarl的pod
kubectl run revkarl --image nginx/nginx:latest 显示pod的较为详细的信息
kubectl get pods -o wide 2.利用控制器管理pod推荐
自动化管理自动创建和删除
自动创建和删除控制器可以自动创建、删除和管理 Pod确保集群始终处于期望的状态。例如Deployment 控制器可以根据指定的副本数自动创建或删除 Pod。自动恢复如果 Pod 出现故障或崩溃控制器会自动检测并重新创建新的 Pod确保应用的高可用性。 2.高可用性和容错性
自动重启控制器可以监控 Pod 的健康状态如果某个 Pod 失败控制器会自动重启它确保应用始终可用。负载均衡通过 ReplicationController 或 ReplicaSet可以确保多个 Pod 实例在不同的节点上运行实现负载均衡和故障隔离 3.水平扩展
自动扩展使用 Horizontal Pod Autoscaler (HPA)可以根据 CPU 使用率或其他指标自动调整 Pod 的数量以应对负载变化。手动扩展管理员可以轻松地手动增加或减少 Pod 的副本数以适应业务需求。 4. 滚动更新和回滚
滚动更新使用 Deployment 控制器可以进行滚动更新逐步替换旧的 Pod 实例确保应用在更新过程中始终保持可用。回滚如果新版本的 Pod 出现问题可以轻松地回滚到之前的版本确保应用的稳定性和可靠性。 5. 资源配置和管理
资源请求和限制控制器可以为 Pod 设置资源请求和限制确保每个 Pod 都有足够的资源来运行同时避免资源浪费。亲和性和反亲和性通过设置亲和性和反亲和性规则可以控制 Pod 的调度行为确保 Pod 在合适的节点上运行提高性能和可靠性。 6. 简化运维
集中管理控制器提供了一种集中管理多个 Pod 的方式简化了运维工作。管理员可以通过一个控制器管理多个 Pod而不是单独管理每个 Pod。标准化控制器提供了一种标准化的方式来管理 Pod确保所有 Pod 都遵循相同的标准和规范。 7. 服务发现和负载均衡
服务发现通过 Service 对象可以为一组 Pod 提供稳定的网络标识符实现服务发现。负载均衡Service 对象可以自动将流量分发到后端的 Pod实现负载均衡。 建立控制器并自动运行pod
kubectl create deployment revkarl --image nginx/nginx:latest 为revkarl扩容 为revkarl缩容 3.应用版本的更新
利用控制器建立pod
kubectl create deployment revkarl --image myapp:v1 --replicas 2
暴露端口
kubectl expose deployment revkarl --port 80 --target-port 80
service/revkarl exposed 查看历史版本
kubectl rollout history deployment revkarl 更新控制器镜像版本
kubectl set image deployments/revkarl myappmyapp:v2 访问测试一下 版本回滚
kubectl rollout undo deployment revkarl --to-revision 1 4.利用yaml文件部署应用
获得资源帮助
kubectl explain pod.spec.containers 运行简单的单个容器pod
kubectl run revkarl --image myapp:v1 --dry-runclient -o yaml pod.yml
kubectl apply -f pod.yml
运行多个容器pod
vim pod.yml
apiVersion: v1
kind: Pod
metadata:labels:run: revkarlname: revkarl
spec:containers:- image: myapp:v1name: web1- image: myapp:v2name: web2在一个pod中开启多个容器时一定要确保容器彼此不能互相干扰 vim pod.yml
apiVersion: v1
kind: Pod
metadata:labels:run: revkarlname: revkarl
spec:containers:- image: myapp:v1name: web1- image: busybox:latestname: web2command: [/bin/sh,-c,sleep 1000000]三、pod的生命周期
1.init容器 Pod 可以包含多个容器应用运行在这些容器里面同时 Pod 也可以有一个或多个先于应用容器启动的 Init 容器。 Init 容器与普通的容器非常像除了如下两点: o它们总是运行到完成 o init 容器不支持 Readiness因为它们必须在 Pod 就绪之前运行完成每个Init 容器必须运 行成功下一个才能够运行。 如果Pod的 Init 容器失败Kubernetes 会不断地重启该 Pod直到 Init 容器成功为止。但是如果 Pod 对应的 restartPolicy 值为 Never它不会重新启动。
init容器的功能
Init 容器可以包含一些安装过程中应用容器中不存在的实用工具或个性化代码。Init 容器可以安全地运行这些工具避免这些工具导致应用镜像的安全性降低。应用镜像的创建者和部署者可以各自独立工作而没有必要联合构建一个单独的应用镜像。Init 容器能以不同于Pod内应用容器的文件系统视图运行。因此Init容器可具有访问 Secrets 的权限而应用容器不能够访问。由于 Init 容器必须在应用容器启动之前运行完成因此 Init 容器提供了一种机制来阻塞或延迟应用容器的启动直到满足了一组先决条件。一旦前置条件满足Pod内的所有的应用容器会并行启动。 init容器示例
kubectl run initpod --image myapp:v1 -o yaml pod.yml
vim pod.yml
apiVersion: v1
kind: Pod
metadata:labels:run: initpodname: initpod
spec:containers:- image: myapp:v1name: myappinitContainers:- name: init-myserviceimage: busyboxcommand: [sh,-c,until test -e /testfile;do echo wating for myservice;sleep 2;done]
