【摘要】 kubectl常用命令：获取pod，查看pod相关信息，重启pod，上传下载pod中的文件等命令。1.        获取pod1)   获取指定命名空间的pod：kubectl get pods –n namespace2)   获取所有命名空间的pod：kubectl get pod --all-namespaces2.        重启podkubectl get pods -n namespace，获取到controller的NAME。1)   重启：kubectl delete pod xxx -n namespace （备注：xxx替换为上面获取的pod的NAME即可。）2)   强制重启：kubectl delete pod xxx --force --grace-period=0 -n namespace （备注：xxx替换为上面获取的pod的NAME即可。）3)   重启多个：a)     kubectl delete pod NAME1 NAME2b)     kubectl delete pod NAME1 NAME2 --force --grace-period=0 -n namespace3.        进入podkubectl exec -ti xxx /bin/bash –n namespace xxx替换为要进入容器的id4.        查看pod相关信息1)   describe查看pod版本等信息：kubectl describe pod 容器名字 -n namespace2)   查看pod端口：kubectl get service –n namespace3)   查看pod所在的node的IP地址：kubectl get pods –owide –n namespace5.        从本地拷贝文件到pod中1)   先上传文件到master节点2)   然后在master节点的上传的文件存放目录执行：kubectl cp 文件名 namespace/xxx:/tmp/文件名 （备注：xxx为容器名称）3)   如执行命令：kubectl cp dbs-iaasclient-1.4.1.jar default/dwscontroller-87859b8bc-k4wb9:/tmp/dbs-iaasclient-1.4.1.jar后，该文件就在了容器中的/tmp路径中了6.        从pod下载文件到本地中1)   先在pod中查看要下载文件的路径：2)  在master节点的执行：kubectl cp namespace/xxx:文件名 /master存放该文件的目录/文件名（备注：xxx为容器名称）如，执行命令kubectl cp dws/dwscontroller-c9d6f657d-ggk27:a.log /tmp/a.log后，该文件就在master的/tmp路径中了3)   再通过其他方式从master节点下载下来即可。想了解GuassDB(DWS)更多信息，欢迎微信搜索“GaussDB DWS”关注微信公众号，和您分享最新最全的PB级数仓黑科技，后台还可获取众多学习资料哦~转载来自：https://bbs.huaweicloud.com/blogs/266491

　　      作者：MAYUR SHAH 来源：Devops.com　　各类企业都面临数字化转型和缩减 IT 预算的需求，低代码市场在全球范围内迅速崛起。即使越来越多的专业开发人员和公民开发人员采用低代码，我们还是会想到一个有趣的问题——低代码的前景如何？它能否成为现代开发团队的主流方法？　　答案很可能是——一个开源、低代码平台！它提供高生产力，同时支持与企业内现代软件开发实践的整体结构无缝集成。　　可以假设低代码演变为开放的低代码，而带来更大的创新和敏捷性。　　为了进一步理解这意味着什么，让我们深入研究一下。什么是开放系统？　　根据维基百科，开放系统是提供互操作性、可移植性和开放软件标准的某种组合的计算机系统。　　多年来，软件行业从设计、实施和使用开放系统中获益匪浅。TCP/IP 协议标准、UNIX 系统、Web 浏览器、REST API——所有这些都是开放标准的光辉例子，这些标准后来变得非常成功并被广泛采用。通过保持开放，它们实现了更高的互操作性、简化了开发并促进了快速创新。　　低代码现在处于其采用曲线的关键阶段。在过去的几年里，我们看到公民开发人员成功地使用低代码执行影子 IT，并以惊人的速度生产应用程序。如今，低代码平台已针对企业用途进行了强化，经过编程以了解复杂应用程序的可扩展性和安全性需求，并且具有足够成熟的集成功能以无缝适应现有工具和技术。　　因此，我们现在看到专业开发社区更多地采用低代码，涵盖从简单仪表板到复杂应用程序的各种用例。低代码下一个演变是它成为企业 IT 中的主流，并用于构建关键任务应用程序和系统。　　开放式低代码平台的案例　　现代软件开发团队中，开发人员的速度和组织敏捷性已成为高性能软件开发团队的关键基准，因为这些指标与业务绩效直接相关。根据麦肯锡的一份研究报告，在开发者速度得分方面处于前四分之一的团队的股东总回报高 60%，营业利润率高 20%。这样的团队可以更快地进行实验并毫不拖延地将代码发布到生产环境中。　　低代码应该对开发人员的工作实践和工作流程造成最小的干扰。此外，低代码可以与整个企业应用程序架构的结构无缝集成也很重要。如果低代码平台基于开放标准且灵活，那么企业应用程序基础架构的其余部分可以与其共存。　　是什么让低代码平台开放？　　以开发人员为中心的功能　　开发人员喜欢控制、灵活性和统一的体验。他们在坚持自己喜欢的语言、工具以及应用程序开发和交付工作流程方面感到很自在。一个提供生产力和同等灵活性的低代码平台，专注于构建健壮的企业架构，必将成为应用程序开发的未来。　　平台应专注于在应用程序生命周期的概念、设计、集成、开发和部署阶段提供统一的开发人员体验，采用现代、同类最佳和云原生的技术堆栈。同样重要的是，为开发人员提供一种轻松将任何外部创新引入低代码平台的方法。　　可视化、定制和所有权　　许多低代码平台不会生成 100% 的应用程序代码。此外，由专有平台生成的大部分代码也是专有的，并且经常保持隐藏状态，不易访问或扩展。　　生成基于开放标准的真实代码的平台是一笔巨大的财富，特别是对于构建复杂应用程序的专业开发人员而言，这些应用程序需要广泛的定制和与企业工具（安全、测试、调试、集成等）的深度集成。　　生成的代码应基于对开发人员友好、同类最佳的应用程序堆栈和标准设计模式。这样，应用程序团队将完全熟悉和理解代码。启用代码的完全导出允许团队拥有平台创建的代码。　　灵活的应用架构　　应用架构应该是松耦合的，支持可以独立构建、部署和扩展的微服务和微前端。这样，架构可以轻松支持云原生应用程序开发。　　此外，应用程序生命周期的所有其他方面都应允许即插即用功能。这包括但不限于插入自定义 UI 组件（小部件、模板）、自定义安全提供程序、自定义后端代码、日志框架、事件驱动系统等。即插即用模型确保开发团队可以集成为企业微调的自定义提供程序。　　现代发展最佳实践　　现代应用程序开发实践已经发展到允许团队更快地进行实验并以前所未有的速度将代码发布到生产中。性能和可扩展性方面的优化产生了可以支持数百万最终用户的应用程序。随着开发人员逐渐适应低代码，平台应在构建应用程序时与所有现代开发实践保持一致并实施。这个想法是为了最大限度地减少开发人员在实现低代码的过程中的摩擦，以便他们继续利用与复杂编程世界中相同的设计原则、应用程序工具和企业集成。　　基础设施即代码 (IaC)　　开发人员需要一种持续部署软件的方法，以便始终有一个应用程序版本可用于生产。低代码平台应支持 IaC 选项，因此生成的代码始终可以无缝部署在开发人员选择的基础架构上。平台应该集成到构建、测试和发布系统（例如版本控制系统、CI/CD、工件存储库、容器镜像存储库、Kubernetes 集群和公共或私有云实例）。这样，由低代码构建的工件就会持续集成并部署到企业的运营系统中。　　低代码正处于企业内部的转折点，因为它成为数字化转型和应用程序现代化的首选平台。这是低代码平台成为企业应用程序架构的关键组成部分的机会。开放的低代码方法将使应用程序开发团队能够从组织内流行的底层最佳实践中受益。　　低代码不仅仅是一种生产力工具；它有可能成为推动企业创新和业务敏捷性的技术和文化催化剂。　　- End -本文来源于网易号APICloud汤圆攻城狮原文链接：https://www.163.com/dy/article/GD5PJAGD0531OBOL.html

