<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel><title>NAT on Tony Bai</title><link>https://tonybai.com/tags/nat/</link><description>Recent content in NAT on Tony Bai</description><generator>Hugo</generator><language>zh-cn</language><copyright>2004-2026 Tony Bai. 版权所有.</copyright><lastBuildDate>Sat, 21 Jun 2025 00:00:00 +0800</lastBuildDate><atom:link href="https://tonybai.com/tags/nat/index.xml" rel="self" type="application/rss+xml"/><item><title>Kubernetes 2.0 畅想：告别 YAML、etcd 束缚与 Helm 之痛，K8s 的下一站是什么？</title><link>https://tonybai.com/2025/06/21/kubernetes-2-0/</link><pubDate>Sat, 21 Jun 2025 00:00:00 +0800</pubDate><guid>https://tonybai.com/2025/06/21/kubernetes-2-0/</guid><description>Kubernetes 2.0 畅想：告别 YAML、etcd 束缚与 Helm 之痛，K8s 的下一站是什么？ - Tony Bai =============== Tony Bai 一个程序员的心路历程 * Google Go语言编码风格规范 * Google Go语言编码风格规范：指南篇 * Google Go语言编码风格规范：决定篇 * Google Go语言编码风格规范：最佳实践篇 * G...</description></item><item><title>探索基于pion开发的WebRTC应用的建连过程</title><link>https://tonybai.com/2024/12/26/exploring-the-connection-establish-process-of-webrtc-app-built-with-pion/</link><pubDate>Thu, 26 Dec 2024 00:00:00 +0800</pubDate><guid>https://tonybai.com/2024/12/26/exploring-the-connection-establish-process-of-webrtc-app-built-with-pion/</guid><description>本文永久链接 – https://tonybai.com/2024/12/26/exploring-the-connection-establish-process-of-webrtc-app-built-with-pion 在《WebRTC第一课：从信令、ICE到NAT穿透的连接建立全流程》一文中，我们从理论层面全面细致地了解了WebRTC连接建立的完整流程。这个流程大致可以分为以下几个阶段： ...</description></item><item><title>WebRTC第一课：从信令、ICE到NAT穿透的连接建立全流程</title><link>https://tonybai.com/2024/12/14/webrtc-first-lesson-how-connection-estabish/</link><pubDate>Sat, 14 Dec 2024 00:00:00 +0800</pubDate><guid>https://tonybai.com/2024/12/14/webrtc-first-lesson-how-connection-estabish/</guid><description>本文永久链接 – https://tonybai.com/2024/12/14/webrtc-first-lesson-how-connection-estabish 在上一篇文章《WebRTC第一课：网络架构与NAT工作原理》中，我们介绍了WebRTC的网络架构和NAT的基本概念，学习了WebRTC采用端对端（P2P）的通信模型，知道了NAT（网络地址转换）的概念以及给像WebRTC这样的直接P...</description></item><item><title>探索Docker默认网络NAT映射的分配与过滤行为</title><link>https://tonybai.com/2024/12/05/exploring-nat-mapping-assignment-and-filtering-behavior-of-docker-default-network/</link><pubDate>Thu, 05 Dec 2024 00:00:00 +0800</pubDate><guid>https://tonybai.com/2024/12/05/exploring-nat-mapping-assignment-and-filtering-behavior-of-docker-default-network/</guid><description>本文永久链接 – https://tonybai.com/2024/12/05/exploring-nat-mapping-assignment-and-filtering-behavior-of-docker-default-network 在《WebRTC第一课：网络架构与NAT工作原理》一文中，我们对WebRTC的网路架构进行说明，了解到了NAT的工作原理、RFC 3489对NAT的四种传统...</description></item><item><title>WebRTC第一课：网络架构与NAT工作原理</title><link>https://tonybai.com/2024/11/27/webrtc-first-lesson-network-architecture-and-how-nat-work/</link><pubDate>Wed, 27 Nov 2024 00:00:00 +0800</pubDate><guid>https://tonybai.com/2024/11/27/webrtc-first-lesson-network-architecture-and-how-nat-work/</guid><description>本文永久链接 – https://tonybai.com/2024/11/27/webrtc-first-lesson-network-architecture-and-how-nat-work 2023年下旬，OpenAI与Livekit的合作在科技圈引起了不小的轰动。这两家公司联手，通过WebRTC技术和大型语言模型（LLM）的结合，使AI模型具有了看、听和说话的能力。这一举动不仅彰显了Web...</description></item><item><title>使用Docker容器突破客户端6w可用端口的误区</title><link>https://tonybai.com/2021/12/14/the-misconception-of-using-docker-to-break-out-of-6w-ports-of-the-client/</link><pubDate>Tue, 14 Dec 2021 00:00:00 +0800</pubDate><guid>https://tonybai.com/2021/12/14/the-misconception-of-using-docker-to-break-out-of-6w-ports-of-the-client/</guid><description>本文永久链接 – https://tonybai.com/2021/12/14/the-misconception-of-using-docker-to-break-out-of-6w-ports-of-the-client 近期的一个项目刚刚完成了第一个版本的开发，经过一段时间的自测与集成测试，功能问题已经不是重点了。项目在初期设定了性能目标，压测与性能优化势在必行，因此这一阶段我们都在做压测前...</description></item><item><title>使用nomad在weave网络中部署工作负载</title><link>https://tonybai.com/2019/04/20/deploy-workload-in-weave-network-using-nomad/</link><pubDate>Sat, 20 Apr 2019 00:00:00 +0800</pubDate><guid>https://tonybai.com/2019/04/20/deploy-workload-in-weave-network-using-nomad/</guid><description>当初Kubernetes网络的设计目标是**使得开发者使用pod时在网络这一层面可以像使用传统物理主机或虚拟机一样**。具体的基本要求如下： * 所有pod间均应可以在无需NAT的情况下直接通信； * 所有集群节点与所有集群的Pod之间均应可以在无需NAT的情况下直接通信； * 容器自身的地址和其他pod看到的它的地址是同一个地址； 按照这样的要求，集群中的每个pod都在一个平坦的、共享网络命名空...</description></item><item><title>再谈Docker容器单机网络：利用iptables trace和ebtables log</title><link>https://tonybai.com/2017/11/06/explain-docker-single-host-network-using-iptables-trace-and-ebtables-log/</link><pubDate>Mon, 06 Nov 2017 00:00:00 +0800</pubDate><guid>https://tonybai.com/2017/11/06/explain-docker-single-host-network-using-iptables-trace-and-ebtables-log/</guid><description>这大半年一直在搞Kubernetes。每次搭建Kubernetes集群，或多或少都会被Kubernetes的“网络插件们”折腾折腾。因此，要说目前Kubernetes中最难搞的是什么？个人觉得莫过于其Pod网络了，至少也是最难搞的之一。除此之外，以Service和Pod为中心的Kubernetes架构还大量利用iptables规则来实现Service的反向代理和负载均衡，这又与Docker原生容器...</description></item><item><title>理解Kubernetes网络之Flannel网络</title><link>https://tonybai.com/2017/01/17/understanding-flannel-network-for-kubernetes/</link><pubDate>Tue, 17 Jan 2017 00:00:00 +0800</pubDate><guid>https://tonybai.com/2017/01/17/understanding-flannel-network-for-kubernetes/</guid><description>第一次采用kube-up.sh脚本方式安装的Kubernetes cluster目前运行良好，master node上的组件状态也始终是“没毛病”： kubectl get cs NAME STATUS MESSAGE ERROR controller-manager Healthy ok scheduler Healthy ok etcd-0 Healthy {&amp;#34;health&amp;#34;: &amp;#34;true&amp;#34;}...</description></item><item><title>理解Docker跨多主机容器网络</title><link>https://tonybai.com/2016/02/15/understanding-docker-multi-host-networking/</link><pubDate>Mon, 15 Feb 2016 00:00:00 +0800</pubDate><guid>https://tonybai.com/2016/02/15/understanding-docker-multi-host-networking/</guid><description>在Docker 1.9 出世前，跨多主机的容器通信方案大致有如下三种： 1、端口映射 将宿主机A的端口P映射到容器C的网络空间监听的端口P’上，仅提供四层及以上应用和服务使用。这样其他主机上的容器通过访问宿主机A的端口P实 现与容器C的通信。显然这个方案的应用场景很有局限。 2、将物理网卡桥接到虚拟网桥，使得容器与宿主机配置在同一网段下 在各个宿主机上都建立一个新虚拟网桥设备br0，将各自物理网卡...</description></item><item><title>理解Docker容器端口映射</title><link>https://tonybai.com/2016/01/18/understanding-binding-docker-container-ports-to-host/</link><pubDate>Mon, 18 Jan 2016 00:00:00 +0800</pubDate><guid>https://tonybai.com/2016/01/18/understanding-binding-docker-container-ports-to-host/</guid><description>在”理解Docker单机容器网络“一文中，还有一个Docker容器网络的功能尚未提及，那就是Docker容器的端口映射。即将容器的服务端口P’ 绑定到宿主机的端口P上，最终达到一种效果：外部程序通过宿主机的P端口访问，就像直接访问Docker容器网络内部容器提供的服务一样。 Docker针对端口映射前后有两种方案，一种是1.7版本之前docker-proxy+iptables DNAT的方式；另一...</description></item><item><title>理解Docker单机容器网络</title><link>https://tonybai.com/2016/01/15/understanding-container-networking-on-single-host/</link><pubDate>Fri, 15 Jan 2016 00:00:00 +0800</pubDate><guid>https://tonybai.com/2016/01/15/understanding-container-networking-on-single-host/</guid><description>Docker容器是近两年最 火的IT技术之一，用“火山爆发式“来形容Docker的成 长也不为过。Docker在产品服务的devops 运维、云 计算(CaaS)、大数据以及企业内部应用等领域正在被越来越多的接受和广泛应用。Docker技术的本质在于提升计算密度和提升部署效率，高屋 建瓴的讲，它的出现符合人类社会对绿色发展的追求，降低资源消耗，提升资源的单位利用率。不过经历了两年多的发展，Dock...</description></item></channel></rss>