blackhole引起k8s DNS访问异常

Ubuntu 20.04 部署生产级 Postfix 邮件服务器实战指南 邮件服务器是现代运维中关键的异步通信基座,其核心在于可控投递、状态可溯与异常自愈。Postfix 作为成熟稳定的MTA(邮件传输代理),依托其模块化架构和精细的队列控制机制,天然适配本地化、合规性与离线场景需求。在 Ubuntu 系统生态中,20.04 版本提供了长期支持与稳定内核,但原生 postfix 包存在 IPv6 监听禁用、TLS 证书权限陷阱及 debconf 配置劫持等隐蔽风险。本文聚焦于构建‘零外部依赖、全链路可审计、多异常可降级’的本地邮件分发基座,覆盖从基础监听配置、transport_ 阅读详情

环境背景

3个节点的k8s集群:

[root@kube-196 ~]# kubectl get nodes
NAME       STATUS   ROLES    AGE   VERSION
kube-195   Ready    <none>   8d    v1.14.2
kube-196   Ready    master   12d   v1.14.1
kube-197   Ready    <none>   12d   v1.14.1

网络方案为flannel host-gw+ipvs。

部署情况

[root@kube-196 ~]# kubectl get all -A -o wide
NAMESPACE     NAME                                             READY   STATUS             RESTARTS   AGE     IP                NODE       NOMINATED NODE   READINESS GATES
default       pod/apm-kafka-0                                  0/1     CrashLoopBackOff   16         47m     10.244.1.16       kube-197   <none>           <none>
default       pod/apm-kafka-zookeeper-0                        1/1     Running            0          47m     10.244.1.15       kube-197   <none>           <none>
default       pod/apm-kafka-zookeeper-1                        1/1     Running            0          46m     10.244.2.31       kube-195   <none>           <none>
default       pod/apm-kafka-zookeeper-2                        1/1     Running            1          45m     10.244.2.32       kube-195   <none>           <none>
 
default       pod/testclient                                   1/1     Running            0          29m     10.244.1.17       kube-197   <none>           <none>
 
kube-system   pod/coredns-5f6bc7cdd5-phjzg                     1/1     Running            0          4d23h   10.244.2.10       kube-195   <none>           <none>
kube-system   pod/coredns-5f6bc7cdd5-tvrx8                     1/1     Running            0          79m     10.244.1.14       kube-197   <none>           <none>
kube-system   pod/coredns-5f6bc7cdd5-v96x8                     1/1     Running            0          99m     10.244.1.13       kube-197   <none>           <none>
kube-system   pod/etcd-kube-196                                1/1     Running            4          12d     192.168.200.196   kube-196   <none>           <none>
kube-system   pod/kube-apiserver-kube-196                      1/1     Running            4          22h     192.168.200.196   kube-196   <none>           <none>
kube-system   pod/kube-controller-manager-kube-196             1/1     Running            4          22h     192.168.200.196   kube-196   <none>           <none>
kube-system   pod/kube-flannel-ds-amd64-24l6b                  1/1     Running            0          81m     192.168.200.196   kube-196   <none>           <none>
kube-system   pod/kube-flannel-ds-amd64-d9tbn                  1/1     Running            2          22h     192.168.200.197   kube-197   <none>           <none>
kube-system   pod/kube-flannel-ds-amd64-scmfp                  1/1     Running            0          22h     192.168.200.195   kube-195   <none>           <none>
kube-system   pod/kube-proxy-5nd72                             1/1     Running            0          80m     192.168.200.196   kube-196   <none>           <none>
kube-system   pod/kube-proxy-qrgnf                             1/1     Running            12         12d     192.168.200.197   kube-197   <none>           <none>
kube-system   pod/kube-proxy-sfgr2                             1/1     Running            0          8d      192.168.200.195   kube-195   <none>           <none>
kube-system   pod/kube-scheduler-kube-196                      1/1     Running            5          12d     192.168.200.196   kube-196   <none>           <none>
 
