K8s面试题——基础篇1

发布时间:2024年01月15日

文章目录

一、简述etcd及其特点

  • etcd是CentOS团队发起的开源项目,是一个管理配置信息和服务发现(service discovery)的项目,它的目标是构建一个高可用的分布式键值(key-value)数据库,基于Go语言实现。

特点:

  • 简单:支持REST风格的HTTP+JSON API
  • 安全: 支持HTTPS方式的访问
  • 快速: 支持并发1 k/s 的写操作
  • 可靠: 支持分布式结构,基于Raft的一致性算法,Raft是一套通过选举主节点来实现分布式系统一致性的算法。

二、简述 etcd 适应的场景

  1. 服务发现(Service Discovery):服务发现主要解决在同一个分布式集群中的进程或服务,要如何才能找到对方并建立连接。本质上来说,服务发现就是想要了解集群中是否有进程在监听 udp 或 tcp 端口,并且通过名字就可以查找和连接。
  2. 消息发布与订阅:在分布式系统中,最适用的一种组件间通信方式就是消息发布与订阅。即构建一个配置共享中心,数据提供者在这个配置中心发布消息,而消息使用者则订阅他们关心的主题,一旦主题有消息发布,就会实时通知订阅者。通过这种方式可以做到分布式系统配置的集中式管理与动态更新。应用中用到的一些配置信息放到 etcd 上进行集中管理。
  3. 负载均衡:在分布式系统中,为了保证服务的高可用以及数据的一致性,通常都会把数据和服务部署多份,以此达到对等服务,即使其中的某一个服务失效了,也不影响使用。etcd 本身分布式架构存储的信息访问支持负载均衡。etcd 集群化以后,每个 etcd 的核心节点都可以处理用户的请求。所以,把数据量小但是访问频繁的消息数据直接存储到 etcd 中也可以实现负载均衡的效果。
  4. 分布式通知与协调:与消息发布和订阅类似,都用到了 etcd 中的 Watcher 机制,通过注册与异步通知机制,实现分布式环境下不同系统之间的通知与协调,从而对数据变更做到实时处理。
  5. 分布式锁:因为 etcd 使用 Raft 算法保持了数据的强一致性,某次操作存储到集群中的值必然是全局一致的,所以很容易实现分布式锁。锁服务有两种使用方式,一是保持独占,二是控制时序。
  6. 集群监控与 Leader 竞选:通过 etcd 来进行监控实现起来非常简单并且实时性强。

三、简述什么是 Kubernetes

  • Kubernetes 是一个全新的基于容器技术的分布式系统支撑平台。是 Google 开源的容器集群管理系统(谷歌内部:Borg)。
  • 在 Docker 技术的基础上,为容器化的应用提供部署运行、资源调度、服务发现和动态伸缩等一系列完整功能,提高了大规模容器集群管理的便捷性。并且具有完备的集群管理能力,多层次的安全防护和准入机制、多租户应用支撑能力、透明的服务注册和发现机制、內建智能负载均衡器、强大的故障发现和自我修复能力、服务滚动升级和在线扩容能力、可扩展的资源自动调度机制以及多粒度的资源配额管理能力。

四、简述 Kubernetes 和 Docker 的关系

  • Docker 提供容器的生命周期管理,和Docker 镜像构建运行时容器。它的主要优点是将软件、应用程序运行所需的设置和依赖项打包到一个容器中,从而实现了可移植性等优点。
  • Kubernetes 用于关联和编排在多个主机上运行的容器。

五、简述 Kubernetes 中什么是 Minikube、Kubectl、Kubelet

  • Minikube 是一种可以在本地轻松运行一个单节点 Kubernetes 群集的工具。
  • Kubectl 是一个命令行工具,可以使用该工具控制 Kubernetes 集群管理器,如检查群集资源,创建、删除和更新组件,查看应用程序。
  • Kubelet 是一个代理服务,它在每个节点上运行,并使从服务器与主服务器通信。