　1234<form>  <input name="name">  <input type="submit" value="提交"></form>以这种方式提交，input 值为22222222时，后面递交的url 就会变为localhost:3980/input.html?name=222222其中有些值得注意的细节：    设置type=submit后，输入控件会变成一个按钮，显示的文字为其value值，默认值是Submit。    form[method]默认值为GET，所以提交后会使用GET方式进行页面跳转。    input[type]默认值为text，所以第一个input显示为文本框。input其实是一个由输入控件改装过来的按钮，这源于Web早期的简陋设计。我们给它设置name便可以验证这一点：<input name='btn' value='提交' type='submit'>提交后的Url就会变为localhost:3980/input.html?name=222222&btn=提交注意其中的URL为/?key=foo&btn=ok。作为按钮的input控件同时被当做一个表单输入提交给了服务器。 它到底是交互控件还是数据控件呢？定位是有些不清晰。再加上它的样式难以定制、不可作为其他标签的容器， 所以建议不要用input作为表单提交按钮。注意：input的type属性还可以是button，这时它只是一个按钮，不会引发表单提交。2、button[tpe=submit]button的语义很明确，就是一个按钮不含数据，作用就是用户交互。但它也有type和value属性。 type的默认值是submit，所以点击一个button会引起表单提交：1234<form> <input name='key'> <button>确定</button></form>如果你在做IE浏览器的兼容，请记住button[type]在IE中的默认值是button，这意味着它只是一个按钮而不会引发表单提交。　　另外，我们通过设置元素内容的方式来指定button的文字。这意味着button是一个容器控件， 其中可以包含任意的HTML标签，同时样式更容易定制。这也是为什么Bootstrap 文档中大量使用button作为示例的原因之一。但是，button会很乱。button可以设置name和value。提交表单时，value会被作为表单数据提交给服务器。 在IE中，甚至会把button开始与结束标签之间的内容作为name对应的值提交给服务器。button和input的相似还不止于此，button也可以设置type=reset，此时点击按钮会导致表单被重置（这还挺有用的）。 w3school给出了如下的示例：123456<form action="form_action.asp" method="get"> First name: <input type="text" name="fname" /> Last name: <input type="text" name="lname" /> <button type="submit" value="Submit">Submit</button> <button type="reset" value="Reset">Reset</button></form>对于button就不多说了，建议用button作为交互用的按钮，来提交表单。同时请注意设置type=submit来兼容IE。回车键提交表单Enter键是可以提交表单的！但是你可能已经注意到了，并非所有的表单都可以用Enter键来提交。来看HTML2.0 标准：    When there is only one single-line text input field in a form, the user agent should accept Enter in that field as a request to submit the form.    当表单中只有一个单行的文本输入控件时，用户代理应当接受回车键来提交表单。“单行”指的是type为text而非textarea，显然在textarea中回车提交表单是怎样的难以接受。 其实在实践中，有多个单行的input也可以用Enter提交，比如登录页面。4.阻止表单提交阻止表单提交也是一个常见的话题，通常用于客户端的表单验证。通用的办法是设置onsubmit：1234<form onsubmit="return false;"> <input name='key'> <input value='ok' type='submit'></form>只需要在onsubmit的一系列语句最后返回false，便可以阻止它提交。 如果你希望调用一个方法来决定是否阻止提交，记得在此处返回方法的返回值：1234<form onsubmit="return false;"> <input name='key'> <input value='ok' type='submit'></form>

已经容器化的应用，想要进行微服务治理，但是又不想被任何框架绑定，怎么能够最小代价地具备微服务治理、灰度发布等能力呢？请参考附件文档，带您体验容器应用启用Istio容器服务网格（ASM），开启灰度发布/微服务治理历程。

　　最近复习了一遍Spring IOC容器的初始化过程，结合书籍《Spring源码深度解析》总结了一下，IOC容器的初始化过程，大概分为以下三点：1、定位资源：　　定位相关的配置文件，扫描相关注解2、加载资源：　　将配置信息加载到内存中3、注册：　　根据载入的配置信息，初始化对象，并将其装载至容器中POM文件<?xml version="1.0" encoding="UTF-8"?> <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd"> <modelVersion>4.0.0</modelVersion> <groupId>org.example</groupId> <artifactId>springTest</artifactId> <version>1.0-SNAPSHOT</version> <dependencies> <!-- https://mvnrepository.com/artifact/org.springframework/spring-context --> <dependency> <groupId>org.springframework</groupId> <artifactId>spring-context</artifactId> <version>5.0.2.RELEASE</version> </dependency> </dependencies> </project>测试代码public class ServiceB { public static void main(String[] args) { ApplicationContext context = new ClassPathXmlApplicationContext("spring.xml"); Object serviceA = context.getBean("serviceA"); System.out.println(serviceA); }xml配置<?xml version="1.0" encoding="UTF-8"?> <beans xmlns="http://www.springframework.org/schema/beans" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:context="http://www.springframework.org/schema/context" xmlns:cache="http://www.springframework.org/schema/cache" xmlns:p="http://www.springframework.org/schema/p" xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd http://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context.xsd http://www.springframework.org/schema/cache http://www.springframework.org/schema/cache/spring-cache.xsd"> <context:component-scan base-package="com.donkeys.spring"/> <bean id="serviceA" class="com.donkeys.spring.service.ServiceA"></bean> </beans>资源定位过程解析　　代码中，使用的是ClassPathXmlApplicationContext类去加载Sping的配置文件，所以先给出该类类图ClassPathXmlApplicationContext构造方法 public ClassPathXmlApplicationContext( String[] configLocations, boolean refresh, @Nullable ApplicationContext parent) throws BeansException { super(parent); //根据传入的配置文件名称，调用父类的setConfigLocations方法，解析配置文件路径, setConfigLocations(configLocations); //refresh = true //refresh() 方法会重启整个容器 if (refresh) { refresh(); } }　　构造方法中一共做了2件事，首先是设置配置文件的路径，然后对整个容器进行刷新。　　这里我们重点关注refresh()方法；进入refresh()方法AbstractApplicationContext类的refresh()方法@Override public void refresh() throws BeansException, IllegalStateException { synchronized (this.startupShutdownMonitor) { // Prepare this context for refreshing. //为刷新前做准备 prepareRefresh(); // Tell the subclass to refresh the internal bean factory. //获取IOC容器，这里就是处理资源定位以配置文件加载/注册的方法 ConfigurableListableBeanFactory beanFactory = obtainFreshBeanFactory(); // Prepare the bean factory for use in this context. prepareBeanFactory(beanFactory); try { // Allows post-processing of the bean factory in context subclasses. postProcessBeanFactory(beanFactory); // Invoke factory processors registered as beans in the context. invokeBeanFactoryPostProcessors(beanFactory); // Register bean processors that intercept bean creation. registerBeanPostProcessors(beanFactory); // Initialize message source for this context. initMessageSource(); // Initialize event multicaster for this context. initApplicationEventMulticaster(); // Initialize other special beans in specific context subclasses. onRefresh(); // Check for listener beans and register them. registerListeners(); // Instantiate all remaining (non-lazy-init) singletons. finishBeanFactoryInitialization(beanFactory); // Last step: publish corresponding event. finishRefresh(); } catch (BeansException ex) { if (logger.isWarnEnabled()) { logger.warn("Exception encountered during context initialization - " + "cancelling refresh attempt: " + ex); } // Destroy already created singletons to avoid dangling resources. destroyBeans(); // Reset 'active' flag. cancelRefresh(ex); // Propagate exception to caller. throw ex; } finally { // Reset common introspection caches in Spring's core, since we // might not ever need metadata for singleton beans anymore... resetCommonCaches(); } } }　　这里主要关注**obtainFreshBeanFactory()**方法/** * Tell the subclass to refresh the internal bean factory. * @return the fresh BeanFactory instance * @see #refreshBeanFactory() * @see #getBeanFactory() */ protected ConfigurableListableBeanFactory obtainFreshBeanFactory() { //刷新IOC容器 //这里使用了委派设计模式，父类定义了抽象的refreshBeanFactory方法，具体调用实现调用子类的refreshBeanFactory方法 refreshBeanFactory(); //获取一个新的容器 ConfigurableListableBeanFactory beanFactory = getBeanFactory(); if (logger.isDebugEnabled()) { logger.debug("Bean factory for " + getDisplayName() + ": " + beanFactory); } return beanFactory; }　　**obtainFreshBeanFactory()**方法总共干了2件事，　　重置容器，refreshBeanFactory()方法中会设置相关标志，清除旧的容器，同时为Spring上下文生成一个新的容器，获取一个新的容器AbstractRefreshableApplicationContext的refreshBeanFactory()方法　　下面我们进入**refreshBeanFactory()**方法/** * This implementation performs an actual refresh of this context's underlying * bean factory, shutting down the previous bean factory (if any) and * initializing a fresh bean factory for the next phase of the context's lifecycle. * 该方法会将之前的bean工厂全部关闭，并初始化一个全新的bean 工厂类 用于Spring 上下文的生命周期 * bean工厂就是IOC容器 */ @Override protected final void refreshBeanFactory() throws BeansException { //判断是否之前也有容器 //如果有就销毁掉 if (hasBeanFactory()) { destroyBeans(); closeBeanFactory(); } try { //创建一个新的工厂 DefaultListableBeanFactory beanFactory = createBeanFactory(); beanFactory.setSerializationId(getId()); customizeBeanFactory(beanFactory); //读取Bean对象的定义 //这里也是使用的委派设计模式 loadBeanDefinitions(beanFactory); synchronized (this.beanFactoryMonitor) { this.beanFactory = beanFactory; } } catch (IOException ex) { throw new ApplicationContextException("I/O error parsing bean definition source for " + getDisplayName(), ex); } }　　这里创建了新的容器工厂，同时将新的工厂传入了loadBeanDefinitions()方法中，下面来看一下在loadBeanDefinitions方法中具体做了什么操作。AbstractXmlApplicationContext的 loadBeanDefinitions(DefaultListableBeanFactory beanFactory)方法　　在AbstractRefreshableApplicationContext类的refreshBeanFactory方法中，调用了loadBeanDefinitions方法，但是这个方法它的一个抽象方法，具体实现应由子类去实现，我们在程序启动时，使用的ClassPathXmlApplicationContext类。根据文章开头的类图可以知道，这里会调用子类AbstractXmlApplicationContext的loadBeanDefinitions方法去完成本次加载@Override protected void loadBeanDefinitions(DefaultListableBeanFactory beanFactory) throws BeansException, IOException { // Create a new XmlBeanDefinitionReader for the given BeanFactory. //使用默认的beanFactory去创建 XmlBeanDefinitionReader XmlBeanDefinitionReader beanDefinitionReader = new XmlBeanDefinitionReader(beanFactory); // Configure the bean definition reader with this context's // resource loading environment. //设置资源的加载环境 beanDefinitionReader.setEnvironment(this.getEnvironment()); //设置资源读取器 beanDefinitionReader.setResourceLoader(this); //设置实体解析器 beanDefinitionReader.setEntityResolver(new ResourceEntityResolver(this)); // Allow a subclass to provide custom initialization of the reader, // then proceed with actually loading the bean definitions. //初始化 bean对象定义读取器 initBeanDefinitionReader(beanDefinitionReader); //使用初始化完成的读取器，调用loadBeanDefinitions方法 loadBeanDefinitions(beanDefinitionReader); }　　总的来说，这里只干了一件事，那就是初始化配置//设置资源读取器 beanDefinitionReader.setResourceLoader(this); //初始化 bean对象定义读取器 initBeanDefinitionReader(beanDefinitionReader);　　设置资源读取器，这里设置的资源读取器就是当前这个对象本身　　通过类图我们可以发现我们这个类的顶级父类ApplicationContext，继承自DefaultResourceLoader这个类，该类实现了ResourceLoader接口，说明这个类的实例化对象本身是具有资源读取器的功能的　　初始化bean对象定义读取器，这里设置xml文件的校验方式　　下面我们继续看**loadBeanDefinitions(XmlBeanDefinitionReader reader)**方法protected void loadBeanDefinitions(XmlBeanDefinitionReader reader) throws BeansException, IOException { //从子类对象中获取到资源定位 Resource[] configResources = getConfigResources(); if (configResources != null) { //XmlBeanDefinitionReader 读取器调用其父类的 reader.loadBeanDefinitions(configResources); } String[] configLocations = getConfigLocations(); if (configLocations != null) { reader.loadBeanDefinitions(configLocations); } }　　先看这一行//这行代码的具体实现是由子类完成的，通过类图可以知道AbstractXmlApplicationContext的子类为ClassPathXmlApplicationContext //这里主要将我们最开始在构造方法中设置好的配置文件进行返回 Resource[] configResources = getConfigResources();　　再看这一行//如果返回的配置文件不为空，就将返回的已经封装好的资源文件进行读取， if (configResources != null) { //XmlBeanDefinitionReader 读取器调用其父类的 reader.loadBeanDefinitions(configResources); }　　至此。资源文件定位过程已经加载完成。后续就是读取和注册。整个IOC容器加载过程中最重要的是读取过程，我们可以从刚刚的定位过程来看，虽然叫定位过程，但是其实就是一个配置文件读取器的初始化过程，这个过程会设置相关的解析策略以及校验策略。最终读取器生成后，就可以将我们早早设置好的配置文件载入然后进行读取。————————————————

