CCA 模拟考 A

在每个节点上运行的cilium-agent承担什么职责？

• 代表API服务器确定Pod调度
• 监控节点的端点、策略和服务状态，以更新该节点的eBPF映射和程序
• 单手分配整个集群的身份并部署到其他节点
• 代表kubelet在容器运行时指导Pod创建

为什么Cilium基于身份而不是IP地址执行策略？

• 基于IP的规则不能存储在eBPF映射中
• 因为Kubernetes不提供Pods IP
• 这是因为标识号始终比IP地址短，节省了eBPF映射容量。
• Pod IP从重新计划更改为重新计划，但标签集完好无损，因为如果使用标签派生的标识，则无需重新计算规则

CiliumEndpoint资源代表什么？

• 由Cilium管理的单个工作负载的网络状态，包含标识和IP以及策略执行状态
• PodCIDR频段分配给节点
• 群集中定义的网络策略列表
• Hubble这是在该节点收集的流的聚合结果。

关于Cilium的cluster-pool IPAM模式，以下哪项陈述是正确的？

• 您需要为每个节点创建单独的云子网
• kube-controller-manager给出的PodCIDR。
• Cilium截断此集群频带中每个节点的块，并将其信息记录在CiliumNode中
• 每个POD直接从云提供商附加辅助IP

Cilium Operator不做什么？

• 在IPAM池中为每个节点分配块
• 检索未使用的身份
• 对CiliumEndpoint等资源进行垃圾回收
• 将每个节点的eBPF程序直接加载到内核中

在身份分配模式下使用CRD和KVStore(etcd)有什么区别？

• CRD模式使用Kubernetes API服务器作为存储库，因此没有额外的操作负担，并且KVStore模式放置外部etcd以从大型集群卸载API服务器。
• CRD模式仅覆盖L3策略， L7策略只能在KVStore模式下执行
• CRD模式无法写入IPv6
• 两种模式的名称不同，保存位置相同

移除kube-proxy并使用Cilium的替代功能时，必须指定什么值？为什么？

• 节点的MTU值，因为我们需要计算隧道开销
• Hubble中继地址，因为我们需要收集流量
• 这是API服务器的地址和端口，因为没有kube-proxy，就无法用ClusterIP到达API服务器，所以在启动时有循环
• etcd端点列表，因为需要在仓库中查找标识

选择原生路由而非隧道模式时，必须满足什么条件？

• 所有节点必须使用相同的内核版本
• 节点之间的下层网络应该知道POD CIDR，并且能够原样路由
• 所有Pod必须使用hostNetwork
• 集群必须是单个节点

当我打开VXLAN封装时，为什么要关心MTU？

• 内部有效负载与封装报头一样减少，否则大数据包将被分段或丢弃，导致间歇性故障
• 因为当封装打开时，内核会将MTU初始化为零。
• 因为VXLAN仅适用于巨型帧
• 因为MTU的值进入了恒等计算

在链式模式下将Cilium附加到现有CNI的配置有哪些特点？

• 链条接管Cilium直至IPAM
• 网络策略不能在链接模式下写入
• 现有的CNI负责地址分配和默认链接， Cilium将策略和观察置于其上
• 链是一种方法，其中两个CNI每个授予一个Pod IP

在执行L7策略时， Cilium如何处理流量？

• eBPF直接从内核解析到HTTP方法和路径
• 只有该流量将被转移到节点上的Envoy代理以应用L7规则，其余的将直接倒入eBPF路径
• 将所有流量无一例外地发送到Envoy
• 每个Pod自动注入Sidecar代理

为什么Cilium需要保留身份？

• 因为政策中只能引用预订身份。
• 为未标记的Pod提供临时编号。
• 创建与预先创建的节点数量一样多的身份。
• 这是因为策略应指向没有Kubernetes标签的目标，例如主机或群集外地址。

CiliumNetworkPolicy和CiliumClusterwideNetworkPolicy有什么区别？

• 前者仅覆盖L3，后者直至L7
• 前者属于且仅适用于命名空间，而后者没有针对整个集群甚至主机的命名空间。
• 前者只能表示allow，后者只能表示deny
• 后者仅适用于Cilium Operator浮动，否则忽略

如果没有选择哪个Pod的策略， Pod的流量会发生什么情况？

• 所有路线都将被屏蔽
• 只有ingress将被阻止
• Cilium自动粘贴此默认策略模板
• 允许所有路线

哪个保留实体用于允许集群外的流量流向互联网？

• cluster
• host
• remote-node
• world

toFQDNs规则需要什么才能发挥作用？