六、简述 Kubernetes 常见的部署方式

  • kubeadm:也是推荐的一种部署方式;
  • 二进制部署;
  • minikube:在本地轻松运行一个单节点 Kubernetes 群集的工具。

七、简述 Kubernetes 如何实现集群管理

  • 在集群管理方面,Kubernetes 将集群中的机器划分为一个 Master 节点和一群工作节点 Node。
  • 其中,在 Master 节点运行着集群管理相关的一组进程 kube-apiserver、kube-controller-manager 和 kube-scheduler,这些进程实现了整个集群的资源管理、Pod调度、弹性伸缩、安全控制、系统监控和纠错等管理能力,并且都是全自动完成的。

八、简述 Kubernetes 的优势、适应场景及其特点

  • Kubernetes 作为一个完备的分布式系统支撑平台,其主要优势:

    1. 容器编排
    2. 轻量级
    3. 开源
    4. 弹性伸缩
    5. 负载均衡
  • Kubernetes 常见场景:

    1. 快速部署应用
    2. 快速扩展应用
    3. 无缝对接新的应用功能
    4. 节省资源,优化硬件资源的使用
  • Kubernetes 相关特点:

    1. 可移植:支持公有云、私有云、混合云、多重云(multi-cloud)。
    2. 可扩展:模块化,、插件化、可挂载、可组合。
    3. 自动化:自动部署、自动重启、自动复制、自动伸缩/扩展。

九、简述 Kubernetes 的缺点或当前的不足之处

  • 安装过程和配置相对困难复杂。
  • 管理服务相对繁琐。
  • 运行和编译需要很多时间。
  • 它比其他替代品更昂贵。
  • 对于简单的应用程序来说,可能不需要涉及 Kubernetes 即可满足。

十、简述 Kubernetes 相关基础概念

  • master:k8s集群的管理节点,负责管理集群,提供集群的资源数据访问入口。拥有 Etcd 存储服务(可选),运行 Api Server 进程,Controller Manager 服务进程及 Scheduler 服务进程。
  • node(worker):Node(worker)是 Kubernetes 集群架构中运行 Pod 的服务节点,是 Kubernetes 集群操作的单元,用来承载被分配 Pod 的运行,是 Pod 运行的宿主机。运行 docker eninge 服务,守护进程 kunelet 及负载均衡器 kube-proxy。
  • pod:运行于 Node 节点上,若干相关容器的组合。Pod 内包含的容器运行在同一宿主机上,使用相同的网络命名空间、IP 地址和端口,能够通过 localhost 进行通信。Pod 是 Kurbernetes 进行创建、调度和管理的最小单位,它提供了比容器更高层次的抽象,使得部署和管理更加灵活。一个 Pod 可以包含一个容器或者多个相关容器。
  • label:Kubernetes 中的 Label 实质是一系列的 Key/Value 键值对,其中 key 与 value可自定义。Label 可以附加到各种资源对象上,如 Node、Pod、Service、RC 等。一个资源对象可以定义任意数量的 Label,同一个 Label 也可以被添加到任意数量的资源对象上去。Kubernetes 通过 Label Selector(标签选择器)查询和筛选资源对象。
  • Replica Set(副本集): Pod 只是单个应用实例的抽象,要构建高可用应用,通常需要构建多个同样的副本,提供同一个服务。Kubernetes 为此抽象出副本集 Replica Set,其允许用户定义 Pod 的副本数,每一个 Pod 都会被当作一个无状态的成员进行管理,Kubernetes 保证总是有用户期望的数量的 Pod 正常运行。当某个副本宕机以后,控制器将会创建一个新的副本。当因业务负载发生变更而需要调整扩缩容时,可以方便地调整副本数量。
  • Deployment:Deployment 在内部使用了 RS 来实现目的,Deployment 相当于 RC的一次升级,其最大的特色为可以随时获知当前 Pod 的部署进度。
  • HPA(Horizontal Pod Autoscaler):Pod 的横向自动扩容,也是 Kubernetes 的一种资源,通过追踪分析 RC 控制的所有 Pod 目标的负载变化情况,来确定是否需要针对性的调整 Pod 副本数量。
  • Service:Service 定义了 Pod 的逻辑集合和访问该集合的策略,是真实服务的抽象。Service 提供了一个统一的服务访问入口以及服务代理和发现机制,关联多个相同 Label 的 Pod,用户不需要了解后台 Pod 是如何运行。
  • Volume:Volume 是 Pod 中能够被多个容器访问的共享目录,Kubernetes 中的Volume 是定义在 Pod 上,可以被一个或多个 Pod 中的容器挂载到某个目录下。
  • Namespace:Namespace 用于实现多租户的资源隔离,可将集群内部的资源对象分配到不同的 Namespace 中,形成逻辑上的不同项目、小组或用户组,便于不同的 Namespace 在共享使用整个集群的资源的同时还能被分别管理。

