<rss xmlns:atom="http://www.w3.org/2005/Atom" version="2.0"><channel><title>Iptables - 标签 - 研发日志 · R&amp;D Log</title><link>https://rd163.visword.com/tags/iptables/</link><description>Iptables - 标签 - 研发日志 · R&amp;D Log</description><generator>Hugo -- gohugo.io</generator><language>zh-CN</language><managingEditor>whutluohui@gmail.com (小智晖)</managingEditor><webMaster>whutluohui@gmail.com (小智晖)</webMaster><copyright>本作品采用知识共享署名-非商业性使用 4.0 国际许可协议进行许可。</copyright><lastBuildDate>Sun, 12 Jan 2025 00:00:00 +0800</lastBuildDate><atom:link href="https://rd163.visword.com/tags/iptables/" rel="self" type="application/rss+xml"/><item><title>kubernetes 网络模型</title><link>https://rd163.visword.com/posts/k8s-networking-model/</link><pubDate>Sun, 12 Jan 2025 00:00:00 +0800</pubDate><author><name>小智晖</name></author><guid>https://rd163.visword.com/posts/k8s-networking-model/</guid><description><![CDATA[<h2 id="k8s通信原理" class="headerLink">
    <a href="#k8s%e9%80%9a%e4%bf%a1%e5%8e%9f%e7%90%86" class="header-mark"></a>K8s通信原理</h2><p>这是一张由外向内的典型的容器网络架构图。</p>
<p><img class="tw:inline" loading="lazy" src='https://wmxiaozhi.github.io/picx-images-hosting/picx-imgs/k8s-net/k8s-network-arch.png'     ></p>
<p>为了能够正常通信，图中每个参与通信的实体都需要有一个 IP 地址，由集群外部到集群内部：</p>
<table>
	<thead>
			<tr>
					<th>IP类型</th>
					<th>说明</th>
			</tr>
	</thead>
	<tbody>
			<tr>
					<td>Proxy-IP</td>
					<td>代理层公网地址IP，外部访问应用的网关服务器。[实际需要关注的IP]</td>
			</tr>
			<tr>
					<td>Service-IP</td>
					<td>Service的固定虚拟IP，Service-IP是内部，外部无法寻址到。</td>
			</tr>
			<tr>
					<td>Node-IP</td>
					<td>容器宿主机的主机IP。</td>
			</tr>
			<tr>
					<td>Container-Bridge-IP</td>
					<td>容器网桥（docker0）IP，容器的网络都需要通过容器网桥转发。</td>
			</tr>
			<tr>
					<td>Pod-IP</td>
					<td>Pod的IP，等效于Pod中网络容器的Container-IP。</td>
			</tr>
			<tr>
					<td>Container-IP</td>
					<td>容器的IP，容器的网络是个隔离的网络空间。</td>
			</tr>
	</tbody>
</table>
<h3 id="容器间通信" class="headerLink">
    <a href="#%e5%ae%b9%e5%99%a8%e9%97%b4%e9%80%9a%e4%bf%a1" class="header-mark"></a>容器间通信</h3><p>先来看最简单的情况， 即同一个Pod内部容器之间的通信：</p>]]></description></item><item><title>tproxy（透明代理）</title><link>https://rd163.visword.com/posts/tproxy/</link><pubDate>Sun, 12 Jan 2025 00:00:00 +0800</pubDate><author><name>小智晖</name></author><guid>https://rd163.visword.com/posts/tproxy/</guid><description><![CDATA[<h2 id="什么是透明代理" class="headerLink">
    <a href="#%e4%bb%80%e4%b9%88%e6%98%af%e9%80%8f%e6%98%8e%e4%bb%a3%e7%90%86" class="header-mark"></a>什么是透明代理</h2><p><a href="https://www.kernel.org/doc/html/latest/networking/tproxy.html" target="_blank" rel="noopener noreferrer">tproxy</a> 即 transparent（透明）proxy。这里的 transparent 有两层含义：</p>
<ul>
<li><strong>对 client（客户端）透明</strong>：客户端无需任何额外配置，既不必修改请求地址，也不必采用代理协议与代理服务器协商。相比之下，socks 或 http 代理都需要在客户端显式设置代理地址，并在发起请求时通过代理协议告知代理服务器真实的目标地址。</li>
<li><strong>对 server（服务端）透明</strong>：服务端看到的是 client 端的地址，而非 proxy 的地址，仿佛请求从未经过中转。</li>
</ul>
<p>换句话说，在一条透明的链路里，两端都不知道代理的存在。这与传统代理协议（如 HTTP CONNECT、SOCKS5）形成鲜明对比，后者要求应用感知代理并主动与之交互。</p>]]></description></item></channel></rss>