Skip to content

Commit af3d6b2

Browse files
andrewbytecoderandrewbytecoder
committed
k8s 网络命名空间
1 parent 1092f84 commit af3d6b2

File tree

7 files changed

+42
-3
lines changed

7 files changed

+42
-3
lines changed

‎k8s/attachments/Image00586.jpg

59 KB
Loading

‎k8s/attachments/Image00587.jpg

67.5 KB
Loading

‎k8s/attachments/Image00649.jpg

26.8 KB
Loading

‎k8s/attachments/Image00653.jpg

57.4 KB
Loading

‎k8s/kubernetes.md

Lines changed: 13 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -1,8 +1,11 @@
1+
![[Image00587.jpg]]
2+
13
从过去以物理机和虚拟机为主体的开发运维环境，向以容器为核心的基础设施的转变过程，并不是一次温和的改革，而是涵盖了对网络、存储、调度、操作系统、分布式原理等各个方面的容器化理解和改造。这些关于 Linux 内核、分布式系统、网络、存储等方方面面的积累，并不会在Docker 或者 Kubernetes 的文档中交代清楚。可偏偏就是它们，才是真正掌握容器技术体系的精髓所在。
24

35
Kubernetes是一个 **生产级别的容器编排平台和集群管理系统**，不仅能够创建、调度容器，还能够监控、管理服务器。
46

57

8+
69
```bash
710
# 启动kubernetes集群
811
miikube start
@@ -853,7 +856,7 @@ Pod 还承担着作为调度单元的关键职责。
853856
如图所示，在边车模式下，一个主容器（负责业务逻辑处理）与一个或多个边车容器共同运行在同一个 Pod 内。边车容器负责处理非业务逻辑的任务，如日志记录、监控、安全保障或数据同步。边车容器将这些职能从主业务容器中分离，使得开发更加高内聚、低耦合的软件变得更加容易。
854857
![](https://www.thebyte.com.cn/assets/sidecar-Clxo9o_p.svg)
855858
### 容器镜像的原理与应用
856-
容器镜像是 Docker 革命性的创新，它在短短几年就迅速改变了整个云计算领域的发展历程。在本节中，我们将深入分析镜像技术原理，并探讨其在下载加速、启动加速、存储优化等场景中的最佳实践。
859+
容器镜像是 Docker 革命性的创新，它在短短几年就迅速改变了整个云计算领域的发展历程。我们将深入分析镜像技术原理，并探讨其在下载加速、启动加速、存储优化等场景中的最佳实践。
857860

858861
#### 什么是容器镜像
859862

@@ -3127,6 +3130,15 @@ brctl setfd br0 0
31273130
```
31283131
****
31293132

3133+
### kube-proxy
3134+
开始的时候，kube-proxy确实是一个proxy，等待连接，对每个进来的连接，连接到一个pod。这称为userspace（用户空间）代理模式。后来，性能更好的iptables代理模式取代了它。iptables代理模式目前是默认的模式，如果你有需要也仍然可以配置Kubernetes使用旧模式。
3135+
3136+
每个Service有其自己稳定的IP地址和端口。客户端（通常为pod）通过连接该IP和端口使用服务。IP地址是虚拟的，没有被分配给任何网络接口，当数据包离开节点时也不会列为数据包的源或目的IP地址。Service的一个关键细节是，它们包含一个IP、端口对（或者针对多端口Service有多个IP、端口对），所以服务IP本身并不代表任何东西。这就是为什么你不能够ping它们。
3137+
3138+
当在API服务器中创建一个服务时，虚拟IP地址立刻就会分配给它。之后很短时间内，API服务器会通知所有运行在工作节点上的kube-proxy客户端有一个新服务已经被创建了。然后，每个kube-proxy都会让该服务在自己的运行节点上可寻址。原理是通过建立一些iptables规则，确保每个目的地为服务的IP/端口对的数据包被解析，目的地址被修改，这样数据包就会被重定向到支持服务的一个pod。
3139+
3140+
![[Image00586.jpg]]
3141+
31303142
### calico 网络
31313143

31323144
.calico 网络不经过网桥，直接跳到目的网络

‎k8s/kubernetes_network.md

Lines changed: 20 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -12,11 +12,12 @@ Kubernetes集群至少应该包含三个网络，如图网络环境所示。一
1212

1313
![[image-2025-01-27-01-07-54-828.png]]
1414

15-
1615
## Docker网络基础
1716

1817
Docker技术依赖于近年来Linux内核虚拟化技术的发展， 所以Docker对Linux内核有很强的依赖。 Docker使用到的技术有网络命名空间（ Network Namespace） 、 Veth设备对、 网桥、 ipatables和路由。
1918