十一、简述 Kubernetes 集群相关组件

  • Kubernetes API Server:作为Kubernetes 系统的入口,其封装了核心对象的增删改查操作,以 RESTful API 接口方式提供给外部客户和内部组件调用,集群内各个功能模块之间数据交互和通信的中心枢纽。
  • Kubernetes Scheduler:为新建立的 Pod 进行节点(node)选择(即分配机器),负责集群的资源调度。
  • Kubernetes Controller:负责执行各种控制器,目前已经提供了很多控制器来保证 Kubernetes 的正常运行。
  • Replication Controller:管理维护 Replication Controller,关联 Replication Controller 和 Pod,保证Replication Controller 定义的副本数量与实际运行 Pod数量一致。
  • Node Controller:管理维护 Node,定期检查 Node 的健康状态,标识出(失效|未失效)的 Node 节点。
  • Namespace Controller:管理维护 Namespace,定期清理无效的 Namespace,包括 Namesapce 下的 API 对象,比如 Pod、Service 等。
  • Service Controller:管理维护 Service,提供负载以及服务代理。
  • EndPoints Controller:管理维护 Endpoints,关联 Service 和 Pod,创建 Endpoints为 Service 的后端,当 Pod 发生变化时,实时更新 Endpoints。
  • Service Account Controller:管理维护 Service Account,为每个 Namespace 创建默认的 Service Account,同时为 Service Account 创建 Service Account Secret。
  • Persistent Volume Controller:管理维护 Persistent Volume 和 Persistent Volume Claim,为新的 Persistent Volume Claim 分配 Persistent Volume 进行绑定,为释放的 Persistent Volume 执行清理回收。
  • Daemon Set Controller:管理维护 Daemon Set,负责创建 Daemon Pod,保证指定的 Node 上正常的运行 Daemon Pod。
  • Deployment Controller:管理维护 Deployment,关联 Deployment 和 Replication Controller,保证运行指定数量的Pod。当Deployment更新时,控制实现Replication Controller 和 Pod 的更新。
  • Job Controller:管理维护 Job,为 Jod 创建一次性任务 Pod,保证完成 Job 指定完成的任务数目。
  • Pod Autoscaler Controller:实现 Pod 的自动伸缩,定时获取监控数据,进行策略匹配,当满足条件时执行 Pod 的伸缩动作。

十二、简述 Kubernetes RC 的机制

  • Replication Controller 用来管理 Pod 的副本,保证集群中存在指定数量的 Pod 副本。
  • 当定义了 RC 并提交至 Kubernetes 集群中之后,Master 节点上的 Controller Manager 组件获悉,并同时巡检系统中当前存活的目标 Pod,并确保目标 Pod 实例的数量刚好等于此 RC 的期望值,若存在过多的 Pod 副本在运行,系统会停止一些 Pod,反之则自动创建一些 Pod。

十三、简述 Kubernetes Replica Set 和 Replication Controller 之间有什么区别

  • Replica Set 和 Replication Controller 类似,都是确保在任何给定时间运行指定数量的 Pod 副本。
  • 不同之处在于 RS 使用基于集合的选择器,而 Replication Controller 使用基于权限的选择器。

