杂烩饭

假设 Prometheus1 是一个集群内的 Prometheus，需要远程写入数据到 Prometheus_Core Prometheus_Core 开启 remote_write_receiverPrometheus_Core 需要打开接收远程写入的功能，通过增加启动参数 --web.enable-remote-write-receiver： 1./prometheus --web.enable-remote-write-receiver --web.config.file=web.yml --web.listen-address=0.0.0.0:9090 远程写的接口地址 /api/v1/write Prometheus_Core 开启认证参考 Prometheus开启basic_auth认证 Prometheus1 配置 remote_writePrometheus1 需要将 remote_write 写入到 Prometheus_Core 的远程接口 12345678910111213141516remote_write:- url:...

考虑将公司的联邦集群（pull）换成 remote_write（push）这种形式， 所以需要将 Prometheus 开放到公网，看了看认证相关的配置 也可以使用 Nginx 来反向代理，可以参考 Nginx开启基本http认证， 不过 Prometheus 原生带了 basic auth 和 ssl 认证, 官网的说明https://prometheus.io/docs/guides/basic-auth/ 开启 web 配置文件1./prometheus --web.config.file="web.yml" --web.listen-address="0.0.0.0:9001" 生成密码密码需要 bcrypt 加密，这里使用 htpasswd 工具生成 Ubuntu和Debian安装CentOS和Fedora安装1apt install apache2-utils1yum install httpd-tools 1htpasswd -nB 'admin' web 配置文件vim...

在 k8s 环境下进行灰度，ingress-nginx 自带了灰度注解， 这篇文章挺详细的https://v2-1.docs.kubesphere.io/docs/zh-CN/quick-start/ingress-canary/ 再此之前有个需求， 根据请求 header 有没有特定的值，来判断是否进入灰度环境。当时的做法是在集群内用 nginx 12345# 如果有个header叫grayif ($http_gray = "true") { proxy_pass http://nginx.test1:80; break;} 这种方式可以实现需求， 不过不灵活， 也不优雅， 搜了一下， 发现 ingress nginx 原生提供了灰度的方案 ingress 自带 canary 部署简单来说就是部署了两套环境， 这两套一模一样， 只是在不同的 namespace（同一个 namespace 需要取不同的名字），service 和 ingress 域名都配置成一样的， 然后在 canary 环境的 ingress...

使用 k8s 的 ingress 暴露服务，会有使用负载均衡反向代理 ingress 的情况，那么我们的 ingress 获取到的 ip 都是 4 层负载的 ip，比如常用架构图 4 层 Proxy Protocol 透传 tcp 工作在网络第 4 层,Proxy Protocol 就是在 tcp 中增加一个小的报头，用来存储额外的信息 代理协议即 Proxy Protocol,是 haproxy 的作者 Willy Tarreau 于 2010 年开发和设计的一个 Internet 协议，通过为 tcp 添加一个很小的头信息，来方便的传递客户端信息（协议栈、源 IP、目的 IP、源端口、目的端口等)，在网络情况复杂又需要获取客户 IP 时非常有用。其本质是在三次握手结束后由代理在连接中插入了一个携带了原始连接四元组信息的数据包。 目前 proxy protocol 有两个版本，v1 仅支持 human-readable 报头格式（ASCIII 码），v2 需同时支持 human-readable 和二进制格式，即需要兼容 v1 格式proxy protocol...

centos7 的默认源里面的 git 版本是 1.8.3, 比较老了, 对于有些操作会提示 git 版本太低, 可以使用第三方源的方式来安装新版本的 git 使用 Wandisco 源创建仓库文件 12345678cat > /etc/yum.repos.d/wandisco-git.repo <<-'EOF'[wandisco-git]name=Wandisco GIT Repositorybaseurl=http://opensource.wandisco.com/centos/7/git/$basearch/enabled=1gpgcheck=1gpgkey=http://opensource.wandisco.com/RPM-GPG-KEY-WANdiscoEOF 安装 git1sudo yum install git 查看版本1git version 离线安装 (手动安装 rpm)下载两个文件到本地 12wget...