运行容器（1）运行Nginx应用运行Nginx应用。[root@master ~]# cat nginx.yamlapiVersion: apps/v1 kind: Deployment metadata:   name: nginxspec:  replicas: 1   selector:     matchLabels:       app: nginx  template:     metadata:      labels:         app: nginx    spec:       containers:      - name: nginxapp-container        image: nginx:latest        imagePullPolicy: IfNotPresent        ports:         - name: nginxapp          containerPort: 80[root@master ~]# kubectl create -f nginx.yamldeployment.apps/nginx created（2）查看Pods验证Pods是否正常运行。[root@master ~]# kubectl get podsNAME                    READY   STATUS    RESTARTS   AGEnginx-75dcbbc897-c4xbp        1/1       Running    0            93s……（3）开放端口使用expose将service的80端口开放出去。[root@master ~]# kubectl expose deploy/nginx --port 80service/nginx exposed（4）测试Nginx应用[root@master ~]# kubectl get svcNAME         TYPE        CLUSTER-IP     EXTERNAL-IP   PORT(S)   AGEkubernetes       ClusterIP     10.96.0.1         <none>        443/TCP   3h18mnginx           ClusterIP     10.100.220.6      <none>        80/TCP    9s[root@master ~]#  curl 10.100.220.6:80……<h1>Welcome to nginx!</h1><p>If you see this page, the nginx web server is successfully installed andworking. Further configuration is required.</p><p>For online documentation and support please refer to<a href="http://nginx.org/">nginx.org</a>.<br/>Commercial support is available at<a href="http://nginx.com/">nginx.com</a>.</p><p><em>Thank you for using nginx.</em></p></body></html>使用curl工具可以成功获取到Nginx网页信息，说明80端口已开放成功。3.3.Kubernetes运维（1）Node的隔离与恢复在硬件升级、硬件维护等情况下，需要将某些Node隔离。使用kubectl cordon <node_name>命令可禁止Pod调度到该节点上(单节点不需执行)，在其上运行的Pod并不会自动停止，管理员需要手动停止在该Node上运行的Pod。[root@master ~]# kubectl cordon node查看Node的状态，可以观察到在node的状态中增加了一项SchedulingDisabled，对于后续创建的Pod，系统将不会再向该Node进行调度。[root@master ~]# kubectl get nodes通过kubectl uncordon命令可完成对Node的恢复。[root@master ~]# kubectl uncordon node[root@master ~]# kubectl get nodes可以看到Node节点已恢复调度，允许Pod调度到该节点上。通过kubectl drain <node>命令可实现对node节点的驱逐，该命令会删除该节点上的所有Pod（DaemonSet除外），在其他Node上重新启动它们。（2）Pod动态扩容和缩放在实际生产系统中，经常会遇到某个服务需要扩容的场景，也可能会遇到由于资源紧张或者工作负载降低而需要减少服务实例数量的场景。此时可以利用kubectl scale deployment命令来完成这些任务。通过执行下面的命令将Nginx Deployment控制的Pod副本数量从初始的1更新为5。[root@master ~]# kubectl scale deployment nginx --replicas=5deployment.extensions/nginx scaled执行kubectl get pods命令来验证Pod的副本数量增加到5。[root@master ~]# kubectl get podsNAME                    READY   STATUS    RESTARTS   AGEnginx-ccb467dc5-2f6n2   1/1     Running   0          34s......将--replicas设置为比当前Pod副本数量更小的数字，系统将会“杀掉”一些运行中的Pod，即可实现应用集群缩容。[root@master ~]# kubectl scale deployment nginx --replicas=2deployment.extensions/nginx scaled[root@master ~]# kubectl get podsNAME                    READY   STATUS    RESTARTS   AGEnginx-ccb467dc5-bl4jp   1/1     Running   0          2m50snginx-ccb467dc5-jlr4c   1/1     Running   0          5m21s（3）应用滚动升级当集群中的某个服务需要升级时，需要停止目前与该服务相关的所有Pod，然后重新拉取镜像并启动。如果集群规模比较大，这个工作就变成了一个挑战。如果采取先全部停止，然后逐步升级的方式，会导致较长时间的服务不可用。Kubernetes提供了rolling-update（滚动升级）功能来解决上述问题。滚动升级通过执行kubectl rolling-update命令一键完成，该命令创建了一个新的Deployment，然后自动控制旧的Deployment中的Pod副本数量逐渐减少到0，同时新的Deployment中的Pod副本数量从0逐步增加到目标值，最终实现了Pod的升级。注意：系统要求新的Deployment需要与旧的Deployment在相同的命名空间（Namespace）内，即不能把别人的资产偷偷转移到自家名下。下面的示例在第一次部署时使用httpd:2.2.31，然后使用滚动升级更新到httpd:2.2.32。定义httpd.yaml文件。[root@master ~]# cat httpd.yamlapiVersion: apps/v1kind: Deploymentmetadata:  name: httpdspec:  selector:     matchLabels:       app: httpd  replicas: 3  template:    metadata:      labels:        app: httpd    spec:      containers:        - name: httpd          image: httpd:2.2.31          imagePullPolicy: IfNotPresent          ports:            - containerPort: 80启动Deployment。[root@master ~]# kubectl create -f httpd.yaml deployment.apps/httpd created[root@master ~]# kubectl get podsNAME                     READY   STATUS    RESTARTS   AGEhttpd-5ddb558f47-46tf5   1/1     Running   0          49shttpd-5ddb558f47-5dg96   1/1     Running   0          49shttpd-5ddb558f47-672sk   1/1     Running   0          49s查看Deployment。[root@master ~]# kubectl get deployments httpd -o wideNAME READY UP-TO-DATE AVAILABLE AGE CONTAINERS IMAGES SELECTORhttpd    3/3      3           3        93s    httpd     httpd:2.2.31  run=httpd可以看到，IMAGES为httpd:2.2.31。把配置文件中的httpd:2.2.31改为httpd:2.2.32，再次启动。[root@master ~]# cat httpd.yaml apiVersion: apps/v1kind: Deploymentmetadata:  name: httpdspec:  selector:     matchLabels:       app: httpd  replicas: 3  template:    metadata:      labels:        app: httpd    spec:      containers:        - name: httpd          image: httpd:2.2.32          imagePullPolicy: IfNotPresent          ports:            - containerPort: 80[root@master ~]# kubectl apply -f httpd.yamlWarning: kubectl apply should be used on resource created by either kubectl create --save-config or kubectl applydeployment.apps/httpd configured再次查看Deployment。[root@master ~]# kubectl get deployments httpd -o wideNAME READY UP-TO-DATE AVAILABLE AGE CONTAINERS IMAGES SELECTORhttpd    3/3      3       3            7m53s   httpd   httpd:2.2.32  run=httpd查看Deployment的详细信息。[root@master ~]# kubectl describe deployment httpd…...Events:  Type    Reason             Age   From                   Message  ----    ------             ----  ----                   -------  Normal  ScalingReplicaSet  22m   deployment-controller  Scaled up replica set httpd-5ddb558f47 to 3  Normal  ScalingReplicaSet  15m   deployment-controller  Scaled up replica set httpd-8bdffc6d8 to 1  Normal  ScalingReplicaSet  14m   deployment-controller  Scaled down replica set httpd-5ddb558f47 to 2  Normal  ScalingReplicaSet  14m   deployment-controller  Scaled up replica set httpd-8bdffc6d8 to 2  Normal  ScalingReplicaSet  14m   deployment-controller  Scaled down replica set httpd-5ddb558f47 to 1  Normal  ScalingReplicaSet  14m   deployment-controller  Scaled up replica set httpd-8bdffc6d8 to 3  Normal  ScalingReplicaSet  13m   deployment-controller  Scaled down replica set httpd-5ddb558f47 to 0上面的日志信息就描述了滚动升级的过程：① 启动一个新版Pod。② 把旧版Pod数量降为2。③ 再启动一个新版，数量变为2。④ 把旧版Pod数量降为1。⑤ 再启动一个新版，数量变为3。⑥ 把旧版Pod数量降为0。这就是滚动的意思，始终保持副本数量为3，控制新旧Pod的交替，实现了无缝升级。kubectl apply每次更新应用时，kubernetes都会记录下当前的配置，保存为一个revision，这样就可以回滚到某个特定的版本。创建3个配置文件，内容中唯一不同的就是镜像的版本号。httpd.v1.yaml：[root@master ~]# cat httpd.v1.yaml apiVersion: apps/v1kind: Deploymentmetadata:  name: httpdspec:  selector:     matchLabels:       app: httpd  revisionHistoryLimit: 10 # 指定保留最近的几个revision  replicas: 3  template:    metadata:      labels:        app: httpd    spec:      containers:        - name: httpd          image: httpd:2.2.31          ports:            - containerPort: 80httpd.v2.yaml：[root@master ~]# cat httpd.v2.yaml apiVersion: apps/v1kind: Deploymentmetadata:  name: httpdspec:  selector:    matchLabels:       app: httpd  revisionHistoryLimit: 10 # 指定保留最近的几个revision  replicas: 3  template:    metadata:      labels:        app: httpd    spec:      containers:        - name: httpd          image: httpd:2.2.32          ports:            - containerPort: 80部署Deployment。[root@master ~]# kubectl apply -f httpd.v1.yaml --recorddeployment.apps/httpd configured[root@master ~]# kubectl apply -f httpd.v2.yaml --recorddeployment.apps/httpd configured--record的作用是将当前命令记录到revision中，可以知道每个revision对应的是哪个配置文件。查看Deployment。[root@master ~]# kubectl get deployments -o wideNAME READY UP-TO-DATE AVAILABLE AGE CONTAINERS IMAGES SELECTORhttpd    3/3        1           3      31m      httpd   httpd:2.2.32 app=httpd查看revision历史记录。[root@master ~]# kubectl rollout history deployment httpddeployment.apps/httpd REVISION  CHANGE-CAUSE1         <none>2         kubectl apply --filename=httpd.v2.yaml --record=trueCHANGE-CAUSE即-record的结果。执行如下操作，回滚到指定版本revision 1。[root@master ~]# kubectl rollout undo deployment httpd --to-revision=1deployment.extensions/httpd rolled back[root@master ~]# kubectl get deployments -o wideNAME READY UP-TO-DATE AVAILABLE AGE CONTAINERS IMAGES SELECTORhttpd    3/3       3            3      35m     httpd    httpd:2.2.31 app=httpd再次查看Deployment可以看到httpd版本已经回退了。查看revision历史记录，可以看到revision记录也发生了变化。[root@master ~]# kubectl rollout history deployment httpddeployment.extensions/httpd ......