十四、简述 kube-proxy 作用

  • kube-proxy 运行在所有节点上,它监听 apiserver 中 service 和 endpoint 的变化情况,创建路由规则以提供服务 IP 和负载均衡功能。
  • 简单理解此进程是 Service 的透明代理兼负载均衡器,其核心功能是将到某个 Service 的访问请求转发到后端的多个 Pod实例上。

十五、简述 kube-proxy iptables 原理

  • Kubernetes 从 1.2 版本开始,将 iptables 作为 kube-proxy 的默认模式。iptables 模式下的 kube-proxy 不再起到 Proxy 的作用,其核心功能:通过 API Server 的 Watch 接口实时跟踪 Service 与 Endpoint 的变更信息,并更新对应的 iptables 规则,Client 的请求流量则通过 iptables 的 NAT 机制“直接路由”到目标 Pod。

十六、简述 kube-proxy ipvs 原理

  • IPVS 在 Kubernetes1.11 中升级为 GA 稳定版。IPVS 则专门用于高性能负载均衡,并使用更高效的数据结构(Hash 表),允许几乎无限的规模扩张,因此被 kube-proxy采纳为最新模式。
  • 在 IPVS 模式下,使用 iptables 的扩展 ipset,而不是直接调用 iptables 来生成规则链。iptables 规则链是一个线性的数据结构,ipset 则引入了带索引的数据结构,因此当规则很多时,也可以很高效地查找和匹配。
  • 可以将 ipset 简单理解为一个 IP(段)的集合,这个集合的内容可以是 IP 地址、IP 网段、端口等,iptables 可以直接添加规则对这个“可变的集合”进行操作,这样做的好处在于可以大大减少 iptables 规则的数量,从而减少性能损耗。

十七、简述 kube-proxy ipvs 和 iptables 的异同

  • iptables 与 IPVS 都是基于 Netfilter 实现的,但因为定位不同,二者有着本质的差别。iptables 是为防火墙而设计的;IPVS 则专门用于高性能负载均衡,并使用更高效的数据结构(Hash 表),允许几乎无限的规模扩张。
  • 与 iptables 相比,IPVS 拥有以下明显优势:
    1. 为大型集群提供了更好的可扩展性和性能;
    2. 支持比 iptables 更复杂的负载均衡算法(最小负载、最少连接、加权等);
    3. 支持服务器健康检查和连接重试等功能;
    4. 可以动态修改 ipset 的集合,即使 iptables 的规则正在使用这个集合。

十八、简述 Kubernetes 中什么是静态 Pod

  • 静态 pod 是由 kubelet 进行管理的仅存在于特定 Node 的 Pod 上,它们不能通过 API Server 进行管理,无法与 ReplicationController、Deployment 或者 DaemonSet 进行关联,并且 kubelet 无法对他们进行健康检查。
  • 静态 Pod 总是由 kubelet 进行创建,并且总是在kubelet 所在的 Node 上运行。

十九、简述 Kubernetes 中 Pod 可能位于的状态

  • Pending:API Server 已经创建该 Pod,且 Pod 内还有一个或多个容器的镜像没有创建,包括正在下载镜像的过程。
  • Running:Pod 内所有容器均已创建,且至少有一个容器处于运行状态、正在启动状态或正在重启状态。
  • Succeeded:Pod 内所有容器均成功执行退出,且不会重启。
  • Failed:Pod 内所有容器均已退出,但至少有一个容器退出为失败状态。
  • Unknown:由于某种原因无法获取该 Pod 状态,可能由于网络通信不畅导致。

