metrics

kubeadm是官方社区推出的一个用于快速部署kubernetes集群的工具。 1.安装要求 在开始之前，部署Kubernetes集群机器需要满足以下几个条件： 一台或多台机器，操作系统 CentOS7.6-86_x64 硬件配置：4GB或更多RAM，4个CPU或更多CPU，硬盘30GB或更多 集群中所有机器之间网络互通 禁止swap分区 2. 准备环境 关闭防火墙： systemctl stop firewalld systemctl disable firewalld 关闭selinux： sed -i 's/enforcing/disabled/' /etc/selinux/config setenforce 0 关闭swap： swapoff -a $ 临时 sed -i '/ swap / s/^\(.*\)$/#\1/g' /etc/fstab $ 永久 添加主机名与IP对应关系（记得设置主机名）： $ cat >> /etc/hosts<<EOF 9.110.187.120 k8s-master 9.110.187.125 k8s-node1 9.110.187.126 k8s-node2 EOF 将桥接的IPv4流量传递到iptables的链： $ cat > /etc/sysctl.d/k8s.conf << EOF net.bridge.bridge-nf

前言 今天和大家聊一聊在Spring Cloud微服务框架实践中，比较核心但是又很容易把人搞得稀里糊涂的一个问题，那就是在 Spring Cloud 中 Hystrix 、 Ribbon 以及 Feign 它们三者之间在处理微服务调用超时从而触发熔断降级的关系是什么？ 我们知道在 Spring Cloud 微服务体系下， 微服务之间的互相调用可以通过 Feign 进行声明式调用，在这个服务调用过程中 Feign 会通过 Ribbon 从服务注册中心获取目标微服务的服务器地址列表，之后在网络请求的过程中 Ribbon 就会将请求以负载均衡的方式打到微服务的不同实例上 ，从而实现 Spring Cloud 微服务架构中最为关键的功能即服务发现及客户端负载均衡调用。 另一方面微服务在互相调用的过程中， 为了防止某个微服务的故障消耗掉整个系统所有微服务的连接资源，所以在实施微服务调用的过程中我们会要求在调用方实施针对被调用微服务的熔断逻辑 。而要实现这个逻辑场景在 Spring Cloud 微服务框架下我们是通过 Hystrix 这个框架来实现的。 调用方会针对被调用微服务设置调用超时时间，一旦超时就会进入熔断逻辑，而这个故障指标信息也会返回给 Hystrix 组件， Hystrix 组件会根据熔断情况判断被调微服务的故障情况从而打开熔断器，之后所有针对该微服务的请求就会直接进入熔断逻辑

用keras搭好模型架构之后的下一步，就是执行编译操作。在编译时，经常需要指定三个参数 loss optimizer metrics 这三个参数有两类选择： 使用字符串 使用标识符，如keras.losses，keras.optimizers，metrics包下面的函数 例如： sgd = SGD(lr=0.01, decay=1e-6, momentum=0.9, nesterov=True) model.compile(loss='categorical_crossentropy', optimizer=sgd, metrics=['accuracy']) 因为有时可以使用字符串，有时可以使用标识符，令人很想知道背后是如何操作的。下面分别针对optimizer，loss，metrics三种对象的获取进行研究。 optimizer 一个模型只能有一个optimizer，在执行编译的时候只能指定一个optimizer。 在keras.optimizers.py中，有一个get函数，用于根据用户传进来的optimizer参数获取优化器的实例： def get(identifier): # 如果后端是tensorflow并且使用的是tensorflow自带的优化器实例，可以直接使用tensorflow原生的优化器 if K.backend() == 'tensorflow': #

Memory Access Patterns 大部分device一开始从global Memory获取数据，而且，大部分GPU应用表现会被带宽限制。因此最大化应用对global Memory带宽的使用时获取高性能的第一步。也就是说，global Memory的使用就没调节好，其它的优化方案也获取不到什么大效果,下面的内容会涉及到不少L1的知识，这部分了解下就好，L1在Maxwell之后就不用了，但是cache的知识点是不变的。 Aligned and Coalesced Access 如下图所示，global Memory的load/store要经由cache，所有的数据会初始化在DRAM，也就是物理的device Memory上，而kernel能够获取的global Memory实际上是一块逻辑内存空间。Kernel对Memory的请求都是由DRAM和SM的片上内存以128-byte和32-byte传输解决的。 所有获取global Memory都要经过L2 cache，也有许多还要经过L1 cache，主要由GPU的架构和获取模式决定的。如果L1和L2都被使用，那么Memory的获取是以128-byte为单位传输的，如果只使用L2，则以32-byte为单位传输，在允许使用L1的GPU中（Maxwell已经彻底不使用L1，原本走L1都换成走texture cache）