尊敬的合作伙伴：       您好，请从support网站下载最新的《边缘计算二次开发指南》，该脚本同最新的文档一起更新，本帖将不再更新，谢谢。502H：cid:link_0T2：cid:link_1AR-CORE：cid:link_2T1由于开源社区不再维护Debian 8，请使用T2系列的《二次开发指南》制作debian10的32位容器以及app

这段时间一直困在k8s的深坑里，部署k8s并不困难，但是之后的运行却是反反复复的遇到各种故障。总结一下k8s故障排查的途径：kubectl describe pod/deployment/service 查看pod/deployment/service的基本信息，会有少量的出错信息，找到后用做关键字搜下，就能滤掉一波故障。tailf /var/log/messagesjournalctl -f -u kubelet查看各个组件运行的最新日志，同样，找到报错关键字搜资料。kubectl logs  <pod> -c <contrainer>进入容器查看容器的日志，这个途径有局限，就是pod上的容器必须已经跑起来了，但是大部分故障是跑不起来。kubectl get <pod> -o yaml这条命令，个人理解是把运行的pod生成一个容器。

InitContainers是一种专用的容器，在应用程序容器启动之前运行，可以包括一些应用程序镜像中不存在的实用工具和安装脚本，可以完成应用的必要数据初始化等工作。总的来说就是在正式的容器启动之前做一些准备工作的。挂接的volum/file等等，是容器内外交换信息的工具，而InitContainer可以视为一个在容器胜生成之前的信息灌入的流程。顾名思义,InitContainers用于初始化工作,执行完就结束,为一次性的任务。IniteContainers支持大部分应用容器配置,但不支持健康检查。应用场景：环境检查:例如确保应用容器依赖的服务启动后再启动应用容器初始化配置（给应用容器准备配置文件）示例:部署一个web网站,网站程序没有打到镜像中,而是希望从代码仓库中动态拉取放到应用容器中。root@ecs-beijing1:~# vi pod-initcontainer.yaml              ---apiVersion: v1kind: Podmetadata: name: init-demospec: initContainers:   - name: download     image: busybox     command:       - wget       - "-0"       - "/opt/index.html"       - http://www.ctnrs.com     volumeMounts:       - name: wwwroot         mountPath: "/opt" containers:   - name: nginx     image: nginx     ports:       - containerPort: 80     volumeMounts:       - name: wwwroot         mountPath: /usr/share/nginx/html volumes:  - name: wwwroot    emptyDir: {}"pod-initcontainer.yaml" 28L, 504C written                                                                         root@ecs-beijing1:~# kubectl apply -f pod-initcontainer.yamlpod/init-demo createdroot@ecs-beijing1:~# kubectl get podNAME        READY   STATUS     RESTARTS   AGEinit-demo   0/1     Init:0/1   0          33sroot@ecs-beijing1:~# kubectl exec -it init-demo --bashroot@init-demo:~#cd /usr/share/nginx/html root@init-demo:/usr/share/nginx/html# lsindex.htmlroot@init-demo:/usr/share/nginx/html# cat index.html.....    <script src="/js/jquery.min.js"></script><script src="/js/feather.min.js"></script><script src="/js/fresh.js"></script><script src="/js/jquery.panelslider.min.js"></script><script src="/js/modernizr.min.js"></script>  </body></html>页面已经下载到容器里面了。