NAMESPACE     NAME                                   TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)                      AGE     SELECTOR
default       service/apm-kafka                      ClusterIP   10.110.242.169   <none>        9092/TCP                     47m     app=kafka,release=apm-kafka
default       service/apm-kafka-0-external           NodePort    10.101.213.10    <none>        19092:31090/TCP              47m     app=kafka,release=apm-kafka,statefulset.kubernetes.io/pod-name=apm-kafka-0
default       service/apm-kafka-1-external           NodePort    10.111.193.151   <none>        19092:31091/TCP              47m     app=kafka,release=apm-kafka,statefulset.kubernetes.io/pod-name=apm-kafka-1
default       service/apm-kafka-2-external           NodePort    10.96.221.224    <none>        19092:31092/TCP              47m     app=kafka,release=apm-kafka,statefulset.kubernetes.io/pod-name=apm-kafka-2
default       service/apm-kafka-headless             ClusterIP   None             <none>        9092/TCP                     47m     app=kafka,release=apm-kafka
default       service/apm-kafka-zookeeper            ClusterIP   10.107.245.32    <none>        2181/TCP                     47m     app=zookeeper,release=apm-kafka
default       service/apm-kafka-zookeeper-headless   ClusterIP   None             <none>        2181/TCP,3888/TCP,2888/TCP   47m     app=zookeeper,release=apm-kafka
 
default       service/kubernetes                     ClusterIP   10.96.0.1        <none>        443/TCP                      12d     <none>
kube-system   service/kube-dns                       ClusterIP   10.96.0.10       <none>        53/UDP,53/TCP,9153/TCP       4d23h   k8s-app=kube-dns


NAMESPACE     NAME                                     DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR                     AGE   CONTAINERS     IMAGES                                   SELECTOR
kube-system   daemonset.apps/kube-flannel-ds-amd64     3         3         3       3            3           beta.kubernetes.io/arch=amd64     22h   kube-flannel   quay.io/coreos/flannel:v0.11.0-amd64     app=flannel,tier=node
kube-system   daemonset.apps/kube-proxy                3         3         3       3            3           <none>                            12d   kube-proxy     k8s.gcr.io/kube-proxy:v1.14.0            k8s-app=kube-proxy

NAMESPACE     NAME                                         READY   UP-TO-DATE   AVAILABLE   AGE     CONTAINERS                   IMAGES                                                               SELECTOR
kube-system   deployment.apps/coredns                      3/3     3            3           4d23h   coredns                      k8s.gcr.io/coredns:1.5.0                                             k8s-app=kube-dns
 

NAMESPACE     NAME                                                   DESIRED   CURRENT   READY   AGE     CONTAINERS                   IMAGES                                                               SELECTOR
kube-system   replicaset.apps/coredns-5f6bc7cdd5                     3         3         3       4d23h   coredns                      k8s.gcr.io/coredns:1.5.0                                             k8s-app=kube-dns,pod-template-hash=5f6bc7cdd5
 

NAMESPACE   NAME                                   READY   AGE   CONTAINERS     IMAGES
default     statefulset.apps/apm-kafka             0/3     47m   kafka-broker   confluentinc/cp-kafka:5.0.1
default     statefulset.apps/apm-kafka-zookeeper   3/3     47m   zookeeper      registry.cn-hangzhou.aliyuncs.com/appstore/k8szk:v2

可以看到从192.168.200.195主机的容器ping 192.168.200.197主机上的其他容器的ip和headless service名字,是可以ping通的。

[root@kube-196 ~]# kubectl exec -it testclient /bin/sh 
# ping apm-kafka-headless
PING apm-kafka-headless.default.svc.cluster.local (10.244.1.16): 56 data bytes
64 bytes from 10.244.1.16: icmp_seq=0 ttl=64 time=0.097 ms
64 bytes from 10.244.1.16: icmp_seq=1 ttl=64 time=0.103 ms
64 bytes from 10.244.1.16: icmp_seq=2 ttl=64 time=0.081 ms
^C--- apm-kafka-headless.default.svc.cluster.local ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max/stddev = 0.081/0.094/0.103/0.000 ms
# ping apm-kafka-zookeeper-headless 
PING apm-kafka-zookeeper-headless.default.svc.cluster.local (10.244.1.15): 56 data bytes
64 bytes from 10.244.1.15: icmp_seq=0 ttl=64 time=0.116 ms
64 bytes from 10.244.1.15: icmp_seq=1 ttl=64 time=0.109 ms
64 bytes from 10.244.1.15: icmp_seq=2 ttl=64 time=0.100 ms
64 bytes from 10.244.1.15: icmp_seq=3 ttl=64 time=0.098 ms
64 bytes from 10.244.1.15: icmp_seq=4 ttl=64 time=0.093 ms
64 bytes from 10.244.1.15: icmp_seq=5 ttl=64 time=0.107 ms
64 bytes from 10.244.1.15: icmp_seq=6 ttl=64 time=0.103 ms
^C--- apm-kafka-zookeeper-headless.default.svc.cluster.local ping statistics ---
7 packets transmitted, 7 packets received, 0% packet loss
round-trip min/avg/max/stddev = 0.093/0.104/0.116/0.000 ms
 