二十、简述 Kubernetes 创建一个 Pod 的主要流程

  1. 客户端提交 Pod 的配置信息(可以是 yaml 文件定义的信息)到 kube-apiserver。
  2. Apiserver 收到指令后,通知给 controller-manager 创建一个资源对象。
  3. Controller-manager 通过 api-server 将 pod 的配置信息存储到 ETCD 数据中心中。
  4. Kube-scheduler 检测到 pod 信息会开始调度预选,会先过滤掉不符合 Pod 资源配置要求的节点,然后开始调度调优,主要是挑选出更适合运行 pod 的节点,然后将 pod 的资源配置单发送到 node 节点上的 kubelet 组件上。
  5. Kubelet 根据 scheduler 发来的资源配置单运行 pod,运行成功后,将 pod 的运行信息返回给 scheduler,scheduler 将返回的 pod 运行状况的信息存储到 etcd数据中心。

二十一、简述 Kubernetes 中 Pod 的重启策略

  • Pod 重启策略(RestartPolicy)应用于 Pod 内的所有容器,并且仅在 Pod 所处的 Node上由 kubelet 进行判断和重启操作。当某个容器异常退出或者健康检查失败时,kubelet将根据 RestartPolicy 的设置来进行相应操作。

  • Pod 的重启策略包括:Always、OnFailure 和 Never,默认值为 Always。

    1. Always:当容器失效时,由 kubelet 自动重启该容器;
    2. OnFailure:当容器终止运行且退出码不为 0 时,由 kubelet 自动重启该容器;
    3. Never:不论容器运行状态如何,kubelet 都不会重启该容器。
  • 同时 Pod 的重启策略与控制方式关联,当前可用于管理 Pod 的控制器包括Replication Controller、Job、DaemonSet 及直接管理 kubelet 管理(静态 Pod)。

  • 不同控制器的重启策略限制如下:

    1. RC 和 DaemonSet:必须设置为 Always,需要保证该容器持续运行;
    2. Job:OnFailure 或 Never,确保容器执行完成后不再重启;
    3. kubelet:在 Pod 失效时重启,不论将 RestartPolicy 设置为何值,也不会对 Pod进行健康检查。

二十二、简述 Kubernetes 中 Pod 的健康检查方式

  • 对 Pod 的健康检查可以通过两类探针来检查:LivenessProbe 和 ReadinessProbe。
    1. LivenessProbe 探针:用于判断容器是否存活(running 状态),如果 LivenessProbe探针探测到容器不健康,则 kubelet 将杀掉该容器,并根据容器的重启策略做相应处理。若一个容器不包含 LivenessProbe 探针,kubelet 认为该容器的LivenessProbe 探针返回值用于是“Success”。
    2. ReadineeProbe 探针:用于判断容器是否启动完成(ready 状态)。如果ReadinessProbe 探针探测到失败,则 Pod 的状态将被修改。Endpoint Controller将从 Service 的 Endpoint 中删除包含该容器所在 Pod 的 Eenpoint。
    3. startupProbe 探针:启动检查机制,应用一些启动缓慢的业务,避免业务长时间启动而被上面两类探针 kill 掉。

二十三、简述Kubernetes Pod的LivenessProbe探针的常见方式

  • kubelet 定期执行 LivenessProbe 探针来诊断容器的健康状态,通常有以下三种方式:
    1. ExecAction:在容器内执行一个命令,若返回码为 0,则表明容器健康。
    2. TCPSocketAction:通过容器的 IP 地址和端口号执行 TCP 检查,若能建立 TCP连接,则表明容器健康。
    3. HTTPGetAction:通过容器的 IP 地址、端口号及路径调用 HTTP Get 方法,若响应的状态码大于等于 200 且小于 400,则表明容器健康。

二十四、简述 Kubernetes Pod 的常见调度方式

  1. Deployment 或 RC:该调度策略主要功能就是自动部署一个容器应用的多份副本,以及持续监控副本的数量,在集群内始终维持用户指定的副本数量。
  2. NodeSelector:定向调度,当需要手动指定将 Pod 调度到特定 Node 上,可以通过 Node 的标签(Label)和 Pod 的 nodeSelector 属性相匹配。
  3. NodeAffinity 亲和性调度:亲和性调度机制极大的扩展了 Pod 的调度能力,目前有两种节点亲和力表达:
    • requiredDuringSchedulingIgnoredDuringExecution:硬规则,必须满足指定的规则,调度器才可以调度 Pod 至 Node 上(类似 nodeSelector,语法不同)。
    • preferredDuringSchedulingIgnoredDuringExecution:软规则,优先调度至满足的Node 的节点,但不强求,多个优先级规则还可以设置权重值。
  4. Taints 和 Tolerations(污点和容忍):
    • Taint:使 Node 拒绝特定 Pod 运行;
    • Toleration:为 Pod 的属性,表示 Pod 能容忍(运行)标注了 Taint 的 Node。

