FPGA是网络交换领域的不二选择 - 潘伟涛

西安电子科技大学通信工程学院 潘伟涛副教授

原文链接:https://zhuanlan.zhihu.com/p/112055720

前两天华为公布了单端口800Gbps的方案,而在FPGA领域,ISSCC2020会议上,Xilinx公司则发布了单通道112Gbps的高速串口

华为单端口800Gbps的光口,Xilinx发布的单通道112Gbps的高速串口,一家是世界上目前最大的通信设备商,另一家则是世界上最大的FPGA厂商,正因为一些冥冥之中的原因走的越来越近。800Gbps光口中所使用的技术,就是8个112Gbps的高速串行通道绑定而实现的。FPGA与网络交换的渊源,让我从可编程网络的历史说起。


可编程网络的历史

1、基于小型计算机的路由器(1969年至1990年代中期)

分组交换网络上的第一个路由器可能是1969年ARPANET上的接口消息处理器(IMP)。IMP论文中描述的IMP是在Honeywell DDP-516微型计算机上实现的。在今天的术语中,这种路由器被称为软件路由器,因为它是作为通用计算机之上的软件实现的。

在小型计算机之上实现路由器的这种方法足以满足当时所需的适度转发速率。例如,IMP论文报告说,IMP的最大吞吐量约为700 kbit/s,足以在两个方向上服务于多条50 kbit/s的线路。此类基于微型计算机的路由器也非常出色:可编程路由器的功能仅需升级微型计算机上的转发软件即可。

这种使用小型计算机构建生产路由器的方法一直持续到1990年代中期。1970年代著名的软件路由器例子是David Mills的Fuzzball路由器。1980年代最著名的例子是Noel Chiappa的C网关,这是MIT初创公司Proteon 的基础,以及William Yeager的“夜间运货”多协议路由器,这是斯坦福初创公司思科系统公司的基础。

到1990年代中期,由于互联网和万维网的迅速采用,软件已无法满足对更高链接速度的需求。瞻博网络的M40路由器是1998年硬件路由器的早期示例。M40包含用于实现路由器的数据平面的专用芯片以及用于实现路由器的控制平面的控制处理器。正如我们在第一章中所描述的那样,自1990年代中期以来,最快的路由器主要由专用硬件构成,因为硬件专业化是维持链路速度逐年提高的唯一方法。

img

图1:自1969年ARPANET上的第一台路由器以来,软件路由器的总容量。直到1990年代中期,软件路由器才够用。但是,从那时起,最快的路由器主要是固定功能的设备,这些设备是由专用的非可编程硬件构建而成的,与最好的软件路由器相比,这些路由器的性能提高了10-100倍。

2、主动网络(1990年代中期)

1990年代中期,有源网络得到了发展,这种方法提倡网络是可编程的或“有源的”,以允许在网络基础架构中部署新服务。主动网络至少有两种方法。首先,可编程路由器方法,它允许网络运营商以受限方式对路由器进行编程。其次,封装方法,其中最终主机会将程序作为封装嵌入到数据包中,然后由路由器执行。

主动网络主要与胶囊方法有关。但是胶囊方法引起了一些安全隐患。由于程序是由最终用户嵌入到数据包中的,因此恶意或错误的最终用户程序可能会破坏整个路由器。解决安全问题的一种方法是在隔离的应用程序级虚拟机(如Java虚拟机)中执行胶囊程序。但是,使用虚拟机进行隔离以降低转发性能为代价。

即使使用提供有效隔离的技术(例如SNAP),在通用处理器上执行数据包转发时,也会对性能造成重大影响。例如,SNAP在2001年报告的转发速率为100Mbit/s,比1998年开发的Juniper M40 40Gbit/s硬件路由器慢了两个数量级。

胶囊方法可能是所有主动网络愿景中最雄心勃勃的方法,由于安全方面的考虑,它并未以最通用的形式出现。但是,最近的系统向终端主机公开了路由器功能的一个更为受限的子集(例如,终端主机读取路由器状态但不写入路由器状态的能力),这使人想起了封装方法。另一方面,可编程路由器方法已经以各种形式被采用:软件定义的网络和可编程路由器芯片都为网络运营商提供了不同种类的受限路由器可编程性。

3、软件路由器(1999年至今)