# ping apm-kafka-zookeeper-headless
PING apm-kafka-zookeeper-headless.default.svc.cluster.local (10.244.1.15): 56 data bytes
64 bytes from 10.244.1.15: icmp_seq=0 ttl=64 time=0.095 ms
64 bytes from 10.244.1.15: icmp_seq=1 ttl=64 time=0.099 ms
64 bytes from 10.244.1.15: icmp_seq=2 ttl=64 time=0.118 ms
64 bytes from 10.244.1.15: icmp_seq=3 ttl=64 time=0.113 ms
64 bytes from 10.244.1.15: icmp_seq=4 ttl=64 time=0.145 ms
^C--- apm-kafka-zookeeper-headless.default.svc.cluster.local ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/stddev = 0.095/0.114/0.145/0.000 ms

但ping 不同192.168.200.195上的容器(10.244.2.31)。

# ping 10.244.2.31
PING 10.244.2.31 (10.244.2.31): 56 data bytes

直接ping 192.168.200.195的宿主机也是通的,也就是说网络包到达195的宿主机之后,没有路由到容器内。

查看195的路由

[root@kube-195 ~]# ip route
default via 192.168.200.254 dev eth0  proto static  metric 100 
10.244.0.0/24 via 10.244.0.0 dev flannel.1 onlink 
10.244.1.0/24 via 10.244.1.0 dev flannel.1 onlink 
blackhole 10.244.2.0/24  proto bird 
10.244.2.0/24 dev cni0  proto kernel  scope link  src 10.244.2.1 
169.254.169.254 via 192.168.200.130 dev eth0  proto dhcp  metric 100 
192.168.82.0/24 dev docker0  proto kernel  scope link  src 192.168.82.1 
192.168.200.0/24 dev eth0  proto kernel  scope link  src 192.168.200.195  metric 100 

发现有条

blackhole 10.244.2.0/24  proto bird

的路由规则。其在

10.244.2.0/24 dev cni0  proto kernel  scope link  src 10.244.2.1

之前。所以所有在195主机上路由到10.244.2.0/24 子网的包都会被丢弃。

[root@kube-195 ~]# ip route del 10.244.2.0/24

删除该路由规则。

[root@kube-195 ~]# ip route
default via 192.168.200.254 dev eth0  proto static  metric 100 
10.244.0.0/24 via 10.244.0.0 dev flannel.1 onlink 
10.244.1.0/24 via 10.244.1.0 dev flannel.1 onlink 
10.244.2.0/24 dev cni0  proto kernel  scope link  src 10.244.2.1 
169.254.169.254 via 192.168.200.130 dev eth0  proto dhcp  metric 100 
192.168.82.0/24 dev docker0  proto kernel  scope link  src 192.168.82.1 
192.168.200.0/24 dev eth0  proto kernel  scope link  src 192.168.200.195  metric 100 

就可以ping通了:

# ping apm-kafka-zookeeper-headless
PING apm-kafka-zookeeper-headless.default.svc.cluster.local (10.244.2.31): 56 data bytes
64 bytes from 10.244.2.31: icmp_seq=0 ttl=62 time=0.920 ms
64 bytes from 10.244.2.31: icmp_seq=1 ttl=62 time=0.765 ms
64 bytes from 10.244.2.31: icmp_seq=2 ttl=62 time=0.940 ms
64 bytes from 10.244.2.31: icmp_seq=3 ttl=62 time=0.924 ms
^C--- apm-kafka-zookeeper-headless.default.svc.cluster.local ping statistics ---
4 packets transmitted, 4 packets received, 0% packet loss
round-trip min/avg/max/stddev = 0.765/0.887/0.940/0.071 ms

发现calico网络也有类似的问题:
https://github.com/projectcalico/calico/issues/2457
因为我们的集群之前也安装过calico,而该规则适用于calico网络下本机访问的。