• Cilium查看DNS查询的egress允许DNS端口和DNS可见性规则
• 为每个节点部署单独的DNS服务器
• 在kube-proxy中激活IPVS模式并设置会话亲和力
• Hubble UI安装

except字段在toCIDRSet中做什么？

• 创建单独的deny规则，明确拒绝指定的波段
• 将异常波段中的流量仅保留为日志
• 将异常区段委托给其他策略
• 从允许频带内减去特定子频带，以便此规则不允许部分子频带

首次应用egress策略后， Pod中的所有服务名解析均失败。最可能的原因是什么？

• DNS本身被阻止，因为不允许UDP 53 egress前往kube-dns
• 政策在ingress方向应用不正确
• CoreDNS Pods尚未收到标识
• 应用策略时初始化的Pod上的resolv.conf

当L7 HTTP规则只允许某些路径时，来自不允许路径的请求是如何处理的？

• TCP在连接阶段被阻塞，客户端看到连接被拒绝
• 请求通过，仅留下审核日志
• 连接已建立，代理返回HTTP 403响应
• 在客户端超时之前未收到响应

打开策略审计模式（ policy audit mode ）时会发生什么？

• 默认拒绝也将开始应用于没有策略的Pod
• 让将被拒绝的流量实际通过，但将其记录为审核，以便在执行策略之前查看影响的范围
• 所有流量立即被拦截，只剩下日志
• 仅强制L7规则，忽略L3规则

同一个Pod同时应用了标准NetworkPolicy和CiliumNetworkPolicy，结果如何？

• 两个策略的验收规则将被评估为联合，如果选择了任一方向，则将启动默认拒绝
• CiliumNetworkPolicy完全取代标准策略
• 标准策略优先，忽略Cilium策略
• 被确定为冲突，且两项政策均不适用

我们希望限制主机本身的传入流量。我们需要什么？

• 为每个节点手动添加iptables规则
• 一般指定hostNetwork POD作为选择器CiliumNetworkPolicy
• 打开主机防火墙功能，使用nodeSelector编写CiliumClusterwideNetworkPolicy
• 重新打开kube-proxy以管理节点端口

如果我将策略强制模式保留为always，会发生什么？

• deny规则始终在allow规则之后进行评估
• 策略默认拒绝所有未检查的端点，因此如果没有明确的权限，通信将丢失
• L7规则自动应用于所有流量
• 现有连接将被保留，仅检查新连接

与边车模式相比，Cilium的无边车服务网格模型有什么特点？

• 要使用L7功能，您仍然需要为每个pod放置一个代理
• 不支持HTTP基于路径的路由，因为根本不使用代理
• L3和L4由eBPF处理，仅需要L7的流量由节点级代理处理，减少了代理数量和每个POD的资源消耗
• 网格函数在API服务器上运行，而不是在节点上运行

在节点级共享代理时，需要承担什么代价？

• 代理故障或过载的影响范围不是由单个Pod扩大，而是由该节点上的多个工作负载扩大
• 您需要为每个节点使用不同版本的Envoy
• L7策略不适用于命名空间之外
• 每次重启Pod时都会重置代理设置

使用Cilium编写Gateway API需要什么？

• 应将Sidecar注入所有Pod中
• 安装Gateway API CRD，打开Cilium对Gateway API的支持，写入指向cilium控制器的GatewayClass
• 您需要一起部署一个单独的Ingress控制器，并将路由委托给它
• kube-proxy必须维护

使用CiliumEnvoyConfig的最合适情况是什么？

• 我想更改将IP分配给Pod的方式
• 当您想要加密节点之间的流量时
• 当您想要协调整个集群的身份计算中使用的标签列表时
• Gateway当要放置API或Ingress未表示的Envoy级侦听器和路由设置时，

在比较WireGuard和IPsec的节点到节点流量加密方面，哪个陈述是正确的？

• 两者都透明加密节点间的流量， WireGuard设置简单，在有合规需求的环境中选择IPsec
• WireGuard每pod加密， IPsec每节点加密
• IPsec只能在隧道模式下使用， WireGuard只能在本地路由中使用
• 两种方法必须同时开启才能正常运行

如果启用节点到节点加密，您将无法获得什么？

• 往返节点的Pod流量的保密性
• 防御物理网络窃听
• 基于工作负载身份的应用程序级相互身份验证
• 应用时无需更改应用程序代码

如何用Gateway API的HTTPRoute按90:10将流量分配给两个后端服务？

• 您需要为每个服务单独创建一个Gateway
• 在backendRefs中列出两个服务并分别指定weight
• 将pod副本数设置为9比1
• 在CiliumNetworkPolicy中指定比率

