OpsThoughts

前言如题， 主要记录一下之前搭建部署的一套日志收集系统。这里采用docker-compose的方式运行，还是那句话主要是思路。 方式: 一台服务器上面利用docker-compose运行三个ES节点跟Kibana,并启用SSL,再使用Filebeat来收集服务器上面的应用日志到ES， 最后Kibana来做展示 配置目录创建1234mkdir -p /data/{es/node-1/{data,certs,logs,config},plugins}mkdir -p /data/{es/node-2/{data,certs,logs,config},plugins}mkdir -p /data/{es/node-3/{data,certs,logs,config},plugins}mkdir -p /data/kibana/{certs,config} -p 部署文件12345678910111213141516171819202122232425262728293031323334353637383940414243444546474849505152535455565758596...

背景线上API服务出现了5xx的请求错误, 未能在第一时间发现导致用户主动向团队报告接口有异常， 由于API的接口比较多，也只是监控了部分，事后通过日志才发现的确用户侧在对某个接口访问时，频繁出现5xx告警，我这边也没有收到什么通知，目前先暂且不说出现5xx是什么造成的，而是在API接口响应状态的监控方面没有做到很到位， 所以需要对Nginx日志中的状态为5xx的请求监控告警，以便能快速响应，解决问题。 ElastAlert2ElastAlert 2是一个简单的框架，用于对来自 Elasticsearch 和 OpenSearch 的数据的异常、尖峰或其他感兴趣的模式发出警报。 官方文档：https://elastalert2.readthedocs.io/en/latest/ Github: https://github.com/jertel/elastalert2 配置部署当然还是选择容器化方式运行，官方也提供得有镜像： 1docker pull docker pull jertel/elastalert2 配置文件配置可参考 https://github.com/jert...

在日常巡检过程当中，不需要登录服务器去查看，通过调用k8s api的方式获取所有pod的状态 然后在每天9点执行本脚本即可。 123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101from kubernetes import client, configfrom kubernetes.client.rest import ApiExceptionfrom datetime import datetime, timezoneimport requestsimport jsonimport sysimport pytz# 加载 Kubernetes 配置#默认会在master节点去读取 ~/.kube/config 文件config.load_kube_...

