首页 文章 精选 留言 我的

精选列表

搜索[原生UI],共10000篇文章
优秀的个人博客,低调大师

原生Kubernetes监控功能详解-Part2

今晚20:30,Kubernetes Master Class在线培训第六期《在Kubernetes中创建高可用应用》即将开播,点击http://live.vhall.com/847710932 即可免费预约注册! 监控的重要性不言而喻,它让我们能充分了解到应用程序的状况。Kubernetes有很多内置工具可供用户们选择,让大家更好地对基础架构层(node)和逻辑层(pod)有充分的了解。 在本系列文章的第一篇中,我们关注了专为用户提供监控和指标的工具Dashboard和cAdvisor。在本文中,我们将继续分享关注工作负载扩缩容和生命周期管理的监控工具:Probe(探针)和Horizontal Pod Autoscaler(HPA)。同样的,一切介绍都将以demo形式进行。 Demo的前期准备 在本系列文章的上一篇中,我们已经演示了如何启动Rancher实例以及Kubernetes集群。在上篇文章中我们提到过,Kubernetes附带了一些内置的监控工具,包括: Kubernetes dashboard:为集群上运行的资源提供一个概览。它还提供了一种非常基本的部署以及与这些资源进行交互的方法。 cAdvisor:一种用于监控资源使用情况并分析容器性能的开源代理。 Liveness和Readiness Probe:主动监控容器的健康情况。 Horizontal Pod Autoscaler:基于通过分析不同指标所收集的信息,根据需要增加pod的数量。 在上篇文章了,我们深度分析了前两个组件Kubernetes Dashboard和cAdvisor,在本文中,我们将继续探讨后两个工具:探针及HPA。 Probe(探针) 健康检查有两种:liveness和readiness。 readiness探针让Kubernetes知道应用程序是否已准备好,来为流量提供服务。只有探针允许通过时,Kubernetes才会允许服务将流量发送到pod。如果探针没有通过,Kubernetes将停止向该Pod发送流量,直到再次通过为止。 当你的应用程序需要花费相当长的时间来启动时,readiness探针非常有用。即使进程已经启动,在探针成功通过之前,该服务也无法工作。默认情况下,Kubernetes将在容器内的进程启动后立即开始发送流量,但是在有readiness探针的情况下,Kubernetes将在应用程序完全启动后再允许服务路由流量。 liveness探针让Kubernetes知道应用程序是否处于运行状态。如果处于运行状态,则不采取任何行动。如果该应用程序未处于运行状态,Kubernetes将删除该pod并启动一个新的pod替换之前的pod。当你的应用程序停止提供请求时,liveness探针非常有用。由于进程仍在运行,因此默认情况下,Kubernetes将继续向pod发送请求。凭借liveness探针,Kubernetes将检测到应用程序不再提供请求并将重新启动pod。 对于liveness和readiness检查,可以使用以下类型的探针: http:自定义探针中最常见的一种。Kubernetes ping一条路径,如果它在200-300的范围内获得http响应,则将该pod标记为健康。 command:使用此探针时,Kubernetes将在其中一个pod容器内运行命令。如果该命令返回退出代码0,则容器将标记为健康。 tcp:Kubernetes将尝试在指定端口上建立TCP连接。如果能够建立连接,则容器标记为健康。 配置探针时,可提供以下参数: initialDelaySeconds:首次启动容器时,发送readiness/liveness探针之前等待的时间。对于liveness检查,请确保仅在应用程序准备就绪后启动探针,否则你的应用程序将会继续重新启动。 periodSeconds:执行探针的频率(默认值为10)。 timeoutSeconds:探针超时的时间,以秒为单位(默认值为1)。 successThreshold:探针成功的最小连续成功检查次数。 failureThreshold:放弃之前探针失败的次数。放弃liveness探针会导致Kubernetes重新启动pod。对于liveness探针,pod将被标记为未准备好。 Readiness探针的演示 在本节中,我们将使用命令检查来配置readiness探针。我们将使用默认的nginx容器部署两个副本。在容器中找到名为/tmp/healthy的文件之前,不会有任何流量发送到pod。 首先,输入以下命令创建一个readiness.yaml文件: apiVersion: apps/v1 kind: Deployment metadata: name: readiness-demo spec: selector: matchLabels: app: nginx replicas: 2 template: metadata: labels: app: nginx spec: containers: - image: nginx name: nginx ports: - containerPort: 80 readinessProbe: exec: command: - ls - /tmp/healthy initialDelaySeconds: 5 periodSeconds: 5 --- apiVersion: v1 kind: Service metadata: name: lb spec: type: LoadBalancer ports: - port: 80 protocol: TCP targetPort: 80 selector: > apiVersion: apps/v1 kind: Deployment metadata: name: readiness-demo spec: selector: matchLabels: app: nginx replicas: 2 template: metadata: labels: app: nginx spec: containers: - image: nginx name: nginx ports: - containerPort: 80 readinessProbe: exec: command: - ls - /tmp/healthy initialDelaySeconds: 5 periodSeconds: 5 --- apiVersion: v1 kind: Service metadata: name: lb spec: type: LoadBalancer ports: - port: 80 protocol: TCP targetPort: 80 selector: app: nginx app: nginx 接下来,应用YAML文件: 我们将看到正在创建的部署和服务: 除非readiness探针通过,否则pod将不会进入READY状态。在这种情况下,由于没有名为/tmp/healthy的文件,因此将被标记为失败,服务将不会发送任何流量。 为了更好地理解,我们将修改两个pod的默认nginx索引页面。当被请求时,第一个将显示1作为响应,第二个将显示2作为响应。 下面将特定pod名称替换为计算机上部署创建的pod名称: 在第一个pod中创建所需的文件,以便转换到READY状态并可以在那里路由流量: 探针每5秒运行一次,因此我们可能需要稍等一会儿才能看到结果: 一旦状态发生变化,我们就可以开始点击负载均衡器的外部IP: 下面我们应该能看到我们修改过的Nginx页面了,它由一个数字标识符组成: 为第二个pod创建文件也会导致该pod进入READY状态。此处的流量也会被重定向: 当第二个pod标记为READY时,该服务将向两个pod发送流量: 此时的输出应该已经指明了,流量正在两个pod之间分配: Liveness探针的演示 在本节中,我们将演示使用tcp检查配置的liveness探针。如上所述,我们将使用默认的nginx容器部署两个副本。如果容器内的端口80没有正处于监听状态,则不会将流量发送到容器,并且将重新启动容器。 首先,我们来看看liveness探针演示文件: apiVersion: apps/v1 kind: Deployment metadata: name: liveness-demo spec: selector: matchLabels: app: nginx replicas: 2 template: metadata: labels: app: nginx spec: containers: - image: nginx name: nginx ports: - containerPort: 80 livenessProbe: tcpSocket: port: 80 initialDelaySeconds: 15 periodSeconds: 5 --- apiVersion: v1 kind: Service metadata: name: lb spec: type: LoadBalancer ports: - port: 80 protocol: TCP targetPort: 80 selector: app: nginx 我们可以用一个命令来应用YAML: 然后,我们可以检查pod,并像上面一样修改默认的Nginx页面以使用简单的1或2来表示响应。 首先,找到Nginx部署给pod的名称: 接下来,使用数字标识符替换每个pod中的默认索引页: 流量已被服务重定向,因此可立即从两个pod获取响应: 同样,响应应该表明流量正在两个pod之间分配: 现在我们已经准备好在第一个pod中停止Nginx进程,以查看处于运行状态的liveness探针。一旦Kubernetes注意到容器不再监听端口80,pod的状态将会改变并重新启动。我们可以观察其转换的一些状态,直到再次正常运行。 首先,停止其中一个pod中的Web服务器进程: 现在,当Kubernetes注意到探针失败并采取措施重启pod时,审核pod的状态: 你可能会看到pod在再次处于健康状况之前进行了多种状态的转换: 如果我们通过我们的服务请求页面,我们将从第二个pod中看到正确的响应,即修改后的标识符“2”。然而,刚创建的pod将从容器镜像返回了默认的Nginx页面: 这表明Kubernetes已经部署了一个全新的pod来替换之前失败的pod。 Horizontal Pod Autoscaler Horizontal Pod Autoscaler(HPA)是Kubernetes的一项功能,使我们能够根据观察到的指标对部署、复制控制器、或副本集所需的pod数量进行自动扩缩容。在实际使用中,CPU指标通常是最主要的触发因素,但自定义指标也可以是触发因素。 基于测量到的资源使用情况,该过程的每个部分都是自动完成的,不需要人工干预。相关指标可以从metrics.k8s.io、custom.metrics.k8s.io或external.metrics.k8s.io等API获取。 在下文的示例中,我们将基于CPU指标进行演示。我们可以在这种情况下使用的命令是kubectl top pods,它将显示pod的CPU和内存使用情况。 首先,创建一个YAML文件,该文件将使用单个副本创建部署: 输入以下内容来应用部署: 这是一个很简单的deployment,具有相同的Nginx镜像和单个副本: 接下来,让我们了解如何实现自动缩放机制。使用kubectl get / describe hpa命令,可以查看当前已定义的autoscaler。要定义新的autoscaler,我们可以使用kubectl create命令。但是,创建autoscaler的最简单方法是以现有部署为目标,如下所示: 这将为我们之前创建的hpa-demo部署创建一个autoscaler,而且预计CPU利用率为50%。副本号在此处设为1到10之间的数字,因此当高负载时autoscaler将创建的最大pod数为10。 你可以通过输入以下内容来确认autoscaler的配置: 我们也可以用YAML格式定义它,从而更容易地进行审查和变更管理: 为了查看HPA的运行情况,我们需要运行一个在CPU上创建负载的命令。这里有很多种方法,但一个非常简单的例子如下: 首先,检查唯一pod上的负载。因为它目前处于空闲状态,所以没有太多负载: 现在,让我们在当前pod上生成一些负载。一旦负载增加,我们应该就能看到HPA开始自动创建一些额外的pod来处理所增加的负载。让以下命令运行几秒钟,然后停止命令: 检查当前pod上的当前负载: HPA开始发挥作用,并开始创建额外的pod。Kubernetes显示部署已自动缩放,现在有三个副本: 我们可以看到HPA的详细信息以及将其扩展到三个副本的原因: Name: hpa-demo Namespace: default Labels: <none> Annotations: kubectl.kubernetes.io/last-applied-configuration={"apiVersion":"autoscaling/v1","kind":"HorizontalPodAutoscaler","metadata":{"annotations":{},"name":"hpa-demo","namespace":"default"},"spec":{"maxRepli... CreationTimestamp: Sat, 30 Mar 2019 17:43:50 +0200 Reference: Deployment/hpa-demo Metrics: ( current / target ) resource cpu on pods (as a percentage of request): 104% (104m) / 50% Min replicas: 1 Max replicas: 10 Conditions: Type Status Reason Message ---- ------ ------ ------- AbleToScale True ReadyForNewScale recommended size matches current size ScalingActive True ValidMetricFound the HPA was able to successfully calculate a replica count from cpu resource utilization (percentage of request) ScalingLimited False DesiredWithinRange the desired count is within the acceptable range Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal SuccessfulRescale 15s horizontal-pod-autoscaler New size: 3; reason: cpu resource utilization (percentage of request) above target 由于我们停止了生成负载的命令,所以如果我们等待几分钟,HPA应该注意到负载减少并缩小副本的数量。没有高负载,就不需要创建额外的两个pod。 autoscaler在Kubernetes中执行缩减操作之前等待的默认时间是5分钟。您可以通过调整--horizontal-pod-autoscaler-downscale-delay设置来修改该时间,更多信息可以参考官方文档: https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/ 等待时间结束后,我们会发现,在高负载的标记处,部署的pod数量减少了: pod数量会变回到基数: 如果再次检查HPA的描述,我们将能看到减少副本数量的原因: Name: hpa-demo Namespace: default Labels: <none> Annotations: kubectl.kubernetes.io/last-applied-configuration={"apiVersion":"autoscaling/v1","kind":"HorizontalPodAutoscaler","metadata":{"annotations":{},"name":"hpa-demo","namespace":"default"},"spec":{"maxRepli... CreationTimestamp: Sat, 30 Mar 2019 17:43:50 +0200 Reference: Deployment/hpa-demo Metrics: ( current / target ) resource cpu on pods (as a percentage of request): 0% (0) / 50% Min replicas: 1 Max replicas: 10 Conditions: Type Status Reason Message ---- ------ ------ ------- AbleToScale True SucceededRescale the HPA controller was able to update the target scale to 1 ScalingActive True ValidMetricFound the HPA was able to successfully calculate a replica count from cpu resource utilization (percentage of request) ScalingLimited True TooFewReplicas the desired replica count is increasing faster than the maximum scale rate Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal SuccessfulRescale 5m horizontal-pod-autoscaler New size: 3; reason: cpu resource utilization (percentage of request) above target Normal SuccessfulRescale 13s horizontal-pod-autoscaler New size: 1; reason: All metrics below target` 结 语 相信通过这两篇系列文章,我们能够深入地理解了Kubernetes是如何使用内置工具为集群设置监控的。我们知道了Kubernetes在幕后如何通过不间断的工作来保证应用程序的运行,同时可以的话也应该更进一步去了解其背后的原理。 从Dashboard和探针收集所有数据,再通过cAdvisor公开所有容器资源,可以帮助我们了解到资源限制或容量规划。良好地监控Kubernetes是至关重要的,因为它可以帮助我们了解到集群、以及在集群上运行着的应用程序的运行状况和性能。