19+
20+
2021
### 网络命名空间
2122

2223
为了支持网络协议栈的多个实例， Linux在网络栈中引入了网络命名空间， 这些独立的协议栈被隔离到不同的命名空间中。 处于不同命名空间中的网络栈是完全隔离的， 彼此之间无法通信。 通过对网络资源的隔离， 就能在一个宿主机上虚拟多个不同的网络环境。 Docker正是利用了网络的命名空间特性， 实现了不同容器之间的网络隔离。
@@ -46,6 +47,7 @@ ip netns exec <name> bash
4647
exit
4748
```
4849

50+
4951
### Veth设备对
5052

5153
引入Veth设备对是为了在不同的网络命名空间之间通信， 利用它可以直接将两个网络命名空间连接起来。 由于要连接两个网络命名空间，所以Veth设备都是成对出现的， 很像一对以太网卡， 并且中间有一根直连的网线。 既然是一对网卡， 那么我们将其中一端称为另一端的peer。在Veth设备的一端发送数据时， 它会将数据直接发送到另一端， 并触发
@@ -88,12 +90,28 @@ ip link set <veth1> up
8890
在bridge模式下， Docker Daemon首次启动时会创建一个虚拟网桥，默认的名称是docker0， 然后按照RPC1918的模型在私有网络空间中给这个网桥分配一个子网。 针对由Docker创建的每一个容器， 都会创建一个虚拟以太网设备（Veth设备对） ， 其中一端关联到网桥上， 另一端使用Linux的网络命名空间技术映射到容器内的eth0设备， 然后在网桥的地址段内给eth0接口分配一个IP地址。
8991

9092
## Kubernetes的网络实现
91-
9293
- 容器到容器之间的直接通信。
9394
- 抽象的Pod到Pod之间的通信。
9495
- Pod到Service之间的通信。
9596
- 集群内部与外部组件之间的通信
9697

98+
### 网络模型
99+
#### 宿主机网络
100+
pod可以使用宿主节点的网络接口，而不是拥有自己独立的网络。这意味着这个pod没有自己的IP地址；如果这个pod中的某一进程绑定了某个端口，那么该进程将被绑定到宿主节点的端口上。一个配置了hostNetwork:true的pod使用宿主节点的网络接口，而不是它自己的
101+
![[Image00649.jpg]]
102+
查看宿主机网络网卡信息
103+
```bash
104+
kubectl exec <pod-name> ifconfig
105+
```
106+
107+
#### hostPort与nodePort
108+
通过配置pod的spec.containers.ports字段中某个容器某一端口的hostPort属性来实现。
109+
不要混淆使用hostPort的pod和通过NodePort服务暴露的pod。
110+
111+
在图中首先注意到的是，对于一个使用hostPort的pod，到达宿主节点的端口的连接会被直接转发到pod的对应端口上；然而在NodePort服务中，到达宿主节点的端口的连接将被转发到随机选取的pod上（这个pod可能在其他节点上）。另外一个区别是，对于使用hostPort的pod，仅有运行了这类pod的节点会绑定对应的端口；而NodePort类型的服务会在所有的节点上绑定端口，即使这个节点上没有运行对应的pod
112+
![[Image00653.jpg]]
113+
114+
97115
### 容器到容器的通信
98116

99117
同一个Pod内的容器（Pod内的容器是不会跨宿主机的） 共享同一个网络命名空间， 共享同一个Linux协议栈。 所以对于网络的各类操作，就和它们在同一台机器上一样， 它们甚至可以用localhost地址访问彼此的端口。

‎linux/performance-tools.md

Lines changed: 9 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -4,6 +4,15 @@
44
![[Pasted image 20250620100517.png]]
55

66

7+
| 模块 | 监控命令 | |
8+
| ------- | ------------------------------------------------------------------------------- | --- |
9+
| CPU | lscpu、cpuinfo、top、atop、vmstat、mpstat、pidstat、Dstat、Nmon、sar、cpupower、irqbalance | |
10+
| Memory | top、atop、vmstat、pidstat、Dstat、Nmon、sar、free、smem | |
11+
| I/O | iostat、iotop、pidstat、Dstat、Nmon、sar | |
12+
| Network | netstat、ifstat、iftop、Ethtool | |
13+
| System | top、atop、vmstat、pidstat、Nmon、sar | |
14+
| Swap | vmstat、Nmon、sar、Meminfo、smem | |
15+
716

817
### USE 方法
918

0 commit comments

Comments
 (0)