背景：对于A500而言，老架构与新架构的镜像打包流程有较大差异，客户/FAE在进行镜像构建时会存在疑惑目标：总结指导文档，在A500小站上进行镜像构建及容器部署固件包：A500-3000-3010-firmware_20.1.0.zipNNRT包：A500-3000-nnrt_20.1.rc1_linux-aarch64.run 1.       前期准备在进行镜像构建前，需要确定固件版本，根据固件的版本选择对应nnrt离线推理包1）  确定固件版本第一种方法：参考support指南，登录WebUI确定小站固件版本：第二种方法：进入develop开发者模式，通过命令npu-smi info查询固件版本：ssh admin@小站IP           —— 进入IES命令行界面develop     ——进入开发者模式npu-smi info      ——查询固件版本2）  软件包及脚本准备对于新架构A构建镜像前，需要准备好nnrt软件包、Dockerfile、业务程序压缩包以及脚本，然后把准备好的材料上传至小站上。上传之前建议检查下小站磁盘空间是否足够，如下图：本案例所使用文件如下：A500-3000-nnrt_20.1.rc1_linux-aarch64.run -- 推理业务需要用到里面的acllib库dist.tar -- 存放推理业务的执行文件、配置文件，本案例存放resnet50分类推理执行程序Dockerfile -- 镜像构建文本文件install.sh -- 解压dist.tar，进行一些权限、目录的设置run.sh -- docker拉起后运行的脚本，执行推理业务程序注： Dockerfile、install.sh、run.sh的书写要求及参考->官方文档 2.       构建镜像本案例中所用基础镜像是ubuntu18.04-arm64，如果小站没连外网，先下好离线包进行加载：docker load -i ubuntu18.04_arm_base.tar构建业务镜像：docker build -t test:v20.1 --build-arg NNRT_PKG=A500-3000-nnrt_20.1.rc1_linux-aarch64.run --build-arg DIST_PKG=dist.tar .-t        指定镜像名字及标签--build-arg          Dockerfile变量传参docker images3.       验证镜像docker run -it -d \--device=/dev/davinci0 --device=/dev/davinci_manager --device=/dev/hisi_hdc --device /dev/devmm_svm \-v /usr/local/bin/npu-smi:/usr/local/bin/npu-smi \-v /var/log/npu/conf/slog/slog.conf:/var/log/npu/conf/slog/slog.conf \-v /home/data/miniD/driver/lib64:/home/data/miniD/driver/lib64 \-v /home/data/miniD/driver/add-ons:/home/data/miniD/driver/add-ons \-v /home/data/miniD/driver/tools:/home/data/miniD/driver/tools \-v /home/log:/home/log/ \-v /opt/dk_test/resnet50_aipp.om:/home/model/resnet50_aipp.om \ test:v20.1黄色：NPU驱动相关库及工具绿色：本案例会把推理结果记录在/home/log/log.txt日志下蓝色：模型文件紫色：镜像名及标签注：挂载目录根据实际业务情况而定，但如果用到小站上的芯片，必须把黄色目录挂载进容器可以看到docker已经起来了，再看/home/log/log.txt文件得到推理结果：4.       导出镜像查看镜像ID或名称：docker images必须根据镜像的REPOSITORY、TAG进行保存：docker save test:v20.1 | gzip > test.tar.gz5.       web部署镜像登录WebUI界面，进入管理->服务软件界面：开始创建服务实例：（官方文档）名称（服务实例的名称）、容器镜像文件、是否校验镜像（一般选否）、附加配置文件（可以放模型及配置文件）、内存（默认限制500M）、AI算力（勾上代表使用NPU）挂载目录设置：本地卷名称——用户自定义，名称合法即可挂载点——选择HostPath，对应docker run命令的-v参数主机挂载点——主机挂载目录必须在白名单内，白名单路径：    /opt/middleware/AtlasEdge/software/edge_core/conf/podconfig.json容器挂载目录——自定义容器内挂载的目录权限——根据需求进行权限分配容器端口映射及权限设置：

