首页
关于
留言
接口
搜索
资讯
技术
资源
悦读
杂记
首页
登录
登录
搜索
emer
累计撰写
58
篇文章
累计收到
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日
465 阅读
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 评论
技术
2023-10-28
Kubernetes docker Containerd ctr、crictl、nerdctl -容器和镜像操作命令工具【转】
一、概述作为接替 Docker 运行时的 Containerd 在早在 Kubernetes1.7 时就能直接与 Kubelet 集成使用,只是大部分时候我们因熟悉 Docker,在部署集群时采用了默认的 dockershim。在V1.24起的版本的 kubelet 就彻底移除了dockershim,改为默认使用Containerd了,当然也使用 cri-dockerd 适配器来将 Docker Engine 与 Kubernetes 集成。可以参考官方文档:https://kubernetes.io/zh-cn/docs/setup/production-environment/container-runtimes/#docker二、Containerd 常见命令操作更换 Containerd 后,以往我们常用的 docker 命令也不再使用,取而代之的分别是 crictl 和 ctr 两个命令客户端。crictl 是遵循 CRI 接口规范的一个命令行工具,通常用它来检查和管理kubelet节点上的容器运行时和镜像。ctr 是 containerd 的一个客户端工具。ctr -v 输出的是 containerd 的版本,crictl -v 输出的是当前 k8s 的版本,从结果显而易见你可以认为 crictl 是用于 k8s 的。一般来说你某个主机安装了 k8s 后,命令行才会有 crictl 命令。而 ctr 是跟 k8s 无关的,你主机安装了 containerd 服务后就可以操作 ctr 命令。使用crictl命令之前,需要先配置/etc/crictl.yaml如下:runtime-endpoint: unix:///run/containerd/containerd.sockimage-endpoint: unix:///run/containerd/containerd.socktimeout: 10debug: false或者使用命令:crictl config runtime-endpoint unix:///run/containerd/containerd.sockcrictl config image-endpoint unix:///run/containerd/containerd.sockdocker ctr crictl三种命令对比图由于 Containerd 也有 namespaces 的概念,对于上层编排系统的支持,ctr 客户端 主要区分了 3 个命名空间分别是k8s.io、moby和default,以上我们用crictl操作的均在k8s.io命名空间,使用ctr 看镜像列表就需要加上-n 参数。crictl 是只有一个k8s.io命名空间,但是没有-n 参数。【温馨提示】ctr images pull 拉取的镜像默认放在default,而 crictl pull 和 kubelet 默认拉取的镜像都在 k8s.io 命名空间下。所以通过ctr导入镜像的时候特别注意一点,最好指定命名空间。注意-n不能放在命令最后面,下面几行查看的镜像是一样的ctr -n=k8s.io image lsctr -n k8s.io image lscrictl 没有-n参数,操作都在k8s.io命名空间下。crictl image lscrictl imagescrictl image list = ctr -n=k8s.io image listcrictl image ls = ctr -n=k8s.io image lscrictl images = ctr -n=k8s.io image listcrictl images = ctr -n=k8s.io image ls使用ctr命令指定命名空间导入镜像ctr -n=k8s.io image import dashboard.tar查看镜像,可以看到可以查询到了crictl images三、containerd 客户端工具 nerdctl推荐使用 nerdctl,使用效果与 docker 命令的语法一致,github 下载链接:https://github.com/containerd/nerdctl/releases精简 (nerdctl–linux-amd64.tar.gz): 只包含 nerdctl完整 (nerdctl-full–linux-amd64.tar.gz): 包含 containerd, runc, and CNI 等依赖nerdctl 的目标并不是单纯地复制 docker 的功能,它还实现了很多 docker 不具备的功能,例如延迟拉取镜像(lazy-pulling)、镜像加密(imgcrypt)等。具体看 nerdctl。延迟拉取镜像功能可以参考这篇文章:Containerd 使用 Stargz Snapshotter 延迟拉取镜像https://icloudnative.io/posts/startup-containers-in-lightning-speed-with-lazy-image-distribution-on-containerd/1)安装 nerdctl(精简版)wget https://github.com/containerd/nerdctl/releases/download/v0.22.2/nerdctl-0.22.2-linux-amd64.tar.gz解压tar -xf nerdctl-0.22.2-linux-amd64.tar.gzln -s /opt/k8s/nerdctl/nerdctl /usr/local/bin/nerdctl2)安装 nerdctl(完整版,这里不装)wget https://github.com/containerd/nerdctl/releases/download/v0.22.2/nerdctl-full-0.22.2-linux-amd64.tar.gztar -xf nerdctl-full-0.16.0-linux-amd64.tar.gz -C /usr/local/cp /usr/local/lib/systemd/system/*.service /etc/systemd/system/启动服务 buildkitsystemctl enable buildkit containerd --nowsystemctl status buildkit containerd3)安装 buildkit 支持构建镜像buildkit GitHub 地址:https://github.com/moby/buildkit使用精简版 nerdctl 无法直接通过 containerd 构建镜像,需要与 buildkit 组全使用以实现镜像构建。当然你也可以安装上面的完整 nerdctl;buildkit 项目是 Docker 公司开源出来的一个构建工具包,支持 OCI 标准的镜像构建。它主要包含以下部分:服务端 buildkitd,当前支持 runc 和 containerd 作为 worker,默认是 runc;客户端 buildctl,负责解析 Dockerfile,并向服务端 buildkitd 发出构建请求。buildkit 是典型的C/S 架构,client 和 server 可以不在一台服务器上。而 nerdctl 在构建镜像方面也可以作为 buildkitd 的客户端。https://github.com/moby/buildkit/releaseswget https://github.com/moby/buildkit/releases/download/v0.10.4/buildkit-v0.10.4.linux-amd64.tar.gztar -xf buildkit-v0.10.4.linux-amd64.tar.gz -C /usr/local/配置 buildkit 的启动文件,可以从这里下载:https://github.com/moby/buildkit/tree/master/examples/systemdbuildkit 需要配置两个文件/usr/lib/systemd/system/buildkit.socketcat > /usr/lib/systemd/system/buildkit.socket <<EOF[Unit]Description=BuildKitDocumentation=https://github.com/moby/buildkit[Socket]ListenStream=%t/buildkit/buildkitd.sockSocketMode=0660[Install]WantedBy=sockets.targetEOF/usr/lib/systemd/system/buildkit.servicecat > /usr/lib/systemd/system/buildkit.service << EOF[Unit]Description=BuildKitRequires=buildkit.socketAfter=buildkit.socketDocumentation=https://github.com/moby/buildkit[Service]Replace runc builds with containerd buildsExecStart=/usr/local/bin/buildkitd --addr fd://[Install]WantedBy=multi-user.targetEOFsystemctl daemon-reloadsystemctl enable buildkit --now四、实战操作1)修改 containerd 配置文件配置如下:[plugins.“io.containerd.grpc.v1.cri”.registry]config_path = “”[plugins."io.containerd.grpc.v1.cri".registry.auths] [plugins."io.containerd.grpc.v1.cri".registry.configs] [plugins."io.containerd.grpc.v1.cri".registry.configs."myharbor-minio.com".tls] insecure_skip_verify = true #跳过认证 ca_file = "/etc/containerd/myharbor-minio.com/ca.crt" [plugins."io.containerd.grpc.v1.cri".registry.configs."myharbor-minio.com".auth] username = "admin" password = "Harbor12345" [plugins."io.containerd.grpc.v1.cri".registry.headers] [plugins."io.containerd.grpc.v1.cri".registry.mirrors] [plugins."io.containerd.grpc.v1.cri".registry.mirrors."myharbor-minio.com"] endpoint = ["https://myharbor-minio.com"]重新加载配置systemctl daemon-reload重启containerdsystemctl restart containerd注意:这个配置文件是给crictl和kubelet使用,ctr是不可以用这个配置文件的,ctr 不使用 CRI,因此它不读取 plugins."io.containerd.grpc.v1.cri"配置2)ctr 拉取推送镜像推送镜像到harborctr --namespace=k8s.io images push myharbor-minio.com/bigdata/minio:2022.8.22-debian-11-r0 --skip-verify --user admin:Harbor12345–namespace=k8s.io 指定命名空间,不是必须,根据环境而定–skip-verify 跳过认证–user 指定harbor用户名及密码ctr images pull --user admin:Harbor12345 --tlscacert=/etc/containerd/myharbor-minio.com/ca.crt myharbor-minio.com/bigdata/minio:2022.8.22-debian-11-r0不想-u user:password 每次必须使用 ctr pull/ctr push, 可以使用nerdctl 。3)镜像构建cat > Dockerfile <<EOFFROM nginx:alpineRUN echo ‘Hello Nerdctl From Containerd’ > /usr/share/nginx/html/index.htmlEOF然后在文件所在目录执行镜像构建命令:不加-n指定命名空间,crictl看不到,kubelet也不能使用它,默认在default命名空间下nerdctl -n k8s.io build -t nginx:nerctl -f ./Dockerfile .参数解释-t:指定镜像名称. :当前目录Dockerfile-f:指定Dockerfile路径–no-cache:不缓存4)打标签 tagcrictl没有tag命令,只能使用nerdctl和ctr,必须指定命名空间,要不然kubelet无法使用。ctr -n k8s.io i tagnerdctl -n k8s.io tag nginx:nerctl myharbor-minio.com/bigdata/nginx:nerctlctr -n k8s.io tag nginx:nerctl myharbor-minio.com/bigdata/nginx:nerctl查看镜像nerdctl -n k8s.io images myharbor-minio.com/bigdata/nginx:nerctl5)将镜像推送到 Harbor第一种情况:http方式,配置如下:以下两个哪个都可以mkdir -p /etc/docker/certs.d/myharbor-minio.com:443mkdir -p /etc/containerd/certs.d/myharbor-minio.com:443cat > /etc/containerd/certs.d/myharbor-minio.com:443/hosts.toml <<EOFserver = “https://docker.io”[host.“http://myharbor-minio.com:80”]capabilities = [“pull”, “resolve”,“push”]skip_verify = trueca = “ca.crt” #相对路径ca = “/opt/auth/ca.crt” #绝对路径ca = [“/opt/auth/ca.crt”]ca = [“ca.crt”]client = [[“/opt/auth/nginx.cclinux.cn.crt”, “/opt/auth/nginx.cclinux.cn.key”]]EOF第二种情况:https方式,配置如下:以下两个哪个都可以mkdir -p /etc/docker/certs.d/myharbor-minio.com:443mkdir -p /etc/containerd/certs.d/myharbor-minio.com:443cat > /etc/containerd/certs.d/myharbor-minio.com:443/hosts.toml <<EOFserver = “https://docker.io”[host.“https://myharbor-minio.com:443”]capabilities = [“pull”, “resolve”,“push”]skip_verify = trueca = “ca.crt” #相对路径ca = “/opt/auth/ca.crt” #绝对路径ca = [“/opt/auth/ca.crt”]ca = [“/etc/containerd/myharbor-minio.com/ca.crt”]client = [[“/opt/auth/nginx.cclinux.cn.crt”, “/opt/auth/nginx.cclinux.cn.key”]]EOF通过 nerdctl 登录 harborecho Harbor12345 | nerdctl login --username “admin” --password-stdin myharbor-minio.com:443nerdctl login --username “admin” --password Harbor12345 myharbor-minio.com:443登出nerdctl logout开始将镜像推送到 harbor推送到Harbor–insecure-registry skips verifying HTTPS certs, and allows falling back to plain HTTPnerdctl --insecure-registry --namespace=k8s.io push myharbor-minio.com/bigdata/nginx:nerctlctr --namespace=k8s.io images push myharbor-minio.com/bigdata/nginx:nerctl --skip-verify --user admin:Harbor12345–namespace=k8s.io 指定命名空间,跟-n一样,不是必须,根据环境而定–skip-verify 跳过认证–user 指定harbor用户名及密码————————————————版权声明:本文为CSDN博主「稚辉君.MCA.P8.JAVA高级架构师」的原创文章,遵循CC 4.0 BY-SA版权协议,转载请附上原文出处链接及本声明。原文链接:https://blog.csdn.net/m0_37843156/article/details/128277966
2023年-10月-28日
728 阅读
0 评论
技术
2023-10-28
k8s 中的三种容器探测方法
k8s 中的三种容器探测方法:启动探测、存活探测、就绪探测1、启动探测 startupProbe:探测容器中的应用是否已经启动。如果提供了启动探测(startup probe),则禁用所有其他探测,直到它成功为止。如果启动探测失败,kubelet 将杀死容器,容器服从其重启策略进行重启。如果容器没有提供启动探测,则默认状态为成功Success。2、存活探测 livenessprobe:用指定的方式(exec、tcp、http)检测pod中的容器是否正常运行,如果检测失败,则认为容器不健康,那么Kubelet将根据Pod中设置的 restartPolicy策略来判断Pod 是否要进行重启操作,如果容器配置中没有配置 livenessProbe,Kubelet 将认为存活探针探测一直为success(成功)状态。3、就绪探测 readnessprobe:就绪性探针,用于检测容器中的应用是否可以接受请求,当探测成功后才使Pod对外提供网络访问,将容器标记为就绪状态,可以加到pod前端负载,如果探测失败,则将容器标记为未就绪状态,会把pod从前端负载移除。我们可以自定义在pod启动时是否执行这些检测,如果不设置,则检测结果均默认为通过,如果设置,则顺序为startupProbe>readinessProbe和livenessProbe,其中readinessProbe和livenessProbe是并发关系,官方文档是是这样描述的:Caution: Liveness probes do not wait for readiness probes to succeed. If you want to wait before executing a liveness probe you should use initialDelaySeconds or a startupProbe以上三种探测方法都支持下面三种探针:1、exec:在容器中执行指定的命令,如果执行成功,退出码为 0 则探测成功。2、TCPSocket:通过容器的 IP 地址和端口号执行 TCP 检 查,如果能够建立 TCP 连接,则表明容器健康。3、HTTPGet:通过容器的IP地址、端口号及路径调用 HTTP Get方法,如果响应的状态码大于等于200且小于400,则认为容器健康通常探针探测结果有以下值:1、Success:表示通过检测。2、Failure:表示未通过检测。3、Unknown:表示检测没有正常进行。Pod探针相关的属性:探针(Probe)有许多可选字段,可以用来更加精确的控制Liveness和Readiness两种探针的行为initialDelaySeconds:容器启动后要等待多少秒后探针开始工作,单位“秒”,默认是 0 秒,最小值是 0periodSeconds: 执行探测的时间间隔(单位是秒),默认为 10s,单位“秒”,最小值是1timeoutSeconds: 探针执行检测请求后,等待响应的超时时间,默认为1,单位“秒”。successThreshold:连续探测几次成功,才认为探测成功,默认为 1,在 Liveness 探针中必须为1,最小值为1。failureThreshold: 探测失败的重试次数,重试一定次数后将认为失败,在 readiness 探针中,Pod会被标记为未就绪,默认为 3,最小值为 1两种探针区别:ReadinessProbe 和 livenessProbe 可以使用相同探测方式,只是对 Pod 的处置方式不同:readinessProbe 当检测失败后,将 Pod 的 IP:Port 从对应的 EndPoint 列表中删除。livenessProbe 当检测失败后,将杀死容器并根据 Pod 的重启策略来决定作出对应的措施。
2023年-10月-28日
657 阅读
0 评论
技术
2023-10-28
一些与Pod相关的kubectl命令
kubectl是Kubernetes的命令行工具,主要使用 Kubernetes API 与 Kubernetes 集群的控制面进行通信的管理命令。以下是一些与Pod相关的常用命令:1、创建Pod: kubectl create用于创建pod,如要创建名为pod-test的Pod,可以使用以下命令kubectl create pod pod-test --image=tomcat #将为以tomcat镜像创建一个名为pod-test的Pod2、获取Pod信息: kubectl get pods3、查看Pod日志信息:kubectl logs Pod名4、进入Pod: kubectl exec -it Pod名 -- /bin/bash5、删除Pod:1)利用Pod名直接删除: kubectl delete pod Pod名2) 利用Pod配置yaml文件删除: kubectl delete -f Pod-yaml文件名.yaml3) 强制删除某个Pod:kubectl delete pod xxx --force --grace-period=04)删除所有pods: kubectl delete pods --all6、查看分析Pod: kubectl describe pod Pod名kubectl describe pod pod-name7、更新Pod: kubectl apply -f podname.yaml此命令也可以用于指定Pod配置yaml文件创建Pod8、暂停和恢复Pod暂停Pod:kubectl pause pod pod名恢复Pod:kubectl unpause pod pod名9、手动扩容和缩减pod: kubectl scale如想要将Pod的副本扩大到6个,以下尝试以下命令kubectl scale --replicas=6 deployment/pod名10、导入导出Pod:导出Pod: kubectl export pod Pod名 --output=Pod名.yaml11、查看Pod的CPU和内存资源使用(需要安装metric-server组件)kubectl top pods
2023年-10月-28日
316 阅读
0 评论
技术
1
2
3
4