摄影网站开发背景怎么写,德州网站建设推广价格,外贸代运营,商务网站建设中存在的问题OCI概念 OCI#xff0c;Open Container Initiative#xff0c;开放容器标准#xff0c;是一个轻量级#xff0c;开放的治理结构#xff08;项目#xff09;#xff0c;在 Linux 基金会的支持下成立#xff0c;致力于围绕容器格式和运行时创建开放的行业标准。
OCI 项目…OCI概念 OCIOpen Container Initiative开放容器标准是一个轻量级开放的治理结构项目在 Linux 基金会的支持下成立致力于围绕容器格式和运行时创建开放的行业标准。
OCI 项目由 DockerCoreOS后来被 Red Hat 收购了相应的席位被 Red Hat 继承和容器行业中的其他领导者在 2015 年 6 月的时候启动。
runc: OCI默认实现,在资源效率和标准通用方面最强但是在安全隔离方面却最弱kata更加强调安全gvisor: gVisor 通过拦截所有从应用到主机内核的系统调用并使用用户空间中 gVisor 的内核实现来处理这些调用rkt: 弃用crunRedhat 领导的 OCI 实现它是由 C 开发的性能好且轻量级
Open Container Initiative - Open Container Initiative
Runtime spec: GitHub - opencontainers/runtime-spec: OCI Runtime Specification
Image spec: GitHub - opencontainers/image-spec: OCI Image Format
Distribution spec: GitHub - opencontainers/distribution-spec: OCI Distribution Specification
Tools implemented OCI
opencontainers/runc
kata-containers/runtime
google/gvisor
github.com/rkt/rkt
github.com/containers/crun
OCI运行时环境
runc: 容器的低级运行时OCI的默认实现
CONTAINER_ID$(docker create busybox:latest)
docker export -o busybox.tar ${CONTAINER_ID}
mkdir rootfs
tar -xf busybox.tar -C rootfs
runc spec
sudo runc run test
# top
containerd: 容器的高级运行时runc的封装
显然 runc 是只是一个命令行工具containerd_是一个长期居住守护进程。containerd 是一个工业级标准的容器运行时它强调简单性、健壮性和可移植性containerd 可以负责干下面这些事情
• 管理容器的生命周期从创建容器到销毁容器 • 拉取 / 推送容器镜像 • 存储管理管理镜像及容器数据的存储 • 调用 runc 运行容器与 runc 等容器运行时交互 • 管理容器网络接口及网络 sudo ctr images list
sudo ctr images pull docker.io/library/busybox:latest
sudo ctr containers list
sudo ctr run -t --net-host docker.io/library/busybox:latest test
# ping 10.67.126.18
sudo ctr container delete test Runc和OCI在整个K8S体系架构中的位置 早期: kubelet -- docker-manager -- docker 中期: kubelet -CRI- docker-shim -- docker -- containerd -- runc 中期: kubelet -CRI- cri-containerd -- containerd -- runc 当前: kubelet -CRI- containerd(CRI plugin) -- runc 当前: kubelet -CRI- cri-o -- runc CNI介绍 CNI (Container Network Interface), a Cloud Native Computing Foundation project, consists of a specification and libraries for writing plugins to configure network interfaces in Linux containers, along with a number of supported plugins.
As well as the specification , the CNI repository contains the Go source code of a library for integrating CNI into applications and an example command-line tool for executing CNI plugins. A separate repository contains reference plugins and a template for making new plugins.
CNI Responsibilities
Pod IP address management
Pod-2-pod communication within a node
Pod-2-pod communication cross nodes
CNI SPEC
A configuration file (/etc/cni/net.d/)
CRI invokes CNI plugin binary file (/opt/cni/bin/)
Plugin do some operations and return an IP for container
创建一个Pod的流程 其中在 “Invoke CNI plugin”阶段会进入到下面的程序调用
github.com/containerd/containerd
sandbox_run.go
func (c *criService) RunPodSandbox......if err : c.setupPodNetwork(ctx, sandbox); err ! nil { -func (c *criService) setupPodNetwork......result, err netPlugin.SetupSerially(ctx, id, path, opts...) -cni.go
func (c *libcni) SetupSerially(ctx context.Context, id string......result, err : c.attachNetworksSerially(ctx, ns) -func (c *libcni) attachNetworksSerially...r, err : network.Attach(ctx, ns) -namespace.go
func (n *Network) Attach(ctx context.Context, ns *Namespace) (*types100.Result, error) {r, err : n.cni.AddNetworkList(ctx, n.config, ns.config(n.ifName)) -api.go
func (c *CNIConfig) AddNetworkList…result, err c.addNetwork(ctx, list.Name, list.CNIVersion, net, result, rt) -func (c *CNIConfig) addNetwork(ctx context.Context, name, cniVersion return invoke.ExecPluginWithResult(ctx, pluginPath, newConf.Bytes, c.args(ADD, rt), c.exec) -exec.go
func ExecPluginWithResult(ctx context.Context... -...stdoutBytes, err : exec.ExecPlugin(ctx, pluginPath, netconf, args.AsEnv()) -raw_exec.go
func (e *RawExec) ExecPlugin(ctx context.Context,...c : exec.CommandContext(ctx, pluginPath)Sandbox
K8S在创建任何一个Pod的时候都会先创建一个sandbox容器或者pause容器起到一个占位的目的这个Pod中的其它容器会共享pause容器中的网络和存储资源
config_unix.go - sandboxImage: registry.k8s.io/pause:3.8“
https://github.com/kubernetes/kubernetes/blob/master/build/pause/linux/pause.c Cnitool
Cnitool是一个用于CNI开发和测试的工具
https://github.com/containernetworking/cni/blob/main/cnitool/cnitool.go
sudo su –
mkdir cnitool cd cnitool
go install github.com/containernetworking/cni/cnitoollatest
git clone https://github.com/containernetworking/plugins.git
cd plugins
./build_linux.sh
echo {cniVersion:0.4.0,name:myptp,type:ptp,ipMasq:true,ipam:{type:host-local,subnet:172.16.29.0/24,routes:[{dst:0.0.0.0/0}]}} | sudo tee /etc/cni/net.d/10-myptp.confip netns add testing
ip netns add testing2
CNI_PATH./bin cnitool add myptp /var/run/netns/testing
CNI_PATH./bin cnitool add myptp /var/run/netns/testing2
ip -n testing addr
ip -n testing2 addr
ip netns exec testing ping testing2 IP
ip netns exec testing2 ping testing IPCNI_PATH./bin cnitool del myptp /var/run/netns/testing
CNI_PATH./bin cnitool del myptp /var/run/netns/testing2
ip netns del testing
ip netns del testing2常见CNI插件
Flannel: The basic CNI, high performance, but not support security related features
Calico: High performance, support security features
Weave: Mesh overlay between all nodes, fast datapath, support security features
Cilium: Use eBPF to support advanced network features, support security features, resource usage is high
The Ultimate Guide To Using Calico, Flannel, Weave and Cilium - Platform9 https://itnext.io/benchmark-results-of-kubernetes-network-plugins-cni-over-10gbit-s-network-updated-august-2020-6e1b757b9e49
Flannel
Flannel 在 Kubernetes 集群的所有节点上运行一个简单的覆盖网络。 它在第 3 层 OSI 网络模型的网络层提供网络。
Flannel 支持 VXLAN 作为其默认后端但你也可以将其配置为使用 UDP 和 host-gw。**AWS VPC、AliVPC、IPIP 和 IPSec 等一些实验性后端也可用但目前尚未得到官方支持。
Flannel 的缺点之一是缺乏高级功能例如配置网络策略和防火墙的能力。因此 Flannel 是 Kubernetes 集群网络的一个很好的入门级选择但是如果你正在寻找高级网络功能你可能需要考虑其他 CNI 选项例如 Calico。
Calico
与 Flannel 一样Calico 在 OSI 模型的第 3 层上运行并使用 BGP 协议在其默认配置中的节点之间移动网络数据包并使用 IP in IP 进行封装。使用 BGPCalico 可以本地定向数据包而无需将它们包装在额外的封装层中。
Calico 最有价值的特性是它对网络策略的支持。通过定义和执行网络策略你可以规定哪些 pod 可以发送和接收流量并管理网络内的安全性。
Weave
Weave 在 Kubernetes 集群的所有节点之间创建一个网格覆盖并将其与每个节点上的路由组件结合使用以在整个集群中动态路由流量。默认情况下Weave 使用快速数据路径方法路由数据包该方法尝试沿最短路径在节点之间发送流量。该网络不断分析交通流量并优化路线。如果快速数据路径发生故障则称为***sleeve***数据包转发的较慢网络方法是备用方法 。
Cilium
Cilium 可以为大规模部署提供优势并利用 eBPF 来提高可观察性和网络管理效率。Cilium 仍然是一个年轻的项目在下面引用的基准测试中它似乎确实更耗费资源。
网桥/veth-pair
网桥可以理解为Linux上的一个虚拟交换机可以连接不用的veth-pair起到转发数据包的作用。
Veth-pair类似一根网线可以连接不同的network space让不同的ns通信。
Veth-pair的一端可以连接到kernel ns但在kernel ns中需要一个路由才能进入到veth-pair的另一端。
下面演示不同的ns通过网桥可以相互ping通对方
brctl addbr br0
ip link set br0 up
ip netns add ns1
ip netns add ns2
ip link add veth1-ns type veth peer name veth1-br
ip link add veth2-ns type veth peer name veth2-br
ip link set veth1-ns netns ns1
ip link set veth2-ns netns ns2
ip netns exec ns1 ip link set lo up
ip netns exec ns1 ip link set veth1-ns up
ip netns exec ns1 ip addr add 10.0.0.2/24 dev veth1-ns
ip netns exec ns2 ip link set lo up
ip netns exec ns2 ip link set veth2-ns up
ip netns exec ns2 ip addr add 10.0.0.3/24 dev veth2-ns
ip link set veth1-br up
ip link set veth2-br up
brctl addif br0 veth1-br
brctl addif br0 veth2-brbrctl show
ip netns list
ip netns exec ns1 ifconfig
ip netns exec ns2 ifconfigip netns exec ns1 ping 10.0.0.3
ip netns exec ns2 ping 10.0.0.2ifconfig br0 down
brctl delbr br0
ip link delete veth1-br
ip link delete veth2-br
ip netns del ns1
ip netns del ns2如何实现一个CNI
CNI要解决的问题有
IP地址管理Node内不同Pod的通信不同Node上Pod的通信
IP地址管理需要考虑的事情是如何保证不同Node上为Pod分配的IP地址不会冲突以及如何全局统一来协调。通常这里需要用到etcd数据库保存全局的IP地址分配的配置。
Node内不同的Pod通信可以考虑使用网桥ethpair。
不同的Node上Pod的通信比较复杂如果Node在同一子网可以考虑最简单的静态路由的方案也就是underlay网络或者基于静态路由的BGP方案。如果Node不在同一子网需要考虑overlay的网络方案例如IPIPvxlan等。
按照CNI规范实现一个CNI需要创建一个配置文件用以描述CNI plugin以及一个二进制的plugin可执行文件。这里我们实现一个基于静态路由的SimpleCNI
CNI plugin配置文件参考下面
rootrxxxx:/etc/cni/net.d# cat simplecni.conf
{cniVersion: 0.3.0,name: simplecni,type: simplecni,bridge: simplecni0,subnet: 10.244.0.0/16
}Plugin可执行文件参考以下模板编译好simplecni以后需要将binary放到以下位置/opt/cni/bin/simplecni,
https://github.com/containernetworking/plugins/blob/main/plugins/main/bridge/bridge.go 为了简化IPAM的管理这里没有使用etcd数据库而是在每个node上创建了一个配置文件ipam.config用于IP地址的管理和分配
rootxxx:/etc/cni# cat ipam.config
{Subnet:10.244.1.0,SubnetPrefix:10.244.1.,Gateway:10.244.1.1,IPIndex:“1}
由于SimpleCNI基于静态路由所以需要手动在不同的Node上配置类似下面的路由规则以实现不同Node上的Pos间的相互通信
# On node1
ip route add 10.244.2.0/24 via 192.168.2.1 dev eth1# On node2
ip route add 10.244.1.0/24 via 192.168.1.1 dev eth1SimpleCNI代码参考K8S-Related/SimpleCNI at main · wangxiaohui2015/K8S-Related (github.com)
IPIP
IP in IP可用于跨子网的Node上Pod与Pod的通信基本原理是将Pod与Pod通信的IP层数据包封装到Node上IP数据包的payload部分通过Node的IP层进行通信。使用IPIP后会在OS上创建一个tunl0的设备用于IPIP协议的解析数据包的封装和解封OS Kernel本身支持IPIP协议。参考
一文明白calico的IPIP网络模式 - 知乎 VXLan
VXLan是另一种overlay技术其将内层层2的数据包封装包外层UDP里面以实现虚拟数据链路层技术。
参考flannel使用的vxlan和calico使用的IPIP对比 - 知乎
