<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Networks on Henry Du Blog</title>
    <link>https://www.henrydu.com/tags/networks/</link>
    <description>Recent content in Networks on Henry Du Blog</description>
    <generator>Hugo -- gohugo.io</generator>
    <language>en-us</language>
    <lastBuildDate>Sat, 13 Jan 2024 00:00:00 +0000</lastBuildDate>
    
	<atom:link href="https://www.henrydu.com/tags/networks/index.xml" rel="self" type="application/rss+xml" />
    
    
    <item>
      <title>Reading Notes: Netfilter and iptables (1)</title>
      <link>https://www.henrydu.com/2024/01/13/netfilter-iptables-1/</link>
      <pubDate>Sat, 13 Jan 2024 00:00:00 +0000</pubDate>
      
      <guid>https://www.henrydu.com/2024/01/13/netfilter-iptables-1/</guid>
      <description>Reading Notes: Netfilter and iptables Netfilter is firewalling subsystem in the Linux kernel as a modular[1]. For example, some fields are included in the sk_buf data structure only if the kernel is compiled with support for Netfilter feature.
struct sk_buff is defined in linux/include/skbuff.h. There is a well defined document on the top of the file. It include the netfilter common header file
#if IS_ENABLED(CONFIG_NF_CONNTRACK) #include &amp;lt;linux/netfilter/nf_conntrack_common.h&amp;gt;#endif Firewalling, essentially, hooks into certain places in the network stack code that packets always pass through when the packets or the kernel meet certain conditions.</description>
    </item>
    
    <item>
      <title>Cross-host Container Networks</title>
      <link>https://www.henrydu.com/2021/12/01/cross-host-container-network-vxlan-mode/</link>
      <pubDate>Wed, 01 Dec 2021 00:00:00 +0000</pubDate>
      
      <guid>https://www.henrydu.com/2021/12/01/cross-host-container-network-vxlan-mode/</guid>
      <description>Cross-host Container Networks - VXLAN mode VXLAN We have reviewed the UDP mode of cross-host container networks. We realized that there will be a performance issue because the IP packets have to be processed by the user space application. VXLAN allows us to handle the encapsulation/decapsulation in Linux kernel space.
Virtual Extensible LAN a.k.a VXLAN (RFC7348) is supported by Linux kernel. It is able to encapsulate the IP packets by another layer and construct the overlay networks like the UDP tunnel does.</description>
    </item>
    
    <item>
      <title>Cross-host Container Networks</title>
      <link>https://www.henrydu.com/2021/11/28/cross-host-container-network-udp-mode/</link>
      <pubDate>Sun, 28 Nov 2021 00:00:00 +0000</pubDate>
      
      <guid>https://www.henrydu.com/2021/11/28/cross-host-container-network-udp-mode/</guid>
      <description>Cross-host Container Networks - UDP mode In the previous article, we walked through containers network in one Linux host. However, by default Docker configuration, one container is unable to communicate with the other container in different host.
In order to solve cross-host container communication problem, there are many solutions. We will go through some of them one by one. First and very famous one is Flannel CNI.
Flannel CNI Flannel CNI project is the one of the projects developed by CoreOS.</description>
    </item>
    
    <item>
      <title>K8S Runtime: With or Without Docker</title>
      <link>https://www.henrydu.com/2020/12/12/k8s-runtime/</link>
      <pubDate>Sat, 12 Dec 2020 00:00:00 +0000</pubDate>
      
      <guid>https://www.henrydu.com/2020/12/12/k8s-runtime/</guid>
      <description>K8S Container Runtime Evolution With Docker In Kubernetes v1.20 release note, the major change is to deprecate dockershim, which means, K8S will never use Docker as container runtime. The Kubernetes community has written a blog post about this in detail.
The docker runtime is just one component of Docker suite. Developers still use Docker to compile a docker image, and use docker hub to store docker images, as a docker image repository.</description>
    </item>
    
    <item>
      <title>Cilium: K8S Service Load Balancing - Part 2</title>
      <link>https://www.henrydu.com/2020/12/03/cilium-service-lb-2/</link>
      <pubDate>Thu, 03 Dec 2020 00:00:00 +0000</pubDate>
      
      <guid>https://www.henrydu.com/2020/12/03/cilium-service-lb-2/</guid>
      <description>Cilium’s service LB based on eBPF/XDP The first part introduced K8S service. Now, we can focus on Cilium&amp;rsquo;s service LB based on eBPF/XDP.
Cilium agent Cilium service LB implements data path for all K8s service types via BPF.
 cilium-agent on each node watches kube-apiserver. cilium-agent observes the changes in K8S service. cilium-agent dynamically update BPF configuration according to changes in K8S service.   As the diagram shown above, there are two components realized the service</description>
    </item>
    
    <item>
      <title>Cilium: K8S Service Load Balancing - Part 1</title>
      <link>https://www.henrydu.com/2020/11/30/cilium-service-lb-1/</link>
      <pubDate>Mon, 30 Nov 2020 00:00:00 +0000</pubDate>
      
      <guid>https://www.henrydu.com/2020/11/30/cilium-service-lb-1/</guid>
      <description>Cilium: K8S Service Load Balancing - Part 1 This blog is my reading note when I read K8S Service Load Balancing with BPF &amp;amp; XDP, presented by Daniel Borkmann and Martynas Pumputis in Linux Plumbers Conference.
Kubernetes Networking Basic I have summarized kubernetes network feature when I introduced Flannel CNI. Kubenetes network is a flat network in the sense that each pod must be reachable by its IP address within a cluster.</description>
    </item>
    
    <item>
      <title>K3S Supports CNI and Flannel Plugin</title>
      <link>https://www.henrydu.com/2020/11/16/k3s-cni-flannel/</link>
      <pubDate>Mon, 16 Nov 2020 00:00:00 +0000</pubDate>
      
      <guid>https://www.henrydu.com/2020/11/16/k3s-cni-flannel/</guid>
      <description>K3S Supports Container Network Interface (CNI) and Flannel Introduction Kubernetes network provide the following features:
 Pods can communicate directly with all other pods on all nodes (no NAT). All nodes agents can communicate with other pods on all nodes (no NAT). The IP that a container sees itself as is the same IP that others see it as.  This article explains how every pod is assigned an IP address managed by K3S.</description>
    </item>
    
  </channel>
</rss>