优秀的个人博客,低调大师

原生js——四种对话框

js一共提供了四种对话弹框,即alert()、confirm()、prompt()、showModalDialog()。具体使用方法如下: 1.alert() alert()向用户显示一条消息并等待用户关闭对话框。 在大多数的浏览器里,alert()方法会产生阻塞,并等待用户关闭对话框。 也就是说,在用户关掉它们所显示的对话框之前,它们不会返回。这就意味着在弹出一个对话框前,代码就会停止运行。如果当前正在载入文档,也会停止载入,直到用户用要求的输入进行响应为止。 alert("我是一个alert对话框"); 2.confirm() confirm()也显示一条消息,要求用户单击“确定”或“取消”按钮,并返回一个布尔值。 在浏览器中,confirm()会产生阻塞。 var test_value = confirm("你确定要继续吗?"); console.log(test_value); // 如果点击【确定】则返回true,点击【取消】,返回false 3.prompt() prompt()同样也显示一条消息,等待用户输入字符串,并返回那个字符串。 在浏览器中,prompt()会产生阻塞。 var message = prompt("请输入你的名字:"); console.log(message); 4.showModalDialog() 首先要说明的是,之前的三种对话框是通用的,showModalDialog()有一定的兼容性,可以简单概括为:IE、火狐、safari浏览器是支持的。但是Chrome和opera浏览器是不支持的,不过我们可以采用window.open()来代替。 showModalDialog()显示一个包含HTML格式的“模态对话框”,可以给它传入参数,以及从对话框里返回值。 showModalDialog()在浏览器当前窗口中显示一个模态窗口,在显示模态窗口的时候,可以传入三个参数: 第一个参数用以指定提供对话框HTML内容的URL 第二个参数是一个任意值(数组和对象均可),这个值在对话框里的脚本中可以通过window.dialogArguments属性的值访问。 第三个参数是一个非标准的列表,包含以分号隔开的name=value对,如果提供了这个参数,可以配置对话框的尺寸或其他属性。具体属性如下: |属性|说明| |:---:|:---| |dialogHeight|对话框高度,不小于100px| |dialogWidth|对话框宽度。| |dialogLeft|离屏幕左的距离。| |dialogTop|离屏幕上的距离。| |center|{ yes | no | 1 | 0 }:是否居中,默认yes,但仍可以指定高度和宽度。| |help|{ yes | no | 1 | 0 }:是否显示帮助按钮,默认yes。| |resizable|{ yes | no | 1 | 0 } [IE5+]: 是否可被改变大小。默认no。| |status|{ yes | no | 1 | 0 } [IE5+]: 是否显示状态栏。默认为yes[ Modeless]或no[Modal]。| |scroll|{ yes | no | 1 | 0 | on | off }:是否显示滚动条。默认为yes。| 在进行模态弹窗的时候,我们首先应该新建一个弹窗的新页面,并在里面写出我们需要的html、css和js代码。例如我们新建一个modal_html.html页面: <form action="#"> <label for="user_name">Name:</label> <input type="text" id="user_name"> <br> <label for="user_gender">Gender:</label> <input type="text" id="user_gender"> <br> <label for="user_age">Age:</label> <input type="text" id="user_age"> </form> <button id="btn_ok">ok</button> <button id="btn_cancle">cancle</button> <script> // 获取页面中的三个input元素,并赋值 var user_name = document.getElementById('user_name'); var user_age = document.getElementById('user_age'); var user_gender = document.getElementById('user_gender'); user_name.value = window.dialogArguments[0]; user_age.value = window.dialogArguments[1]; user_gender.value = window.dialogArguments[2]; var btn_ok = document.getElementById('btn_ok'); var btn_cancle = document.getElementById('btn_cancle'); // 点击【ok】按钮,关闭并返回模态窗口中的值 btn_ok.addEventListener("click",function(){ window.returnValue = [] window.returnValue[0] = user_name.value; window.returnValue[1] = user_age.value; window.returnValue[2] = user_gender.value; window.close(); }); // 点击【cancel】,直接关闭模态窗口,不返回值 btn_cancle.addEventListener("click",function(){ window.close(); }); </script> 新的页面创建好之后,我们便可以在另外一个页面parent.html进行模态弹窗,按照要求传入三个参数,parent.html页面的代码如下: var p = window.showModalDialog("modal_html.html", ["Tom", 23, "meal"], "dialogWidth:400px;dialogHeight:200px;resizable:no"); // 上述代码等价于以下代码 var param_1 = "modal_html.html"; var param_2 = ["Tom", 23, "meal"]; var param_3 = "dialogWidth:400px;dialogHeight:200px;resizable:no"; var p = window.showModalDialog(param_1, param_2, param_3); 如果想从parent.html页面向模态窗口中传递数据,可以在模态窗口modal_html.html页面中,使用window.dialogArguments数组接受,示例代码如下: var user_name = document.getElementById('user_name'); var user_age = document.getElementById('user_age'); var user_gender = document.getElementById('user_gender'); user_name.value = window.dialogArguments[0]; user_age.value = window.dialogArguments[1]; user_gender.value = window.dialogArguments[2]; 如果想从模态窗口中向打开模态窗口的parent.html页面返回数据,首先要在parent.html页面设置window.returnValue,注意这里不需要使用return语句显式返回。使用window.close();语句关闭模态窗口的时候,会自动返回window.returnValue。事例代码如下: // 点击【ok】按钮,关闭并返回模态窗口中的值 btn_ok.addEventListener("click",function(){ window.returnValue = [] window.returnValue[0] = user_name.value; window.returnValue[1] = user_age.value; window.returnValue[2] = user_gender.value; window.close(); }); 在模态窗口页面设置好window.returnValue,我们便可以在parent.html页面进行引用,示例代码如下: var p = window.showModalDialog("modal_html.html", ["Tom", 23, "meal"], "dialogWidth:400px;dialogHeight:200px;resizable:no"); alert(p[0]); // 如果在模态窗口中不修改,则为Tom alert(p[1]); // 如果在模态窗口中不修改,则为 23 alert(p[2]); // 如果在模态窗口中不修改,则为 meal

