通过shell脚本扫描从Kubernetes节点往外的tcp请求
2023-4-4
由于Kubernetes中部署的服务队外发起的tcp请求很难监控, 最近数据库运维在排查来自集群的大量数据库请求, 网络层只能看到来自哪个Kubernetes节点主机. 所以写了下面这个脚本来定时扫描.
technology
使用docker运行orcale xe 11g
2022-10-18
注意: 根据自己实际情况, 替换下面名利中的<var>变量. 启动orcale xe 11g容器 # Oracle Database XE是人人都可免费使用的 Oracle 数据库. Oracle Database XE 支持最高: 最多 12 GB 的用户磁盘数据 最大 2 GB 的数据库 RAM 最多 2 个 CPU 线程 产品介绍地址: https://www.oracle.com/cn/database/technologies/appdev/xe.html Oracle Database XE支持容器化部署, 镜像项目地址(这里面也有详细使用文档): https://hub.docker.com/r/oracleinanutshell/oracle-xe-11g docker run -d \ --name=oracle-xe-11g \ --restart=always \ -p 31521:1521 \ -p 38080:8080 \ -v /data/oracle_data:/opt/oracle/oracle_data:rw \ oracleinanutshell/oracle-xe-11g 该镜像的默认登录信息是: hostname: localhost port: 31521 sid: xe username: system 或者 sys password: oracle 使用了主机的/data/oracle_data目录作为数据持久化目录. ...
使用fluentd收集kubernetes日志并推送给kafka
2022-10-3
这篇文章使用fluentd官方提供的kubernetes部署方案daemonset来部署日志收集, 参考项目地址: https://github.com/fluent/fluentd-kubernetes-daemonset 本文使用的kubernetes版本为: 1.22.8 使用fluentd镜像为: fluent/fluentd-kubernetes-daemonset:v1.15.2-debian-kafka2-1.0 请注意下文配置中<var>标记, 需要根据需求自行替换. 创建命名空间 # 本项目所有的资源创建在logging下, 先创建它: kubectl create ns logging-kafka 先创建服务账号 # 创建服务账号并赋予集群查看的权限, 使用下面的命令: kubectl -n logging-kafka create -f - <<EOF apiVersion: v1 kind: ServiceAccount metadata: name: fluentd EOF 创建绑定关系: kubectl create -f - <<EOF kind: ClusterRoleBinding apiVersion: rbac.authorization.k8s.io/v1 metadata: name: fluentd-kafka roleRef: kind: ClusterRole name: view apiGroup: rbac.authorization.k8s.io subjects: - kind: ServiceAccount name: fluentd namespace: logging-kafka EOF 创建配置文件 # 执行下面到命令创建configmap: ...
使用fluentd收集kubernetes日志并推送到ES
2022-9-20
这篇文章使用fluentd官方提供的kubernetes部署方案daemonset来部署日志收集, 参考项目地址: https://github.com/fluent/fluentd-kubernetes-daemonset 本文使用的kubernetes版本为: 1.22.8 使用fluentd镜像为: fluent/fluentd-kubernetes-daemonset:v1.15.2-debian-elasticsearch7-1.0 请注意下文配置中<var>标记, 需要根据需求自行替换. 创建命名空间 # 本项目所有的资源创建在logging下, 先创建它: NAMESPACE=logging kubectl create ns $NAMESPACE 先创建服务账号 # 创建服务账号并赋予集群查看的权限, 使用下面的命令: kubectl -n $NAMESPACE create -f - <<EOF apiVersion: v1 kind: ServiceAccount metadata: name: fluentd EOF 创建绑定关系: kubectl create -f - <<EOF kind: ClusterRoleBinding apiVersion: rbac.authorization.k8s.io/v1 metadata: name: fluentd roleRef: kind: ClusterRole name: view apiGroup: rbac.authorization.k8s.io subjects: - kind: ServiceAccount name: fluentd namespace: ${NAMESPACE} EOF 创建配置文件 # 配置文件使用configmap挂在在容器内, 覆盖容器内现有的配置文件. ...
Envoy的静态配置使用方法
2022-9-15
Envoy静态配置 # L4转发 # 下面的例子是配置4层转发, 将443端口的流量都代理到www.example.com对应的后端的443端口上, 如下: static_resources:listeners:- name:listener_0address:socket_address:protocol:TCPaddress:0.0.0.0port_value:443filter_chains:- filters:- name:envoy.filters.network.tcp_proxytyped_config:"@type": type.googleapis.com/envoy.extensions.filters.network.tcp_proxy.v3.TcpProxystat_prefix:tcp_443cluster:cluster_0clusters:- name:cluster_0type:LOGICAL_DNSdns_lookup_family:V4_ONLYload_assignment:cluster_name:cluster_0endpoints:- lb_endpoints:- endpoint:address:socket_address:address:www.example.comport_value:443启动Envoy # 将创建的静态配置文件envoy-custom.yaml映射到容器内部, 启动: docker run -d --name=envoy --restart=always \ -p 443:443 -v /root/envoy-custom.yaml:/etc/envoy/envoy.yaml \ envoyproxy/envoy:v1.22.2
使用rsync在主机之间同步目录
2022-8-30
rsync安装 # 在传输双方的服务器上都安装rsync软件. 如果服务器上有rsync可以跳过. 先检查有没有安装rsync: rsync -h 如果没有安装, 使用下面的命令安装: # Debian sudo apt-get install rsync # Red Hat sudo yum install rsync # Arch Linux sudo pacman -S rsync 启动rsync守护进程 # rsync使用最多的是ssh模式. 在现代的公司中, 出于安全的原因, 很多ssh是被禁止使用的. 所以, 我们可以使用rsync的守护进程模式. 一起看看怎么用吧. rsync守护进程部署在传输双方(发送方或者接受方)的任何一端都可以的. 下面的配置和命令中, 我以发送方(10.138.228.201)和接收方(10.206.38.30)为例. 我选择接收方, 先部署配置文件. 配置文件地址: /etc/rsyncd.conf. 配置文件 官方参考手册 以下是一个参考的配置, 每一项配置我都增加了备注说明: # 指定rsync以什么用户/组传输文件 # 默认nobody,如果使用了系统不存在的用户和组 # 需要先手动创建用户和组 # 它会是生成的文件所属的用户和组 # 也可以把它们配置到模块中 uid = root gid = root # 选择yes可以在操作模块时chroot到同步目录中 # 优势是面对安全威胁能提供额外保护 # 缺点是使用chroot需要root权限, # 以及在传输符号连接或保存用户名/组时会有些问题 use chroot = no # 指定监听端口 # 默认873 port = 873 # 最大连接数 max connections = 200 # 超时时间 timeout = 600 # 进程pid所在的文件 pid file = /var/run/rsyncd. ...
使用etcdctl查看kubernetes存储的内容
2022-8-29
下面这个脚本提供了etcdctl连接etcd所需要的断点、证书相关的信息, 能快速或许并调用命令查看, 这个脚本需要在master节点上执行: #!/bin/bash ENDPOINTS=$(ps -ef | grep kube-apiserver | grep -P 'etcd-servers=(.*?)\s' -o | awk -F= '{print $2}') CACERT=$(ps -ef | grep kube-apiserver | grep -P 'etcd-cafile=(.*?)\s' -o | awk -F= '{print $2}') CERT=$(ps -ef | grep kube-apiserver | grep -P 'etcd-certfile=(.*?)\s' -o | awk -F= '{print $2}') KEY=$(ps -ef | grep kube-apiserver | grep -P 'etcd-keyfile=(.*?)\s' -o | awk -F= '{print $2}') alias etcdctl='ETCDCTL_API=3 etcdctl --endpoints=${ENDPOINTS} --cacert=${CACERT} --key=${KEY} --cert=${CERT} -w=json' 好了下面可以直接使用etcdctl命令了, 比如: ...
MetalLB二层模式使用指南
2022-8-8
MetalLB概念安装配置和使用请查看 测试组件的版本情况 # kubernetes: v1.22.8 metellb: v0.10.3 nginx: latest 创建测试应用 # 创建一个nginx服务和service资源: kubectl -n without-istio create deploy nginx --image=nginx 测试分配IP # 创建loadbalancer类型的service: kubectl -n without-istio create service loadbalancer nginx --tcp=80:80 查看该service详细配置: apiVersion:v1kind:Servicemetadata:labels:app:nginxnamespace:without-istioname:nginx...spec:allocateLoadBalancerNodePorts:trueclusterIP:10.233.15.89clusterIPs:- 10.233.15.89externalTrafficPolicy:ClusterinternalTrafficPolicy:ClusteripFamilies:- IPv4ipFamilyPolicy:SingleStackports:- name:80-80nodePort:30662port:80protocol:TCPtargetPort:80selector:app:nginxsessionAffinity:Nonetype:LoadBalancerstatus:loadBalancer:ingress:- ip:10.206.65.234可以发现external-ip已经完成分配. 在同一个局域网内, 使用curl命令测试联通情况: 可以看到, 是可以正常访问的. 手动指定地址池 # 默认, metallb会从所有的可用地址池中分配IP, 除非我们关闭某一个地址池的自动分配auto-assign: false. metallb v0.12之前都是用configmap进行配置, 而不是用CRD. 这里是 配置相关文档. 下面我们让集群中有两个地址池, 其中一个关闭自动分配. 修改metallb的配置文件, 增加一个address-pools(expensive), 地址范围10.206.65.224-10.206.65.233, 如下: kubectl -n metallb-system edit cm config 可以看到目前有两个地址池, 同时配置auto-assign: false来关闭对expensive地址池的自动分配. ...
在istio service mesh中使用nginx反向代理
2022-8-8
nginx反向代理的请求, 和我们直接请求有一定的区别, 比如: http version # nginx proxy 发出的反向代理请求的http version默认是: 1.0, 但是istio支持1.1 & 2.0, 所以如果不增加http版本限制的话istio就无法进行报文解析, 也就无法应用istio-proxy(sidecar)L7层代理策略, 我们知道istio流量治理是基于L7层的. http header: Host # 有时候nginx发出的代理请求的http header中host的值, 不能保证是上游服务的host name. 在这种情况下, 是没办法匹配上游服务在istio-proxy中的L7流量治理的配置. 怎么解决? # 所以, 需要在nginx代理配置处增加两项配置: ... location / { proxy_http_version 1.1; <- proxy_set_header Host <upstream-host>; <- proxy_pass http://<upstream-host>:8080; } ... 即可. 参考 # nginx官方文档proxy_http_version介绍 nginx官方文档proxy_set_header介绍
Fluentd配置文件最佳实践
2022-7-31
Fluentd负责Kubernetes中容器日志的收集工作, 以Daemonset形式运行在每一个节点上. 下面这个配置是在多个生产集群使用的配置, 经过多次调优的. 有一些关键的配置增加了配置解释说明. 目前使用问题不大. 持续更新配置中…