自1990年代后期以来,一种可编程性的方法就是使用通用基板来编写数据包处理程序,而固定功能路由器硬件则无法编程。多年来,通用基板已经发生了变化。例如,Click 在2000年使用了单核CPU。在2000年代初期,英特尔推出了专门针对网络的一系列处理器,称为网络处理器,例如2000年的IXP1200 和2000年的IXP2800 。RouteBricks项目在2009年使用了多核处理器,PacketShader项目在2010年使用了GPU ,而NetFPGA-SUME项目在2014年使用了FPGA 。

已经发现软件路由器被用作对路由器进行编程的一种手段,但是却牺牲了性能。在链接速度较低但计算要求较高的情况下,它们特别有用。例如,该方法已被用于实现WiFi 中的MAC层算法和无线物理层中的信号处理算法。

在开发软件路由器的同时,还开发了许多用于数据包处理的特定领域语言(DSL)。例如,单击使用C ++在软件路由器上进行数据包处理。packetC 和Microengine C 目标网络处理器。

4、软件定义的网络(2004年至今)

从2000年代初期开始,研究人员就主张将路由器的控制平面(运行分布式路由协议以计算其路由表的路由器部分)与路由器的数据平面(通过查看路由表的数据来转发数据包)分开。作为示例,链路状态路由协议的实现将是控制平面的一部分,而基于最长前缀的表查找的实现将是数据平面的一部分。

这种方法背后的思想,后来被称为软件定义网络(SDN),是网络运营商在管理大型网络(例如流量工程,访问控制,创建虚拟网络)时所需要的大部分灵活性。与控制平面有关,与数据平面无关。此外,与数据平面相比,控制平面执行的频率相对较低:每几毫秒一次,而不是每几纳秒一次。因此,虽然必须以硬件来实现数据平面以提高性能,但控制平面操作的相对少见的性质允许将其从路由器移出并移至商品通用处理器,在此可以更轻松地进行操作程序。

SDN还引入了集中控制的概念:通过将路由器控制平面从路由器移到通用处理器上,可以将整个网络控制平面集中在几个服务器上。这样一来,这几台服务器就可以利用全局网络可见性来计算整个网络的路由。SDN有效地用了更简单的集中图计算(例如,使用Dijkstra算法的最短路径)代替了易于出错的分布式路由计算协议。

一旦控制平面为每个路由器计算了路由,SDN还需要一种控制平面的机制来填充路由表的内容。在转发数据包时,数据平面将查询这些表。这些机制中最著名的是OpenFlow API ,它公开了路由器硬件中路由表的最小接口。OpenFlow的目标是充当跨接口到不同路由器芯片中的路由表的最小公分母。这样一来,现有芯片就可以立即支持OpenFlow API。

尽管OpenFlow API使对网络的控制平面进行编程成为可能,但并不一定使它变得容易。因此,SDN的发展也导致了高级编程语言的发展,以对路由器的控制平面进行编程。尽管SDN在编程和验证丰富的控制平面策略方面进行了大量研究工作,但在启用数据平面中的可编程性方面却进行了很多工作。

5、网络功能虚拟化(2012年至今)

网络功能虚拟化(NFV)试图将更丰富的数据包处理功能(超出原始数据包转发功能)转移到商品通用处理器和云基础架构中。这种数据包处理功能包括深度数据包检查,负载平衡,入侵检测和WAN加速,通常统称为“中间盒”。出现了一些系统来对这种中间盒的数据和控制平面进行编程。

这种中间盒的一种常见用例是在网络的边缘(例如,在蜂窝基站处),其中,每当客户端访问因特网时,各种分组处理功能就在处理器集群上运行。由于NFV是在软件平台上执行数据包处理的,因此它也可以看作是链路速率要求相对较低的边缘上的软件路由器的实际用例。

6、基于边缘/终端主机的软件定义网络(2013年至今)

很快就清楚了,OpenFlow API不足以表达网络运营商的所有需求,因为它被设计为易于采用的通用最小分母API。OpenFlow缺乏表达能力,导致了基于边缘的软件定义网络方法。

通过这种方法,网络的路由器分为两类。边缘路由器位于网络的入口或边缘,并执行可编程的数据包处理。网络的核心是核心路由器,这些路由器简单地转发几乎没有可编程性的数据包。由于边缘路由器在空间上分布以服务于不同位置的客户端,因此每个边缘路由器只需要处理进出网络的总流量中的一小部分。