原作者： FutureCity原文链接：https://bbs.huaweicloud.com/blogs/2669891 业务场景普惠金融是行业热门课题，近几年央行政策支持中小微企业发展（特别是制造业），银行也把该方向作为业务拓展重点。但小微企业的信用评估是一个难点，小微企业一般都没有大额固定资产作授信抵押，银行也缺少高质量的数据作为评价依据，小微企业的贷款普遍存在难度大、周期长、额度低等问题。政府拥有小微企业多维度的数据，如纳税、社保、用水用电等，信用评估价值高，受限于政府网络和数据安全管理要求，政府数据不能直接提供给银行。那么，有没有一种方式，在不共享数据的情况下，实现数据的分析应用，即数据可用不可见。数据隐私计算技术，可用于满足该场景需求，如华为云可信智能计算服务 TICS (Trusted Intelligent Computing Service)，提供跨组织数据安全共享方案，政府无须将数据提供给银行，银行基于 TICS 的安全计算环境，运行数据分析模型，获取业务所需的分析结果。2 方案架构以政府和银行小微企业数据共享场景为例，政府数据部署在华为云数据库服务 RDS，银行数据存储在本地数据中心的 Mysql Server，通过边缘节点 IEF Edge Node 接入。TICS 服务同时支持云、边两种数据接入方式，基于华为云边缘服务 IEF 实现 TICS Agent 的远程部署和持续更新。TICS 可信聚合计算通过 TICS AGG 节点实现，AGG 提供基于 TEE 或 SGX 两种硬件隐私计算环境，也支持半同态加密、差分隐私等软件类的隐私计算能力，适用于联邦数据分析（基于标准 SQL）与联邦学习等业务场景。本方案架构设计参考下图：银行本地数据中心接入公网，有 3 种方式，不同方式下 IEF Agent 的接入配置要求说明如下：无网络限制的透明代理（ NAT 网关）透明代理的工作方式类似于 NAT 网关，银行内网服务器的数据包默认全部发送给透明代理（作为网关），透明代理再将数据包转发给外网访问地址，内网应用感知不到代理的存在，故称为透明代理。该方式边缘节点的接入配置最简单，只需完成 IEF Agent 的标准配置即可，参考链接 IEF 边缘节点注册与纳管 。带网络限制的透明代理（ NAT 网关）该方式下，银行对访问公网有网络限制，需要根据域名 / IP 地址和端口号，开通网络权限。需要放通的网络权限，参考 开通外网访问权限。带网络限制的普通代理和透明代理不同，普通代理是一个独立服务器，内网应用须配置代理访问地址，确保访问外网的数据包先发给代理，再由代理转发外网目的地址。本文介绍的最佳实践配置，主要针对最复杂的第 3 种场景：带网络限制的普通代理，如 squid 上网代理（其他类型的代理配置类似）。普通代理工作在 TCP/IP 协议应用层，代理的配置在应用级别生效，而非操作系统级别，本地服务器中的不同应用程序，均须添加代理配置，这一点尤其要注意。上图名词解释：TICS Service: 华为云 可信智能计算服务 管理节点，提供数据联盟管理、用户权限配置、代理管理等功能TICS AGG: TICS Aggregation Node 可信计算聚合节点，多方数据的融合计算在该节点完成TICS Agent: TICS 代理，提供数据接入管理、安全隐私规则配置、数据分析和联邦学习任务运行等功能，是 TICS 服务业务操作的关键组件，每个 TICS 数据联盟的参与方可拥有 1 个或多个 TICS AgentSWR: 华为云 容器镜像服务 Software Repository for Container，用于 IEF Agent 边缘容器镜像管理IEF Service: 华为云 边缘计算服务 Intelligent Edge Fabric 管理节点，负责边缘节点创建、管理和边缘容器应用同步操作等Edge Node: 部署 IEF Agent 的边缘节点，一般是一台硬件服务器或虚拟机IEF Agent: 部署在 Edge Node 上的边缘节点管理软件，负责与云端 IEF Service 进行通信，管理本地运行的边缘容器实例如 TICS Agent，支持实例更新、状态监控、日志管理等功能CCE: 华为云 云容器引擎 Cloud Container Engine，云上托管的 Kubernetes 集群，在本案例中，用于政务 TICS Agent 代理的部署CCE Node: CCE 节点即 Kubernetes 节点，是云端的一台虚机或裸金属服务器POD: Kubernetes 集群运行计算任务的最小单位，本案例用于部署政府侧的 TICS Agent，是 1 个或多个容器的集合，参考 POD 名词解释RDS: 华为云 托管 Mysql 数据库，本案例用于存储政务共享数据NAT: 网络地址转换网关 Network Address Translation，用于内外网通信转接，内网访问外网的网络流量均重定向到 NAT 网关，再转发给外网目的地址3 前置条件3.1 开通外网访问权限银行本地边缘节点，访问公有云的 IEF 和 TICS 服务，须开通以下网络端口：目的 IP 地址访问域名目的端口用途119.3.227.164ief2-placement.cn-north-4.myhuaweicloud.com443边缘计算 IEF 服务端49.4.115.239ief2-edgeaccess.cn-north-4.myhuaweicloud.com443边缘计算 IEF 连接网关119.3.215.28ief2-telemetry.cn-north-4.myhuaweicloud.com8065/8102/8149边缘计算 IEF 日志与计量端口49.4.112.92ief2-software-north-4.obs.cn-north-4.myhuaweicloud.com443边缘容器镜像存储49.4.112.18swr.cn-north-4.myhuaweicloud.com443容器镜像管理服务接口49.4.112.6tics.cn-north-4.myhuaweicloud.com443TICS 服务端接口49.4.112.113obs.cn-north-4.myhuaweicloud.com443OBS 服务接口139.9.118.165无域名访问地址30001~30016TICS 聚合计算节点 AGG 端口以上网络配置基于华为云北京四 Region，其他 Region IP 地址和域名均不同，须进行相应调整。参考链接 获取 IEF 云端服务 IP 地址3.2 注册华为云账号TICS 服务同一数据联盟参与方可以进行数据共享，数据联盟每个参与方都是华为云租户，因此使用 TICS 服务必须先注册华为云账号。登录 华为云官网 即可完成账号注册。3.3 申请 TICS 服务公测TICS 服务目前处于受邀公测阶段，请登录华为云 TICS 服务 ，点击 “立即体验” 按钮，即可申请公测。公测申请提交后，华为云 TICS 服务管理人员将在约 1~2 天内完成审批。3.4 加入 TICS 服务联盟任何华为云账号均可发起创建 TICS 数据联盟，公测阶段资源有限，建议参与测试的用户优先加入现有数据联盟。用户将华为云账号提供给 TICS 服务管理员（可通过华为云销售获取联系方式），由 TICS 服务管理员将账号加入到数据联盟。华为云账号格式一般为 hwxxxxxxxx (hw 加 8 位数字)，登录华为云账号中心即可查看。TICS 服务管理员将账号添加到数据联盟后，用户将在 TICS 服务 “通知管理”模块收到加入数据联盟申请，选择同意即可加入该数据联盟。3.5 准备华为云费用银行采用边缘服务方式接入华为云，涉及一定的华为云费用。边缘节点部署 IEF Agent 是免费的，在 IEF Agent 运行容器实例需要收费，收费标准参考链接 IEF 服务定价。TICS Agent 部署在边缘节点上需要一个容器实例，费用为 1099 ￥/月/实例。用户可自行充值华为云账号完成测试，也可联系华为云销售申请华为云测试券，覆盖测试所需费用。注：完成实名认证的企业账号才能申请测试券，请登录华为云官网 账号中心>实名认证，参考 实名认证操作指南 完成认证。3.6 准备 IEF 边缘节点边缘节点是部署在银行本地数据中心的服务器或虚拟机，支持 X86 和鲲鹏 ARM 架构，推荐配置如下：操作系统：CentOS 7.6硬件配置：cpu >= 8 core，内存 >= 16G环境依赖：docker 18.06.3 版本IEF 边缘节点须具备外网访问权限，和云端互动时，均由边缘节点发起访问，因此边缘节点无需独立公网 IP 地址。更多边缘节点规格要求，参考 配置边缘节点环境 。4 部署 IEF Agent在边缘节点上部署 IEF Agent，须先登录华为云 IEF 服务控制台 ，选择功能模块 边缘资源>边缘节点，点击红色按钮 “注册边缘节点”，根据提示，下载边缘节点安装程序 edge-installer_1.0.0_x86_64.tar.gz 和配置文件 ief-node.tar.gz (ief-node 是节点名称)，导入到边缘节点服务器。参考下面配置，在普通代理上网的环境下，完成 IEF Agent 部署和云端纳管。以 sudo 权限登录边缘节点执行如下命令解压软件包到 /opt 文件夹sudo tar -zxvf edge-installer_1.0.0_x86_64.tar.gz -C /opt解压配置文件到 /opt/IEF/Certsudo mkdir -p /opt/IEF/Cert sudo tar -zxvf 边缘节点名称.tar.gz -C /opt/IEF/Cert配置 IEF Agent 外网访问代理vi /opt/IEF/Cert/user_config http_proxy=proxy_ip:proxy_port # proxy_ip 和 proxy_port 请修改为现网的代理 IP 地址和端口号，下同 https_proxy=proxy_ip:proxy_port安装 IEF Agentcd /opt/edge_installer sudo ./installer -op=install验证边缘节点是否纳管成功登录华为云 IEF 服务控制台 边缘资源>边缘节点，查看新建边缘节点的运行状态，“运行中”表示纳管成功。更多相关配置参考 IEF 边缘节点注册与纳管。5 部署 TICS AgentTICS Agent 是部署在 边缘节点上的一个容器实例，登录华为云 TICS 服务控制台，即可发起创建 TICS Agent，华为云 IEF 服务会负责将 TICS Agent 的容器镜像（保存在 SWR 上）同步到边缘节点，完成 TICS Agent 的部署操作。参考下面配置，完成 TICS Agent 在边缘节点上的部署：配置 docker 外网访问代理从云端获取 TICS Agent的容器镜像将执行 docker pull 操作，须配置 docker 的访问代理，否则将导致镜像获取失败。sudo mkdir -p /etc/systemd/system/docker.service.d vi /etc/systemd/system/docker.service.d/http-proxy.conf [Service] Environment="HTTP_PROXY=proxy_ip:proxy_port" # proxy_ip 和 proxy_port 请修改为现网的代理 IP 地址和端口号，下同 Environment="HTTPS_PROXY=proxy_ip:proxy_port" :wq # 保存文件 # 重启 docker sudo systemctl daemon-reload sudo systemctl restart docker获取华为云账号 AK/SK访问密钥 AK/SK Access Key ID/Secret Access Key 包含访问密钥ID（AK）和秘密访问密钥（SK）两部分，是华为云账号的长期身份凭证，TICS Agent 代理部署须配置 AK/SK 信息，授予代理接入权限。AK/SK 登录华为云官网 账号中心>基本信息>管理我的凭证>访问密钥，点击“新增访问密钥”，即可下载访问密钥，文件名为 credentials.csv。详细操作指南参考 访问密钥 。注：访问密钥生成后，只能下载一次，请妥善保管。下载TICS Agent 配置登录华为云控制台 TICS 服务，选择 通知管理>下载代理配置，保存至本地，解压后得到 3 个文件，在下一步创建 TICS Agent 代理中会用到agent.p12 - 联盟配置tics_league_datacloud.json - 代理密钥truststore.jks - CA 证书创建 TICS Agent登录华为云控制台 TICS 服务，选择 代理管理>部署代理，在部署代理页面，依次完成以下操作：导入联盟配置 agent.p12上传文件 代理密钥 tics_league_datacloud.json上传文件 CA 证书 truststore.jks导入当前账号 AK/SK credentials.csv配置代理登录密码，该密码请注意保存，后面和代理登录账号 admin 一起用于代理管理页面的登录选择 IEF 边缘节点部署，纳管节点选择已创建好的 IEF 边缘节点主机路径配置边缘节点上数据保存路径，如 /home/tics，须确保该路径已创建且具备写权限点击 “立即创建” 按钮，完成代理创建操作配置 TICS Agent 外网访问代理TICS Agent 通过 java sdk 与华为云 TICS AGG 进行通信，须配置 java 访问外网的代理配置，确保与 AGG 通信正常。以 sudo 权限登录边缘节点，执行以下命令：docker ps # 查看 docker 容器实例 docker exec -ti xxxx /bin/bash # xxxx 对应 tics 容器实例 id vi /etc/hosts # 配置容器实例内部 TICS 服务域名解析 49.4.112.6 tics.cn-north-4.myhuaweicloud.com hostname # 获取当前主机名，后面配置将用到 vi /opt/cloud/tics/tics-agent-console/bin/common.sh JAVA_OPTS="-Dhttps.proxyHost=proxy_ip -Dhttps.proxyPort=proxy_port -Dhttp.nonProxyHosts=当前主机名" # proxy_ip 和 proxy_port 请修改为现网的代理 IP 地址和端口号，下同 :wq # 重启服务，使配置生效 su service sh stop.sh sh start.sh & vi /opt/cloud/tics/tics-agent-web/bin/common.sh JAVA_OPTS="-Dhttps.proxyHost=proxy_ip -Dhttps.proxyPort=proxy_port -Dhttp.nonProxyHosts=当前主机名" :wq # 重启服务，使配置生效 su service sh stop.sh sh start.sh &验证 TICS Agent 是否部署成功登录华为云控制台 TICS 服务，选择 代理管理，点击代理名进入代理管理页面，点击代理登录地址 “前往代理Agent”，打开代理登录界面，输入步骤 4 中的代理用户名 Admin 与代理登录密码，完成代理登录。登录代理页面后，查看右上角的状态符号，显示为绿色，则表示代理通信正常，代理部署成功。注：边缘节点部署方式下，TICS Agent 代理登录 IP 地址为内网 IP 地址，请确保测试使用的 PC 或笔记本，与 TICS Agent 内网网络连通性。

