Kubernetes一直是当今业界的流行语,也是最好的编排工具。它吸引了许多想要提升自己职业生涯的经验丰富的专业人士。HuaWei,Pokemon,Box,eBay,Ing,Yahoo Japan,SAP,纽约时报,Open AI,Sound Cloud等跨国公司也使用Kubernetes。我相信你已经知道这些事实,这也是促使你打开这个Kubernetes面试问题文章原因。
在这篇关于Kubernetes面试问题的文章中,我将讨论在面试中提出的与Kubernetes相关的最重要问题。因此,为了您的理解,我将此博客分为以下4个部分:
所以让我们开始吧!!
这部分问题将包含您需要了解的与Kubernetes工作相关的所有基本问题。
Kubernetes是一个开源容器管理工具,负责容器部署,容器扩缩容以及负载平衡。作为Google的创意之作,它提供了出色的社区,并与所有云提供商合作。因此,我们可以说Kubernetes不是一个容器化平台,而是一个多容器管理解决方案。
众所周知,Docker提供容器的生命周期管理,Docker镜像构建运行时容器。但是,由于这些单独的容器必须通信,因此使用Kubernetes。因此,我们说Docker构建容器,这些容器通过Kubernetes相互通信。因此,可以使用Kubernetes手动关联和编排在多个主机上运行的容器。
请参考上图。左侧架构表示在主机上部署应用程序。因此,这种架构将具有操作系统,然后操作系统将具有内核,该内核将在应用程序所需的操作系统上安装各种库。因此,在这种框架中,您可以拥有n个应用程序,并且所有应用程序将共享该操作系统中存在的库,而在容器中部署应用程序时,体系结构则略有不同。
这种架构将有一个内核,这是唯一一个在所有应用程序之间唯一共同的东西。因此,如果有一个需要Java的特定应用程序,那么我们将获得访问Java的特定应用程序,如果有另一个需要Python的应用程序,则只有该特定应用程序才能访问Python。
您可以在图表右侧看到的各个块基本上是容器化的,并且这些块与其他应用程序隔离。因此,应用程序具有与系统其余部分隔离的必要库和二进制文件,并且不能被任何其他应用程序侵占。
考虑一个应用程序有5-6个微服务的场景。现在,这些微服务被放在单独的容器中,但如果没有容器编排就无法进行通信。因此,由于编排意味着所有乐器在音乐中和谐共处,所以类似的容器编排意味着各个容器中的所有服务协同工作以满足单个服务器的需求。
考虑到你有5-6个微服务用于执行各种任务的单个应用程序,所有这些微服务都放在容器中。现在,为了确保这些容器彼此通信,我们需要容器编排。
正如您在上图中所看到的,在没有使用容器编排的情况下,还存在许多挑战。因此,为了克服这些挑战,容器编排就到位了。
Kubernetes的功能如下:
由于典型应用程序将具有跨多个主机运行的容器集群,因此所有这些容器都需要相互通信。因此,要做到这一点,你需要一些能够负载平衡,扩展和监控容器的东西。由于Kubernetes与云无关并且可以在任何公共/私有提供商上运行,因此必须是您简化容器化部署的选择。
Kubernetes背后的基础是我们可以实施所需的状态管理,我的意思是我们可以提供特定配置的集群服务,并且集群服务将在基础架构中运行并运行该配置。
因此,正如您在上图中所看到的,部署文件将具有提供给集群服务所需的所有配置。现在,部署文件将被提供给API,然后由集群服务决定如何在环境中安排这些pod,并确保正确运行的pod数量。
因此,位于服务前面的API,工作节点和节点运行的Kubelet进程,共同构成了Kubernetes集群。
Google Container Engine(GKE)是Docker容器和集群的开源管理平台。这个基于Kubernetes的引擎仅支持在Google的公共云服务中运行的群集。
Heapster是由每个节点上运行的Kubelet提供的集群范围的数据聚合器。此容器管理工具在Kubernetes集群上本机支持,并作为pod运行,就像集群中的任何其他pod一样。因此,它基本上发现集群中的所有节点,并通过机上Kubernetes代理查询集群中Kubernetes节点的使用信息。
Minikube是一种工具,可以在本地轻松运行Kubernetes。这将在虚拟机中运行单节点Kubernetes群集。
Kubectl是一个平台,您可以使用该平台将命令传递给集群。因此,它基本上为CLI提供了针对Kubernetes集群运行命令的方法,以及创建和管理Kubernetes组件的各种方法。
这是一个代理服务,它在每个节点上运行,并使从服务器与主服务器通信。因此,Kubelet处理PodSpec中提供给它的容器的描述,并确保PodSpec中描述的容器运行正常。
这部分问题将涉及与Kubernetes架构相关的问题。
Kubernetes Architecture主要有两个组件 - 主节点和工作节点。如下图所示,master和worker节点中包含许多内置组件。主节点具有kube-controller-manager,kube-apiserver,kube-scheduler等。而工作节点具有在每个节点上运行的kubelet和kube-proxy。
Kube-proxy可以在每个节点上运行,并且可以跨后端网络服务进行简单的TCP / UDP数据包转发。基本上,它是一个网络代理,它反映了每个节点上Kubernetes API中配置的服务。因此,Docker可链接的兼容环境变量提供由代理打开的群集IP和端口。
Kubernetes master控制容器存在的节点和节点内部。现在,这些单独的容器包含在容器内部和每个容器内部,您可以根据配置和要求拥有不同数量的容器。因此,如果必须部署pod,则可以使用用户界面或命令行界面部署它们。然后,在节点上调度这些pod,并根据资源需求,将pod分配给这些节点。kube-apiserver确保在Kubernetes节点和主组件之间建立通信。
kube -apiserver遵循横向扩展架构,是主节点控制面板的前端。这将公开Kubernetes主节点组件的所有API,并负责在Kubernetes节点和Kubernetes主组件之间建立通信。
kube-scheduler负责工作节点上工作负载的分配和管理。因此,它根据资源需求选择最合适的节点来运行未调度的pod,并跟踪资源利用率。它确保不在已满的节点上调度工作负载。
多个控制器进程在主节点上运行,但是一起编译为单个进程运行,即Kubernetes控制器管理器。因此,Controller Manager是一个嵌入控制器并执行命名空间创建和垃圾收集的守护程序。它拥有责任并与API服务器通信以管理端点。
因此,主节点上运行的不同类型的控制器管理器是:
Etcd是用Go编程语言编写的,是一个分布式键值存储,用于协调分布式工作。因此,Etcd存储Kubernetes集群的配置数据,表示在任何给定时间点的集群状态。
以下是使用的不同类型的服务:
负载均衡器是暴露服务的最常见和标准方式之一。根据工作环境使用两种类型的负载均衡器,即内部负载均衡器或外部负载均衡器。内部负载均衡器自动平衡负载并使用所需配置分配容器,而外部负载均衡器将流量从外部负载引导至后端容器。
Ingress网络是一组规则,充当Kubernetes集群的入口点。这允许入站连接,可以将其配置为通过可访问的URL,负载平衡流量或通过提供基于名称的虚拟主机从外部提供服务。因此,Ingress是一个API对象,通常通过HTTP管理集群中服务的外部访问,是暴露服务的最有效方式。
现在,让我以一个例子向您解释Ingress网络的工作。
有2个节点具有带有Linux桥接器的pod和根网络命名空间。除此之外,还有一个名为flannel0(网络插件)的新虚拟以太网设备被添加到根网络中。
现在,假设我们希望数据包从pod1流向pod 4.请参阅下图。
Cloud Controller Manager负责持久存储,网络路由,从核心Kubernetes特定代码中抽象出特定于云的代码,以及管理与底层云服务的通信。它可能会分成几个不同的容器,具体取决于您运行的是哪个云平台,然后它可以使云供应商和Kubernetes代码在没有任何相互依赖的情况下开发。因此,云供应商开发他们的代码并在运行Kubernetes时与Kubernetes云控制器管理器连接。
各种类型的云控制器管理器如下:
对于用户而言,了解应用程序的性能和所有不同抽象层的资源利用率非常重要,Kubernetes通过在容器,pod,服务和整个集群等不同级别创建抽象来考虑集群的管理。现在,可以监视每个级别,这只是容器资源监视。
各种容器资源监控工具如下:
Replica Set 和 Replication Controller几乎完全相同。它们都确保在任何给定时间运行指定数量的pod副本。不同之处在于复制pod使用的选择器。Replica Set使用基于集合的选择器,而Replication Controller使用基于权限的选择器。
Headless Service类似于“普通”服务,但没有群集IP。此服务使您可以直接访问pod,而无需通过代理访问它。
以下是使用Kubernetes时可以遵循的最佳安全措施:
在联邦集群的帮助下,可以将多个Kubernetes集群作为单个集群进行管理。因此,您可以在数据中心/云中创建多个Kubernetes集群,并使用联邦来在一个位置控制/管理它们。
联合集群可以通过执行以下两项操作来实现此目的。请参考下图。
这部分问题将包含您在面试中可能遇到的各种基于场景的问题。
假设一家基于单一架构的公司处理众多产品。现在,随着公司在当今的扩展行业的扩展,他们的单一架构开始引发问题。
您如何看待公司从单一服务转向微服务并部署其服务容器?
解:
由于公司的目标是从单一应用程序转向微服务,它们最终可以逐个构建,并行构建,只需在后台切换配置。然后他们可以将这些内置微服务放在Kubernetes平台上。因此,他们可以从一次或两次迁移服务开始,并监控它们以确保一切运行稳定。一旦他们觉得一切顺利,他们就可以将其余的应用程序迁移到他们的Kubernetes集群中。
考虑一家拥有分布式系统的跨国公司,拥有大量数据中心,虚拟机和许多从事各种任务的员工。
您认为这样 的公司如何以与Kubernetes一致的方式管理所有任务?
解:
正如我们所有人都知道IT部门推出了数千个容器,其任务在分布式系统中遍布全球众多节点。
在这种情况下,公司可以使用能够为基于云的应用程序提供敏捷性,横向扩展功能和DevOps实践的东西。
因此,该公司可以使用Kubernetes来定制他们的调度架构并支持多种容器格式。这使得容器任务之间的亲和性成为可能,从而提供更高的效率,并为各种容器网络解决方案和容器存储提供广泛支持。
考虑一种情况,即公司希望通过维持最低成本来提高其效率和技术运营速度。
您认为公司将如何实现这一目标?
解:
公司可以通过构建CI/CD管道来实现DevOps方法,但是这里可能出现的一个问题是配置可能需要一段时间才能启动并运行。因此,在实施CI/CD管道之后,公司的下一步应该是在云环境中工作。一旦他们开始处理云环境,他们就可以在集群上安排容器,并可以在Kubernetes的帮助下进行协调。这种方法将有助于公司缩短部署时间,并在各种环境中加快速度。
假设一家公司想要修改它的部署方法,并希望建立一个更具可扩展性和响应性的平台。
您如何看待这家公司能够实现这一目标以满足客户需求?
解:
为了给数百万客户提供他们期望的数字体验,公司需要一个可扩展且响应迅速的平台,以便他们能够快速地将数据发送到客户网站。现在,要做到这一点,公司应该从他们的私有数据中心(如果他们使用任何)转移到任何云环境,如AWS。不仅如此,他们还应该实现微服务架构,以便他们可以开始使用Docker容器。一旦他们准备好基础框架,他们就可以开始使用最好的编排平台,即Kubernetes。这将使团队能够自主地构建应用程序并快速交付它们。
考虑一家拥有非常分散的系统的跨国公司,期待解决整体代码库问题。
您认为公司如何解决他们的问题?
解
那么,为了解决这个问题,我们可以将他们的单片代码库转移到微服务设计,然后每个微服务都可以被视为一个容器。因此,所有这些容器都可以在Kubernetes的帮助下进行部署和协调。
我们所有人都知道,从单片到微服务的转变解决了开发方面的问题,但却增加了部署方面的问题。
公司如何解决部署方面的问题?
解
团队可以试验容器编排平台,例如Kubernetes,并在数据中心运行。因此,通过这种方式,公司可以生成模板化应用程序,在五分钟内部署它,并在此时将实际实例集中在暂存环境中。这种Kubernetes项目将有数十个并行运行的微服务,以提高生产率,即使节点出现故障,也可以立即重新安排,而不会影响性能。
假设一家公司希望通过采用新技术来优化其工作负载的分配。
公司如何有效地实现这种资源分配?
解
这个问题的解决方案就是Kubernetes。Kubernetes确保资源得到有效优化,并且只使用特定应用程序所需的那些资源。因此,通过使用最佳容器编排工具,公司可以有效地实现资源分配。
考虑一家拼车公司希望通过同时扩展其平台来增加服务器数量。
您认为公司如何处理服务器及其安装?
解
公司可以采用集装箱化的概念。一旦他们将所有应用程序部署到容器中,他们就可以使用Kubernetes进行编排,并使用像Prometheus这样的容器监视工具来监视容器中的操作。因此,利用容器的这种使用,在数据中心中为它们提供更好的容量规划,因为它们现在将受到更少的限制,因为服务和它们运行的硬件之间存在抽象。
考虑一种情况,公司希望向具有各种环境的客户提供所有必需的分发。
您认为他们如何以动态的方式实现这一关键目标?
解
该公司可以使用Docker环境,组建一个横截面团队,使用Kubernetes构建Web应用程序。这种框架将帮助公司实现在最短的时间内将所需产品投入生产的目标。因此,在这样的机器运行的情况下,公司可以向所有具有各种环境的客户发放电子邮件。
假设公司希望在不同的云基础架构上运行各种工作负载,从裸机到公共云。
公司将如何在不同界面的存在下实现这一目标?
解
该公司可以将其基础设施分解为微服务,然后采用Kubernetes。这将使公司在不同的云基础架构上运行各种工作负载。
这部分问题将包括多项面试问题,这些问题在面试中经常被问到。
好了,今天到此为止,希望能够给您带来一些帮助。