二十五、简述 Kubernetes 初始化容器(init container)

  • init container 的运行方式与应用容器不同,它们必须先于应用容器执行完成,当设置了多个 init container 时,将按顺序逐个运行,并且只有前一个 init container 运行成功后才能运行后一个 init container。
  • 当所有 init container 都成功运行后,Kubernetes 才会初始化 Pod 的各种信息,并开始创建和运行应用容器。

二十六、简述 Kubernetes deployment 升级过程

  • 初始创建 Deployment 时,系统创建了一个 ReplicaSet,并按用户的需求创建了对应数量的 Pod 副本。
  • 当更新 Deployment 时,系统创建了一个新的 ReplicaSet,并将其副本数量扩展到 1,然后将旧 ReplicaSet 缩减为 2。
  • 之后,系统继续按照相同的更新策略对新旧两个 ReplicaSet 进行逐个调整。
  • 最后,新的 ReplicaSet 运行了对应个新版本 Pod 副本,旧的 ReplicaSet 副本数量则缩减为 0。

二十七、简述 Kubernetes deployment 升级策略

  • 在 Deployment 的定义中,可以通过 spec.strategy 指定 Pod 更新的策略,目前支持两种策略:Recreate(重建)和 RollingUpdate(滚动更新),默认值为 RollingUpdate。
    1. Recreate:设置 spec.strategy.type=Recreate,表示 Deployment 在更新 Pod 时,会先杀掉所有正在运行的 Pod,然后创建新的 Pod。
    2. RollingUpdate:设置 spec.strategy.type=RollingUpdate,表示 Deployment 会以滚动更新的方式来逐个更新 Pod。同时,可以通过设置 spec.strategy.rollingUpdate下的两个参数(maxUnavailable 和 maxSurge)来控制滚动更新的过程。

二十八、简述 Kubernetes DaemonSet 类型的资源特性

  • DaemonSet 资源对象会在每个 Kubernetes 集群中的节点上运行,并且每个节点只能运行一个 pod,这是它和 deployment 资源对象的最大也是唯一的区别。因此,在定义 yaml文件中,不支持定义 replicas。
  • 它的一般使用场景如下:
    1. 在去做每个节点的日志收集工作。
    2. 监控每个节点的的运行状态。

二十九、简述 Kubernetes 自动扩容机制

  • Kubernetes 使用 Horizontal Pod Autoscaler(HPA)的控制器实现基于 CPU 使用率进行自动 Pod 扩缩容的功能。HPA 控制器周期性地监测目标 Pod 的资源性能指标,并与 HPA 资源对象中的扩缩容条件进行对比,在满足条件时对 Pod 副本数量进行调整。
  • HPA 原理:Kubernetes 中的某个 Metrics Server(Heapster 或自定义 Metrics Server)持续采集所有Pod 副本的指标数据。HPA 控制器通过 Metrics Server 的 API(Heapster 的 API 或聚合API)获取这些数据,基于用户定义的扩缩容规则进行计算,得到目标 Pod 副本数量。
  • 当目标 Pod 副本数量与当前副本数量不同时,HPA 控制器就向 Pod 的副本控制器(Deployment、RC 或ReplicaSet)发起 scale 操作,调整 Pod 的副本数量,完成扩缩容操作。

