两学一做知识竞赛网站,江宁区建设局网站,套模板建设网站多少钱,怎么简单做网站排名文章目录 一、简述 Kubernetes 如何保证集群的安全性二、简述 Kubernetes 准入机制三、简述 Kubernetes RBAC 及其特点#xff08;优势#xff09;四、简述 Kubernetes Secret 作用五、简述 Kubernetes Secret 有哪些使用方式六、简述 Kubernetes PodSecurityPolicy 机制七、… 文章目录 一、简述 Kubernetes 如何保证集群的安全性二、简述 Kubernetes 准入机制三、简述 Kubernetes RBAC 及其特点优势四、简述 Kubernetes Secret 作用五、简述 Kubernetes Secret 有哪些使用方式六、简述 Kubernetes PodSecurityPolicy 机制七、简述 Kubernetes PodSecurityPolicy 机制能实现哪些安全策略八、简述 Kubernetes 网络模型九、简述 Kubernetes CNI 模型十、简述 Kubernetes 网络策略十一、简述 Kubernetes 网络策略原理十二、简述 Kubernetes 中 flannel 的作用十三、简述 Kubernetes Calico 网络组件实现原理十四、简述 Kubernetes 共享存储的作用十五、简述 Kubernetes 数据持久化的方式有哪些十六、简述 Kubernetes PV 和 PVC十七、简述 Kubernetes PV 生命周期内的阶段十八、简述 Kubernetes 所支持的存储供应模式十九、简述 Kubernetes CSI 模型二十、简述 Kubernetes Worker 节点加入集群的过程二十一、简述 Kubernetes Pod 如何实现对节点的资源控制二十二、简述 Kubernetes Requests 和 Limits 如何影响 Pod 的调度二十三、简述 Kubernetes Metric Service二十四、简述 Kubernetes 中如何使用 EFK 实现日志的统一管理二十五、简述 Kubernetes 如何进行优雅的节点关机维护二十六、简述 Kubernetes 集群联邦二十七、简述 Helm 及其优势二十八、什么是 Headless Service二十九、简述K8s 常用的 CNI 网络插件calico flannel的工作原理和区别三十、Worker 节点宕机简述 Pods 驱逐流程三十一、简述 kube-proxy 的三种工作模式和原理三十二、Docker 的网络通信模式 一、简述 Kubernetes 如何保证集群的安全性 Kubernetes 通过一系列机制来实现集群的安全控制主要有如下不同的维度 基础设施方面保证容器与其所在宿主机的隔离权限方面 最小权限原则合理限制所有组件的权限确保组件只执行它被授权的行为通过限制单个组件的能力来限制它的权限范围。用户权限划分普通用户和管理员的角色。 集群方面 API Server 的认证授权Kubernetes 集群中所有资源的访问和变更都是通过 Kubernetes API Server 来实现的因此需要建议采用更安全的 HTTPS或 Token 来识别和认证客户端身份Authentication以及随后访问权限的授权Authorization环节。API Server 的授权管理通过授权策略来决定一个 API 调用是否合法。对合法用户进行授权并且随后在用户访问时进行鉴权建议采用更安全的 RBAC 方式来提升集群安全授权。敏感数据引入 Secret 机制对于集群敏感数据建议使用 Secret 方式进行保护。AdmissionControl准入机制对 kubernetes api 的请求过程中顺序为先经过认证 授权然后执行准入操作最后对目标对象进行操作。 二、简述 Kubernetes 准入机制 在对集群进行请求时每个准入控制代码都按照一定顺序执行。如果有一个准入控制拒绝了此次请求那么整个请求的结果将会立即返回并提示用户相应的 error 信息。准入控制AdmissionControl准入控制本质上为一段准入代码在对 kubernetes api 的请求过程中顺序为先经过认证 授权然后执行准入操作最后对目标对象进行操作。常用组件控制代码如下 AlwaysAdmit允许所有请求AlwaysDeny禁止所有请求多用于测试环境。ServiceAccount它将 serviceAccounts 实现了自动化它会辅助 serviceAccount做一些事情比如如果 pod 没有 serviceAccount 属性它会自动添加一个 default并确保 pod 的 serviceAccount 始终存在。LimitRanger观察所有的请求确保没有违反已经定义好的约束条件这些条件定义在 namespace 中 LimitRange 对象中。NamespaceExists观察所有的请求如果请求尝试创建一个不存在的 namespace则这个请求被拒绝。 三、简述 Kubernetes RBAC 及其特点优势 RBAC 是基于角色的访问控制是一种基于个人用户的角色来管理对计算机或网络资源的访问的方法。相对于其他授权模式RBAC 具有如下优势 对集群中的资源和非资源权限均有完整的覆盖。整个 RBAC 完全由几个 API 对象完成 同其他 API 对象一样 可以用 kubectl或 API 进行操作。可以在运行时进行调整无须重新启动 API Server。 四、简述 Kubernetes Secret 作用 Secret 对象主要作用是保管私密数据比如密码、OAuth Tokens、SSH Keys 等信息。将这些私密信息放在 Secret 对象中比直接放在 Pod 或 Docker Image 中更安全也更便于使用和分发。 五、简述 Kubernetes Secret 有哪些使用方式 创建完 secret 之后可通过如下三种方式使用 在创建 Pod 时通过为 Pod 指定 Service Account 来自动使用该 Secret。通过挂载该 Secret 到 Pod 来使用它。在 Docker 镜像下载时使用通过指定 Pod 的 spc.ImagePullSecrets 来引用它。 六、简述 Kubernetes PodSecurityPolicy 机制 Kubernetes PodSecurityPolicy 是为了更精细地控制 Pod 对资源的使用方式以及提升安全策略。在开启 PodSecurityPolicy 准入控制器后Kubernetes 默认不允许创建任何 Pod需要创建 PodSecurityPolicy 策略和相应的 RBAC 授权策略Authorizing PoliciesPod才能创建成功。 七、简述 Kubernetes PodSecurityPolicy 机制能实现哪些安全策略 在 PodSecurityPolicy 对象中可以设置不同字段来控制 Pod 运行时的各种安全策略常见的有 特权模式privileged 是否允许 Pod 以特权模式运行。宿主机资源控制 Pod 对宿主机资源的控制如 hostPID是否允许 Pod 共享宿主机的进程空间。用户和组设置运行容器的用户 ID范围或组范围。提升权限AllowPrivilegeEscalation设置容器内的子进程是否可以提升权限通常在设置非 root 用户MustRunAsNonRoot时进行设置。SELinux进行 SELinux 的相关配置。 八、简述 Kubernetes 网络模型 Kubernetes 网络模型中每个 Pod 都拥有一个独立的 IP 地址并假定所有 Pod 都在一个可以直接连通的、扁平的网络空间中。所以不管它们是否运行在同一个 Node宿主机中都要求它们可以直接通过对方的 IP 进行访问。设计这个原则的原因是用户不需要额外考虑如何建立 Pod 之间的连接也不需要考虑如何将容器端口映射到主机端口等问题。同时为每个 Pod 都设置一个 IP 地址的模型使得同一个 Pod 内的不同容器会共享同一个网络命名空间也就是同一个 Linux 网络协议栈。这就意味着同一个 Pod 内的容器可以通过 localhost 来连接对方的端口。在 Kubernetes 的集群里IP 是以 Pod 为单位进行分配的。一个 Pod 内部的所有容器共享一个网络堆栈相当于一个网络命名空间它们的 IP 地址、网络设备、配置等都是共享的。 九、简述 Kubernetes CNI 模型 CNI 提供了一种应用容器的插件化网络解决方案定义对容器网络进行操作和配置的规范通过插件的形式对 CNI 接口进行实现。CNI 仅关注在创建容器时分配网络资源和在销毁容器时删除网络资源。在 CNI 模型中只涉及两个概念容器和网络。 容器Container是拥有独立 Linux 网络命名空间的环境例如使用 Docker或 rkt 创建的容器。容器需要拥有自己的 Linux 网络命名空间这是加入网络的必要条件。网络Network表示可以互连的一组实体这些实体拥有各自独立、唯一的IP 地址可以是容器、物理机或者其他网络设备比如路由器等。 对容器网络的设置和操作都通过插件Plugin进行具体实现CNI 插件包括两种类型CNI Plugin 和 IPAMIP Address ManagementPlugin。 CNI Plugin 负责为容器配置网络资源IPAM Plugin 负责对容器的 IP 地址进行分配和管理。IPAM Plugin 作为 CNI Plugin 的一部分与 CNI Plugin 协同工作。 十、简述 Kubernetes 网络策略 为实现细粒度的容器间网络访问隔离策略Kubernetes 引入 Network Policy。Network Policy 的主要功能是对 Pod 间的网络通信进行限制和准入控制设置允许访问或禁止访问的客户端 Pod 列表。Network Policy 定义网络策略配合策略控制器PolicyController进行策略的实现。 十一、简述 Kubernetes 网络策略原理 Network Policy 的工作原理主要为policy controller 需要实现一个 API Listener监听用户设置的 Network Policy 定义并将网络访问规则通过各 Node 的 Agent 进行实际设置Agent 则需要通过 CNI 网络插件实现。 十二、简述 Kubernetes 中 flannel 的作用 Flannel 可以用于 Kubernetes 底层网络的实现主要作用有 它能协助 Kubernetes给每一个 Node 上的 Docker 容器都分配互相不冲突的 IP地址。它能在这些 IP 地址之间建立一个覆盖网络Overlay Network通过这个覆盖网络将数据包原封不动地传递到目标容器内。 十三、简述 Kubernetes Calico 网络组件实现原理 Calico 是一个基于 BGP 的纯三层的网络方案与 OpenStack、Kubernetes、AWS、GCE等云平台都能够良好地集成。Calico 在每个计算节点都利用 Linux Kernel 实现了一个高效的 vRouter 来负责数据转发。每个 vRouter 都通过 BGP 协议把在本节点上运行的容器的路由信息向整个 Calico 网络广播并自动设置到达其他节点的路由转发规则。Calico 保证所有容器之间的数据流量都是通过 IP 路由的方式完成互联互通的。Calico 节点组网时可以直接利用数据中心的网络结构L2 或者 L3不需要额外的 NAT、隧道或者 Overlay Network没有额外的封包解包能够节约 CPU 运算提高网络效率。 十四、简述 Kubernetes 共享存储的作用 Kubernetes 对于有状态的容器应用或者对数据需要持久化的应用因此需要更加可靠的存储来保存应用产生的重要数据以便容器应用在重建之后仍然可以使用之前的数据。因此需要使用共享存储。 十五、简述 Kubernetes 数据持久化的方式有哪些 EmptyDir空目录没有指定要挂载宿主机上的某个目录直接由 Pod 内保部映射到宿主机上。类似于 docker 中的 manager volume。 场景 只需要临时将数据保存在磁盘上比如在合并/排序算法中作为两个容器的共享存储。 特性 同个 pod 里面的不同容器共享同一个持久化目录当 pod 节点删除时volume 的数据也会被删除。emptyDir 的数据持久化的生命周期和使用的 pod 一致一般是作为临时存储使用。 Hostpath将宿主机上已存在的目录或文件挂载到容器内部。类似于 docker 中的 bind mount 挂载方式。 特性增加了 pod 与节点之间的耦合。 PersistentVolume简称 PV如基于 NFS 服务的 PV也可以基于 GFS 的 PV。它的作用是统一数据持久化目录方便管理。 十六、简述 Kubernetes PV 和 PVC PV 是对底层网络共享存储的抽象将共享存储定义为一种“资源”。PVC 则是用户对存储资源的一个“申请”。 十七、简述 Kubernetes PV 生命周期内的阶段 某个 PV 在生命周期中可能处于以下 4 个阶段Phaes之一。 Available可用状态还未与某个 PVC 绑定。Bound已与某个 PVC 绑定。Released绑定的 PVC 已经删除资源已释放但没有被集群回收。Failed自动资源回收失败。 十八、简述 Kubernetes 所支持的存储供应模式 Kubernetes 支持两种资源的存储供应模式静态模式Static和动态模式Dynamic。 静态模式集群管理员手工创建许多 PV在定义 PV 时需要将后端存储的特性进行设置。动态模式集群管理员无须手工创建 PV而是通过 StorageClass 的设置对后端存储进行描述标记为某种类型。此时要求 PVC 对存储的类型进行声明系统将自动完成 PV 的创建及与 PVC 的绑定。 十九、简述 Kubernetes CSI 模型 Kubernetes CSI 是 Kubernetes 推出与容器对接的存储接口标准存储提供方只需要基于标准接口进行存储插件的实现就能使用 Kubernetes 的原生存储机制为容器提供存储服务。CSI 使得存储提供方的代码能和 Kubernetes 代码彻底解耦部署也与 Kubernetes核心组件分离显然存储插件的开发由提供方自行维护就能为 Kubernetes 用户提供更多的存储功能也更加安全可靠。CSI 包括 CSI Controller 和 CSI Node CSI Controller 的主要功能是提供存储服务视角对存储资源和存储卷进行管理和操作。CSI Node 的主要功能是对主机Node上的 Volume 进行管理和操作。 二十、简述 Kubernetes Worker 节点加入集群的过程 通常需要对 Worker 节点进行扩容从而将应用系统进行水平扩展。主要过程如下 在该 Node 上安装 Docker、kubelet 和 kube-proxy 服务然后配置 kubelet 和 kubeproxy 的启动参数将 Master URL 指定为当前Kubernetes 集群 Master 的地址最后启动这些服务通过 kubelet 默认的自动注册机制新的 Worker 将会自动加入现有的Kubernetes 集群中Kubernetes Master 在接受了新 Worker 的注册之后会自动将其纳入当前集群的调度范围。 二十一、简述 Kubernetes Pod 如何实现对节点的资源控制 Kubernetes 集群里的节点提供的资源主要是计算资源计算资源是可计量的能被申请、分配和使用的基础资源。当前 Kubernetes 集群中的计算资源主要包括 CPU、GPU及 Memory。CPU 与 Memory 是被 Pod 使用的因此在配置 Pod 时可以通过参数 CPU Request 及 Memory Request 为其中的每个容器指定所需使用的 CPU 与 Memory 量Kubernetes 会根据 Request 的值去查找有足够资源的 Node 来调度此 Pod。通常一个程序所使用的 CPU 与 Memory 是一个动态的量确切地说是一个范围跟它的负载密切相关负载增加时CPU 和 Memory 的使用量也会增加。 二十二、简述 Kubernetes Requests 和 Limits 如何影响 Pod 的调度 当一个 Pod 创建成功时Kubernetes 调度器Scheduler会为该 Pod 选择一个节点来执行。对于每种计算资源CPU 和 Memory而言每个节点都有一个能用于运行 Pod的最大容量值。调度器在调度时首先要确保调度后该节点上所有 Pod 的 CPU 和内存的 Requests 总和不超过该节点能提供给 Pod 使用的 CPU 和 Memory 的最大容量值。 二十三、简述 Kubernetes Metric Service 在 Kubernetes 从 1.10 版本后采用 Metrics Server 作为默认的性能数据采集和监控主要用于提供核心指标Core Metrics包括 Node、Pod 的 CPU 和内存使用指标。对其他自定义指标Custom Metrics的监控则由 Prometheus 等组件来完成。 二十四、简述 Kubernetes 中如何使用 EFK 实现日志的统一管理 在 Kubernetes 集群环境中通常一个完整的应用或服务涉及组件过多建议对日志系统进行集中化管理通常采用 EFK 实现。EFK 是 Elasticsearch、Fluentd 和 Kibana 的组合其各组件功能如下 Elasticsearch是一个搜索引擎负责存储日志并提供查询接口Fluentd负责从 Kubernetes 搜集日志每个 node 节点上面的 fluentd 监控并收集该节点上面的系统日志并将处理过后的日志信息发送给 ElasticsearchKibana提供了一个 Web GUI用户可以浏览和搜索存储在 Elasticsearch 中的日志。 通过在每台 node 上部署一个以 DaemonSet 方式运行的 fluentd 来收集每台 node 上的日志。Fluentd 将 docker 日志目录/var/lib/docker/containers 和/var/log 目录挂载到 Pod 中然后 Pod 会在 node 节点的/var/log/pods 目录中创建新的目录可以区别不同的容器日志输出该目录下有一个日志文件链接到/var/lib/docker/contianers 目录下的容器日志输出。 二十五、简述 Kubernetes 如何进行优雅的节点关机维护 由于 Kubernetes 节点运行大量 Pod因此在进行关机维护之前建议先使用 kubectldrain 将该节点的 Pod 进行驱逐然后进行关机维护。 二十六、简述 Kubernetes 集群联邦 Kubernetes 集群联邦可以将多个 Kubernetes 集群作为一个集群进行管理。因此可以在一个数据中心/云中创建多个 Kubernetes 集群并使用集群联邦在一个地方控制/管理所有集群。 二十七、简述 Helm 及其优势 Helm 是 Kubernetes 的软件包管理工具。类似 Ubuntu 中使用的 apt、Centos 中使用的yum 或者 Python 中的 pip 一样。Helm 能够将一组 K8S 资源打包统一管理, 是查找、共享和使用为 Kubernetes 构建的软件的最佳方式。Helm 中通常每个包称为一个 Chart一个 Chart 是一个目录一般情况下会将目录进行打包压缩形成 name-version.tgz 格式的单一文件方便传输和存储。在 Kubernetes 中部署一个可以使用的应用需要涉及到很多的 Kubernetes 资源的共同协作。使用 helm 则具有如下优势 统一管理、配置和更新这些分散的 k8s 的应用资源文件分发和复用一套应用模板将应用的一系列资源当做一个软件包管理。 对于应用发布者而言可以通过 Helm 打包应用、管理应用依赖关系、管理应用版本并发布应用到软件仓库。 对于使用者而言使用 Helm 后不用需要编写复杂的应用部署文件可以以简单的方式在 Kubernetes 上查找、安装、升级、回滚、卸载应用程序。 二十八、什么是 Headless Service Headless Service 类似于“普通”服务但没有群集 IP。此服务使您可以直接访问 pod而无需通过代理访问它。 二十九、简述K8s 常用的 CNI 网络插件calico flannel的工作原理和区别 calico 的工作原理 calico 根据 iptables 规则进行路由转发并没有进行封包解包的过程这和 flannel比起来效率就会快多。calico 包括如下重要组件FelixetcdBGP ClientBGP Route Reflector。下面分别说明一下这些组件。 Felix主要负责路由配置以及 ACLS 规则的配置以及下发它存在在每个 node 节点上。etcd分布式键值存储主要负责网络元数据一致性确保 Calico 网络状态的准确性可以与 kubernetes 共用BGPClient(BIRD), 主要负责把 Felix 写入 kernel 的路由信息分发到当前 Calico 网络确保 workload 间的通信的有效性BGPRoute Reflector(BIRD), 大规模部署时使用摒弃所有节点互联的 mesh 模式通过一个或者多个 BGPRoute Reflector 来完成集中式的路由分发。通过将整个互联网的可扩展 IP 网络原则压缩到数据中心级别Calico 在每一个计算节点利用 Linuxkernel 实现了一个高效的 vRouter 来负责数据转发而每个 vRouter 通过BGP 协议负责把自己上运行的 workload 的路由信息向整个 Calico 网络内传播小规模部署可以直接互联大规模下可通过指定的 BGProute reflector 来完成。这样保证最终所有的 workload 之间的数据流量都是通过 IP 包的方式完成互联的。 Flannel 的工作原理 Flannel 实质上是一种“覆盖网络(overlay network)”也就是将 TCP 数据包装在另一种网络包里面进行路由转发和通信目前已经支持 UDP、VxLAN、AWS VPC 和 GCE 路由等数据转发方式。默认的节点间数据通信方式是 UDP 转发。数据从源容器中发出后经由所在主机的 docker0 虚拟网卡转发到 flannel0 虚拟网卡先可以不经过 docker0 网卡使用 cni 模式这是个 P2P 的虚拟网卡flanneld 服务监听在网卡的另外一端。Flannel 通过 Etcd 服务维护了一张节点间的路由表详细记录了各节点子网网段 。源主机的 flanneld 服务将原本的数据内容 UDP 封装后根据自己的路由表投递给目的节点的 flanneld 服务数据到达以后被解包然后直接进入目的节点的 flannel0 虚拟网卡然后被转发到目的主机的 docker0 虚拟网卡最后就像本机容器通信一下的有 docker0路由到达目标容器。flannel 在进行路由转发的基础上进行了封包解包的操作这样浪费了 CPU 的计算资源。 三十、Worker 节点宕机简述 Pods 驱逐流程 在 Kubernetes 集群中当节点由于某些原因网络、宕机等不能正常工作时会被认定为不可用状态Unknown 或者 False 状态当时间超过了 pod-eviction-timeout 值时那么节点上的所有 Pod 都会被节点控制器计划删除。Kubernetes 集群中有一个节点生命周期控制器node_lifecycle_controller.go。它会与每一个节点上的 kubelet 进行通信以收集各个节点以及节点上容器的相关状态信息。当超出一定时间后不能与 kubelet 通信那么就会标记该节点为 Unknown 状态。并且节点生命周期控制器会自动创建代表状况的污点用于防止调度器调度 pod 到该节点。那么 Unknown 状态的节点上已经运行的 pod 会怎么处理呢节点上的所有 Pod都会被污点管理器taint_manager.go计划删除。而在节点被认定为不可用状态到删除节点上的 Pod 之间是有一段时间的这段时间被称为容忍度。如果在不配置的情况下Kubernetes 会自动给 Pod 添加一个 key 为node.kubernetes.io/not-ready 的容忍度 并配置 tolerationSeconds300同样Kubernetes会给 Pod 添加一个 key 为 node.kubernetes.io/unreachable 的容忍度 并配置tolerationSeconds300。当到了删除 Pod 时污点管理器会创建污点标记事件然后驱逐 pod 。这里需要注意的是由于已经不能与 kubelet 通信所以该节点上的 Pod 在管理后台看到的是处于灰色标记但是此时如果去获取 pod 的状态其实还是处于 Running 状态。每种类型的资源都有相应的资源控制器Controller例如deployment_controller.go、stateful_set_control.go。每种控制器都在监听资源变化从而做出相应的动作执行。 deployment 控制器在监听到 Pod 被驱逐后会创建一个新的 Pod 出来但是 Statefulset控制器并不会创建出新的 Pod原因是因为它可能会违反 StatefulSet 固有的至多一个的语义可能出现具有相同身份的多个成员这将可能是灾难性的并且可能导致数据丢失。 三十一、简述 kube-proxy 的三种工作模式和原理 userspace 模式 该模式下 kube-proxy 会为每一个 Service 创建一个监听端口。发向 Cluster IP 的请求被Iptables 规则重定向到 Kube-proxy 监听的端口上Kube-proxy 根据 LB 算法选择一个提供服务的 Pod 并和其建立链接以将请求转发到 Pod 上。该模式下Kube-proxy 充当了一个四层 Load balancer 的角色。由于 kube-proxy 运行在userspace 中在进行转发处理时会增加两次内核和用户空间之间的数据拷贝效率较另外两种模式低一些好处是当后端的 Pod 不可用时kube-proxy 可以重试其他 Pod。 iptables 模式 为了避免增加内核和用户空间的数据拷贝操作提高转发效率Kube-proxy 提供了iptables 模式。在该模式下Kube-proxy 为 service 后端的每个 Pod 创建对应的 iptables规则直接将发向 Cluster IP 的请求重定向到一个 Pod IP。 该模式下 Kube-proxy 不承担四层代理的角色只负责创建 iptables 规则。该模式的优点是较 userspace 模式效率更高但不能提供灵活的 LB 策略当后端 Pod 不可用时也无法进行重试。 该模式和 iptables 类似kube-proxy 监控 Pod 的变化并创建相应的 ipvs rules。ipvs 也是在 kernel 模式下通过 netfilter 实现的但采用了 hash table 来存储规则因此在规则较多的情况下Ipvs 相对 iptables 转发效率更高。除此以外ipvs 支持更多的 LB 算法。如果要设置 kube-proxy 为 ipvs 模式必须在操作系统中安装 IPVS 内核模块。 三十二、Docker 的网络通信模式 host 模式使用 --nethost 指定。 和宿主机共用一个 Network Namespace。容器将不会虚拟出自己的网卡配置自己的 IP等而是使用宿主机的 IP 和端口。 container 模式使用 --netcontainer:NAMEorID 指定。 指定新创建的容器和已经存在的一个容器共享一个 Network Namespace而不是和宿主机共享。 none 模式使用 --netnone 指定。 告诉 docker 将新容器放到自己的网络堆栈中但是不要配置它的网络。 bridge 模式使用 --netbridge 指定默认设置。 bridge 模式是 Docker 默认的网络设置此模式会为每一个容器分配 Network Namespace、设置 IP 等并将一个主机上的 Docker 容器连接到一个虚拟网桥上。