4月24日-26日，华为开发者大会2021（Cloud）在全国36座城市、63个线下分会场同步启，旨在汇聚业界大咖、华为科学家、顶级技术专家、天才少年和众多开发者，搭建一个全球性的交流和实践平台，共同探讨和分享最新的ICT技术在行业的深度创新和应用。作为互联网之都，杭州近年来一直在国内数字化、信息化产业中占据着龙头地位，并保持着高速、健康的发展态势，被业内誉为“数字经济第一城”。在杭州的发展过程中，华为一直在不遗余力地通过校企合作等方式添砖加瓦。本次华为开发者大会2021（Cloud）分会场走进了杭州电子科技大学，与高校师生围绕产业创新和鲲鹏生态、技术开源等展开了深入的探讨和学习。会上，杭州电子科技大学校团委副书记杨乐发表讲话。在讲话中杨乐谈到：ICT大大改变了人们的工作、沟通、学习和生活方式。未来，联接、AI、云、计算、行业应用等多种先进技术和机会互相催化、有机融合，必将催生大量的技术创新和应用创新，为社会发展开启了充满想象的广阔前景。杭州电子科技大学将与华为携手，保持对基础研究的持续投入，鼓励自由探索，敢于质疑现有理论，勇于开拓新的方向。鲲鹏展翅，打造5G时代多样化算力底座预计2025年，全球联网的设备数量将突破1000亿，数以ZB计的海量数据，需要被分析、处理。未来十年，是计算体系架构创新的黄金十年，算力需求的不断增长，将推动计算体系架构的创新。计算体系架构创新将主要从从两个方向展开：从通用计算走向通用计算加异构计算的多样性算力创新，和从硬件到基础软件、到应用使能的全栈协同创新。基于这一趋势，2019年，华为向业界正式发布鲲鹏、昇腾计算产业战略，并坚持“硬件开放、软件开源、使能伙伴、发展人才”，开放主板，有序推进与伙伴的整机合作；操作系统openEuler、企业级数据库openGuass、全场景AI计算框架MindSpore全部如期开源，得到伙伴的积极响应和支持。会上，华为向与会成员展示了鲲鹏投资全场景芯片族布局，包含鲲鹏处理器、昇腾AI处理器、智能SSD控制器芯片、智能网卡芯片以及智能管理芯片等。共建生态，把企业级数据库能力带给用户和伙伴会上，在谈到openGauss时，华为布道师张琼指出openGauss是一款高性能、高安全、高可靠的企业级开源关系型数据库(RDBMS)，且具备智能运维管理能力。截至目前，该数据库已完成了内部自用、产品化再到云&开源阶段，2021年将专注于生态构建，分享企业级数据库管理能力，促进数据库教育事业发展，引领生态建设。与此同时，华为布道师张琼还就openEuler进行了介绍。作为面向多样性计算的原生开源操作系统，openEuler定位于聚焦内核能力，释放多样化算力，加速行业应用创新。它具备操作系统完整功能集，能够原生自主演进。目前，openEuler已强力参与基础系统开源项目，成为核心成员，做到自维护、自演进，非常适合开发者学习。在此值得一提的是，会上华为布道师张晓雨还就“如何使用iSula生态链进行容器镜像构建和运行”进行了介绍。他指出，iSula 是华为自主研发的通用容器引擎，旨在统一的架构设计来满足 CT 和 IT 领域的不同需求。相比 Golang 编写的 Docker，轻量级容器具有轻、灵、巧、快的特点，不受硬件规格和架构的限制，底噪开销更小，可应用领域更为广泛。此外，他还通过实操向与会学子展示了iSula容器引擎的使用方法和iSula-build容器镜像构建工具的使用方法，帮助高校学子更好的了解到了iSula生态链对于容器镜像构建和运行的作用。作为浙江省首批重点建设的5所高校之一，杭州电子科技大学一贯坚持“以人为本，追求卓越”的育人理念，致力于培养家国情怀、国际视野、创新精神和实践能力的高素质人才。截止2020年7月，杭州电子科技大学已建设国家级人才培养模式创新实验区一个，国家级虚拟仿真实验教学中心一个，国家级实验教学示范中心三个，国家级精品课程两门，先后为国家和社会培养输送了16万余名优秀人才，获得了全国普通高等学校毕业生就业工作先进集体”“全国毕业生就业典型经验高校”等荣誉称号，为培养信息产业人才做出了卓著的贡献。近年来，华为正逐步将其已经成熟的技术进行开源，帮助更多产业开发者快速成长。通过供应链、技术等方面的优化，不断为开发者提供更加的平台。对于产业创新，质量的提升是要求也是衡量标准，全栈智能的创新技术是引擎，而拥有产业视角和创新技术的人才是关键。可以说，随着产业创新浪潮的兴起，产业开发者的时代已经来临，让我们一起，加入产业创新，加速产业创新，成为了不起的开发者！

docker     docker........................................................................................................ 11.     03命令............................................................................................... 21.1.      镜像 image是一个模板，可以使用这个模板创建容器服务，tomcat镜像-run -tomcat01容器（提供服务器）..................... 31.2.      容器............................................................................................ 31.3.      帮助命令.................................................................................... 31.4.      镜像命令.................................................................................... 31.5.      容器命令.................................................................................... 31.6.      常用其他命令............................................................................ 51.       03命令1.1.          镜像 image是一个模板，可以使用这个模板创建容器服务，tomcat镜像-run -tomcat01容器（提供服务器）1.2.          容器container利用容器技术，独立运行一个或一组应用，通过镜像来创建 可以理解为一个简易的linux操作系统1.3.          帮助命令docker version,docker info显示docker系统信息，包括容器和镜像,docker --help1.4.          镜像命令docker images查看镜像repository仓库源，TAG镜像标签，Imageid,created创建时间，size大小docker images -a,docker images -q只显示id,docker images -aq显示所有镜像docker search mysql搜索镜像docker search mysql --filter=STARS=3000搜索出来的镜像就是STARS大于3000的docker pull --helpdocker pull mysql ,下载镜像 默认下载最新版本，docker pull mysql分层下载，docker image的核心 联合文件系统，docker pull mysql:5.7下载对应版本删除镜像docker rmi f全部删除，docker rmi -f 镜像id，删除对应的镜像，docker rmi -f $(docker images -aq)递归删除所有镜像1.5.          容器命令有镜像才可以创建容器docker pull centos下载镜像类似于虚拟机 但比虚拟机快得多docker run [可选参数] image--name="Name"容器名字-d 后台方式运行-it 使用交互方式运行，进入容器查看内容-p 指定容器的端口 -p 8080:8080-p 主机端口：容器端口-p 容器端口-p 随机指定端口docker run -it centos /bin/bash启动容器 主机名就是镜像id退出容器 到主机exit直接容器停止并退出ctrl+p+q容器不停止退出docker ps查看正在运行的容器docker ps -a查看历史和正在运行的容器docker ps -n=？显示最近创建的容器？代表个数docker ps -q只显示容器的编号删除容器docker rm容器id 删除指定容器，但不能删除正在运行的容器docker rm -f $(docker ps -aq)删除全部容器docker ps -a -q|xargs docker rm删除所有容器启动和停止容器docker start 容器iddocker restart 容器iddocker stop 容器id 停止当前正在运行的容器docker kill 容器id 强制杀掉容器1.6.          常用其他命令后台启动容器docker run -d centos问题docker ps发现centos停止，docker 容器使用后台运行，就必须要有一个前台进程，docker发现后台没有对应的前台应用，会自动停止，就是没有程序写脚本跑出日志docker run -d centos /bin/sh -c "while true;do echo wfang;sleep 1;done"查看日志docker logsdocker logs --help 查看帮助docker logs -tf --tail 10 镜像id ，10为要显示的日志条数，如果不加tail参数 会显示所有日志查看容器内部的信息docker top 容器id查看容器的信息docker inspect (--help)docker inspect 容器id进入当前正在运行的容器方式一 通常容器都是使用后台方式运行的，需要进入容器，修改一些配置docker exec -it 容器it bashShell进入容器后开启一个新终端，可在里面操作-常用docker exec -it 容器it /bin/bash方式二 docker attach 容器id 正在执行当前的代码进入容器正在执行的终端，不会启动新的进程从容器内拷贝文件到主机docker attach 容器idcd /home;touch a.javaexit退出来docker cp 容器id:/home/a.java 将容器的文件拷贝到主机