作者 | 声东 阿里云售后技术专家 导读 ：阿里云售后技术团队的同学，每天都在处理各式各样千奇百怪的线上问题。常见的有网络连接失败、服务器宕机、性能不达标及请求响应慢等。但如果要评选的话，什么问题看起来微不足道事实上却让人绞尽脑汁，我相信肯定是“删不掉”的问题，比如文件删不掉、进程结束不掉、驱动卸载不了等。这样的问题就像冰山，隐藏在它们背后的复杂逻辑，往往超过我们的预想。 背景 今天我们讨论的这个问题，跟 K8s 集群的 Namespace 有关。Namespace 是 K8s 集群资源的“收纳”机制。我们可以把相关的资源“收纳”到同一个 Namespace 里，以避免不相关资源之间不必要的影响。 Namespace 本身也是一种资源。通过集群 API Server 入口，我们可以新建 Namespace，而对于不再使用的 Namespace，我们需要清理掉。Namespace 的 Controller 会通过 API Server，监视集群中 Namespace 的变化，然后根据变化来执行预先定义的动作。 有时候，我们会遇到下图中的问题，即 Namespace 的状态被标记成了 "Terminating"，但却没有办法被完全删除。 从集群入口开始 因为删除操作是通过集群 API Server 来执行的，所以我们要分析 API Server 的行为。跟大多数集群组件类似，API

Kubernetes基于Metrics Server的HPA [TOC] 1. 环境说明和相关介绍 我的kubernetes环境： kubeadm安装的kubernetes1.11 Horizontal Pod Autoscaler（HPA，Pod水平自动伸缩），根据资源利用率或者自定义指标自动调整replication controller、deployment 或 replica set，实现部署的自动扩展和缩减，让部署的规模接近于实际服务的负载。HPA不适于无法缩放的对象，例如DaemonSet。 Kubernetes从1.8版本开始，CPU、内存等资源的metrics信息可以通过 Metrics API来获取，用户可以直接获取这些metrics信息（例如通过执行 kubect top 命令），HPA使用这些metics信息来实现动态伸缩。本文介绍Kubernetes集群基于metric server的HPA。在开始之前我们需要了解一下Metrics API和Metrics Server。 Metrics API ： 通过Metrics API我们可以获取到指定node或者pod的当前资源使用情况，API本身不存储任何信息，所以我们不可能通过API来获取资源的历史使用情况。 Metrics API的获取路径位于： /apis/metrics.k8s.io/ 获取Metrics

参考文档 https://kubernetes.io/docs/tasks/debug-application-cluster/core-metrics-pipeline/#metrics-server https://github.com/kubernetes-incubator/metrics-server/tree/master/deploy/1.8%2B https://www.cnblogs.com/cuishuai/p/9857120.html https://juejin.im/post/5b6592ace51d4515b01c11ed 文档目录 kubernetes1.13.1+etcd3.3.10+flanneld0.10集群部署 kubernetes1.13.1部署kuberneted-dashboard v1.10.1 kubernetes1.13.1部署coredns kubernetes1.13.1部署ingress-nginx并配置https转发dashboard kubernetes1.13.1部署metrics-server0.3.1 kubernetes1.13.1集群使用ceph rbd存储块 kubernetes1.13.1集群结合ceph rbd部署最新版本jenkins 简介 Metrics Server heapster 已经被废弃了

排错 1： Warning FailedGetResourceMetric 12s (x41 over 20m) horizontal-pod-autoscaler unable to get metrics for resource cpu: unable to fetch metrics from API: the server could not find the requested resource (get pods.metrics.k8s.io) 解决：kube-controller-manager的启动项加上： --horizontal-pod-autoscaler-use-rest-clients=false 阿里云K8S：修改/etc/kubernetes/kube-controller-manager.yaml systemctl daemon-reload systemctl restart kube-controller-manager 2： heapster启动参数加入： --api-server 3： missing request for cpu on container xxxx in pod xxxx/xxxx-xxxxxxxxxxx-xxxxxx 解决：给该应用加上request资源限制 来源： 51CTO 作者： 安啼 链接： https:/