三十、简述 Kubernetes Service 类型

  • 通过创建 Service,可以为一组具有相同功能的容器应用提供一个统一的入口地址,并且将请求负载分发到后端的各个容器应用上。其主要类型有:
    1. ClusterIP:虚拟的服务 IP 地址,该地址用于 Kubernetes 集群内部的 Pod 访问,在 Node 上 kube-proxy 通过设置的 iptables 规则进行转发;
    2. NodePort:使用宿主机的端口,使能够访问各 Node 的外部客户端通过 Node 的IP 地址和端口号就能访问服务;
    3. LoadBalancer:使用外接负载均衡器完成到服务的负载分发,需要在spec.status.loadBalancer 字段指定外部负载均衡器的 IP 地址,通常用于公有云。

三十一、简述 Kubernetes Service 分发后端的策略

  • RoundRobin:默认为轮询模式,即轮询将请求转发到后端的各个 Pod 上。
  • SessionAffinity:基于客户端 IP 地址进行会话保持的模式,即第 1 次将某个客户端发起的请求转发到后端的某个 Pod 上,之后从相同的客户端发起的请求都将被转发到后端相同的 Pod 上。

三十二、简述 Kubernetes Headless Service

  • 在某些应用场景中,若需要人为指定负载均衡器,不使用 Service 提供的默认负载均衡的功能,或者应用程序希望知道属于同组服务的其他实例。Kubernetes 提供了Headless Service 来实现这种功能,即不为 Service 设置 ClusterIP(入口 IP 地址),仅通过 Label Selector 将后端的 Pod 列表返回给调用的客户端。

三十三、简述 Kubernetes 外部如何访问集群内的服务

  • 对于 Kubernetes,集群外的客户端默认情况,无法通过 Pod 的 IP 地址或者 Service的虚拟 IP 地址:虚拟端口号进行访问。通常可以通过以下方式进行访问 Kubernetes 集群内的服务:
    1. 映射 Pod 到物理机:将 Pod 端口号映射到宿主机,即在 Pod 中采用 hostPort 方式,以使客户端应用能够通过物理机访问容器应用。
    2. 映射 Service 到物理机:将 Service 端口号映射到宿主机,即在 Service 中采用nodePort 方式,以使客户端应用能够通过物理机访问容器应用。
    3. 映射 Sercie 到 LoadBalancer:通过设置 LoadBalancer 映射到云服务商提供的LoadBalancer 地址。这种用法仅用于在公有云服务提供商的云平台上设置 Service的场景。

三十四、简述 Kubernetes ingress

  • Kubernetes 的 Ingress 资源对象,用于将不同 URL 的访问请求转发到后端不同的Service,以实现 HTTP 层的业务路由机制。
  • Kubernetes 使用了 Ingress 策略和 Ingress Controller,两者结合并实现了一个完整的Ingress 负载均衡器。使用 Ingress 进行负载分发时,Ingress Controller 基于 Ingress 规则将客户端请求直接转发到 Service 对应的后端 Endpoint(Pod)上,从而跳过 kube-proxy的转发功能,kube-proxy 不再起作用,全过程为:ingress controller + ingress 规则 ---->services。
  • 同时当 Ingress Controller 提供的是对外服务,则实际上实现的是边缘路由器的功能。

三十五、简述 Kubernetes 镜像的下载策略

  • Always:镜像标签为 latest 时,总是从指定的仓库中获取镜像。
  • Never:禁止从仓库中下载镜像,也就是说只能使用本地镜像。
  • IfNotPresent:仅当本地没有对应镜像时,才从目标仓库中下载。默认的镜像下载策略是:当镜像标签是 latest 时,默认策略是 Always;当镜像标签是自定义时(也就是标签不是 latest),那么默认策略是 IfNotPresent。

三十六、简述 Kubernetes 的负载均衡器

  • 负载均衡器是暴露服务的最常见和标准方式之一。
  • 根据工作环境使用两种类型的负载均衡器,即内部负载均衡器或外部负载均衡器。内部负载均衡器自动平衡负载并使用所需配置分配容器,而外部负载均衡器将流量从外部负载引导至后端容器。