在Cilium Ingress或Gateway上终止TLS需要什么？

• 您需要手动将证书复制到每个Pod
• 证书必须保存为ConfigMap
• 创建包含证书和密钥的Secret，在资源中引用它， Cilium将读取它并将其传递给Envoy
• 不支持关闭TLS，必须在后端完成

与边车网格相比，Cilium模型中的可观测数据有什么不同？

• 代替离开Pod时的代理参考指示器，在节点数据平面中看到的流量将是默认的观察单位
• 您根本无法获得任何指标。
• L7信息在任何情况下都不可见
• 观测数据仅存储在API服务器上，查看为kubectl

在引入Cilium的服务网格功能之前，需要检查哪些实际约束？

• 如果打开网格，现有网络策略将失效，您需要重写规则
• 网格功能仅在单节点集群上受支持
• 如果打开网格，则需要重新生成所有Pod
• Sidecar Mesh提供的一些细粒度流量控制尚不具备响应能力或需要直接在CiliumEnvoyConfig中编写

使用hubble observe时，如何只查看特定命名空间中被拒绝的流量？

• 将所有流程拖放到文件中，并通过文本编辑器进行搜索
• 将命名空间过滤器和判断过滤器挂在一起，仅输出DROPPED流
• 仅Hubble UI，不能用CLI过滤
• 您需要先将策略置于审核模式，然后才能查看它

为什么选择hubble-relay？

• 因为它充当了流长期存储的数据库。
• 因为它计算政策决策。
• 因为它是唯一生成Prometheus指示器的组件。
• 因为每个节点上的代理都会聚合收集的流，以便可以在一个地方查询它们。

关于在Hubble中保留流量数据，以下哪项陈述是正确的？

• 旧流将被推开，因为每个节点都打包在一个大小的环形缓冲区中
• etcd中永久保存
• CiliumEndpoint将积累资源
• 默认存储期设置为7天

尝试将Hubble指标采集为Prometheus时需要做什么？

• 将Prometheus Sidecar连接到所有Pod
• hubble observe定期将输出保存到文件
• 激活Hubble度量以公开指标端点，并将该端点注册为抓取目标
• 务必一起安装Hubble UI

流量记录中看不到L7信息，最可能的原因是什么？

• 因为hubble-relay删除了L7信息
• 因为流量没有L7规则或可见性设置，并且不通过代理
• 因为L7信息仅在Hubble UI中可见
• 因为eBPF仅解析加密流量。

如何保留流量记录，以便日后用于故障调查？

• 将环形缓冲区大小增加到最大就足够了。
• 始终保持策略审核模式开启
• 增加节点重新启动周期
• 打开“流导出”以流式传输到文件或日志收集管道，并将其保留在外部存储上

安装后要用真实流量验证数据平面是否正常，合适的方法是什么？

• kubectl get pods查看pod是否为Running
• 使用helm list检查发布状态
• 连接到节点，手动发送ping几次
• 运行连接测试以部署测试工作负载，并自动检查pod到pod、节点到节点和外向通信

手动修改cilium-config ConfigMap的值。我需要考虑什么？

• 客服代表在下一个同步周期自动反映
• API服务器需要重启
• 节点需要按顺序重新启动
• 需要重新启动Agent Pod，然后在一个地方进行管理，以确保它们不会与Helm值冲突

为什么在升级Cilium之前先部署preflight？

• 预下载新版本镜像，检查环境与CRD的兼容性，减少实际升级时的停机时间。
• 自动将现有策略转换为新版本的语法。
• 在升级期间阻止所有流量。
• 删除旧版本的eBPF映射。

在已使用kube-proxy的集群中，安全切换到Cilium替代功能的顺序是什么？

• 先删除kube-proxy DaemonSet，然后更改Cilium设置
• 同时关闭两个功能并重新启动集群
• 在Cilium中打开回退功能，检查正常行为并删除kube-proxy
• 将节点逐个从集群中取出，并将它们全部连接在一起

cilium status命令告诉你什么？

• 集群中所有pod的CPU和内存使用情况
• 每个节点代理的状态和数据平面模式，以及控制器和组件是否异常
• 应用的网络策略的全部内容
• 节点内核配置文件的内容

安装Cilium时，如果CRD版本和代理版本不一致，会发生什么情况？

• 包含新字段的资源已被拒绝或忽略，因此策略可能无法按预期应用
• API服务器启动失败
• 代理将自动将CRD还原为以前的版本
• 所有Pod将立即断开连接