参考

blackhole可以用于阻止登录。

In the world of systems administration, having the commands to add or remove a blackhole / nullroute a host or problematic IP address can be very useful. So in this simple, yet useful tutorial, we’ll cover how to exactly go about doing this on nearly any type of Linux OS!

  • How to add a blackhole nullroute:

For this example, let’s assume that we are receiving unwanted SSH login attempts from 192.168.0.195 .

root@server:~# netstat -na | grep :22
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN
tcp 0 0 192.168.0.197:22 192.168.0.195:57776 ESTABLISHED

To add the blackhole for 192.168.0.195:

root@server:~# ip route add blackhole 192.168.0.195/32

To verify the route is in place will will use “ip route show “:

root@server:~# ip route show
default via 192.168.0.1 dev eth0 metric 100
blackhole 192.168.0.195

Subsequently, connections to and from that IP will fail:

root@attacker:~$ ssh 192.168.0.2
ssh: connect to host 192.168.0.2 port 22: No route to host
  • Removing a blackhole:

Typically, blackholes are useful when your server is under attack. After the attack has subsided, or you wish to remove the blackhole you can do so as follows:

root@server:~# ip route del 192.168.0.195
root@server:~# ip route show
default via 192.168.0.1 dev eth0 metric 100
数据库安全不是加把锁:动态纵深防御体系实战指南 数据库安全本质上是数据资产的全生命周期防护,其核心在于从静态配置转向动态、分层、可验证的纵深防御机制。基于最小权限原则、网络微隔离、TDE透明加密、TLS传输加密及行为级审计等关键技术,构建覆盖认证、访问、存储、传输与监控的五层防护链。尤其在云原生与内部威胁加剧背景下,MFA多因素认证、动态权限升降级、SQL指纹识别、代理层策略执行等实操手段,显著提升攻击成本并降低误操作风险。本文聚焦MySQL等主流关系型数据库,提供从基线初始化、自动化权限治理到加密体系压测验证的完整工程化落地路径。 阅读详情

相关推荐

FreeBSD高级网络实战:pf防火墙、CARP高可用与Netgraph虚拟化

FreeBSD并非Linux替代品,而是源自BSD学术传统的完整操作系统,其TCP/IP协议栈、pf有状态防火墙、CARP+pfsync高可用机制及Netgraph内核级网络图框架,共同构成企业级确定性网络的底层基石。相比Linux依赖eBPF+tc+XDP的多层叠加方案,FreeBSD在QoS调度、连接状态同步、零拷贝隧道等场景提供更精简、更低延迟、更高一致性的原生支持。它适用于对吞吐、抖动、调度确定性有严苛要求的CDN边缘、金融低延迟网关、教育专网骨干等场景,尤其适合已掌握Linux netfilter

dfu65065的博客 818

K8S Calico

1. 概述 Calico是一个基于 BGP 的纯三层网络方案。它在每个计算节点都利用 Linux kernel 实现了一个高效的虚拟路由器 vRouter 来进行数据转发。每个 vRouter 都通过 BGP 协议将本节点上运行容器的路由信息向整个 Calico 网络广播,并自动设置到达其他节点的路由转发规则。 Calico 保证所有容器之间的数据流量都通过 IP 路由的方式完成互联互通。Calico 节点组网可以直接利用数据中心的网络结构 (L2/L3),不需要额外的 NAT,隧道或者 Overlay 网

elihe2011的专栏 950

【信息科学与工程学】【通信工程】计算机科学与自动化——第二百三十三篇 云NaaS服务 系列二01