单项认证只需要服务器提供证书即可, 不验证客户端证书, 而双向认证需要验证服务器证书,也需要验证客户端证书, 不满足要求的客户端可以不允许其访问, 并且可以通过后期吊销证书的方式禁止其访问. 证书签名可以参考: 使用certbot自动申请ssl证书 使用acme.sh来自动更新https证书 制作和使用自签名证书 本文提到的 client.crt server.crt 都是通过 ca 签发的 服务器配置Nginx 配置: 1234567891011121314151617server { listen 443 ssl; server_name localhost; ssl_certificate ssl/server.crt; # 配置证书位置 ssl_certificate_key ssl/server.key; # 配置私钥位置 ssl_client_certificate ssl/ca.crt; # 客户端证书 ...

在很多使用到证书的场景, 比如 HTTPS, 可以选择去申请一个免费的证书, 也可以尝试自签名证书, 申请免费证书请看:使用certbot自动申请ssl证书 或者 使用acme.sh来自动更新https证书, 本文介绍自签名证书. 可以直接使用我制作好的工具，一键生成证书：https://github.com/iuxt/my_cert SSL 协议加密方式SSL 协议即用到了对称加密也用到了非对称加密 (公钥加密)，在建立传输链路时，SSL 首先对对称加密的密钥使用公钥进行非对称加密，链路建立好之后，SSL 对传输内容使用对称加密。 对称加密 速度高，可加密内容较大，用来加密会话过程中的消息。 公钥加密 加密速度较慢，但能提供更好的身份认证技术，用来加密对称加密的密钥。 CA 证书生成 CA 私钥1openssl genrsa -out ca.key 4096 生成一个 ca.key 文件 生成 CA 证书非交互式创建交互式创建1openssl req -utf8 -new -x509 -days 3650 -key ca.key -out ca.crt...

常见的使用 Nginx 进行防盗链配置是利用了 referer, 也就是来源地址来判断, 只要不是白名单中的地址, 就禁止访问, referer 是比较有效的方式, 但是可以轻松绕过, 目的是为了防止页面被别人复制粘贴我们的文章, 图片等资源依然使用我们的连接, 占用带宽或流量造成费用. 白名单模式这种模式就是在白名单之外的所有域名都不能请求我们的图片等资源 配置示例: 1234567891011121314151617181920212223242526# 资源防盗链（指定目录or指定文件类型） location ~ .*\.(gif|jpg|jpeg|png|bmp|swf)$ { # location /upload/ { access_log off; # none：表示没有 referer 的可以访问 # blocked：表示 referer 没有值的可以访问 # server_names：表示 Nginx 的 server_name 可以访问 # ~.*google\.：google 前后都是正则匹配,...

kubernetes 每次更新资源会记录资源的历史版本， 方便我们进行回滚操作。真的 k8s 解决了很多运维的痛点问题, 想起来以前没有用 k8s 的时候,用 jenkins 和 ansible 来做的发布和回滚… 查看历史版本12345678kubectl rollout history deployment nfs-client-provisionerdeployment.apps/nfs-client-provisionerREVISION CHANGE-CAUSE1 <none>2 <none>4 <none>5 <none> 这里列出的就是版本， 为什么没有 3， 因为从版本 4 回滚到了版本 3， 则版本 3 就变成了版本 5 查看指定版本详情1kubectl rollout history deployment nfs-client-provisioner --revision=4 回滚到指定版本1kubectl rollout undo...

单节点升级 master 总体来说就是两步， 先修改 apiserver 地址为负载均衡地址，然后添加新的 master 节点。 搭建集群的时候我们注意一下就可以减少后期维护的烦恼，比如： 使用 hostname 而不是 ip 来作为 kube-apiserver 地址 单节点也把负载均衡安排上 假设已经有一个没有负载均衡的单节点 master，现在想将它切换为高可用集群，记录以下步骤： 部署负载均衡参考 Kubernetes之master高可用方案 更新证书 因为我们部署了负载均衡，所以需要通过负载均衡的地址来访问 apiserver，因为证书是针对域名或者 ip 做的签名，如果 ip 变了证书就失效了，这也是为什么建议使用 hostname 来代替 ip 如果你是用 kubeadm init 来创建的集群，那么你需要导出一个 kubeadm 配置 1kubectl -n kube-system get configmap kubeadm-config -o...