因此,相对于核心,边缘路由器对性能的要求要低得多,这使得它们可以在通用CPU上实现。使用通用CPU对边缘路由器进行编程可以使它们比受限的OpenFlow API更具可编程性。开放式虚拟交换机是边缘路由器的一个众所周知的示例。它在终端主机上的虚拟机管理程序中运行,并将单个终端主机上的多个虚拟机连接到网络。最近,边缘上不断增长的性能要求已导致在FPGA 上实现此类虚拟交换机。

从逻辑上讲,边缘路由器可能是终端主机本身。因此,在讨论基于边缘的方法时,我们还包括一些近期的提案,这些提案使用最终主机来实现网络灵活性。例如,Eden通过仅对终端主机进行编程就可以使用商用路由器提供可编程数据平面。微型数据包程序(TPP)允许最终主机将小程序嵌入数据包头中,然后由路由器以类似于基于胶囊的活动网络的样式由路由器执行。TPP使用受限制的指令集来缓解活动网络的性能和安全问题。在测量和监视方面,许多系统仅从终端主机监视网络性能。

对于网络中不可用的应用程序上下文,基于边缘或基于最终主机的解决方案是必需的。例如,只有在终端主机上才能获得有关哪个应用程序使用了网络的知识(可能对监视有用)。同样,许多网络安全应用程序(例如,过滤垃圾邮件)最好在最终主机上运行,因为出于隐私原因,确定什么是垃圾邮件以及什么不是最好的信息留在最终主机上。此外,可以仅通过边缘可编程性来实现很多可编程网络功能(例如,网络虚拟化,访问控制,安全策略等)。

但是,基于边缘的方法不足以解决所有网络问题。例如,通过使用网络支持进行拥塞控制(例如,使用来自路由器的显式拥塞通知支持的DCTCP 和使用来自路由器的拥塞程度的显式信息的XCP),性能有了显着提高。用于提高网络性能的许多其他最新提议依赖于网络核心内路由器的支持。与使用来自不同终端主机有利位置的网络测量结果“三角剖分”网络问题的根本原因相比,直接在网络中进行监视,网络可见性也有了显着提高。总而言之,缺少可编程网络核心会大大降低性能,并使网络调试复杂化。

有人可能会提出一种混合网络架构,该架构将基于边缘的可编程性与更智能但固定的核心路由器相结合。这样的体系结构仍然将所有可编程性置于边缘,但是通过少量固定功能扩展了核心路由器,以支持来自边缘的可编程性。这种方法的示例包括通用数据包调度和带内网络遥测,它们通过细粒度的优先级队列扩展了路由器,并且能够将队列大小信息导出到数据包中,但是保留了所有到边缘的可编程性。

如果存在一小部分功能,这些功能对于固定功能路由器就足够了,那么这种混合方法将是面向未来的通用方法。如果确实存在如此少的一组固定功能,则构建固定功能路由器而不是可编程路由器将是更好且更简单的方法。但是最近几十年来,路由器中不断增加的功能不断涌现。在这种不断变化的功能中,网络内的可编程性为网络运营商提供了未来的证明和安心:能够在需要时快速向路由器添加功能,而无需冗长的硬件迭代周期。

而这正是FPGA所具有的得天独厚的优势。

FPGA是定制计算领域的不二选择

引用前几天FPGA领域大牛丛京生老师在2020年ASP-DAC会议上对于FPGA的一段论述:

可定制计算和人们通常所知的通用处理器相比有着巨大优势。实际我在UCLA的同事Ingrid Verbauwhede教授的工作对我们的研究有不少启发。她2003年在加密编码算法的研究中得到了对于可定制计算非常有利的实验结果[6]。她使用加密算法的专用集成电路(ASIC)实现作为性能基数,如下图左边表格第一行所示。第二行是使用可定制计算的方法得到的运行数据,第三行是在ARM上编写汇编得出的运行数据。可以看见可定制计算总体优于此种方式85倍。再往下一行是在奔腾CPU上编写相同功能的汇编代码得到的运行数据,这在当时是最好的台式机芯片。可定制计算的优势高达8000倍。也许你会说这项研究是否有点老?那我们再来看一些其它的比较工作。下图右侧的图表来自一篇斯坦福大学2010年发表的文章。他们使用H.264视频编解码算法对定制指令集进行了评估。可以看见即使是用上了SIMD和定制指令集,通用CPU和ASIC的差距还是有50倍。显然你不可能对每个计算应用都开发专门的ASIC,这是一项既烧钱又耗时的工作。关键问题是任何算法的改动都需要重新开发一整块新的ASIC。请注意在左边的例子中,第二行的可定制计算是使用可重构的现场可编程逻辑门阵列(FPGA)做的实现。它既可以做到快速低成本,又保证高于通用CPU的性能。所以利用FPGA是一个非常有前景的解决方案。