问题原因在k8s中使用nfs作为持久存储方式，根据不同环境对应不同名称空间的pod使用的存储类/存储卷 相对应，发现mysql8.0.23 在启动时挂载NFS会卡住的情况： 问题复现这里在某台宿主机上面创建了一个本地目录，然后按照默认方式： 1mount -t nfs 10.10.10.142:/data/bbb /tmp/cc 将nfs挂载到本地，然后映射到容器中去，所以这里跟k8s环境没多大联系，主要是nfs挂载问题： 初始化一直卡着，而且在挂载目录发现只有这个文件： 问题排查检查一下nfs挂载的参数情况： 12345mount -v | grep nfs10.10.10.137:/data/nfs_share_137 on /tmp/fans type nfs (rw,relatime,vers=3,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=10.10.10.137,mountvers=3,mo=udp,local_...

一、背景因公司历史遗留原因有个别环境暂时没有使用kubernets, 现在需要将这批服务器的监控系统从zabbix替换到Prometheus, 于是乎这边有个问题就是需要将所有服务器上面的所有的exporter mertics（即 target）地址写到Prometheus配置文件中，这样一来，维护一个文件，似乎还算可以，但是这里我采用Prometheus+Consul的方式来管理服务器上的所有exporter， 那么这样做的好处是我们能更清晰的通过Consul来管理上面的每个exporter url , 以及通过consul自带的自定义元数据，再结合Promethues无疑是个很灵活的方式。 二、架构 promtheus配置数据源为consu_sd_configs 地址指向一个consul客户端地址； 通过脚本调用consulapi的方式将宿主机上面的cadvisor-exporter,node-exporter metrics的地址注册到consul中； promtheus 检测到了新增服务后，会通过这个http://xxxxxx:xxx/metrics url 抓取采集数...

一、搭建架构● 3个或3个以上Nacos节点才能构成集群；● Nacos Nginx Proxy用于代理转发； 二、准备工作Nacos2.0版本相比1.X新增了gRPC的通信方式，因此需要增加2个端口。新增端口是在配置的主端口(server.port)基础上，进行一定偏移量自动生成。 端口 与主端口的偏移量 描述 8848 0 Nacos程序主配置端口 9848 +1000 客户端gRPC请求服务端端口，用于客户端向服务端发起连接和请求 9849 +1001 服务端gRPC请求服务端端口，用于服务间同步等 7848 -1000 Nacos 集群通信端口，用于Nacos 集群间进行选举，检测等 使用VIP/nginx请求时，需要配置成TCP转发，不能配置http2转发，否则连接会被nginx断开 按照上述官方的端口分配要求 ，此处部署的使用三台服务器上面创建的Nacos集群端口分配如下： 节点 IP 端口（所需暴露） 备注 版本 当前线下环境部署文件路径 Nacos_1 192168.18.73 宿主机：8858，9858，9859，785...

一、为什么要进行巡检 当前平台架构复杂，中间件繁多，组件之间耦合度高，微服务还未达到故障自愈水平，所以需要通过告警或巡检等手段发现问题来保障平台持续稳定运行。 当前有客户对平台及上层应用使用频率低，例如三四天登录查看一次数据，但是设备是正常运转的，一旦平台出现问题，刚好客户发现问题，运维 才去解决就为时已晚。 定期巡检方案是模拟人工登录各业务页面，而非接口调用，更能真实地发现问题，并通过截图真实保留平台运行状态。 Prometheus平台的监控报警功能还未覆盖到整个业务系统，部分问题还未能实时监控到，导致平台出现异常后而无法感知。 当前并不能保证客户环境的Prometheus平台本身不存在问题，针对这种不确定性，定期巡检是一个保障平台稳定性的方案，实现平台双保障。 部分客户环境不能够连接外网，Prometheus的监控告警信息无法同步到微信、飞书等，但可以通过定期巡检方案来保障平台稳定运行。 由于以上原因，为了保证SLA，必须进行定期巡检。 二、巡检检查项2.1 服务器基础信息 cpu 利用率 磁盘利用率 内存利用率 服务器时间同步 日常数据备份文件检查 2.2 ...

序 APSCheduler 简介在平常的工作中有些工作都需要定时任务来推动，例如项目中有一个定时刷新排行榜的程序脚本、定时爬出网站的URL程序、定时检测钓鱼网站的程序等等，都涉及到了关于定时任务的问题；虽然这些定时任务在服务器上面都能通过crontab来做；其次想到的是利用time模块的time.sleep()方法使程序休眠来达到定时任务的目的，虽然前两者也可以，但是总觉得不是那么的专业，😁所以就找到了python的定时任务模块APScheduler; APScheduler基于Quartz的一个Python定时任务框架，实现了Quartz的所有功能，使用起来十分方便。提供了基于日期、固定时间间隔以及crontab类型的任务，并且可以持久化任务。基于这些功能，我们可以很方便的实现一个python定时任务系统。 同时APScheduler还提供了Flask的扩展Flask-Apscheduler, 那正好就可以拿来做一个集成定时任务平台; APScheduler有四个组成部分 触发器(trigger)包含调度逻辑，每一个作业有它自己的触发器，用于决定接下来哪一个作业会运行。...

基于harbor搭建企业docker镜像仓库背景docker中要使用镜像，一般会从本地、docker Hup公共仓库和其它第三方公共仓库中下载镜像，一般出于安全和外网(墙)资源下载速率的原因考虑企业级上不会轻易使用。那么有没有一种办法可以存储自己的镜像又有安全认证的仓库呢? —-> 企业级环境中基于Harbor搭建自己的安全认证仓库。 Harbor是VMware公司最近开源的企业级Docker Registry项目, 其目标是帮助用户迅速搭建一个企业级的Docker registry服务。 安装Harborharbor需要安装docker和docker-compose才能使用，安装docker步骤省略， 安装docker-domposedocker-dompose安装步骤如下： 下载最新版的docker-compose文件 1$ curl -L https://github.com/docker/compose/releases/download/1.23.2/docker-compose-$(uname -s)-$(uname -m) -o /usr/l...

my experience with cka exam preparation What is CKA?CKA全称就是Certified Kubernetes Adminsitrator，是由CNCF(Cloud Native Computing Foundation 云原生计算基金会)提供的认证项目，考试费用为300美金，必须要双币行用卡，考试过程为3个小时。我办理的是招行的MasterCard，给了20块加急；缴考试费到考完整个流程方面还是非常简单的。  如果考试第一次考试不通过，账号内会生成一个`Free Retake`，在一年之内有一次免费重考的机会。 Why should obtain certification很有幸在春节前(2019/01/06)完成了2018下半年既定的目标，将CKA顺利拿下。很巧合的是在6年前也就是2013年1月5号我通过了RHCE认证考试(虽然我的RHCE认证早已过期，但是我更想说的是: 万变不离其宗 ) 当K8S已经进入到各行各业，那么一套公正权威的管理员测评体系必然就...

一、概述本文主要记录一下搭建一个kubelet搭建到加入集群到手动、自动(证书轮换的)证书认证过程, 那么我的环境是用的v1.12.4版本，有一台master,除了master上面的一些组件已经搭建完毕，主要重点是在kubelet上面，所以现在就是master已经工作正常的情况下，加入新的kubelet(worker节点)需要做一些什么样的操作。然后需要实现的是: 通过bootstrap token以及boostrap.kubeconfig来引导worker节点申请证书 如果第一步申请发出去之后，在手动在master端进行手动批准证书申请，然后发放kubelet证书 实现kubelet证书的自动批准 实现kubelet证书的自动轮换操作 简单理一下TLS Bootstrapping的一个引导过程 master端创建API Server和Kubelet Client通信凭证即生成 apiserver.pem/apiserver-key.pem/apiserver.csr; 在集群内创建特定的 Bootstrap Token Secret，该 Secret 将替代以前的 tok...

概述etcd是CoreOS团队于2013年6月发起的开源项目，它的目标是构建一个高可用的分布式键值(key-value)数据库。etcd内部采用raft协议作为一致性算法，etcd基于Go语言实现。 etcd作为服务发现系统，有以下的特点： 简单：安装配置简单，而且提供了HTTP API进行交互，使用也很简单安全：支持SSL证书验证快速：根据官方提供的benchmark数据，单实例支持每秒2k+读操作可靠：采用raft算法，实现分布式系统数据的可用性和一致性 etcd项目地址：https://github.com/coreos/etcd/ kubernetes中的使用目前etcd是作为kubernetes集群当中的存储后端 在kuernetes中etcd涉及到的安全相关的主要有: etcd支持备份恢复机制，防止数据被误删导致数据丢失 用户的敏感信息建议放在secret类型的资源中，该类型资源是加密存储在etcd中的 etcd支持https, kube-apiserver访问etcd使用https协议 在kubernetes中的配置: Client -> Server1...

概述今儿是冬至，尽管如此，学习的脚步还是不能停下，今天学习实践一下kubernetes中的静态pod是什么？ 我们知道在前面Pod的声明周期管理都是通过像DaemonSet、StatefulSet、Deployment这种方式创建管理的，而官方文档介绍了一种特殊的pod就是静态Pod， 什么是静态Pod静态Pod是由kubelet进行管理，仅存在于特定Node上的Pod。它们不能通过API Server进行管理，无法与ReplicationController、Deployment或DaemonSet进行关联，并且kubelet也无法对其健康检查。 静态Pod的创建:静态pod可以通过两种方式创建：使用配置文件或HTTP。 通过配置文件创建配置文件只是特定目录中json或yaml格式的标准pod定义。他通过在kubelet守护进程中添加配置参数--pod-manifest-path=<the directory> 来运行静态Pod，kubelet经常会它定期扫描目录； 例如，如何将一个简单web服务作为静态pod启动 选择运行静态pod的节点服务器不一定是node节点...

概述Secret对象与ConfigMap对象类似，但它主要用于存储以下敏感信息，例如密码，OAuth token和SSH key等等。将这些信息存储在secret中，和直接存储在Pod的定义中，或Docker镜像定义中相比，更加安全和灵活。 kuberntes中内置了三种secret类型: Opaque：使用base64编码存储信息，可以通过base64 –decode解码获得原始数据，因此安全性弱。 kubernetes.io/dockerconfigjson：用于存储docker registry的认证信息。 kubernetes.io/service-account-token：用于被 serviceaccount 引用。serviceaccout 创建时 Kubernetes 会默认创建对应的 secret。Pod 如果使用了 serviceaccount，对应的 secret 会自动挂载到 Pod 的 /run/secrets/kubernetes.io/serviceaccount 目录中。(前面博文记录过实践后的食用方法) Opaque SecretOpaque...

概述当你使用kuberentes的时候，有没有遇到过Pod在启动后一会就挂掉然后又重新启动这样的恶性循环？你有没有想过kubernetes是如何检测pod是否还存活？虽然容器已经启动，但是kubernetes如何知道容器的进程是否准备好对外提供服务了呢？ 本博文主要记录实践如何配置容器的存活和就绪探针。 liveness probe（存活探针）用于判断容器是否存活，即Pod是否为running状态，如果LivenessProbe探针探测到容器不健康，则kubelet将kill掉容器，并根据容器的重启策略是否重启，如果一个容器不包含LivenessProbe探针，则Kubelet认为容器的LivenessProbe探针的返回值永远成功。 readiness probe（就绪探针）用于判断容器是否启动完成，即容器的Ready是否为True，可以接收请求，如果ReadinessProbe探测失败，则容器的Ready将为False，控制器将此Pod的Endpoint从对应的service的Endpoint列表中移除，从此不再将任何请求调度此Pod上，直到下次探测成功。 每类探针都支持三种...

概述首先需要了解这三种机制的区别： 认证(Authenticating)是对客户端的认证，通俗点就是用户名密码验证， 授权(Authorization)是对资源的授权，k8s中的资源无非是容器，最终其实就是容器的计算，网络，存储资源，当一个请求经过认证后，需要访问某一个资源（比如创建一个pod），授权检查都会通过访问策略比较该请求上下文的属性，（比如用户，资源和Namespace），根据授权规则判定该资源（比如某namespace下的pod）是否是该客户可访问的。 准入(Admission Control)机制是一种在改变资源的持久化之前（比如某些资源的创建或删除，修改等之前）的机制。在k8s中，这三种机制如下图：k8s的整体架构也是一个微服务的架构，所有的请求都是通过一个GateWay，也就是kube-apiserver这个组件（对外提供REST服务），由图中可以看出，k8s中客户端有两类，一种是普通用户，一种是集群内的Pod，这两种客户端的认证机制略有不同，后文会详述。但无论是哪一种，都需要依次经过认证，授权，准入这三个机制。 kubernetes 中的认证机制需要注意的...

序、为何需要存储卷容器部署过程中一般有以下三种数据: 启动时需要的初始数据，可以是配置文件 启动过程中产生的临时数据，该临时数据需要多个容器间共享 启动过程中产生的持久化数据 以上三种数据都不希望在容器重启时就消失，存储卷由此而来，它可以根据不同场景提供不同类型的存储能力。各类卷:  spec.volumes：通过此字段提供指定的存储卷 spec.containers.volumeMounts：通过此字段将存储卷挂接到容器中 一、普通存储卷的用法:容器启动时依赖数据1. ConfigMap上图也说了它是在容器启动的时候以来的数据来源 示例：12345678910111213141516171819202122232425262728293031323334353637383940# 1.创建configmap预制数据卷cat >> configmap.yaml << EOFapiVersion: v1data: guomaoqiu: hello-worl...

概述概念StatefulSet 是为了解决有状态服务的问题（对应 Deployments 和 ReplicaSets 是为无状态服务而设计），其应用场景包括 稳定的持久化存储，即 Pod 重新调度后还是能访问到相同的持久化数据，基于 PVC 来实现 稳定的网络标志，即 Pod 重新调度后其 PodName 和 HostName 不变，基于 Headless Service（即没有 Cluster IP 的 Service）来实现 有序部署，有序扩展，即 Pod 是有顺序的，在部署或者扩展的时候要依据定义的顺序依次依序进行（即从 0 到 N-1，在下一个 Pod 运行之前所有之前的 Pod 必须都是 Running 和 Ready 状态），基于 init containers 来实现 有序收缩，有序删除（即从 N-1 到 0） 从上面的应用场景可以发现，StatefulSet 由以下几个部分组成： 用于定义网络标志（DNS domain）的 Headless Service 用于创建 PersistentVolumes 的 volumeClaimTemplates 定义具体应...