shrek11的专栏

k8s内部的服务注册主要是依靠几个组件coreDns,service和pod的标签选择器。服务注册的流程pod创建完以后，一般我们都会打算一组标签，标签是key/value形式的,如下---apiVersion: v1kind: Podmetadata: name: nginx labels: env: test #这里给这个pod打上标签spec: containers: - name: nginx image: nginx imagePul

1，下载k8s离线包需要的可以私我2，环境架构ip节点部署程序192.168.145.180k8s-masterdocker etct master192.168.145.181k8s-work1docker etct slave1192.168.145.182k8s-work2docker etct slave23，docker 安装3.1 上传docker-20.10.0.taz包到各个服务器。mkdir /usr/local/docker

记录一下 shell 获取时间段的脚本#! /bin/bashsqoop=/usr/bin/sqoop=today=`date +%Y-%m-%d`whichday=`date -d $today +%w`# 本周v_0_week_startdate=`date -d "$today -$[${whichday}-1] days" +%Y-%m-%d`v_0_week_enddate=`date -d "$v_0_week_startdate+6 days" +%Y-%m-%d`

最近一直在弄k8s，前面安装都要顺畅，包括K8S集群等等。k8s有个很重要的功能，就是它可以根据你服务器的压力动态扩容pod。比如你可以预定你的pod实例是5个，当请求高峰过来的时候，pod压力过大，每个pod的cpu或者内容一下增大当pod的cpu超过一个阈值的时候，k8s可以根据你的设定将pod实例变成8个，10个，设置20个，过段时间，当洪峰过去，cup压力下来后，pod实例又会慢慢的将个数变成10个，8个，最后3个。这个就是K8S的所谓的动态伸缩但是要弄这个功能，最主要.

下面是15个微服务设计中常用的15个设计原则，当然并不是设计时所有都要涉及，可以根据项目场景增加或者删除几项原则。N+1原则：确保系统发生故障时，至少有一个冗余的实例。 回滚设计：确保系统可以回滚到以前发布过的任何一个版本。 禁用设计：确保一些具有高风险的系统功能能够通过开关来禁用，这能为修复时间赢得时间。 监控设计: 在设计阶段就必须考虑监控，而不是在实施完成之后。监控做的好，将为系统的可扩展性预留空间 设计多活的数据中心：确保系统可以在地理上隔离灾难和危机 使用成熟的技术：只用确实好用

前言：之前在研究监控系统：Prometheus，它是云全球云原生基金的第二大项目，然后带出第一大 Kerbernates,然后就开始研究K8S微服务框架是知道阿里的duboo，Netflix的springcloud，这些都是大厂研发并且在各自的公司实施生产稳定的架构，最近2年又出了k8s，开始只了解这东西是google大厂出来做服务编排管理的，后来这东西又归于云计算的一种，最近在看杨波老师的视频《极客时间基于SpringBoot与Kubernetes云原生微服务实践》（想看的私信我），这

前言：从下面的架构图看出，当prometheus拉取信息时，可以通过配置rules（规则）预警，把符合预警信息的指标push给altermanager，altermanager然后把这些指标通过邮件，webhook，微信推送（企业）等推送给相关人员。这就是一个完整的企业监控系统。altermanager安装：从prometheus https://prometheus.io/download/官网下载 altermanager比如我是推送企业微信，编辑 alertma...

前言：比如我们要监控spring boot 的各个指标，比如 JVM的内存各个指标，GC,线程数，甚至自己定义的指标，接口调用次数，成功数，失败数，一段时间调用频率等等。最好效果图如下：

前言首先选型阶段：zabbix 和prometheus如果监控的是物理机，用 Zabbix 没毛病，Zabbix在传统监控系统中，尤其是在服务器相关监控方面，占据绝对优势。甚至环境变动不会很频繁的情况下，Zabbix 也会比 Prometheus 好使；但如果是云环境的话，除非是 Zabbix 玩的非常溜，可以做各种定制，否则还是 Prometheus 吧，毕竟人家就是干这个的。Prometheus开始成为主导及容器监控方面的标配，并且在未来可见的时间内被广泛应用。结论：Linux基金会旗.