img

有些同学可能会比较好奇说:等一会,我在计算机原理课上学过CPU的架构。为什么CPU的性能这么差,差到甚至成百上千倍?实际上原因通过下图看来非常简单明了。你们可以想一想CPU是怎么进行加法操作的。第一件事是从缓存或者内存里拿到这个指令放进处理器流水线。这个过程就已经有9%的能量消耗了。接着指令需要被解码从而CPU才知道这条指令到底要做什么事情,这里又有6%的能耗。因为现代处理器可以支持乱序执行,这样指令很有可能要被重命名来解决一些冲突的问题,这又导致12%的能耗。接下来从寄存器堆拿数据又产生3%。现在万事俱备就等着做加法了,等待数据会有11%的能耗。最终实际的计算部分只占了14%能耗,而剩下的杂事又产生23%能耗。在以上CPU的一系列操作中实际上只有做加法这一步是你关心的。然而,为了得到正确的加法结果一条加法指令需要走一个非常复杂的计算流水线。这就是为什么CPU不高效的原因。因此,未来或许不仅仅是网络交换领域,更多的领域都需要硬件定制。而FPGA则是硬件定制的首要选择。

FPGA是网络交换发展的必然选择

网络将受益于快速灵活的分组处理器。如果分组处理器可以处理自定义标头位,则它将简化新网络协议的设计和部署。同样,如果分组处理器可以处理自定义有效载荷位,则可以将关键网络功能(例如分组分类和共识协议)卸载到网络数据平面。同时,分组处理器必须是快速的。例如,截至目前,数据中心网络带宽一直在稳定增长:10Gbps以太网普及,25Gbps越来越流行,而100Gbps和400Gbps也已经普及。在执行复杂的数据包处理时以线速处理数据包转发需要大量的计算能力和可编程性。不幸的是,现有网络数据平面都无法同时实现灵活性和性能。我们调查了2008年,2012年和2016年的三种数据平面实施技术,以了解不同类型的网络数据平面如何发展以及为什么现有数据平面缺乏灵活性或性能;也就是说,网络数据平面是灵活的(可编程的)或高性能的,但不能兼而有之。

1、软件分组处理器 软件分组处理器是灵活的,但不是很快。软件分组处理器是用高级编程语言(例如C或C ++)编写并在通用CPU上执行的软件程序。25Gbps网络接口可以每19.2ns接收最小大小(64B)的数据包。但是,以这种速度,即使是对最后一级缓存的单次访问也将花费比数据包的到达时间更长的时间。即使使用所有高级软件技术(例如内核旁路,接收方缩放和数据直接I / O),在软件数据平面中处理数据包也具有挑战性。更糟糕的是,由于频率缩放停滞,CPU性能不可能提高。表1总结了2008、2012和2016年用于构建软件数据平面的CPU的三个示例,它们比较了CPU频率,内核总数,制造过程和内存带宽。表格的“核心数量”行显示,2016年CPU核心总数从4个增加到24个,而时钟频率从3.4GHz减少到2.2GHz。如果我们使用时钟频率来估计单线程性能,则性能在2008年至2016年期间不会得到改善。由于网络链接速度接近25Gbps或100Gbps,软件网络数据平面对服务器计算和内存功能造成了很大压力,因此变得不切实际。

img

表1:从2008年到2016年的Dell服务器规格,2008年的XeonCPU没有按核L2高速缓存,而是使用按插槽的L3高速缓存。

