• 【容器 01】ascendHub拉取镜像失败,报x509错误码
    问题现象:docker login 时报错:x509: certificate signed by unknown authority可能原因:1. docker没有配置insecure-registries解决方法:1. 查看docker代理是否已配置cat /proc/`pidof dockerd`/environ | grep -a PROXY或者docker info2. 修改docker代理mkdir /etc/systemd/system/docker.service.d/# 根据docker版本不同,代理配置文件也可能不同,根据实际进行选择编辑vim /etc/systemd/system/docker.service.d/http-proxy.conf# 添加如下内容,根据实际环境进行代理地址配置[Service]Environment="HTTP_PROXY=xx.xx.xx.xx"Environment="HTTPS_PROXY=xx.xx.xx.xx"3. 修改daemon.json文件vim /etc/docker/daemon.json添加如下内容:{        "insecure-registries": ["ascendhub.huawei.com"]}保存文件 :wq4. 重启dockersystemctl daemon-reloadsystemctl restart docker
  • 容器化
    一、容器化改造方案租户对应一个企业。租户中内置多级VDC对企业不同部门。每个部门可以设置配额,对应部门对资源的预算。支持VDC多级管理,最大5级。 部门内的项目,对应project,一个用户可以在不同项目内。一个项目也可以有不同用户。用户可以跨部门关联项目 部门的资源归属到项目中 VDC内用户有不同角色,分别为VDC管理员,负责本级及下级的产品、角色、用户、Project管理、资源管理; VDC业务员:负责资源使用二、高可用规划结合华为云,给出高可用规划的简单说明:1 、分别在2个AZ中部署两套CCE集群,K8S Master采用本地3节点高可用部署;2、应用AZ内高可用部署,通过ClusterIP服务调用不跨AZ。3、应用发布LoadBalancer类型的Service对接到集群所在AZ的融合ELB服务实例;4、应用通过VIP访问数据库,数据库自动切换应用不感知。5、支持多AZ动态容器存储,根据pod所在AZ创建数据卷。三、 网络规划1、集群内部应用默认可通过ClusterIP类型服务相互通信。k8s集群内置DNS服务,服务间访问可以通过IP或域名访问,请画出K8S集群内部应用网络互通示意图:2、Step1:kube-proxy、core-dns从Master中kube-apiserver订阅service,POD2的Service创建时,kube-proxy刷新本节点iptables,core-DNS更新路由数据。3、Step2:Pod2通过域名访问Pod4的service4,发起到core-dns查询请求,并获取对应的ClusterIP(如果使用ClusterIP直接访问则忽略这一步骤)4、Step3:Pod2发送业务报文,目的地址为获取到的ClusterIP。容器网络根据目的地址匹配策略后进行VxLAN封装,封装源地址为容器所在的VM IP地址,目的地址为目的容器所在VM IP,并将报文发给I层vSwitch,然后转发至目的容器所在VM,容器网络解VxLAN封装后,根据ClusterIP将业务报文发送目的service及POD。四、 云原生概念五、 微服务微服务目的是有效的拆分应用,实现敏捷开发和部署 。1、按照业务来划分服务,单个服务代码量小,业务单一,易于维护2、每个微服务都有自己独立的基础组件,例如数据库、缓存等,且运行在独立的进程中3、微服务之间的通信是通过HTTP 协议或者消息组件,且具有容错能力4、微服务有一套服务治理的解决方案,服务之间不相合,可以随时加入和剔除服务5、单个微服务能够集群化部署,并且有负载均衡的能力6、整个微服务系统应该有一个完整的安全机制,包括用户验证、权限验证、资源保护等7、整个微服务系统有链路追踪的能力8、有一套完整的实时日志系统微服务具备功能:1、服务的注册和发现2、服务的负载均衡3、服务的容错4、服务网关5、服务配置的统一管理6、链路追踪7、实时日志六、 CI/CDCICD实现了从代码开发、代码编译、部署、测试、发布上线自动化的一套自动化构建的流程;CI即持续集成(Continuous Integration),它实现代码合并、构建、部署、测试都在一起,不断地执行这个过程,并对结果进行反馈。CD包含两个含义:持续交付(Continuous Delivery),它实现部署到生产环境,给用户进行使用;持续部署(Continuous Deployment),它实现部署到生产环境七、 DevopsDevOps就是让开发人员和运维人员更好地沟通合作,通过自动化流程来使得软件整体过程更加快捷和可靠八、 容器化容器是通过一种虚拟化技术来隔离运行在主机上不同进程,从而达到进程之间、进程和宿主操作系统相互隔离、互不影响的技术。这种相互孤立进程就叫容器,它有自己的一套文件系统资源和从属进程。九、 使用容器引擎客户端上传镜像顺序开始——安装容器引擎——构建镜像——创建组织——连接容器镜像服务——上传镜像——结束十、 CCE引擎优势
  • [问题求助] isula启动容器报错Execute operation failed
    isula启动容器报错Execute operation failed系统环境是openEuler 20.03 (LTS),isula版本是2.0.3,Kernel Version: 4.19.90-2003.4.0.0036.oe1.aarch64
  • [技术干货] 视频存储容器化
    一.存储容器化存储作为基础组件,直接和本地盘打交道,所以我们一个要解决的事情就是如果Kubernetes 管理本地盘。kubernetes管理本地盘通过官方提供的local-static-provisioner自动生成LocalPersistentVolume管理磁盘。LocalPersistentVolume是Kubernetes提供的一种管理本地盘的资源。5.1 使用Statefulset管理存储容器通过statefulset 管理有状态的存储服务, 为每个pod分配一个单独的磁盘可以使用volumeClaimTemplates给每个pod生成唯一的pvc,具体规则{podName},事先准备好PVC 和 PV,通过Statefulset 我们就可以把我们的存储托管到云上了。另外借助daemonset,可以把我们gateway模块部署到每一个node上面。处理云存储的请求。5.2 存储容器化的收益1)降低运维成本基于Kubernetes和statfulset获得了滚动更新,灰度更新,健康检查,快速扩容等功能,只需要一组yaml文件就可以快速搭建一个集群,相比于传统写ansible脚本部署的方式复杂度大大降低。2)降低开发运维成本由于Kubernetes把存储抽象成StorageClass PersistentVolume PersistentVolumeClaim。我们可以通过他们管理我们的存储资源,基于Kubernetes lable的过滤功能,可以实现简单的关系查询,通过PVC与PV管理存储资源,减少管理端的开发。定位问题也能通过POD信息快速定位到问题机器和问题云盘。而且接入Kubernetes生态上的prometheus后,监控告警也能快速开发。3)隔离性增强docker限制cpu memory使用,减少进程之间资源互相干扰,进一步提升资源利用率。在做流媒体容器化过程中,各个系统 Portal 平台、中间件、ops 基础设施、监控等都做了相应的适配改造,改造后的架构矩阵如下图所示。Portal:流媒体 的 PaaS 平台入口,提供 CI/CD 能力、资源管理、自助运维、应用画像、应用授权(db 授权、支付授权、应用间授权)等功能。2.运维工具:提供应用的可观测性工具, 包括 watcher(监控和报警)、bistoury (Java 应用在线 Debug)、qtrace(tracing 系统)、loki/elk(提供实时日志/离线日志查看)。中间件:应用用到的所有中间件,mq、配置中心、分布式调度系统 qschedule、dubbo 、mysql sdk 等。3.虚拟化集群:底层的 K8s 和 OpenStack 集群。4.Noah:测试环境管理平台,支持应用 KVM/容器混合部署。一.CI/CD 流程改造主要改造点:应用画像: 把应用相关的运行时配置、白名单配置、发布参数等收敛到一起,为容器发布提供统一的声明式配置。授权系统: 应用所有的授权操作都通过一个入口进行,并实现自动化的授权。K8s 多集群方案: 通过调研对比,KubeSphere 对运维优化、压测评估后也满足我们对性能的要求,最终我们选取了 KubeSphere 作为多集群方案。二.中间件适配改造改造关注点:由于容器化后,IP 经常变化是常态,所以各个公共组件和中间件要适配和接受这种变化。Qmq组件改造点:Broker端加快过期数据的处理速度。原因:由于IP变化频繁,对于一个主题有几百个甚至上千个的IP订阅,会产生很多文件Qconfig/Qschedule组件改造点:按实例级别的推送、任务执行在容器场景下不建议使用 。原因:因为IP经常变化,在容器化场景下发布、pod驱逐等都会导致IP变化,按实例维度推送没有意义Dubbo组件改造点:更改上线下线逻辑,下线记录由永久节点改为临时节点。 原因:上下线机制加上频繁的IP变更会导致zookeeper上产生大量的过期数据Openresty改造点:监听多K8s集群的endpoint变更,并更新到upstream; KVM、容器server地址共存,支持KVM和容器混合部署;三、应用平滑迁移方案设计为了帮助业务快速平滑地迁移到容器,制定了一些规范和自动化测试验证等操作来实现这个目标。1.容器化的前置条件: 应用无状态、不存在 post_offline hook(服务下线后执行的脚本)、check_url 中不存在预热操作。2.测试环境验证: 自动升级 SDK、自动迁移。我们会在编译阶段帮助业务自动升级和更改 pom 文件来完成 SDK 的升级,并在测试环境部署和验证,如果升级失败会通知用户并提示。3.线上验证: 第一步线上发布,但不接线上流量,然后通过自动化测试验证,验证通过后接入线上流量。4.线上 KVM 与容器混部署:保险起见,线上的容器和 KVM 会同时在线一段时间,等验证期过后再逐步下线 KVM。5.线上全量发布: 确认服务没问题后,下线 KVM。6.观察: 观察一段时间,如果没有问题则回收 KVM。
  • [产品讨论] 容器和虚拟化的联系
    一、容器和虚拟化的联系容器和虚拟化相比容器比虚拟机小很多,通常是MB级,所需的硬件资源也少很多,虚拟机是GB级,意味着一台物理机器可以承载的容器比虚拟机要多的多。容器可以在几秒甚至几毫秒内启动,相比之下,虚拟机启动时间比较长。容器是共享主机的操作系统,因为所有应用必须在统一操作系统上运行。相比,虚拟机可以运行不同的操作系统。使用容器只需对容器主机的操作系统进行补丁和更新,而虚拟机需对每个操作系统进行补丁和更新。如果一个容器导致容器主机操作系统崩溃,则在该主机上运行的所有容器都将失败。容器主机的操作系统内核中的安全漏洞将影响其所托管的所有容器。使用场景虚拟机非常适合传统的资源密集型单片应用程序,尤其是准备将这些应用程序移至云中时。容器更适合承载web服务中使用的微服务。不仅如此,容器和虚拟机也可以共存,容器可以在虚拟机中运行,企业可以利用现有的虚拟化基础设施来管理其容器。
  • [技术干货] 使用Docker容器实现Nginx部署
    1:获取参考资料一、在浏览器地址栏输入hub.docker.com 访问dockerhub官网。二、搜索框内输入要下载的镜像,我们这里下载的是nginx三、点击搜索出来的第一个nginx,进入详情页面四、详情页面介绍1:打了一标签,说明这是一个官方镜像。DOCKER OFFICIAL IMAGE,还有下载量 1B+ (代表10亿+),还收收藏量。2:右侧这个,如果我们要使用这个镜像该如何下载镜像3: 镜像所提供的tags,我们在使用镜像的过程中,我们要选择使用哪个镜像,什么什么版本的镜像,那么我们就要看一下下面这些tags,这些tags是否能够满足我们的需求,如果可以满足,我们就直接使用,如果不能满足我就要自己去制作镜像。另外在我们这些tags中都对应了一个dockerfile links,你点击这些文件就能看到这些dockerfile文档应用的方式,方法。4:【文档中的重点】,是我们如何部署这个nginx的基础$ docker run --name some-nginx -v /some/content:/usr/share/nginx/html:ro -d nginx运行一个niginx应用的容器,docker run 然后-name 给容器起一个名字,名字自定义。这里有一个-v选项,这个选项是干什么的呢?把宿主机的某个目录(/some/content),挂载到容器当中的某个目录(/usr/share/nginx/html)当中去,并且定义它的读写权限(:ro),并且以非交互式的方式运行(-d)这个命令执行完,只能在宿主机中访问nginx相关的应用。不能跨域docker host来访问它。$ docker run --name some-nginx -d -p 8080:80 some-content-nginx如果需要跨dockerhost访问,就需要用到这个方法,把我们容器中的80端口映射到宿主机的8080,后面加上它的镜像就可以了。这样我们就能通过宿主机的8080端口来访问nginx2:运行Nginx应用容器不暴露端口不在docker host暴露端口# docker run -d --name nginx-server -v /opt/nginx-server:/usr/share/nginx/html:ro nginx 664cd1bbda4ad2a71cbd09f0c6baa9b34db80db2d69496670a960be07b9521cb查看进行 # docker ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 664cd1bbda4a nginx "/docker-entrypoint.…" 4 seconds ago Up 3 seconds 80/tcp nginx-server查看容器的IP地址 # docker inspect 664 | grep IPAddress "SecondaryIPAddresses": null, "IPAddress": "172.18.0.1", "IPAddress": "172.18.0.1",在本机使用crul命令进行访问,为什么访问后是403呢?因为我们挂载过去后/opt/nginx-server下面并没有文件。# curl http://172.18.0.1403 Forbiddennginx/1.21.6我们使用echo 把nginx is working 添加到/opt/nginx-server/index.html中去# ls /opt nginx-server # echo "nginx is working" > /opt/nginx-server/index.html重复访问,发现可以重新访问# curl http://172.17.0.1 nginx is working
  • [容器专区] 【LXC容器】如何构建出一个带有Python3环境的LXC容器
    ↵AR502H系列网关的容器是开放的,用户可以根据自身要求来定制,本文介绍如何制作出一个带有Python3运行环境的lxc容器。一,容器制作环境搭建环境制作方法在此不再赘述,请参考《软件二次开发指南》相关章节进行搭建《软件二次开发指南》:cid:link_0二、修改制作容器脚本1、修改编译环境中的/usr/local/bin/create-rootfs的脚本,以完成安装python如上图,在脚本178行左右末尾添加python3 python3-pip2、添加py运行库如上图在脚本185行左右添加如红框内容,该部分可按需添加这里的pip3 install 后建议指定为国内源以保证网络质量三、制作容器按照正常步骤制作容器,制作出的容器就带有python3环境了后记:也可使用相同方法,在容器中安装如gdb等调试工具
  • [问题求助] 国产系统搭建flanneld 跨主机虚拟网络不通
    在国产系统麒麟10上 搭建k8s 虚拟网络(etcd+flanneld),检查系统配置,路由转发,防火墙等相关配置没有问题,检查 etcd ,flanneld配置没有问题,日志输出信息正确,但就是不能建立跨主机的虚拟网络通信,请帮忙看下是什么原因。
  • [问题求助] open Euler下isula容器网络配置,crictl runp pod-config.json找不到文件
    open Euler下isula容器网络配置,crictl runp pod-config.json失败 显示load podSandboxConfig: config at pod-config.json not foundpod-config.json文件在根目录下/CRI/pod-config.json 内容为 { "metadata": { "name": "nginx-sandbox", "namespace": "default", "attempt": 1, "uid": "hdishd83djaidwnduwk28bcsb" }, "log_directory": "/tmp", "linux": { } }daemon.json位置在/etc/isulad/ 配置内容为:{ "group": "isulad", "default-runtime": "lcr", "graph": "/var/lib/isulad", "state": "/var/run/isulad", "engine": "lcr", "log-level": "ERROR", "pidfile": "/var/run/isulad.pid", "log-opts": { "log-file-mode": "0600", "log-path": "/var/lib/isulad", "max-file": "1", "max-size": "30KB" }, "log-driver": "stdout", "hook-spec": "/etc/default/isulad/hooks/default.json", "start-timeout": "2m", "storage-driver": "overlay2", "storage-opts": [ "overlay2.override_kernel_check=true" ], "registry-mirrors": [ ], "insecure-registries": [ ], "pod-sandbox-image": "", "image-opt-timeout": "5m", "image-server-sock-addr": "unix:///var/run/isulad/isula_image.sock", "native.umask": "secure", "network-plugin": "", "cni-bin-dir": "", "cni-conf-dir": "", "image-layer-check": false, "use-decrypted-key": true, "insecure-skip-verify-enforce": false }
  • [问题求助] Open Euler安装isula后,配置cni文件过程中,crictl runp pod-config.json 失败,检查isula状态出错
    用过sudo yum install -y iSulad 安装的isula在跟华为论坛帖子配置cni过程中,crictl runp pod-config.json 失败,报错:load podSandboxConfig: config at pod-config.json not found通过systemctl status isulad检查i酥啦状态,发现报错:isulad[4268]: isulad 20221030202454.588 ERROR src/connect/client/grpc/grpc_isula_image_client.cc:run:137 - error_code: 14: failed to connect to all addresses早重新安装isula后直接检查状态仍然报错,求助
  • [技术干货] 使用华为云yum源在centOS7下安装docket
    ​1:获取华为云开源镜像站YUM源文件百度搜索​容器查找​详情查看​也可以根据下面的进行下载1:获取镜像地址 https://repo.huaweicloud.com/docker-ce/linux/centos/docker-ce.repo2:输入下面的命令 :wget -O /etc/yum.repos.d/docket-ce.repo https://repo.huaweicloud.com/docker-ce/linux/centos/docker-ce.repo意思是:将镜像下载到/etc/yum.repos.d/目录下 镜像名称为docket-ce.repo​查看一下文件在不在看下文件能不能用,使用命令:yum repolist 这里现实有一个183的数量,证明这里面有软件包,说明我们可以使用它​2:安装前先检查一下主机环境(可以跳过)主机:cat /etc/redhat-release内核 :uname -r防火墙:firewall-cmd --stateSELinux:sestatus ​基础运行环境配置,注意SELinux 要是disabled状态Linux中关闭SELinux的方法1、临时关闭:输入命令setenforce 0,重启系统后还会开启。2、永久关闭:输入命令vi /etc/selinux/config,将SELINUX=enforcing改为SELINUX=disabled,然后保存退出。重启系统​3:安装docket-ce执行命令:yum -y install docket-ce如果命令yum -y install docker-ce 报错No package docker-ce available解决方案:cid:link_0正在安装4:配置Docker Daemon启动文件由于Docker使用过程中会对Centos操作系统中的Iptables防火墙中的FORWARD链默认规划产生影响及需要让Docker Daemon接受用户自定义的daemon.json文件,需要要按使用者要求的方式修改。# vim /usr/lib/systemd/system/docker.service删除:- h fd:// --containerd=/run/containerd/containerd.sock添加:ExecStartPost=/sbin/iptables -P FORWARD ACCEPT5:启动Docker服务并查看已安装版本重启加载daemon文件# systemctl daemon-reload启动docker daemon# systemctl start docker设置开机自启动# systemctl enable docker使用docker version客户端命令查看已安装docker软件版本# docker version​
  • 轻松玩转Kubernetes笔记分享
    Kubernetes概述什么是容器?·容器为App提供独立的、受控的运行环境,是一种轻量级的操作系统虚拟化。简单的容器:SandBox(沙盒、沙箱)容器基本概念·容器关键概念―容器一镜像容器关键技术CgroupNameSpace容器时代的“双城记”Docker Kubernetes(K8s)Kubernetes -大海航行的舵手K8s集群主要包括两个部分:Master节点(管理节点)和Node节点(计算节点)Master节点主要还是负责管理和控制。Node节点是工作负载节点,里面是具体的容器。Master节点Master节点提供的集群控制,对集群做出全局性决策,例如调度等。通常在master节点上不运行用户容器。Master节点包括API Server、Scheduler、Controller manager、etcd。API Server :整个系统的对外接口Scheduler:集群内部的资源进行调度Controller Manager:负责管理控制器etcd : Kubernetes的后端存储Node节点节点组件运行在每一个Node节点上,维护运行的pod并提供kubernetes运行时环境。Node节点包括Pod、Docker、kubelet、kube-proxy、Fluentd、kube-dns (可选Pod是K8s最小单位Pod : Kubernetes最基本的操作单元Docker :创建容器;Kubelet:负责监视指派到它所在Node上的Pod,包括创建、修改、监控、删除等;Kube-proxy∶负责为Pod对象提供代理Fluentd:主要负责日志收集、存储与查询。Master节点和Node节点交互Kubernetes云上环境搭建CCE-基于开源K8S、 Docker技术的企业级容器服务云容器引擎(Cloud Container Engine,CCE)是基于业界主流的Docker和Kubernetes开源技术构建的容器服务,提供众多契合企业大规模容器集群场景的功能,在系统可靠性、高性能、开源社区兼容性等多个方面具有独特的优势,满足企业在构建容器云方面的各种需求。CCE优势:高性能、简单易用、安全可靠、开放兼容怎么管理K8s集群图形化WEB-UI 华为云CCE控制台、官方Dashboard命令行Kubectl iWebTerminal 管理员并发用户少Node+EIP 管理员并发用户多华为云Kubernetes环境快速搭建架构CE快该束物建KubernetesKubernetes的访问VPC:提供网络环境EIP:访问公网ECS:弹性云主机CCE:创建K8s集群Kubernetes环境管理进行Kubectl及配置文件下载下载kubectl和kubectl配置文件 kubeconfig.json和kubectlKubectl客户端服务器购买集群中管理节点安全组设置安装和使用kubectl使用Kubernetes只需一个部署文件,使用一条命令就可以部署多层容器(前端,后台等)的完整集群:$kubectl create -f single-config-file.yamlkubectl是和Kubernetes API交互的命令行程序。1.3 Kubernetes核心概念Kubernetes最小管理单元-PODPod是Kubernetes管理的最小基础单元。一个Pod中封装了︰一个或多个紧耦合的应用容器存储资源独立的IP容器运行的选项相同Pod中的任何容器都将共享相同的名称空间和本地网络。容器可以很容易地与其他容器在相同的容器中进行通信实践1:POD的创建和管理1.POD定义文件的上传通过winscp将下载的附件中的yml文件上传至客户端服务器目录并查看;2.创建PODkubectl apply -f POD-1Containeryml3.POD的管理指定POD运行到指定的NODE上kubectl apply -f POD-NodeSelector.yml4.POD的删除kubectl get podkubectl delete pod nginx有状态应用和无状态应用无有状态应用无状态服务,易于部署且易于扩展。如果流量上升,则只需添加更多的负载平衡;上游容器镜像和基础架构中正在运行的容器其实几乎没有区别;可以随时被替代,而且容器实例切换过程中几乎不需要耗费“切换成本”。有状态应用有状态的服务,从部署开始,这些容器就开始与上游镜像不同了,时间越长它们的差异越大;每个运行的应用程序都至少有—个小状态(差异),但对于“无状态”应用程序来说,状态(差异)很小,而且可以进行快速替换。无状态应用控制器– DeploymentReplicationController 无状态应用的高可靠 ReplicaSets 无状态应用的高可靠应用的滚动发布 Deployment实践2:Deployment的创建和管理1.创建deploymentkubectl apply -f deployment.yml2.查看PODkubectl get pod3.手动删除PODkubbectl delete pod nginx-deployment-67d4b848b4-sghfq4.扩展Deployment数量kubectl scale deployment.v1.apps/nginx-deployment --replicas=4kubectl get pod5.查看deployment状态和数量有状态应用控制器- StatefulSet如果部署的应用满足右侧一个或多个部署需求则建议使用StatefulSet。在具有以下特点时使用StatefulSets·稳定性,唯一的网络标识符·稳定性,持久化存储·有序的部署和扩展·有序的删除和终止·有序的自动滚动更新实践3:StatefulSet的创建和管理1.在Winscp将StatefulSet定义文件statefulset.yml上传至ecs-k8s。2.通过以下命令创建StatefulSet。kubetcl apply -f statefulset.yml3.通过以下命令查看POD数量和名称kubectl get pod4.手动删除名称为web-0的POD。kubectl delete pod web-05.再次查看POD。kubectl get pod系统应用控制器- DaemonSetDaemonSet能够让所有或者特定的Node节点运行一个pod。当节点加入到kubernetes集群中,pod会被( DaemonSet ) 调度到该节点上运行。当节点从kubernetes集群中被移除,( DaemonSet )调度的pod会被移除。运行日志采集器在每个Node上,例如fluentd ,logstash运行监控的采集端在每个Node,例如prometheusnode exporter , collectd等每个Node上运行一个分布式存储的守护进程,例如glusterd , ceph适合场景:在一个区域的Node上都运行一个守护进程实践4:DaemonSet的创建和管理在winscp中上传daemonset.yml文件至ecs-k8s查看kube-system命令空间中的DaemonSetkubectl get ds -n kube-system创建daemonsetkubectl apply -f daemonset.yml4.再次查看kube-system中的DaemonSetkubectl get ds -n kube-system5.在CCE中购买节点6.查看各个DaemonSet实例数kubectl get ds -n kube-system临时任务控制器–Job我们经常需要进行批量数据处理和分析,以及按照时间进行调度执行。可以在Kubenrtes中使用容器技术完成,使用Job和CronJob来执行。Job负责批处理任务,即仅执行一次的任务,它保证批处理任务的一个或多个Pod成功结束。CronJob是基于调度的Job执行将会自动产生多个job,调度格式参考Linux的cron系统。实践5:Jobs创建和管理winscp将Job.yml上传运行Jobkubectl apply -f Job. Yml3.查看job运行状态kubectl get job4.查看此Job的输出kubectl get podkubectl logs pi-c5pgr应用访问- ServiceKubernetes应用间互访- Cluster IPKubernetes集群外互访–NodePort公网访问- LoadBalancer实践6 : Service的创建和管理1.上传的deployment文件创建Deploymentkubectl apply -f deployment. Yml2.创建NodePort类型的Service并查看kubectl expose deployment nginx-deployment-type=NodePortkubectl get service通过curl命令验证网站kubectl get node4.url 192.168.0.227:324655.华为云控制台查看其中一个kubernetes Node绑定的公网地址6.在浏览器中,输入ECS绑定的公网地址+Service的Nodeport命名空间- NameSpace作用:Kubernetes可以使用Namespaces(命名空间)创建多个虚拟集群;Namespace为名称提供了一个范围。资源的Names在Namespace中具有唯一性场景:当团队或项目中具有许多用户时,可以考虑使用Namespace来区分,a如果是少量用户集群,可以不需要考虑使用Namespace,如果需要它们提供特殊性质时,可以开始使用Namespace。大多数的Kubernetes中的集群默认会有一个叫default的namespace。实际上,应该是3个:default:你的service和app默认被创建于此。kube-system : kubernetes系统组件使用。kube-public :公共资源使用。实践7∶命名空间的创建和管理默认的Nama&pice实践手动的创建一个NameSpace命名空间并查看kubectl create namespace testkubectl get namespace2.创建一个POD并指定此POD运行在test命名空间llkubectl apply-f POD-1Container.yml -namespace=test3.查看指定命名空间里的PODkubectl get pod -n test.创建一个限制CPU和内存大小的NameSpacekubectl create -f ns-cpu-men.yml -namespace=quota-mem-cpu-examplekubectl get resourcequota mem-cpu-demo -namespace=quota-mem-cpu-example R--output=yaml
  • [技术干货] AtlasEdge调用smartkit进行设备授权报错解决方法
    背景:通过smartkit对AtlasEdge设备进行设备授权时出现执行命令失败排查方法:当授权模式是site, 当前针对MindX 3.0.RC3及之前的版本只支持容器部署、模型文件下载配置,如果下方了网管配置会导致执行命令失败当授权模式是CORE时,除了MindX 3.0.RC2支持Core 模板表格中的所有项外,其他版本(例如MindX 2.0.4.6 MindX 3.0.RC3)只支持imageSha256WhiteList、containerCpuLim、containerCpuLimit配置,如果配置下发了其他项会导致命令失败
  • [问题求助] MindX Edge容器部署错误解决方法
    错误场景1: 部署主机网络容器失败错误提示:"cur config not surpport pod host work"解决方法:使用容器能力工具中的useHostNetwork配置项打开主机网络能力,配置完成后重启中间件。错误场景2: 部署容器报挂在卷不在白名单错误提示:"hostpath [xxxxxxx] Verification failed: not in whitelist",解决方法:使用容器能力工具中的addHostPath配置添加容器挂在白名单,配置完成后重启中间件。错误场景3: 部署容器下发了容器能力集报错错误提示:"check container Capability failed", cur config not surpport"解决方法:使用容器能力工具中的useCapability配置允许容器配置能力集,配置完成后重启中间件。错误场景4: 部署容器下发了容器能力集报错错误提示:"check container Capability failed", cur config not surpport"解决方法:使用容器能力工具中的usePrivileged配置允许部署特权容器,配置完成后重启中间件。错误场景5: 部署容器下发了容器能力集报错错误提示:"check container Privileged failed", cur config not surpport"解决方法:使用容器能力工具中的usePrivileged配置允许部署特权容器,配置完成后重启中间件。错误场景6: 部署root容器失败错误提示:"check container Run As User failed", cur config not surpport"或者"check container Run As Group failed", cur config not surpport"解决方法:使用容器能力工具中的useRunAsRoot配置允许部署root容器,配置完成后重启中间件。错误场景7: 部署容器使用探针报错误错误提示:"cur config not surpport probe"解决方法:使用容器能力工具中的useProbe配置允许容器使用探针功能,配置完成后重启中间件。错误场景8: 部署容器使用探针报错误错误提示:"check container:容器名 StartCommand failed, not surpport"解决方法:使用容器能力工具中的useStartCommand配置允许容器使用启动命令,配置完成后重启中间件。错误场景9: 部署容器使用探针报错误错误提示:"cur config not surpport empty dir volume"解决方法:使用容器能力工具中的emptyDirVolume配置允许容器使用emptydir挂载卷,配置完成后重启中间件。错误场景10: 部署容器使用探针报错误错误提示:"cur config not surpport empty dir volume"解决方法:使用容器能力工具中的emptyDirVolume配置允许容器使用emptydir挂载卷,配置完成后重启中间件。错误场景11: 容器个数超过限制错误提示:"exceed max container number"解决方法:使用容器能力工具中的maxContainerNumber配置允许部署容器的个数,配置完成后重启中间件。错误场景12: 容器个数超过限制错误提示:"exceed max container number"解决方法:使用容器能力工具中的maxContainerNumber配置允许部署容器的个数,配置完成后重启中间件。错误场景13: 部署容器报挂在卷/etc/localtime不在白名单错误提示:"hostpath [/etc/localtime] Verification failed: not in whitelist",解决方法:1) 使用容器能力工具中的addHostPath将"/etc/localtime"添加容器挂在白名单,配置完成后重启中间件。 2) 配套FusionDirector 22.2.RC1及以后的版本错误场景14: 容器使用端口映射时,容器启动失败解决方法:1) 排查容器端口是否取值为[0-1023], 如果是,业务容器需以root运行,并 使用容器能力工具配置useRunAsRoot、useDefaultContainerCap允许容器使用root运行和使用默认的能力集,配置完成后重启中间件。
  • [知识分享] 基于KubeEdge的边缘节点分组管理设计与实现
    摘要:KubeEdge 1.11版本提供了“边缘节点分组管理”新特性,抽象出了跨地域的应用部署模型。本文分享自华为云社区《基于KubeEdge的边缘节点分组管理设计与实现》,作者:云容器大未来 。KubeEdge 1.11版本提供了“边缘节点分组管理”新特性,抽象出了跨地域的应用部署模型。该模型将边缘节点按地区划分为节点组,并将应用所需资源打包成一个整体在节点组上进行部署,降低了边缘应用生命周期管理的复杂度,有效减少运维成本。1. 边缘应用跨地域部署面临的挑战图1 边缘应用跨地域部署示意图在边缘计算场景中,边缘节点通常分布在不同的地理区域,这些区域中的节点有着计算资源、网络结构和硬件平台等属性上的差异。如图1所示,边缘节点部署在杭州、北京和上海等地域,各地域边缘节点的规模不同,不同地域网络不互通,以及不同区域镜像仓库也是不同的,如北京的节点无法通过IP直接访问其他区域的节点。因此在部署边缘应用的时候,通常需要为每个这样的地理区域维护一个Deployment,对于资源少的区域减少副本数量,对于局域网中的节点需要把镜像地址改为本地镜像仓库的地址,同样也需要为每个地区管理单独的Service资源,来解决跨地域节点之间的访问问题。然而随着地理区域和应用数量的增长,对应用的管理会变得越来越复杂,运维成本也随之增加。基于以上背景,KubeEdge提供了边缘节点分组管理能力,来解决在跨地域应用部署中运维复杂度的问题。2. 边缘节点分组管理设计与实现图2 边缘节点分组整体概览如图2所示,边缘节点分组特性的整体设计图,主要由节点分组、边缘应用和流量闭环三个部分的内容组成,下面会就以上各个部分详细展开。2.1 节点分组(NodeGroup)图3 节点分组示例根据边缘节点的地理分布特点,可以把同一区域的边缘节点分为一组,将边缘节点以节点组的形式组织起来,同一节点同时只能属于一个节点组。节点分组可以通过matchLabels字段,指定节点名或者节点的Label两种方式对节点进行选择。节点被包含到某一分组后,会被添加上apps.kubeedge.io/belonging-to:nodegroup的Label。2.2 边缘应用(EdgeApplication)图4 边缘应用EdgeApplication的组成边缘应用用于将应用资源打包,按照节点组进行部署,并满足不同节点组之间的差异化部署需求。该部分引入了一个新的CRD: EdgeApplication,主要包括两个部分:(1) Workload Templates。主要包括边缘应用所需要的资源模板,例如Deployment Template、Service Template和ConfigMap Template等;(2) WorkloadScopes。主要针对不同节点组的需求,用于资源模板的差异化配置,包括副本数量差异化配置(Replicas Overrider)和镜像差异化配置(Image Overrider),其中Image Overrider包括镜像仓库地址、仓库名称和标签。对于应用主体,即Deployment,会根据Deployment Template以及差异化配置Overrider生成每组所需的Deployment版本,通过调整nodeSelector将其分别部署到指定分组中。对于应用依赖的其他资源,如ConfigMap和Service,则只会在集群中通过模板创建一个相应的资源。边缘应用会对创建的资源进行生命周期管理,当删除边缘应用时,所有创建的资源都会被删除。2.3 流量闭环图5 流量闭环示意图通过流量闭环的能力,将服务流量限制在同一节点组内,在一个节点组中访问Service时,后端总是在同一个节点组中。当使用EdgeApplication中的Service Template创建Service时,会为Service添上service-topology:range-nodegroup的annotation,KubeEdge云上组件CloudCore会根据该annotation对Endpoint和Endpointslice进行过滤,滤除不在同一节点组内的后端,之后再下发到边缘节点。此外,在下发集群中默认的Master Service “Kubernetes”所关联的Endpoint和Endpointslice时,会将其维护的IP地址修改为边缘节点MetaServer地址,用户在边缘应用中list/watch集群资源时,可以兼容K8s流量访问方式,实现无缝迁移和对接。3. 实现原理与设计理念在这个部分,我们会分享一下边缘节点分组管理特性的设计理念,并结合KubeEdge整体架构,详细介绍一下我们的实现原理。图6 设计理念我们希望给用户提供一个统一的运维入口,原本我们需要维护各个地区的Deployment,如果需要进行增删改查操作,我们需要对每个地区的Deployment都执行一遍相同的操作,不仅增加了运维成本,还容易引入人为操作的错误。边缘节点分组管理特性通过引入EdgeApplication CRD,统一了Deployment等资源的运维入口。另外我们需要提供更大的扩展可能性,在内部实现中,我们统一使用了Unstructured结构,降低与特定资源的耦合度,方便后续添加其他资源。另外为了不干涉原生资源和流程,我们降低与Kubernetes Reconciliation的耦合度,可以保证Deployment等资源操作过程的原生性。图7 节点组和边缘应用实现在边缘节点分组管理特性中,我们引入了两个CRD,分别是节点组NodeGroup和边缘应用EdgeApplication。在NodeGroup Reconciliation中,NodeGroup Controller用于监听NodeGroup CRD的变化,并对节点的apps.kubeedge.io/belonging-to:nodegroup Label进行增删改等操作,同时,加入节点组的节点,会上报状态到NodeGroup CRD中,我们就可以通过查询NodeGroup直接查看节点组内所有节点的状态。EdgeApplication Reconciliation与NodeGroup Reconciliation类似,由EdgeApplication Controller来监听EdgeApplication CRD的变化,对相应资源进行增删改等操作,同时对应资源会上报状态到EdgeApplication CRD中。图8 整体架构如图8所示,是最终的整体架构图。在边缘节点分组管理特性中,我们引入了新的组件ControllerManager,其中包括了刚才我们介绍的NodeGroup Controller和EdgeApplication Controller,在CloudCore中引入了新的模块EndpointSlice Filter,用于实现流量闭环的能力。图中蓝色区域是前面已经介绍了的节点分组和边缘应用的内容,在这里再重点介绍一下Service Template实现流量闭环能力的过程。首先在EdgeApplication CRD中加入Service的模板,在创建边缘应用时,Service range-nodegroup资源也会随之生成,同时控制面会自动为其创建EndpointSlice。EndpointSlice会通过KubeEdge的云边通道下发到边缘节点,CloudCore中的EndpointSlice Filter会进行过滤,保证下发到同一节点组内的边缘节点,由此可以保证边缘上的客户端访问始终在一个节点组内。对于用户来说,图8中紫色的线表达了用户需要维护的资源。首先用户需要维护NodeGroup,来管理节点组中的节点;其次,用户需要维护EdgeApplication资源,通过EdgeApplication来实现对各个地域边缘应用的生命周期管理。4. 发展规划目前我们已经实现了Deployment、Service和ConfigMap等资源的打包以及流量闭环的能力,并且支持资源的部分状态收集。未来我们将继续拓展边缘节点分组的能力,实现边缘网关,支持StatefulSet等更多资源,逐步完善应用状态收集,并在Kubectl中支持更友好的资源展现形式。欢迎大家能够加入KubeEdge社区,一起完善与增强KubeEdge边缘节点分组等方面的能力。了解KubeEdge社区KubeEdge是业界首个云原生边缘计算框架、云原生计算基金会内部唯一孵化级边缘计算开源项目,社区已完成业界最大规模云原生边云协同高速公路项目(统一管理10万边缘节点/50万边缘应用)、业界首个云原生星地协同卫星、业界首个云原生车云协同汽车、业界首个云原生油田项目,开源业界首个分布式协同AI框架Sedna及业界首个边云协同终身学习范式,并在持续开拓创新中。KubeEdge网站 :  https://kubeedge.ioGitHub地址 : https://github.com/kubeedge/kubeedgeSlack地址 : https://kubeedge.slack.com邮件列表 : https://groups.google.com/forum/#!forum/kubeedge每周社区例会 : https://zoom.us/j/4167237304Twitter : https://twitter.com/KubeEdge文档地址 : https://docs.kubeedge.io/en/latest/本文作者由KubeEdge社区Member——华为云 鲍玥、浙江大学SEL实验室 张逸飞原创。
总条数:427 到第
上滑加载中