容器会在linux系统中进行隔离 sandbox or pause ?
-
Mount：隔离文件系统
-
UTS：隔离主机名和域名
-
PID：隔离 PID 空间
-
网络：隔离网络接口
-
用户：隔离 UID/GID 空间
-
Cgroup：隔离 cgroup 根目录
CNI包含在Linux 容器进行网络配置的规范和库，主要工作就是容器网络的连接能力，并在容器销毁时移除相应的已分配资源。
kubelet调用Containered CRI插件以创建容器，而Containered CRI插件调用CNI插件为容器配置网络。
CNI的基础任务
- 创建veth对 并移入容器 （多个netns连通的介质）
- 鉴别正确的POD CIDR
- 创建CNI配置文件
- IP地址的分配和管理
- 在容器里加入默认路由
- 把路由广播给所有Peer节点
- 在主机上加入路由
- 实施网络策略
calico组件
-
BGP 守护进程，运行在每个节点上，负责相互交换路由信息
-
ConfD 是一个简单的配置管理工具，运行在 Calico Node 容器中。它会从 ETCD 中读取数据（Calico 的 BIRD 配置），并写入磁盘文件。它会循环读取网络和子网，并应用配置数据（CIDR 键），组装为 BIRD 能够使用的配置。这样不管网络如何变化，BIRD 都能够得到通知并在节点之间广播路由。
-
Felix 守护进程在 Calico Node 容器中运行，完成如下功能：从ETCD中读取信息、构建路由表、配置iptables或ipvs
CNI的接口并不是指HTTP，gRPC接口，CNI接口是指对可执行程序的调用（exec）。这些可执行程序称之为CNI插件，以Kubernetes为例，Kubernetes节点默认的CNI插件路径为/etc/cni/net.d/
CNI会配置pod到节点的路由，kube-proxy不会介入pod到pod之间的通信过程。
Kube-proxy
svc IP 到 Pod IP 的转换是通过每个节点上的
kube-proxy完成的
CoreDNS
CoreDNS 这样的 DNS 服务器具备 Kubernetes 集群感知的能力，他们会对 Kubernetes API 进行监控，一旦新建了 Service，就会新建对应的 DNS 记录
SVC ExternalTrafficPolicy
Cluster
默认，会把流量平均分配给该service的所有pod上。
Local
kube-proxy 只会在存在目标pod的节点上加入NodePort的代理规则。
iptables
-
KUBE-SERVICE是Service包的入口。它负责匹配 IP:Port，并把数据包发给对应的
KUBE-SVC-*。 -
KUBE-SVC-*担任负载均衡的角色，会平均分配数据包到KUBE-SEP-*。每个
KUBE-SVC-*都有和Endpoint同样数量的KUBE-SEP-*。 -
KUBE-SEP-*代表的是Service的EndPoint，它负责的是 DNAT，会把Service的 IP:Port 替换为 Pod 的 IP:Port。 -
ClusterIP：
KUBE-SERVICES→KUBE-SVC-XXX→KUBE-SEP-XXX -
NodePort：
KUBE-SERVICES→KUBE-NODEPORTS→KUBE-SVC-XXX→KUBE-SEP-XXX
Headless
- 客户端访问headless service时会获取所有后端pod的地址，其他类型只会获得一个请求轮询到的pod地址。kube-proxy不对这种服务提供支持。
- statefulset资源serviceName字段会创建无头服务，pod通过{podname}.{headless svc name}.{namespace}.svc.cluster.local访问。
抛出疑问
- ipvs mode可以ping svc ip ，iptables mode 不可以
ipvs是有网络接口的 iptables没有
知识点：
- 通常集群中的每个节点都分配有一个
CIDR，用来指定该节点上运行的 Pod 可用的 IP 地址。