三十七、简述 Kubernetes 各模块如何与 API Server 通信

  • Kubernetes API Server 作为集群的核心,负责集群各功能模块之间的通信。集群内的各个功能模块通过 API Server 将信息存入 etcd,当需要获取和操作这些数据时,则通过 API Server 提供的 REST 接口(用 GET、LIST 或 WATCH 方法)来实现,从而实现各模块之间的信息交互。
    1. kubelet 进程与 API Server 的交互:每个 Node 上的 kubelet 每隔一个时间周期,就会调用一次 API Server 的 REST 接口报告自身状态,API Server 在接收到这些信息后,会将节点状态信息更新到 etcd 中。
    2. kube-controller-manager 进程与 API Server 的交互:kube-controller-manager 中的 Node Controller 模块通过 API Server 提供的 Watch 接口实时监控 Node 的信息,并做相应处理。
    3. kube-scheduler 进程与 API Server 的交互:Scheduler 通过 API Server 的 Watch 接口监听到新建 Pod 副本的信息后,会检索所有符合该 Pod 要求的 Node 列表,开始执行 Pod调度逻辑,在调度成功后将 Pod 绑定到目标节点上。

三十八、简述 Kubernetes Scheduler 作用及实现原理

  • Kubernetes Scheduler 是负责 Pod 调度的重要功能模块,Kubernetes Scheduler 在整个系统中承担了“承上启下”的重要功能,“承上”是指它负责接收 Controller Manager 创建的新 Pod,为其调度至目标 Node;“启下”是指调度完成后,目标 Node 上的 kubelet 服务进程接管后继工作,负责 Pod 接下来生命周期。
  • Kubernetes Scheduler 的作用是将待调度的 Pod(API 新创建的 Pod、Controller Manager为补足副本而创建的 Pod 等)按照特定的调度算法和调度策略绑定(Binding)到集群中某个合适的 Node 上,并将绑定信息写入 etcd 中。在整个调度过程中涉及三个对象,分别是待调度 Pod 列表、可用 Node 列表,以及调度算法和策略。
  • Kubernetes Scheduler 通过调度算法调度为待调度 Pod 列表中的每个 Pod 从 Node 列表中选择一个最适合的 Node 来实现 Pod 的调度。随后,目标节点上的 kubelet 通过 API Server监听到Kubernetes Scheduler产生的 Pod 绑定事件,然后获取对应的Pod 清单,下载Image镜像并启动容器。

三十九、简述 Kubernetes Scheduler使用哪两种算法将 Pod绑定到 worker 节点

  1. 预选(Predicates):输入是所有节点,输出是满足预选条件的节点。kube-scheduler根据预选策略过滤掉不满足策略的 Nodes。如果某节点的资源不足或者不满足预选策略的条件则无法通过预选。如“Node 的 label 必须与 Pod 的 Selector 一致”。
  2. 优选(Priorities):输入是预选阶段筛选出的节点,优选会根据优先策略为通过预选的 Nodes 进行打分排名,选择得分最高的 Node。例如,资源越富裕、负载越小的 Node 可能具有越高的排名。

四十、简述 Kubernetes kubelet 的作用

  • 在 Kubernetes 集群中,在每个 Node(又称 Worker)上都会启动一个 kubelet 服务进程。该进程用于处理 Master 下发到本节点的任务,管理 Pod 及 Pod 中的容器。
  • 每个kubelet 进程都会在 API Server 上注册节点自身的信息,定期向 Master 汇报节点资源的使用情况,并通过 cAdvisor 监控容器和节点资源。

四十一、简述 Kubernetes kubelet 监控 Worker 节点资源是使用什么组件来实现的

  • kubelet 使用 cAdvisor 对 worker 节点资源进行监控。在 Kubernetes 系统中,cAdvisor已被默认集成到 kubelet 组件内,当 kubelet 服务启动时,它会自动启动 cAdvisor 服务,然后 cAdvisor 会实时采集所在节点的性能指标及在节点上运行的容器的性能指标。
文章来源:https://blog.csdn.net/yi_qingjun/article/details/135589277
本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。