docker     docker........................................................................................................ 11.     概述.................................................................................................... 21.1.      为什么出现................................................................................ 21.2.      jar--apk发布在应用商店，客户使用apk安装即可使用 jar--jar（环境）--打包带上项目环境（镜像）---（dokcer仓库：商店）-下载我们发布的镜像-直接运行即可......................................... 31.3.      docker的思想来自集装箱 隔离：docker核心思想 打包装箱 每个箱子互相隔离的 通过隔离机制，将服务器资源利用到极致. 31.4.      历史............................................................................................ 31.5.      docker能干嘛............................................................................ 41.6.      docker是怎么工作.................................................................... 51.7.      docker为什么比VM快............................................................. 51.       概述1.1.          为什么出现开发和上线 两套环境，应用环境，应用配置开发和运维：版本更新，运行环境不一致环境配置麻烦 每台机器都要部署环境发布一个项目（jar+redis,mysql,jdk,es)项目能不能带环境传统：开发jar运维来做现在：开发打包部署上线，一套流程做完1.2.          jar--apk发布在应用商店，客户使用apk安装即可使用jar--jar（环境）--打包带上项目环境（镜像）---（dokcer仓库：商店）-下载我们发布的镜像-直接运行即可1.3.          docker的思想来自集装箱隔离：docker核心思想 打包装箱 每个箱子互相隔离的；通过隔离机制，将服务器资源利用到极致1.4.          历史2010年几个IT年轻人在美国成立dotcloud，做一些pass的云计算服务，linux有关的容器技术，他们将自己的技术（容器化技术）命名dockerdocker刚诞生，没有引起注意，dotcloud想活下去，2013年就开源 越来越多发现docker的优点docker每个月更新一个版本，2014年4月docker1.0发布为什么火？容器技术出来之前，我们都是用虚拟机技术在windows中装vmware,通过这个软件可以虚拟出一台或多台电脑，笨重，虚拟机和容器都是属于虚拟化技术docker隔离，镜像（最核心的环境4M+JDK+mysql)十分小巧，运行镜像即可，秒级启动，VM ，linux centos原生镜像（一台电脑）隔离，几个G几分钟才能启动    docker是什么？    •使用最广泛的开源容器引擎    •一种操作系统级的虚拟化技术    •依赖于Linux内核特性：Namespace（资源隔离）和Cgroups（资源限制）    •一个简单的应用程序打包工具1.5.          docker能干嘛docker基于go语言开发虚拟机技术缺点kernel-lib-app app，资源占用多 冗余步骤多 启动很慢容器化技术不是模拟完整的操作系统，kernel-容器（lib-app）直接运行在操作系统上，各容器互相隔离docker和容器的不同传统虚拟机，虚拟出一条硬件，运行完整的操作系统，然后在这个系统上安装和运行软件容器内的应用直接运行在宿主机上，容器是没有自己的内核的，也没有虚拟硬件，所以轻便，每个容器互相隔离，每个容器内部有一个属于自己的文件系统，互不影响应用更快速的交付和部署传统 一堆帮助文档，安装程序，docker打包镜像发布测试，一键运行更便捷的升级和扩容使用了docker后部署应用像搭积木，项目打包为一个镜像，扩展服务器A，服务器B更简单的系统运维开发测试环境都是高度一致更高效地计算资源利用docker是内核级别的虚拟化，一个物理机可以运行多个容器1.6.          docker是怎么工作是一个client-server结构的系统，docker的守护进程运行在主机上，通过socket从客户端访问，dockerserver收到docker client的指令就会执行这个命令1.7.          docker为什么比VM快dokcer有比虚拟机更少的抽象层，docker利用的是宿主机的内核，VM需要guest os，新建一个容器时，不需要虚拟机一样重新加载一个操作系统内核

关联【我用鲲鹏做开发】搭建VScode remote development远程开发环境【我用鲲鹏做开发】搭建VScode remote development远程开发环境——Docker集成【我用鲲鹏做开发】Java鲲鹏应用开发快速入门介绍Docker镜像是目前Spring Boot应用常用的构建打包方式，本篇将介绍如何在鲲鹏环境下构建Spring Boot的Docker镜像。需求资源华为云鲲鹏ECS一台，操作系统安装Ubuntu 18.04 server 64bit with ARM安装VScode remote development远程开发环境，参考【我用鲲鹏做开发】搭建VScode remote development远程开发环境集成Docker环境，参考【我用鲲鹏做开发】搭建VScode remote development远程开发环境——Docker集成搭建Java鲲鹏应用开发环境，参考【我用鲲鹏做开发】Java鲲鹏应用开发快速入门Spring Boot构建Docker镜像这里介绍三种方式：传统方式使用Dockerfile构建jar包到镜像使用Maven Spring Boot插件构建源码到OCI镜像使用优化的Dockerfile分层jar包内容到镜像1、传统方式使用Dockerfile构建jar包到镜像DockerfileFROM adoptopenjdk:11-jre-hotspot ARG JAR_FILE=target/*.jar COPY ${JAR_FILE} application.jar EXPOSE 8080 ENTRYPOINT ["java","-jar","/application.jar"]build.sh# 构建可执行jar包 mvn clean package # 构建Docker镜像 docker build -t java-quickstart:0.0.1-SNAPSHOT .2、使用Maven Spring Boot插件构建源码到OCI镜像使用Spring Boot Maven插件可以使用Buildpack从代码创建OCI镜像，暂不支持arm环境构建。3、使用优化的Dockerfile分层jar包内容到镜像Spring Boot 2.3以上支持jar包分层，分层配置默认false，通过pom.xml配置文件中Spring Boot Maven插件配置启用。<plugin> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-maven-plugin</artifactId> <configuration> <layers> <enabled>true</enabled> </layers> </configuration> </plugin>使用java命令查看分层jar包Usage: java -Djarmode=layertools -jar quickstart-0.0.1-SNAPSHOT.jar Available commands: list List layers from the jar that can be extracted extract Extracts layers from the jar for image creation help Help about any command优化的Dockerfile# the first stage of our build will extract the layers FROM adoptopenjdk:11-jre-hotspot as builder WORKDIR application ARG JAR_FILE=target/*.jar COPY ${JAR_FILE} application.jar RUN java -Djarmode=layertools -jar application.jar extract # the second stage of our build will copy the extracted layers FROM adoptopenjdk:11-jre-hotspot WORKDIR application COPY --from=builder application/dependencies/ ./ COPY --from=builder application/spring-boot-loader/ ./ COPY --from=builder application/snapshot-dependencies/ ./ COPY --from=builder application/application/ ./ ENTRYPOINT ["java", "org.springframework.boot.loader.JarLauncher"]操作步骤本篇采用方式三构建Docker镜像，构建前在hub.docker.com确认FROM镜像adoptopenjdk:11-jre-hotspot能否支持arm环境1、创建Dockerfile和build.sh2、构建镜像执行build.sh，成功后检查3、验证运行镜像docker run -p 9092:8080 -t java-quickstart:0.0.1-SNAPSHOT配置本机端口映射使用浏览器验证通过