CRIO的数据分组转发过程如图2所示，用户网络A中的一台主机欲发送数据分组给用户网络B中的一台主机，其中路由器PE3是VP 24.0.0.0/8的VP-TS，它将通过隧道技术虚拟聚合24.0.0.0/8覆盖的所有子前缀，例如24.1.1.0/24。入口路由器PE1、出口路由器PE2分别属于不同的AS，整个转发流程如下：
PE3向PE1发送VP的BGP通告，PE1的路由表添加一条路由信息(24.0.0.0/8，PE3)
CE1向PE1发送一个24.1.1.0/24的数据分组
PE1在路由表中未查询到24.1.1.0/24的路由信息，但查到路由信息(24.0.0.0/8，PE3)于是将该数据分组转发给PE3
PE3存有24.1.1.0/24的映射信息(24.1.1.0/24，PE2)，根据此映射信息，PE3将数据分组通过隧道发往TE PE2
PE2知道要通过CE2才能到达24.1.1.0/24网络，因此将数据分组去掉封装报头后转发给CE2。
整个转发路径为CE1→PE1→PE3→PE2→CE2，但若PE1存有24.1.1.0/24的映射消息，路径为CE1→PE1→PE2→CE2。由此可见，CRIO在实现地址聚合的同时却将分组的转发路径拉长了。
实施CRIO方案时，BGP路由器只需要存储到Internet的入网点(POP)的路由以及VP-TS的路由。全球的大型提供商共有几千个POP，如果VP被定为/8，整个地址空间共有256个VP，这样传统路由器的路由表(RIB)规模就可以从105量级减少到103量级，大大减少了BGP路由的计算量和路由表的大小同时，路由器中存储的路由指向终点(大型提供商的POP)也会非常的稳定，从而减少了BGP信息的更新频率。文献11对CRIO进行了仿真试验(如图3所示)：采用在所有的ISP上随机部署VP，或在每个ISP内部署所有的VP，或所有的ISP内部路由都是最短路径的3种不同VP部署策略，考察转发表大小与路径长度的关系，结果表明在平均路径长度增加很少的情况下，第一个策略使部署了CRIO的FIB的规模减小一个数量级，其他两个方案则使FIB的规模减小到未部署CRIO的FIB的1/5左右，BGP RIB的规模则可以减少近两个数量级。
CRIO虽然能够缓解目前路由系统所面临的路由表膨胀压力，但是它尚存一些待解决的问题，当多个ISP同时部署VP-TS时，如何解决转发路径可能被多次拉长的问题目前尚不清楚CRIO使数据分组的转发路径拉长，增加了数据分组在路由器内的处理时间，从而增加了传送时延由于CRIO使用隧道技术，封装也会导致带宽、CPU资源的开销增加VP-TS集中了所有发往被聚合的子前缀的流量，很容易成为网络“瓶颈”此外，CRIO缺乏对移动性的支持以上这些问题都有待相关研究人员作进一步的研究。
VA是IETF GROW工作组的提案之一，用于解决当前路由扩展性。VA与CRIO一样，使用隧道技术虚拟聚合分散的子前缀成VP。在VA中，聚合代理被称为汇聚点路由器(APR)。VA的部署范围仅限于ISP内，所以作为隧道起点的APR存储VP内的每个子前缀及对应的远端AS的边界路由器(ASBR)地址，并负责将数据分组通过隧道传送到隧道终点，即远端AS的边界路由器(ASBR)地址，如图4所示。VA保持BGP路由器中的RIB不变，只是阻止RIB中的一些表项加载到BGP路由器的FIB中，这是VA与CRIO的一个不同之处。VA的隧道并不跨越多ISP，解封装数据分组的任务由本地ISP的边缘路由器完成，无需与其他ISP进行协作，这是VA与CRIO的另一区别。由于VA与CRIO的基本思路相似，所以也存在与CRIO一样的问题。此外，由于VA只压缩了路由器中FIB规模，RIB的快速增长仍未得到解决。
2.2 标志和位置标志分离
2.2.1 主机驱动型
主机驱动型是指在主机协议栈的网络层和传输层之间加入主机标志层的分离类型，主机标志负责标志主机，网络地址负责数据分组的寻址和传送，应用连接不再与IP地址绑定，而是与主机标志绑定，网络层IP地址只作为网络层使用的位置标志，用于数据分组的路由转发。IP地址的变更对传输层以上透明，从而IP地址的改变可以不中断已经建立的应用连接，达到支持主机移动性和多归属的目的。HIP是主机驱动型的典型方案，主要要解决主机的安全和移动性问题，如果所有的IP网络都部属HIP，所有的主机都使用全新的名字空间作为主机标志，IP地址仅用于路由，IP地址就可完全按照网络拓扑分配，IP地址恢复可聚合性，从而彻底解决路由扩展性的问题。
HIP在网络层和传输层中间插入主机标志层(HIL)，实现了身份与位置标志的分离，引入主机标志层后的协议体系结构如图5右侧协议栈所示。HIP引进一个新的加密的命名空间，该命名空间引入了3个新的标志符：主机标志符(HI)、主机标志标签(HIT)和局部标志符(LSI)。主机标志符唯一地标志了每台连接到Internet上的主机，每个主机可以有多个HI。HI可以用不对称加密算法中公/私密钥对的公钥来表示，由于不同的加密算法所拥有的密钥长度不一样，因此，在实际使用时，通常用128位定长的HIT来代替HI标志主机身份，HIT是对HI的某种哈希变换，与IPv6地址等长，在应用程序中使用非常方便，同时为了和现有的IPv4地址兼容，HIP协议还定义了LSI，作为局部系统中使用的主机标志符。HIP协议的基本交换是一个使用公钥作为主机标志并建立HIP基本交换加密的4次握手过程，它可以保证通信的安全性。
Red Hat Enterprise Linux CoreOS (RHCOS)代表了下一代的单用途容器 *** 作系统技术。RHCOS是由创建Red Hat Enterprise Linux Atomic Host和CoreOS Container Linux的开发团队创建的，它将Red Hat Enterprise Linux (RHEL)的质量标准与Container Linux的自动化、远程升级特性结合在一起。
RHCOS仅作为OpenShift容器平台4.3的一个组件被支持，适用于所有的OpenShift容器平台机器。RHCOS是OpenShift容器平台控制平面或主机的唯一支持的 *** 作系统。虽然RHCOS是所有集群机器的默认 *** 作系统，但是您可以创建使用RHEL作为其 *** 作系统的 compute 节点(也称为 worker 节点)。RHCOS在OpenShift容器平台上的部署方式有两种:
基于RHEL : 底层 *** 作系统主要由RHEL组件组成。支持RHEL的同样质量、安全和控制措施也支持RHCOS。例如，RHCOS软件在RPM包中，每个RHCOS系统都启动一个RHEL内核和一组由systemd init系统管理的服务。
受控不变性 : 虽然它包含RHEL组件，但RHCOS的设计比默认的RHEL安装管理更严格。管理是在OpenShift容器平台集群中远程执行的。当您设置您的RHCOS机器时，您只能修改一些系统设置。这种受控制的不变性允许OpenShift容器平台在集群中存储RHCOS系统的最新状态，因此它总是能够创建额外的机器，并根据最新的RHCOS配置执行更新。
crio容器运行时 :虽然RHCOS包含运行Docker所需的OCI和libcontainer格式容器的特性，但它合并了crio容器引擎，而不是Docker容器引擎。通过专注于Kubernetes平台所需的特性(如OpenShift容器平台)，crio可以提供与Kubernetes不同版本的特定兼容性。与提供更大特性集的容器引擎相比，crio还提供了更小的足迹和更少的攻击面。目前，crio仅作为OpenShift容器平台集群中的容器引擎可用。
容器工具集 :对于诸如构建、复制和以其他方式管理容器的任务，RHCOS使用一组兼容的容器工具替换Docker CLI工具。podman CLI工具支持许多容器运行时特性，比如运行、启动、停止、列出和删除容器和容器映像。skopeo CLI工具可以复制、验证和签署图像。您可以使用crictl CLI工具来处理来自crio容器引擎的容器和吊舱。虽然不鼓励在RHCOS中直接使用这些工具，但是可以将它们用于调试目的。
rpm-ostree升级 :RHCOS提供使用rpm-ostree系统的事务升级。更新是通过容器映像交付的，并且是OpenShift容器平台更新过程的一部分。部署后，将提取、提取容器映像并将其写入磁盘，然后修改引导装载程序以引导到新版本。机器将以滚动的方式重新启动更新，以确保集群容量受到的影响最小。
通过MachineConfigOperator更新 :在OpenShift容器平台中，Machine Config Operator 处理 *** 作系统升级。与通过yum升级来升级单个包不同，rpm-ostree将 *** 作系统的升级作为一个原子单元来交付。新的 *** 作系统部署在升级期间进行，并在下一次重新启动时生效。如果升级出现问题，一次回滚和重新启动将使系统恢复到以前的状态。OpenShift容器平台中的RHCOS升级是在集群更新期间执行的。
对于RHCOS系统，rpm-ostree文件系统的布局具有以下特点:
RHCOS被设计成部署在OpenShift容器平台集群上，只需要最少的用户配置。其最基本的形式包括:
因为OpenShift容器平台中的RHCOS系统被设计为在此之后完全由OpenShift容器平台集群管理，所以不鼓励直接更改RHCOS机器。虽然可以出于调试目的对RHCOS机器集群进行有限的直接访问，但是不应该直接配置RHCOS系统。相反，如果您需要在您的OpenShift容器平台节点上添加或更改特性，请考虑通过以下方式进行更改:
下面是一些你可以在 day-1 进行的定制的例子:
为了完成这些任务，您可以扩展openshift-install过程，以包括额外的对象，如MachineConfigs。那些导致创建MachineConfigs的过程可以在集群启动后传递给Machine Config Operator。
针对OpenShift容器平台的RHCOS部署之间的差异取决于您是部署在安装程序提供的基础设施上，还是部署在用户提供的基础设施上:
Ignition只有在首次安装RHCOS系统时才能运行。之后，可以使用MachineConfigs提供Ignition配置。
Ignition是在初始配置期间被RHCOS用来 *** 作磁盘的实用工具。它完成常见的磁盘任务，包括分区磁盘、格式化分区、编写文件和配置用户。在第一次启动时，Ignition从安装介质或您指定的位置读取其配置，并将配置应用到机器上。
无论您是安装集群还是向集群中添加机器，Ignition总是执行OpenShift容器平台集群机器的初始配置。大多数实际的系统设置是在每台机器上进行的。对于每台机器，Ignition将获取RHCOS镜像并启动RHCOS内核。在内核命令行上的选项，识别部署类型和启用了启动的初始Ram磁盘(initramfs)的位置。
要使用Ignition创建机器，您需要Ignition配置文件。OpenShift容器平台安装程序创建了部署集群所需的Ignition配置文件。这些文件基于您直接或通过安装配置提供信息给install-config.yaml 文件。
Ignition配置机器的方式与cloud-init或Linux Anaconda kickstart等工具配置系统的方式类似，但有一些重要的区别:
在OpenShift容器平台集群中，RHCOS机器的Ignition过程包括以下几个步骤:
然后，机器就可以加入集群，不需要重新启动。
要查看用于部署引导机的Ignition配置文件，请运行以下命令:
在你回答了几个问题之后，bootstrap.ign, master.ign, 和worker.ign文件出现在您输入的目录中。
为了查看 bootstrap.ign文件，通过jq过滤器，以下是该文件的一个片段:
解码 bootstrap.ign文件内容。将表示该文件内容的base64编码的数据字符串通过管道传输到base64 -d命令。下面是一个例子，使用/etc/motd文件的内容从上面的输出添加到引导机:
在master.ign 和 worker.ign 文件上重复这些命令，查看每种机器类型的Ignition配置文件的来源。对于worker.ign，您应该看到类似下面这样的一行。确定它如何从引导机获得Ignition配置:
下面是一些你可以从bootstrap.ign文件学到:
Machine Config Pools管理节点集群及其相应的Machine Configs。Machine Configs包含集群的配置信息。列出所有已知的Machine Config Pools：
列出所有的Machine Config:
在应用这些MachineConfigs时，Machine Config Operator 的行为与Ignition有所不同。machineconfigs按顺序读取(从00 到99 )。machineconfigs中的标签标识每个节点(主节点或工作节点)的类型。如果相同的文件出现在多个machineconfig文件中，则最后一个获胜。因此，例如，出现在99 文件中的任何文件都将替换出现在00 文件中的相同文件。输入的machineconfig对象被合并到一个“呈现的”machineconfig对象中，该对象将被operator用作目标，并且是您可以在machineconfigpool中看到的值。
要查看从一个MachineConfigs中管理哪些文件，请在一个特定的MachineConfigs中查找“Path:”。例如:
如果您想要更改其中一个文件中的设置，例如将crio.conf文件中的pids_limit更改为1500 (pids_limit = 1500)，您可以创建一个新的只包含您想要更改的文件的machineconfig。
确保稍后为machineconfig指定一个名称(例如10-worker-container-runtime)。请记住，每个文件的内容都是url样式的数据。然后将新的machineconfig应用于集群。
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）