2、基于ASIC的分组处理器基于ASIC的分组处理器速度很快,但不灵活。 这些分组处理器通常用于现代交换机和路由器中,并且倾向于处理一组有限的协议。例如,表2比较了从2008年到2016年的三代Broadcom交换机ASIC,它们是交换机开发中使用的主要设备。收发器行显示,在此期间,端口数量和每端口链接速度已显着提高。但是,开关ASIC提供的功能集在很大程度上保持不变。因此,尽管性能有所提高,但在提供可编程数据平面方面,ASIC仍然不是最佳选择,因为难以满足未直接支持的应用要求。

img

表2:2008年至2016年Broadcom Trident系列交换机ASIC规范

3、基于FPGA的分组处理器

用FPGA实现的分组处理器在硬件性能和软件灵活性之间取得了平衡。例如,NetFPGA项目已被用于原型最短路径路由和拥塞控制算法。使用诸如Verilog之类的硬件描述语言来表达设计,并使用供应商特定的布局布线工具将其综合到FPGA。表3展示了Xilinx在2008、2012和2016年中的三代Virtex系列FPGA。我们为每一代选择了顶级的FPGA模型。Xilinx在每一代产品中使用的工艺技术与Broadcom在同一时期所采用的制造工艺相似。在此期间,Virtex FPGA上收发器的数据速率增加了3倍(从Virtex-6中的11.2Gbps增长到Virtex UltraScale +中的32.75Gbps),收发器的总数从Virtex-6中的72个略微增加到96个在UltraScale +中,由于封装限制,缩放比例有限。FPGA上的逻辑和内存资源分别增加了2倍和5倍。总体而言,FPGA由于具有可重新配置性,因此可以为软件提供竞争性的灵活性。它们提供了与ASIC相当的性能。

img

表3:2008年至2016年的Xilinx Virtex系列FPGA规范

基于FPGA的设计面临的挑战是,数据包处理管道通常使用数据包处理算法进行硬编码。实施新的数据包处理算法需要用户使用硬件描述语言进行编程。而这也是FPGA所面临的一个挑战。能否有更敏捷的开发方式来快速的实现FPGA的可编程,HLS?Chisel?还是别的什么?


树莓派安装 WireGuard 备忘

安装内核头文件

$ sudo apt install raspberrypi-kernel-headers

安装依赖库和编译所需工具

$ sudo apt install libmnl-dev build-essential git

编译安装 WireGuard

$ git clone https://git.zx2c4.com/WireGuard
$ cd WireGuard/
$ cd src/
$ make
$ sudo make install

启动

 # 从服务端获取配置和密钥公钥到/etc/wireguard
 wg-quick up wg0

开机启动

systemctl enable wg-quick@wg0

iptables转发备忘

# 查看nat转发表
iptables -nvL -t nat --line-numbers |more

# 本机: 10.101.7.1:40001(10.250.101.7:40001)
# 转发至10.250.0.1:22
iptables -t nat -A PREROUTING -p tcp -m tcp --dport 40001 -j DNAT --to-destination 10.250.0.1:22
iptables -t nat -A POSTROUTING -d 10.250.0.1 -p tcp -m tcp --dport 22 -j SNAT --to-source 10.101.7.1

# 或者
iptables -t nat -A PREROUTING -p tcp -i flannel.100 --dport 40001 -j DNAT --to 10.250.0.1:22
iptables -t nat -A POSTROUTING -j MASQUERADE

参考资料


树莓派容器构建备忘

由于树莓派是 ARM 芯片,大部分镜像都是基于 x86 架构的,所以无法直接使用,需要从0 开始编译。以下是一个常用镜像的编译,做个备忘。参考资料:

docker build -t ss .

dockerfile文件如下:

FROM multiarch/alpine:armhf-v3.10

ARG SS_VER
ENV SS_URL https://github.com/shadowsocks/shadowsocks-libev/archive/v3.3.4.tar.gz
ENV SS_DIR shadowsocks-libev-3.3.4