资源下载

更多资源
腾讯云软件源

腾讯云软件源

为解决软件依赖安装时官方源访问速度慢的问题,腾讯云为一些软件搭建了缓存服务。您可以通过使用腾讯云软件源站来提升依赖包的安装速度。为了方便用户自由搭建服务架构,目前腾讯云软件源站支持公网访问和内网访问。

Spring

Spring

Spring框架(Spring Framework)是由Rod Johnson于2002年提出的开源Java企业级应用框架,旨在通过使用JavaBean替代传统EJB实现方式降低企业级编程开发的复杂性。该框架基于简单性、可测试性和松耦合性设计理念,提供核心容器、应用上下文、数据访问集成等模块,支持整合Hibernate、Struts等第三方框架,其适用范围不仅限于服务器端开发,绝大多数Java应用均可从中受益。

Rocky Linux

Rocky Linux

Rocky Linux(中文名:洛基)是由Gregory Kurtzer于2020年12月发起的企业级Linux发行版,作为CentOS稳定版停止维护后与RHEL(Red Hat Enterprise Linux)完全兼容的开源替代方案,由社区拥有并管理,支持x86_64、aarch64等架构。其通过重新编译RHEL源代码提供长期稳定性,采用模块化包装和SELinux安全架构,默认包含GNOME桌面环境及XFS文件系统,支持十年生命周期更新。

WebStorm

WebStorm

WebStorm 是jetbrains公司旗下一款JavaScript 开发工具。目前已经被广大中国JS开发者誉为“Web前端开发神器”、“最强大的HTML5编辑器”、“最智能的JavaScript IDE”等。与IntelliJ IDEA同源,继承了IntelliJ IDEA强大的JS部分的功能。

用户登录
用户注册