首页
关于
留言
接口
搜索
资讯
技术
资源
悦读
杂记
首页
登录
登录
搜索
emer
累计撰写
58
篇文章
累计收到
0
条评论
首页
栏目
资讯
技术
资源
悦读
杂记
首页
登录
页面
首页
关于
留言
接口
作者 【1】 的文章
置顶
创建Service资源(CLUSTER ip类型)实例记录
准备工作:把实验镜像包nginx.tar.gz上传到分节点ctdnode1和ctdnode2上,并导入镜像节点1: [root@ctdnode1 ~]# ctr -n=k8s.io images import nginx.tar.gz节点2: [root@ctdnode2 ~]# ctr -n=k8s.io images import nginx.tar.gz1、创建后端pod资源(使用准备好的nginx镜像)1)编写yaml文件:控制节点:[root@ctdmaster1 svc]# vim pod_test.yaml代码如下:apiVersion: apps/v1kind: Deploymentmetadata: name: my-nginxspec: selector: matchLabels: run: my-nginx replicas: 2 template: metadata: labels: run: my-nginx spec: containers: - name: my-nginx image: nginx imagePullPolicy: IfNotPresent ports: - containerPort: 80 startupProbe: periodSeconds: 5 initialDelaySeconds: 60 timeoutSeconds: 10 httpGet: scheme: HTTP port: 80 path: / livenessProbe: periodSeconds: 5 initialDelaySeconds: 60 timeoutSeconds: 10 httpGet: scheme: HTTP port: 80 path: / readinessProbe: periodSeconds: 5 initialDelaySeconds: 60 timeoutSeconds: 10 httpGet: scheme: HTTP port: 80 path: /2)执行命令运行pod资源:控制节点: [root@ctdmaster1 svc]# kubectl apply -f pod_test.yaml 3)、查看运行情况:kubectl get pods -l run=my-nginx -o wide4)请求Pod资源测试目前 Pod资源的应用已经运行起来,但是仅限于集群内,外部无法访问,这里就需要创建Service资源作代理,将外部的访问请求转发到Pod上。(需要注意的是,pod虽然定义了容器端口,但是不会使用调度到该节点上的80端口,也不会使用任何特定的NAT规则去路由流量到Pod上。 这意味着可以在同一个节点上运行多个 Pod,使用相同的容器端口,并且可以从集群中任何其他的Pod或节点上使用IP的方式访问到它们。)2、创建service,做一个好代理。service的工作主要是通过endpoint与selector协同工作实现,由selector选择出pod的ip地址和端口号,然后记录在endpoint中,当有请求访问到service的ip地址时,就会从endpoint中选择出一个ip地址和端口号,然后将请求重定向至对应的pod中,具体会把请求代理到哪个pod,那就是kube-proxy的轮询来实现的。service不会直接到pod,service是直接到endpoint资源,就是地址加端口,再由endpoint再关联到pod。1)创建Service资源yaml文件,控制节点:[root@ctdmaster1 svc]# vim service_test.yamlapiVersion: v1kind: Servicemetadata: name: my-nginx labels: run: my-nginxspec: type: ClusterIP ports: - port: 80 protocol: TCP targetPort: 80 selector: run: my-nginx我们创建一个 Service,具有标签run=my-nginx的Pod,目标TCP端口 80,并且开放一个抽象的Service端口(targetPort:容器接收流量的端口;port:抽象的 Service 端口,可以使任何其它 Pod访问该 Service 的端口)2)、保存退出生,运行Service资源, [root@ctdmaster1 svc]# kubectl apply -f service_test.yaml3)、查看运行情况:[root@ctdmaster1 svc]# kubectl get svc -l run=my-nginxService资源已经运行正常,集群IP地址是:10.97.128.704)、请求Service,测试结果:curl 10.97.128.70由上图可以看到,访问Service的IP请求到的资源跟之前请求pod节点上的资源,得到的结果是一样的。我们测试下,删除一个pod资源,请求Service看看访问结果有没有变。如下图:注意:上面的10.97.128.70:80地址只能是在集群(因为定义的是CLUSTER-IP类型)内部可以访问,在外部还是无法访问,也就是想要通过浏览器访问,那么是访问不通的,如果想要在k8s集群之外访问,是需要把service type类型改成nodePort。最后,有关Service域名其实Service只要创建完成,我们就可以直接解析它的服务名,每一个服务创建完成后都会在集群dns中动态添加一个资源记录,添加完成后我们就可以解析了,资源记录格式是:SVC_NAME.NS_NAME.DOMAIN.LTD.服务名.命名空间.域名后缀集群默认的域名后缀是svc.cluster.local.就像我们上面创建的my-nginx这个服务,它的完整名称解析就是my-nginx.default.svc.cluster.local这个记录好像只有pod内部可以访问,外部无法访问。大家思考下,是不是这样呢?
2023年-11月-6日
306 阅读
0 评论
技术
2023-11-5
K8s里什么是无头服务headless?
『无头服务』即 Kubernetes 中的 Headless Service。Service 是 Kubernetes 对后端一组提供相同服务的 Pod 的逻辑抽象和访问入口。在某些应用场景中,若需要人为指定负载均衡器,不使用 Service 提供的默认负载均衡的功能,或者应用程序希望知道属于同组服务的其他实例。可以通过无头服务实现。Kubernetes 提供了 Headless Service 来实现这种功能,即不为 Service 设置 ClusterIP(入口 IP 地址),仅通过 Label Selector 将后端的 Pod 列表返回给调用的客户端。在nacos集群的资源清单文件,通过selector字段 matchlabels为:app=nacos 。设置了label selector之后,Kubernetes则会根据label selector查询pod列表 自动创建endpoint列表,将服务名(DNS域名)的解析机制配置为:当客户端访问服务名是,得到的是endpoint列表(而不是一个确定的IP地址)也可以回答一、Headless Service概念在某些应用场景中,客户端不需要通过Kubernetes内置的Service实现负载均衡功能,或者需要自行完成对服务后端各个实例的服务发现机制,或者需要自行实现负载均衡功能,可以通过创建特殊的名为“Headless”的服务实现。Headless Service的概念是这种服务没有入口访问地址(无ClusterIP地址),kube-proxy不会为其创建负载转发规则,而服务名(DNS域名)的解析机制取决于该Headless Service是否设置了Label Selector。二、Headless Service设置Label Selector如果Headless Service设置了Label Selector,Kubernetes则将根据Label Selector查询后端Pod列表,自动创建Endpoint列表,将服务名(DNS域名)的解析机制配置为:当客户端访问该服务名时,得到是全部Endpoint列表(而不是一个确定的IP地址)三、Headless Service未设置Label Selector如果Headless Service没有设置Label Selector,则Kubernetes不会自动创建对应的Endpoint列表。DNS系统会根据下列条件设置DNS记录。如果Service类型为ExternalName,则对服务名访问将直接被DNS系统转为Service设置的外部(externalName);如果系统中存在与Service同名的Endpoint定义,则服务名将被解析为Endpoint定义中的列表,适用于非ExternnalName类型的Service————————————————参考的博文https://blog.csdn.net/GaoChuang_/article/details/121313534
2023年-11月-5日
350 阅读
0 评论
技术
2023-11-5
Kubernetes 100个常用命令!
这篇文章是关于使用 Kubectl 进行 Kubernetes 诊断的指南。 列出了 100 个 Kubectl 命令,这些命令对于诊断 Kubernetes 集群中的问题非常有用。这些问题包括但不限于: • 集群信息 • Pod 诊断 • 服务诊断 • 部署诊断 • 网络诊断 • 持久卷和持久卷声明诊断 • 资源使用情况 • 安全和授权 • 节点故障排除 • 其他诊断命令:文章还提到了许多其他命令,如资源扩展和自动扩展、作业和定时作业诊断、Pod 亲和性和反亲和性规则、RBAC 和安全、服务账号诊断、节点排空和取消排空、资源清理等。 集群信息: 1. 显示 Kubernetes 版本:kubectl version 2. 显示集群信息:kubectl cluster-info 3. 列出集群中的所有节点:kubectl get nodes 4. 查看一个具体的节点详情:kubectl describe node 5. 列出所有命名空间:kubectl get namespaces /kubectl get ns 6. 列出所有命名空间中的所有 pod:kubectl get pods --all-namespaces Pod 诊断: 1. 列出特定命名空间中的 pod:kubectl get pods -n 2. 查看一个 Pod 详情:kubectl describe pod -n 3. 查看 Pod 日志:kubectl logs -n 4. 尾部 Pod 日志:kubectl logs -f -n 5. 在 pod 中执行命令:kubectl exec -it -n -- Pod 健康检查: 1. 检查 Pod 准备情况:kubectl get pods -n -o jsonpath='{.status.conditions[?(@.type=="Ready")].status}' 2. 检查 Pod 事件:kubectl get events -n --field-selector involvedObject.name= Service诊断: 1. 列出命名空间中的所有服务:kubectl get svc -n 2. 查看一个服务详情:kubectl describe svc -n Deployment诊断: 1. 列出命名空间中的所有Deployment:kubectl get deployments -n 2. 查看一个Deployment详情:kubectl describe deployment -n 3. 查看滚动发布状态:kubectl rollout status deployment/ -n 4. 查看滚动发布历史记录:kubectl rollout history deployment/ -n StatefulSet诊断: 1. 列出命名空间中的所有 StatefulSet:kubectl get statefulsets -n 2. 查看一个 StatefulSet详情:kubectl describe statefulset -n ConfigMap 和Secret诊断: 1. 列出命名空间中的 ConfigMap:kubectl get configmaps -n 2. 查看一个ConfigMap详情:kubectl describe configmap -n 3. 列出命名空间中的 Secret:kubectl get secrets -n 4. 查看一个Secret详情:kubectl describe secret -n 命名空间诊断: 1. 查看一个命名空间详情:kubectl describe namespace 资源使用情况: 1. 检查 pod 的资源使用情况:kubectl top pod -n 2. 检查节点资源使用情况:kubectl top nodes 图片 网络诊断: 1. 显示命名空间中 Pod 的 IP 地址:kubectl get pods -n -o custom-columns=POD:metadata.name,IP:status.podIP --no-headers 2. 列出命名空间中的所有网络策略:kubectl get networkpolicies -n 3. 查看一个网络策略详情:kubectl describe networkpolicy -n 持久卷 (PV) 和持久卷声明 (PVC) 诊断: 1. 列出PV:kubectl get pv 2. 查看一个PV详情:kubectl describe pv 3. 列出命名空间中的 PVC:kubectl get pvc -n 4. 查看PVC详情:kubectl describe pvc -n 节点诊断: 1. 获取特定节点上运行的 Pod 列表:kubectl get pods --field-selector spec.nodeName= -n 资源配额和限制: 1. 列出命名空间中的资源配额:kubectl get resourcequotas -n 2. 查看一个资源配额详情:kubectl describe resourcequota -n 自定义资源定义 (CRD) 诊断: 1. 列出命名空间中的自定义资源:kubectl get -n 2. 查看自定义资源详情:kubectl describe -n 使用这些命令时,请记住将, , , , , , , , , , , , , , 和替换为你的特定值。 这些命令应该可以帮助你诊断 Kubernetes 集群以及在其中运行的应用程序。 资源伸缩和自动伸缩 1. Deployment伸缩:kubectl scale deployment --replicas= -n 2. 设置Deployment的自动伸缩:kubectl autoscale deployment --min= --max= --cpu-percent= -n 3. 检查水平伸缩器状态:kubectl get hpa -n 作业和 CronJob 诊断: 1. 列出命名空间中的所有作业:kubectl get jobs -n 2. 查看一份工作详情:kubectl describe job -n 3. 列出命名空间中的所有 cron 作业:kubectl get cronjobs -n 4. 查看一个 cron 作业详情:kubectl describe cronjob -n 容量诊断: 1. 列出按容量排序的持久卷 (PV):kubectl get pv --sort-by=.spec.capacity.storage 2. 查看PV回收策略:kubectl get pv -o=jsonpath='{.spec.persistentVolumeReclaimPolicy}' 3. 列出所有存储类别:kubectl get storageclasses Ingress和服务网格诊断: 1. 列出命名空间中的所有Ingress:kubectl get ingress -n 2. 查看一个Ingress详情:kubectl describe ingress -n 3. 列出命名空间中的所有 VirtualServices (Istio):kubectl get virtualservices -n 4. 查看一个 VirtualService (Istio)详情:kubectl describe virtualservice -n Pod 网络故障排除: 1. 运行网络诊断 Pod(例如 busybox)进行调试:kubectl run -it --rm --restart=Never --image=busybox net-debug-pod -- /bin/sh 2. 测试从 Pod 到特定端点的连接:kubectl exec -it -n -- curl 3. 跟踪从一个 Pod 到另一个 Pod 的网络路径:kubectl exec -it -n -- traceroute 4. 检查 Pod 的 DNS 解析:kubectl exec -it -n -- nslookup 配置和资源验证: 1. 验证 Kubernetes YAML 文件而不应用它:kubectl apply --dry-run=client -f 2. 验证 pod 的安全上下文和功能:kubectl auth can-i list pods --as=system:serviceaccount:: RBAC 和安全性: 1. 列出命名空间中的角色和角色绑定:kubectl get roles,rolebindings -n 2. 查看角色或角色绑定详情:kubectl describe role -n 服务帐户诊断: 1. 列出命名空间中的服务帐户:kubectl get serviceaccounts -n 2. 查看一个服务帐户详情:kubectl describe serviceaccount -n 清空节点和解除封锁: 1. 清空节点以进行维护:kubectl drain --ignore-daemonsets 2. 解除对节点的封锁:kubectl uncordon 资源清理: 1. 强制删除 pod(不推荐):kubectl delete pod -n --grace-period=0 --force Pod 亲和性和反亲和性: 1. 列出 pod 的 pod 亲和性规则:kubectl get pod -n -o=jsonpath='{.spec.affinity}' 2. 列出 pod 的 pod 反亲和性规则:kubectl get pod -n -o=jsonpath='{.spec.affinity.podAntiAffinity}' Pod 安全策略 (PSP): 1. 列出所有 Pod 安全策略(如果启用):kubectl get psp 事件: 1. 查看最近的集群事件:kubectl get events --sort-by=.metadata.creationTimestamp 2. 按特定命名空间过滤事件:kubectl get events -n 节点故障排除: 1. 检查节点情况:kubectl describe node | grep Conditions -A5 2. 列出节点容量和可分配资源:kubectl describe node | grep -E "Capacity|Allocatable" 临时容器(Kubernetes 1.18+): 1. 运行临时调试容器:kubectl debug -it -n --image= -- /bin/sh 资源指标(需要指标服务器): 1. 获取 Pod 的 CPU 和内存使用情况:kubectl top pod -n kuelet诊断: 1. 查看节点上的kubelet日志:kubectl logs -n kube-system kubelet- 使用Telepresence 进行高级调试: 1. 使用 Telepresence 调试 pod:telepresence --namespace --swap-deployment 图片 Kubeconfig 和上下文: 1. 列出可用的上下文:kubectl config get-contexts 2. 切换到不同的上下文:kubectl config use-context Pod 安全标准(PodSecurity 准入控制器): 1. 列出 PodSecurityPolicy (PSP) 违规行为:kubectl get psp -A | grep -vE 'NAME|REVIEWED' Pod 中断预算 (PDB) 诊断: 1. 列出命名空间中的所有 PDB:kubectl get pdb -n 2. 查看一个PDB详情:kubectl describe pdb -n 资源锁诊断(如果使用资源锁): 1. 列出命名空间中的资源锁:kubectl get resourcelocks -n 服务端点和 DNS: 1. 列出服务的服务端点:kubectl get endpoints -n 2. 检查 Pod 中的 DNS 配置:kubectl exec -it -n -- cat /etc/resolv.conf 自定义指标(Prometheus、Grafana): 1. 查询Prometheus指标:用于kubectl port-forward访问Prometheus和Grafana服务来查询自定义指标。 Pod 优先级和抢占: 1. 列出优先级:kubectl get priorityclasses Pod 开销(Kubernetes 1.18+): 1. 列出 pod 中的开销:kubectl get pod -n -o=jsonpath='{.spec.overhead}' 存储卷快照诊断(如果使用存储卷快照): 1. 列出存储卷快照:kubectl get volumesnapshot -n 2. 查看存储卷快照详情:kubectl describe volumesnapshot -n 资源反序列化诊断: 1. 反序列化并打印 Kubernetes 资源:kubectl get -n -o=json 节点污点: 1. 列出节点污点:kubectl describe node | grep Taints 更改和验证 Webhook 配置: 1. 列出变异 webhook 配置:kubectl get mutatingwebhookconfigurations 2. 列出验证 Webhook 配置:kubectl get validatingwebhookconfigurations Pod 网络策略: 1. 列出命名空间中的 pod 网络策略:kubectl get networkpolicies -n 节点条件(Kubernetes 1.17+): 1. 自定义查询输出:kubectl get nodes -o custom-columns=NODE:.metadata.name,READY:.status.conditions[?(@.type=="Ready")].status -l 'node-role.kubernetes.io/worker=' 审核日志: 1. 检索审核日志(如果启用):检查 Kubernetes 审核日志配置以了解审核日志的位置。 节点操作系统详细信息: 1. 获取节点的操作系统信息:kubectl get node -o jsonpath='{.status.nodeInfo.osImage}' 这些命令应该涵盖 Kubernetes 中的各种诊断场景。确保将、、等占位符替换为你的集群和用例的实际值。来源:K8S中文社区
2023年-11月-5日
451 阅读
0 评论
技术
2023-11-4
K8S的设计结构
K8S的设计结构大致可分为下列三大部分Client: 属于用户触发请求的客户端,即Kubectl, 用户的各种触发的命令就是通过kuberctl统一封装后进行命令触发的Master:用于处理用户触发的请求,进行处理决策,Worker:命令真正的执行者,读取etcd的结果将数据最终执行K8S设计结构图ClientKubectl: 是k8s 的client,也是一般RD 最常用的操作方式之一,很多K8S的使用者主要就是通过kubectl跟K8S打交道。UI:Dashboard 也是一个独立服务,默认可以不需要,这个服务本身可以通过Kubectl部署在k8s上对外提供服务。MasterApiServer:Master 通信的入口, Client 和 Worker 之前同行ETCD:Master中唯一的决策结果的存储Controller Manager:里面保存各种controllerScheduler:执行实例资源的选择调度决策, 选择出合适的Worker节点来运行服务的Pod,真正的部署操作由Kubelet来执行WorkerKubelet:直接通过ApiServer的watch接口读取原始数据结果KubeProxy:网络请求通过Kubeproxy实现服务接口的转发,作为普通服务的命名管理Pod:将容器、网络和存储单元打包在一起,是服务独立的部署单元。核心思路是高内聚Container:原始服务容器,容器与pod 的对应关系是一个Pod中包含多个容器,多个容器之间的服务可以互相访问核心理念:K8s 设计的核心理念最终概括为4大点: 声明式、显示接口、无入侵性 和 可移植性声明式:对比指令式,需求任何功能通过yml文件来描述自己的需求,最终由k8s调度满足显示接口:任何接口定义都属于显示定义,不存在私有接口,所以给业务CRD 自定义提供前提, 每个K8s 可以根据自己的需求和现有的功能实现自己的服务功能无入侵性:该特点就是说任何服务部署只要提前打包好docker 的image ,是不需要再做任何代码改造,就可以完成部署。可移植性:可移植性主要是强调对于有状态的服务,通过PersistentVolume 支持屏蔽底层的数据存储细节
2023年-11月-4日
441 阅读
0 评论
技术
2023-11-3
金丝雀发布(又称灰度发布、灰度更新)
金丝雀发布的由来:17 世纪,英国矿井工人发现,金丝雀对瓦斯这种气体十分敏感。空气中哪怕有极其微量的瓦斯,金丝雀也会停止歌唱;当瓦斯含量超过一定限度时,虽然人类毫无察觉,金丝雀却早已毒发身亡。当时在采矿设备相对简陋的条件下,工人们每次下井都会带上一只金丝雀作为瓦斯检测指标,以便在危险状况下紧急撤离。所在金丝雀发布也是采取类似的流程,在发布过程中,一般先发1台,或者一个小比例,例如2%的服务器,主要做流量验证用,也称为金丝雀 (Canary) 测试 (国内常称灰度测试),如果发现有问题,立马暂停发布,并回滚版本,并排查出错节点信息,并找到其原因,如果一切正常,则继续发布,直到完全更新。金丝雀发布步骤:步骤一:将流量从待部署节点移出,更新该节点服务到待发布状态,将该节点称为金丝雀节点;步骤二:根据不同策略,将流量引入金丝雀节点。策略可以根据情况指定,比如随机样本策略(随机引入)、狗粮策略(就是内部用户或员工先尝鲜)、分区策略(不同区域用户使用不同版本)、用户特征策略(这种比较复杂,需要根据用户个人资料和特征进行分流,类似于千人千面);步骤三:金丝雀节点验证通过后,选取更多的节点称为金丝雀节点,重复步骤一和步骤二,直到所有节点全部更新金丝雀部署和蓝绿有点像,但是它更加规避风险。你可以阶段性的进行,而不用一次性从蓝色版本切换到绿色版本。采用金丝雀部署,你可以在生产环境的基础设施中小范围的部署新的应用代码。一旦应用签署发布,只有少数用户被路由到它。最大限度的降低影响。如果没有错误发生,新版本可以逐渐推广到整个基础设施。金丝雀和蓝绿的对比
2023年-11月-3日
499 阅读
0 评论
技术
置顶
k8s学习:蓝绿部署演练
准备工作:把实验镜像包myapp-lan.tar.gz和myapp-lv.tar.gz上传到部署node节点,然后导入到镜像:ctr -n=k8s.io images import myapp-lan.tar.gzctr -n=k8s.io images import myapp-lv.tar.gz1、回到master控制节点创建部署配置文件(yaml配置文件),[root@ctdmaster1 ~]# vim lv.yaml配置代码如下 :apiVersion: apps/v1kind: Deploymentmetadata:name: myapp-v1namespace: blue-greenspec:replicas: 3selector:matchLabels:app: myappversion: v2template:metadata:labels:app: myappversion: v2spec:containers:name: myappimage: janakiramm/myapp:v2imagePullPolicy: IfNotPresentports: containerPort: 802、创建名字空间和deploy资源:[root@ctdmaster1 ~]# kubectl create ns blue-greennamespace/blue-green created[root@ctdmaster1 ~]# kubectl apply -f lv.yaml3、查看pods是否创建成功[root@ctdmaster1 ~]# kubectl get pods -n blue-greenNAME READY STATUS RESTARTS AGEmyapp-v1-75d7db5cf7-467dg 1/1 Running 0 26smyapp-v1-75d7db5cf7-4rx4z 1/1 Running 0 26smyapp-v1-75d7db5cf7-lhgz9 1/1 Running 0 26s4、创建前端Service[root@ctdmaster1 ~]# vim service_lanlv.yaml代码如图:执行更新服务命令:kubectl apply -f service_lanlv.yaml执行命令查看是否更新成功:kubectl get svc -n blue-green在浏览器访问http://k8s-master节点ip:30062如节点的IP为192.168.40.161,则访问下 http://192.168.40.161:30062如节点的IP为192.168.40.162,则访问下 http://192.168.40.162:30062两个节点的效果是一样的。5、创建蓝色部署环境(即新上线的环境,要替代绿色环境)1)、创建部署yaml配置文件vim lan.yaml2)执行部署配置命令:kubectl apply -f lan.yaml 并查看运行结果从图中可以看出蓝色版已经运行成功,但是因为在后台运行,所以前端是访问不了的。此时如果需要切换蓝色版本只需要修改前端的配置文件service_lanlv.yaml即可,如:刷新访问节点1的192.168.40.161:30062前面已经更新为蓝色版本,说明实验成功。总的来说,蓝绿部署就是部署两套一样的环境,一个前台运行,一个后台备用,当需要更新的时候,只要把后台运行的更新测试无误之后,把前端的路由或者代理指向后台更新好的环境, 这样后台变前台,前台变后台,如果前台的出了问题,备用的可以立马顶上,这可最大的减少前端访问宕机故障。
2023年-11月-3日
478 阅读
0 评论
技术
2023-11-3
什么是蓝绿部署
蓝绿部署是一种应用发布模式,可将用户流量从先前版本的应用或微服务逐渐转移到几乎相同的新版本中(两者均保持在生产环境中运行)。旧版本可以称为蓝色环境,而新版本则可称为绿色环境。一旦生产流量从蓝色完全转移到绿色,蓝色就可以在回滚或退出生产的情况下保持待机,也可以更新成为下次更新的模板。这种持续部署模式原本存在不足之处。并非所有环境都具有相同的正常运行时间要求或正确执行 CI/CD 流程(如蓝绿部署)所需的资源。但是,随着企业加大对数字化转型的支持,许多应用开始支持这种持续交付。蓝绿部署是一种应用发布模式,可将用户流量从先前版本的应用或微服务逐渐转移到几乎相同的新版本中(两者均保持在生产环境中运行)。蓝绿部署的优势和缺点优点:1、更新过程无需停机,风险较少2、回滚方便,只需要更改路由或者切换DNS服务器,效率较高缺点:1、成本较高,需要部署两套环境。如果新版本中基础服务出现问题,会瞬间影响全网用户;如果新版本有问题也会影响全网用户。2、需要部署两套机器,费用开销大3、在非隔离的机器(Docker、VM)上操作时,可能会导致蓝绿环境被摧毁风险4、负载均衡器/反向代理/路由/DNS处理不当,将导致流量没有切换过来情况出现
2023年-11月-3日
476 阅读
0 评论
技术
2023-11-3
deployment运行demo代码
Deployment是kubernetes中最常用的资源对象,为ReplicaSet和Pod的创建提供了一种声明式的定义方法,在Deployment对象中描述一个期望的状态,Deployment控制器就会按照一定的控制速率把实际状态改成期望状态,通过定义一个Deployment控制器会创建一个新的ReplicaSet控制器,通过ReplicaSet创建pod,删除Deployment控制器,也会删除Deployment控制器下对应的ReplicaSet控制器和pod资源.使用Deployment而不直接创建ReplicaSet是因为Deployment对象拥有许多ReplicaSet没有的特性,例如滚动升级、金丝雀发布、蓝绿部署和回滚。扩展:声明式定义是指直接修改资源清单yaml文件,然后通过kubectl apply -f 资源清单yaml文件,就可以更改资源。apiVersion: apps/v1kind: Deploymentmetadata: name: myapp-v1spec: replicas: 3 selector: matchLabels: app: myapp version: v1 template: metadata: labels: app: myapp version: v1 spec: containers: - name: myapp image: janakiramm/myapp:v2 imagePullPolicy: IfNotPresent ports: - containerPort: 80 version: v1 template: metadata: labels: app: myapp version: v1 spec: containers: - name: myapp image: janakiramm/myapp:v2 imagePullPolicy: IfNotPresent ports: - containerPort: 80 startupProbe: periodSeconds: 5 initialDelaySeconds: 20 timeoutSeconds: 10 httpGet: scheme: HTTP port: 80 path: / livenessProbe: periodSeconds: 5 initialDelaySeconds: 20 timeoutSeconds: 10 httpGet: scheme: HTTP port: 80 path: / readinessProbe: periodSeconds: 5 initialDelaySeconds: 20 timeoutSeconds: 10 httpGet: scheme: HTTP port: 80 path: /
2023年-11月-3日
467 阅读
0 评论
技术
置顶
kubernetes的查询操作命令
1、kubectl get all -o wide -A 【查询所有命名空间下常用资源】缺点:这种方法 kubectl get all 其实查询出来不是全部资源,仅仅是常用资源,仅仅是 service - deployment/statefulset/daemonset/job/cronjob - replicaset - pod 这个绑定链资源,还有 rbac 的 role rolebinding,配置文件 configmap secrets,服务账号 serviceAccount ,service与pod的绑定endpoints都没有查询出来2、kubectl api-versions 【查看所有apiVersion版本】3、kubectl api-resources 【查看所有资源类型】4、kubectl api-resources --verbs=list --namespaced -o name5、kubectl api-resources --verbs=list --namespaced -o name | xargs -n 1 kubectl get --show-kind --ignore-not-found -A #查询所有命名空间下的所有资源
2023年-11月-2日
466 阅读
0 评论
技术
2023-11-1
关于名字空间(Namespace)
在 Kubernetes 中,名字空间(Namespace) 提供一种机制,将同一集群中的资源划分为相互隔离的组。 同一名字空间内的资源名称要唯一,但跨名字空间时没有这个要求。 名字空间作用域仅针对带有名字空间的对象, (例如 Deployment、Service 等),这种作用域对集群范围的对象 (例如 StorageClass、Node、PersistentVolume 等)不适用。名字空间为名称提供了一个范围。资源的名称需要在名字空间内是唯一的,但不能跨名字空间。 名字空间不能相互嵌套,每个 Kubernetes 资源只能在一个名字空间中。名字空间是在多个用户之间划分集群资源的一种方法,而当名字空间中存在一个 ResourceQuota 对象时,对于该名字空间而言,资源配额就是开启的。当名字空间资源配额开启时,在空间里创建的Pod或者应用资源时必须必须设置资源限额,否则创建失败。Kubernetes 初始化启动时会自动创建四个名字空间:1、default:Kubernetes 包含这个名字空间,以便于你无需创建新的名字空间即可开始使用新集群。2、kube-node-lease:该名字空间包含用于与各个节点关联的 Lease(租约)对象。 节点租约允许 kubelet 发送心跳, 由此控制面能够检测到节点故障。3、kube-public:所有的客户端(包括未经身份验证的客户端)都可以读取该名字空间。 该名字空间主要预留为集群使用,以便某些资源需要在整个集群中可见可读。 该名字空间的公共属性只是一种约定而非要求。4、kube-system:该名字空间用于 Kubernetes 系统创建的对象有关名字空间的常用命令:1、创建名字空间kubectl create ns test2、获取当前名字空间列表kubectl get namespace/ns[root@ctdmaster1 ~]# kubectl get namespaceNAME STATUS AGEdefault Active 11dkube-node-lease Active 11dkube-public Active 11dkube-system Active 11dtest Active 11d3、删除名字空间kubectl delete namespaces 名字空间名此命令会删除名字空间下的 所有内容,谨慎操作 ![root@ctdmaster1 ~]# kubectl get nsNAME STATUS AGEdefault Active 11dkube-node-lease Active 11dkube-public Active 11dkube-system Active 11dtest Active 11d[root@ctdmaster1 ~]# kubectl get pods -n testNAME READY STATUS RESTARTS AGEpod-test 1/1 Running 0 158m[root@ctdmaster1 ~]# kubectl delete ns testnamespace "test" deleted[root@ctdmaster1 ~]# kubectl get pods -n testNo resources found in test namespace.[root@ctdmaster1 ~]# kubectl get nsNAME STATUS AGEdefault Active 11dkube-node-lease Active 11dkube-public Active 11dkube-system Active 11d 4、分析名字空间详细信息kubectl describe namespaces [root@ctdmaster1 ~]# kubectl describe ns testName: testLabels: kubernetes.io/metadata.name=testAnnotations: <none>Status: ActiveNo resource quota.No LimitRange resource.5、创建资源配额[root@ctdmaster1 ~]# vim namespace-quota.yaml #以下为资源配额内容apiVersion: v1kind: ResourceQuotametadata: name: mem-cpu-quota namespace: testspec: hard: requests.cpu: "2" requests.memory: 2Gi limits.cpu: "4" limits.memory: 4Gi执行命令:[root@ctdmaster1 ~]# kubectl apply -f namespace-quota.yaml 查看名字空间配额[root@ctdmaster1 ~]# kubectl describe ns testName: testLabels: kubernetes.io/metadata.name=testAnnotations: <none>Status: ActiveResource Quotas Name: mem-cpu-quota Resource Used Hard -------- --- --- limits.cpu 0 4 limits.memory 0 4Gi requests.cpu 0 2 requests.memory 0 2GiNo LimitRange resource.最后需要注意的是 kubernetes 资源(例如 Pod、Service、副本控制器等)都位于某些名字空间中。 但是名字空间资源本身并不在名字空间中,而且底层资源, 例如节点和持久化卷不属于任何名字空间。查看哪些 Kubernetes 资源在名字空间中,哪些不在名字空间中:# 位于名字空间中的资源kubectl api-resources --namespaced=true 不在名字空间中的资源kubectl api-resources --namespaced=false
2023年-11月-1日
284 阅读
0 评论
技术
1
2
3
4
5