RUN set -ex \
    && apk add --no-cache c-ares \
                          libcrypto1.1 \
                          libev \
                          libsodium \
                          mbedtls \
                          pcre \
    && apk add --no-cache \
               --virtual TMP autoconf \
                             automake \
                             build-base \
                             c-ares-dev \
                             curl \
                             gettext-dev \
                             libev-dev \
                             libsodium-dev \
                             libtool \
                             linux-headers \
                             mbedtls-dev \
                             openssl-dev \
                             pcre-dev \
                             tar \
    && curl -sSL $SS_URL | tar xz \
    && cd $SS_DIR \
        && curl -sSL https://github.com/shadowsocks/ipset/archive/shadowsocks.tar.gz | tar xz --strip 1 -C libipset \
        && curl -sSL https://github.com/shadowsocks/libcork/archive/shadowsocks.tar.gz | tar xz --strip 1 -C libcork \
        && curl -sSL https://github.com/shadowsocks/libbloom/archive/master.tar.gz | tar xz --strip 1 -C libbloom \
        && ./autogen.sh \
        && ./configure --disable-documentation \
        && make install \
        && cd .. \
        && rm -rf $SS_DIR \
    && apk del TMP
    
    
ENTRYPOINT ["/usr/local/bin/ss-manager", "--manager-address", "/var/run/shadowsocks-manager.sock", "-c", "/etc/shadowsocks/config.json", "start"]    

运行参考:

docker run -d --name=ss --net=host -v /root/config.json:/etc/shadowsocks/config.json:rw ss

参考资料


k8s 的一些官方/权威学习资料

55038137449

最近在整理一些kubernetes的官方/权威资料,在这里做个记录。

官方

培训

博客

文章

  • 《Site Reliability Engineering: How Google Runs Production Systems》
  • 《BGP in the Data Center (O’Reilly 2017)》
  • 《数据中心网络:Spine- Leaf 架构设计综述(2016)》

链接

  1. Kubernetes 架构路线图

    整个 设计理念: design-proposals 文档已经被抛弃了,转到 KEP 去了,许多文件都是历史文件,可能已过时或未实施。历史文章可以学习。

    Kubernetes Architecture Current and Future - PPT

  2. Kubernetes KEPs

  3. kubernetes 设计理念归档

  4. Kubernetes 增强提案流程

  5. Kubernetes 开发指南

    1. k8s贡献:

    2. 开发:

      • 开发指南( development.md ):设置开发环境。
      • 测试( testing.md ):如何在开发沙箱中运行单元、集成和端到端测试。
      • 一致性测试( conformance-tests.md ) 什么是一致性测试以及如何创建/管理它们。
      • 随机失败测试 flaky-tests.md :目标 99.9% Flaky Tests。
      • 日志约定logging.md):klog 级别。
      • 分析 Kubernetes ( profiling.md ):如何将 go pprof 分析器插入 Kubernetes。
      • 新 metric ( instrumentation.md ):如何向 Kubernetes 代码库添加新的指标。
      • 编码约定coding-conventions.md):为贡献者提供的编码风格建议。
      • 文档约定Kubernetes 文档)为贡献者提供的文档风格建议。
      • 在本地运行集群running-locally.md):用于开发的快速轻量级本地集群部署。
    3. 针对 Kubernetes API 进行开发:

      • REST API文档: 介绍了REST API通过API服务器暴露。
      • 注释Annotations):用于将任意非标识元数据附加到对象。自动化 Kubernetes 对象的程序可能会使用注解来存储少量的状态。
      • API 约定( api-conventions.md ):定义 Kubernetes API 中使用的动词和资源。
      • API 客户端库( Client Libraries ):现有客户端库的列表,包括受支持的和用户贡献的。
    4. 编写插件:

      • 身份验证Authentication):身份验证令牌的当前和计划状态。
      • 授权插件Authorization):授权适用于主 apiserver 端口上的所有 HTTP 请求。本文档解释了可用的授权实现。
      • 准入控制插件admission_control
    5. 构建发布:

      参阅kubernetes/release存储库。

    6. SIG 开发人员相关

  6. Kubernetes 里程碑管理

  7. kubernetes issue

k8s设计思路