尝试配置ClusterMesh时，每个集群需要什么？

• 所有群集必须是相同的云提供商
• 所有集群必须共享一个API服务器
• 每个集群必须有自己的名称和ID，节点必须能够到达彼此的pod频段
• 所有集群必须具有相同的Kubernetes版本

您如何创建全局服务？

• 为每个集群创建相同名称和命名空间的服务，并追加全局注释
• 仅在一个集群上创建服务，其余部分称为ExternalName
• 直接在clustermesh-apiserver中列出服务
• 将所有Pod中远程集群的IP作为环境变量

合并为全局服务后，客户端会看到什么行为？

• 请求始终首先转到远程群集
• 服务名称解析结果将从集群重命名为集群
• 您必须为每个集群手动指定单独的ClusterIP
• 使用与之前相同的服务名称连接，但甚至在后端列表中包含远程集群上的pod

clustermesh-apiserver有什么作用？

• 将所有Pod流量中继到远程群集
• 暴露自群集的身份以及端点和服务信息，供其他群集读取
• 仅确定群集之间的策略
• 代表远程集群中的API服务器

在ClusterMesh环境中编写策略时，我应该注意什么？

• 如果未在端点选择器中指定群集，则可以将来自具有相同名称的不同群集的工作负载匹配在一起
• L7策略不能在ClusterMesh中使用
• 策略必须应用于同一文件中的所有群集
• 群集范围策略在ClusterMesh中被忽略

如何确认ClusterMesh连接状态正常？

• 比较每个集群中的pod数量，看看它们是否相同
• 查看远程集群上带有kubeconfig的Pod列表
• 尝试将ping从节点发送到远程Pod IP
• cilium clustermesh检查status连接的簇数和同步状态

为什么需要eBPF映射？

• 因为eBPF程序不能留下内核日志
• eBPF程序无法在调用之间保持状态，因此它将状态放在地图上并与用户空间共享，例如连接跟踪器或服务列表
• 因为eBPF程序允许您直接分配内核内存。
• 因为您必须有一个映射，以便程序可以绕过验证器。

XDP钩子与tc钩子的区别是什么？

• XDP专用于egress路线， tc专用于ingress路线，因此路线划分
• XDP在用户空间中运行， tc在内核中运行
• XDP在驱动层处理传入数据包的时间非常早，因此丢包性能非常出色， tc稍晚一些，因此有利于使用内核元数据进行处理。
• tc只处理IPv4， XDP只处理IPv6

以下哪种情况会导致eBPF验证器拒绝加载程序？

• 当有可能危及内核的代码时，例如没有保证关闭的循环语句或未经检查的指针访问
• 当程序使用多个地图时
• 当程序以C语言编写时
• 当程序通过地图与用户空间交换数据时

用eBPF而不是内核模块实现数据平面有什么优势？

• 无论内核版本如何，您都可以使用任何函数
• 并重新编译内核源代码。
• 在经过验证的沙箱中运行，大大降低了错误代码破坏整个内核的风险，并允许在不重新启动的情况下刷新功能
• 与执行相同操作的用户空间程序相比，我总是使用更少的内存

连接跟踪映射已满时会出现什么症状？

• 政策规则将自动放宽
• 新连接失败或现有项目被提前回收导致间歇性连接错误，增加地图大小是响应
• 专员将立即终止
• 来自新连接的所有流量都被绕过到用户空间代理

开启eBPF主机路由有什么不同？

• 每个Pod将有一个单独的路由表
• 所有流量均按XDP处理
• 跳过主机网络堆栈的大部分，由eBPF手动交付，以减少CPU的延迟和使用
• 路由决策从内核传递到用户空间代理

最适合使用Cilium的BGP功能的目的是什么？

• 以加密节点之间的Pod流量。
• 在内部路由器上通告Pod频段或负载均衡器IP，使其直接从集群外部路由到该地址。
• 替换集群中的服务发现。
• 自动将授权的IP分配给节点。

在本地数据中心环境中，如何为LoadBalancer类型的Service分配IP？

• 手动将NodePort分配给每个服务
• 将节点的主机IP直接写入服务
• 将kube-proxy更改为IPVS模式
• 如果为LB IPAM定义IP池资源，则Cilium将从该池分配地址

我已经设置了BGP对等，但它没有从外部连接到负载均衡器IP。最好先检查哪一项？

• 尝试重新启动所有Pod
• 更改服务的选择器标签，查看后端是否再次捕获
• 检查对等会话是否为Established，以及广告的目标是否实际包含IP频段
• 尝试降低节点的MTU