国家骨干网(含核心网、IP骨干网、OTN骨干网)/城域网【含3G/4G/5G接入网/PON接入网/OTN接入网+OTN/IP城域网+其他】/中心云(多/双/单Region+多AZ/双AZ/单AZ)+边缘DC+边缘计算节点+端计算节点包括IoT传感器、移动终端、CPE设备。通过5G NR(n78频段,带宽100MHz,子载波间隔30kHz)或GPON(下行2.5Gbps,上行1.25Gbps)接入。本地缓存小于10GB,主要用于临时数据暂存。位于地市级机房,部署MEC服务器(Intel Xeon Platin

weixin_49199313的博客 1337

HCNP——黑洞路由和路由表与FIB表

HCNP——黑洞路由和路由表与FIB表

weixin_62594100的博客 4177

【信息科学与工程学】计算机科学与自动化-——第十五篇云计算 12 公有云里的“多Region + 多AZ“ 02 运营算法01

算法逐步思考推理思考(含数学方程式、对象、资源、任务、进程/协程/线程及对应的代数、约束、目标函数/传递函数/依赖函数、参数及参数的数值范围及边界条件、逐步推理的数学方程式列表、上下文切换、并发/串行/随机/乱序/顺序)算法逐步思考推理思考(含数学方程式、对象、资源、任务、进程/协程/线程及对应的代数、约束、目标函数/传递函数/依赖函数、参数及参数的数值范围及边界条件、逐步推理的数学方程式列表、上下文切换、并发/串行/随机/乱序/顺序)云厂商提高闲置资源利用率。算法复杂度为O(N),N为实例数量。

weixin_49199313的博客 282

IT知识百科:什么是黑洞路由?

黑洞路由作为一种重要的网络安全技术,通过简单高效的流量丢弃机制,能够有效防御DDoS攻击、网络扫描和探测。在实际应用中,黑洞路由被广泛应用于不同行业,发挥着重要作用。尽管面临一些挑战,但通过技术创新和策略优化,黑洞路由在未来网络中仍具有广阔的发展前景。

网络技术联盟站 1802

记录一次K8s 集群故障(路由&Calico)

除了 kube-system下的api-server, etcd-admin, scheduler, controller manager, 以及各个3个节点的kube-proxy 处于running状态,因为kube-proxy和calico-node都是ds, 使用Hostnetwork,因此IP就是所在节点IP。确定它就是k8s kube-apiserver-admin这个pod所单独暴露出来的svc, 是单例的pod,不属于任何rs/ds/deployment/sts。

qq_43024789的博客 2329

零入门kubernetes网络实战-5->路由知识总结

本篇文章主要用于收集、整理、总结路由相关知识点。

码二哥的技术池 446

ip route内容详解

– 我们在k8s-calico2这个node上来看。执行ip r, 在这个node的路由中,需要我们关注的有: 192.168.97.2 dev calic285cddbb40 scope link blackhole 192.168.97.0/26 proto bird 192.168.210.192/26 via 10.173.32.26 dev eth0 proto bird 192.168.211.0/26 via 10.173.32.25 dev eth0 proto bird 192..

weixin_42072280的博客 1万+

亚博k210视觉模块与stm32双向通信

【代码】亚博k210视觉模块与stm32双向通信。

w_150831的博客 3246

FPGA之串口收发字符串之(四)——串口屏USART_HMI介绍

之前对串口各模块的设计都做了相关介绍。这里介绍串口屏的相关知识。 本次项目使用的串口屏型号是陶晶驰串口屏TJC3224T024_011,这个型号的串口屏的资料在官网可以找到。本文抛转引玉,简单介绍以便在本工程中更好的应用。 下图是该串口屏的实物图: 一般地,使用单片机或者嵌入式MCU控制串口屏,都会用到串口,同样地,在FPGA中实现也是类似,不过稍微复杂,具体代码设计过程中有以下问题需要...

隔壁old余的博客 7495

Linux核心网络管理命令2

网络管理命令ip:网络配置工具netstat:查看网络状态ss : 查看网络状态ping : 测试主机之间的网络连通性nmap:网络探测工具和安全/端口扫描器tcpdump:监听网络流量 ip:网络配置工具 ip命令是iproute软件包中的一个强大的网络配置工具,用于显示或管理Linux系统的路由,网络设备,策略路由和隧道 选项说明: 参数选项 解释说明(带@的为重点) -s 输出更详细的信息,...

紅桃10 1679

BMS | 从一串到几百串硬件架构简介

锂电池在生活中越来越多的方面扮演能源的角色,除了大家熟知的电动汽车行业,在一些消费类,工业类电子产品比如手机,电动自行车,电动工具中都有应用,追本溯源今天我们一起来学习下最基础的BMS架构。 1~4串架构 以S8241为代表的无通信/无固件/模拟器件 可实现过充保护、过放保护、过流/短路,参数由器件后缀代码决定;通信类手持设备供电系统;1~4节电池保护板架构 如图使用S-8241系列保护IC,一对充放电MOS管控制充放电的回路的切断和接通,系统供电来自于电芯电压,VM引脚用于检测过...

ningvay的博客 9918

Kubernetes 网络、调度与自动伸缩全解析:从 Calico 网络到 HPA/VPA 实战

集群外部主机可以访问集群内部应用集群内部应用也可以访问集群外部主机各个namespace之间没有做任何的隔离策略如果希望在 IP 地址或端口层面控制网络流量, 考虑使用 Kubernetes 网络策略(NetworkPolicy)。NetworkPolicy 是一种以应用为中心的结构,允许你设置如何允许Pod与网络上的各类网络“实体” 通信。NetworkPolicy 适用于一端或两端与 Pod 的连接,与其他连接无关。**提示:**网络策略通过网络插件来实现。

2403_88632628的博客 212

C2000 ePWM与SDFM同步配置:从寄存器到Driverlib实战解析

在嵌入式实时控制系统中,脉宽调制(PWM)是实现电机驱动、数字电源等应用的核心技术,其信号质量和时序精度直接决定了系统性能。为实现精确控制,PWM信号常需与模数转换器(ADC)或Sigma-Delta滤波器(SDFM)的采样时刻严格同步,以消除开关噪声并获取准确的反馈信号。其技术原理在于通过硬件同步机制,将PWM的特定时间点(如周期中心)作为触发源,控制数据采集的启动时刻。这种硬件级同步能有效提升闭环控制的稳定性和动态响应速度,广泛应用于伺服驱动、变频器等高性能场景。本文聚焦于TI C2000系列微控制器,

weixin_33692284的博客 445

ABAQUS二次开发中创建SET

在ABAQUS中创建加载、边界条件时,需要使用set,创建set时需要使用对象集合对象中的Set函数,这个函数需要提供加入对象集合的列表,但这个对象列表好像并不能自行创建,只能通过ABAQUS各类对象集合中的findAt、getSequenceFromMask、getByBoundingSphere、getByBoundingCylinder或getByBoundingSphere函数得到,但这几个函数在直接使用PYTHON编程时都不太好用。这个函数返回一个字典,如下所示。

hohoyu的专栏 2482

一文打通 K8s 网络与调度!NetworkPolicy、亲和反亲和、drain 驱逐、HPA 压力测试全实验!

本文深入探讨Kubernetes网络与调度核心机制,主要内容包括: 网络方案:对比Flannel、Calico等CNI插件的Underlay/Overlay模型,分析性能差异与适用场景,详解NetworkPolicy实现原理。 调度机制:完整解析kube-scheduler工作流程,涵盖节点选择、亲和/反亲和策略、污点容忍等核心调度策略,以及节点维护操作。 弹性伸缩:实战部署Metrics-Server,详细演示HPA基于CPU/内存指标的自动扩缩容,包括压力测试和精细调控,对比HPA与VPA差异。 全文通

Augustsky12138的博客 227

三维重建Fusion中的TSDF算法通俗描述

看个视频 https://www.youtube.com/watch?v=8M_-lSYqACo 这是mobilefusion的视频,大家先了解一下,看到在三维重建的时候外面有个长方体包围盒了吗? 数据准备: 我们不同角度拍摄的RGB图、深度图和相应的pose.txt。 步骤: 1.建立长方体包围盒 要建立一个长方体包围盒。让所有的三维点都在这个长方体里面。 假设z方向垂直相机。 很明显,x,y方...

qq_30339595的博客 1万+

混沌工程实战:基于Gremlin的CPU、内存与网络故障注入与自动化验证

在分布式系统和云原生架构中,系统可靠性是核心挑战。混沌工程作为一种主动的工程实践,其核心原理是通过在受控环境中注入故障,提前暴露系统脆弱性,从而验证和提升系统韧性。这项技术的核心价值在于将传统的被动“救火”转变为主动的“防火演练”,帮助团队建立对系统在真实故障场景下行为的信心。其典型应用场景包括验证微服务的容错能力、测试弹性伸缩策略的有效性,以及确保在基础设施出现问题时业务连续性。本文以混沌工程平台Gremlin为例,深入探讨如何系统化地进行资源层故障注入,涵盖CPU、内存与网络等核心攻击类型,并分享如何将

weixin_30718391的博客 288

1.1 了解Spring框架 -《SSM深入解析与项目实战》

文章目录第1篇 基础概念第1章 谈谈SSM框架和Redis1.1 了解Spring框架1.1.1 如何学习Spring1.1.2 IoC(Inversion of Control 控制反转)1.1.3 AOP(Aspect Oriented Programing面向切面编程) 项目中所有的源码都可以在此链接的仓库中找到:https://github.com/chenhaoxiang/uifuture-ssm 本章非常形象的介绍了Springn中最核心的两个概念,IoC和AOP,使用了现实中的例子

谙忆-陈浩翔 2135

pytorch搭建SSAE实现预测分类代码模板完整代码

pytorch搭建SSAE实现预测分类代码模板完整代码

325

linux 多网卡 路由顺序_Linux 路由和多网卡网关的路由出口设置

Linux 路由和多网卡网关的路由出口设置刚刚见到一个网络方面的要求,有个 Linux 服务器接了两条线,一条连接内网 192.168.0.0/24 ,一条连接电信的网 192.168.1.0/24 。这两个网络网关分别为 192.168.0.1 和 192.168.1.1, 都是可以上互联网的,但是要求服务器上的应用使用不同的 IP 访问不同的网,进行流量分离。在路由层面是可以实现这些功能的,需...

weixin_40006779的博客 739

汉书HE8,好用的汇编代码编写工具

汉书HE8,好用的汇编代码编写工具早期编写汇编代码所用功能强大

Calico

而其他节点,只需要跟这几个专门的节点交换路由信息,就可以获得整个集群的路由规则信息了。​ 在路径传输方式上,BGP路由的好坏不是基于距离(多数路由协议选路都是基于带宽的),它的选路基于丰富的路径属性,而这些属性在路由传输时携带,它的路由信息包含目标网络和到达该网络的路径(即沿途AS的列表)。( IGP:发现路由;​ 但是,这种跨域通信能力需要集群处于相同的网络环境,并且需要支持 BGP 的网络设备,网络性能优秀(不需要信息封装的开销和延迟),但是缺少一定的数据加密安全性,并且依赖外部的 BGP 服务器;

qq_49288154的博客 2289

文档:亲测可用解决vnc灰屏,黑屏,鼠标大黑叉情况

主要解决vnc-viewer灰屏,黑屏,鼠标大黑叉等现象,详细见文档。

efm32 入门.pdf

本PDF共计22页,介绍的是操作驱动API,下载与否自己斟酌。

BlackHole开发日记-使用三种不同IO模型实现一个DNS代理服务器

2019独角兽企业重金招聘Python工程师标准>>> ...

weixin_33894992的博客 177

计算机控制技术及应用

《计算机控制技术及应用》通过总结作者的科研成果和吸收国内外的先进理论、方法和技术,以计算机控制系统的网络化、开放化、智能化和集成化发展趋势为主线索,主要介绍计算机控制系统的基本概念和计算机控制系统的典型形式,计算机控制系统的数学描述与基本分析方法,以及数字PID控制器、最少拍控制系统、达林算法、状态变量设计法等设计方法及其各种改进算法。重点突出计算机控制系统输入输出通道接口的设计方法和典型控制系统的设计案例与实现方法等。

马哥linux第六周作业

1、简述osi七层模型和TCP/IP五层模型 osi七层模型分别是:应用层,表示层,会话层,传输层,网络层,数据链路层,物理层。 TCP/IP五层模型分别是:应用层,传输层,网络层,数据链路层,物理层 2、简述iproute家族命令 iproute家族命令:   ip命令 ip [ OPTIONS ] OBJECT { COMMAND | help } 常用OBJECT:link,ad...

mark's technic world 685

k8s技术预研12--kubernetes的常见开源网络组件

1、开源的网络组件k8s的网络模型假定了所有Pod都在一个可以直接连通的扁平的网络空间中。这是因为k8s出自Google,而在GCE里面是提供了网络模型作为基础设施的,所以k8s就假定这个网络已经存在。而在大家私有的平台设施里搭建k8s集群,就不能假定这种网络已经存在了。我们需要自己实现这个网络,将不同节点上的Docker容器之间的互相访问先打通,然后运行k8s。目前已经有多个开源组件支持容器网络...

watermelonbig的专栏 6241
上一篇: kubernetes环境部署Spring Cloud
下一篇: kubernetes日志采集方案
正说杂谈
博客等级 码龄15年 30粉丝 25原创
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付:10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

正说杂谈

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值