来自Kubernetes 架构路线图

  1. 核心,标准化的 API 和执行机制。包括

    • REST 机制
    • 安全性
    • Pod
    • 容器
    • cni
    • csi

    基本稳定,变动不大。

  2. 应用管理层,部署和路由部分,就是编排和服务网络相关的内容。包括

    • 健康检查/自恢复
    • 伸缩
    • 服务发现
    • 负载均衡
    • 路由

    k8s默认提供了实现,但允许开发者替换成另一套完整的方案。

  3. 治理层,提供更高级别的自动化和策略执行,包括

    • 多租户
    • 监控指标
    • 自动伸缩
    • provisioning
    • 授权方案
    • 配额quota方案
    • 网络方案
    • 存储方案
  4. 接口层,用于与 Kubernetes API 交互的常用库、工具、UI 和系统。

  5. 生态系统,不属于k8s“真正的一部分”。大部分的开发工作都在这一部分:

    • CI/CD
    • 中间件
    • 日志记录
    • 监控
    • 数据处理
    • PaaS
    • serverless/FaaS
    • 工作流
    • 容器运行时
    • 镜像管理
    • 节点管理
    • 云提供商管理

arch-roadmap-1

k8s学习路径

来自https://caicloud.io/blog/5d42b1fb0b15e4002bdd6cf6

  1. 第一阶段 炼气期

    • Kubernetes 的背景
    • 安装 Kubernetes 环境
    • Kubernetes 基本概念和使用方法

    不要尝试学习过多的资源类型。学会熟练使用以下常用资源并熟记它们的概念:Pod、Node、Label、Event、Service、Configmap & Secret、Deployment、Namespace。

  2. 第二阶段 筑基期

    • Kubernetes 的基本架构
    • Kubernetes 容器调度的基本流程

    学习文章,请不要死记硬背 Kubernetes 架构,要开动大脑去理解其背后设计的原因。

  3. 第三阶段 金丹期

    • Kubernetes API 结构
    • 熟悉 Kubernetes 各个子系统
    • 熟悉 Kubernetes 排错相关内容

    学习文章:

  4. 第四阶段 元婴期

    • 加深对各个资源的理解
    • 学习更多 Kubernetes 概念和知识
    • 计算/存储/网络/安全/调度
  5. 第五阶段 化神期

    • 学习更多 Kubernetes 集群层面的功能
    • 更加深入学习 Kubernetes 架构和组件能力

    各种参数的学习。保持两个基本点不动摇:

    • 一是懂 Kubernetes 架构和最核心的能力
    • 二是懂得怎么快速定位我们需要的能力
  6. 第六阶段 练虚期

    • 对 Kubernetes 的扩展机制了如指掌
    • 可以编写 Kubernetes 控制器,能够基于扩展机制灵活地二次开发

    开发:

    • 常见工具
      • kubebuilder:来自 Kubernetes 官方的 API 扩展项目
      • sample-controller:来自 Kubernetes 官方的一个样例
      • operator-sdk:来自红帽的一个 operator 库
      • shell-operator:适合运维开发使用的 shell operator 库
      • meta-controller:来自 Google 的一个更加”傻瓜”式编写控制器的库
    • API 资源扩展能力
      • Annotation:保存少量非结构化第三方数据
      • Finalizer:资源删除时,用户调用外部系统的钩子
      • CustomResourceDefinition:自定义 Kubernetes API
      • API Aggregation:多个 API Server 聚合,适用于较大量的 API 定制
    • API 访问扩展能力
    • 调度器扩展能力
    • 网络扩展能力
    • 存储扩展能力
    • 运行时扩展能力
    • 特殊硬件或资源扩展能力
      • 扩展资源 Extended Resource:通过 Kubernetes 原生 API 方式支持添加自定义资源
      • 设备插件 Device Plugin:使用 Device Plugin 插件,可以对接任何我们需要的硬件
    • 监控扩展能力

    推荐实现一个端到端的 Kubernetes 控制器,可以对整个 Kubernetes 的二次开发有更加深入的了解。此外,针对所有的扩展能力,建议先建立一个全面的认识,再根据需要深入某一项能力。

    除了通过用户手册来学习上面的技术,也可多参考 Kubernetes 的花式设计文档,主要是 Design Proposals、KEPs。

  7. 第七阶段 大乘期

    • 了解 Kubernetes 生态项目
    • 跟踪 Kubernetes 社区发展
    • 跟踪 CNCF 社区发展

Mac 开启 ssh 服务

开启

系统偏好设置 -> 共享

image-20200319011355023

image-20200319011410376

确认

launchctl list | grep ssh

image-20220805101412197

命令行开启或关闭:

sudo launchctl load -w /System/Library/LaunchDaemons/ssh.plist
sudo launchctl unload -w /System/Library/LaunchDaemons/ssh.plist