当前位置：
  1. 首页
  2. 未分类
  3. 正文

运维工程师面试题分享

未分类 0 269

DevOps代表开发和运营。 这是一种新的软件开发形式，彻底改变了软件产品的开发和分发方式。DevOps方法论着眼于提供频繁的较小升级，而不是罕见的大型功能集。

IT运营受益于DevOps。 在DevOps出现之前，IT团队仍然存在一些内在的担忧。 这导致IT团队面临某种程度的意外怀疑。

但是，随着DevOps的加入，这一切都发生了变化，这使IT运营部门可以与组织的其他部门共享这些问题，从而提高了透明度，并提高了IT运营部门与其他团队之间的协调性。

问题1： 您能告诉我们DevOps和Agile之间的根本区别吗？

答 ：尽管DevOps与敏捷方法（这是最流行的SDLC方法之一）有一些相似之处，但两者都是软件开发的根本不同的方法。 以下是两者之间的各种基本差异：

敏捷方法–敏捷方法仅适用于敏捷开发，而敏捷方法则适用于DevOps中的开发和运营。

实践和流程–敏捷涉及敏捷Scrum和敏捷看板等实践，而DevOps涉及CD（持续交付），CI（持续集成）和CT（持续测试）等流程。

优先级–敏捷优先考虑及时性，而DevOps优先考虑及时性和质量。

发布周期– DevOps提供较小的发布周期并提供即时反馈，而Agile仅提供较小的发布周期而没有立即反馈。

反馈源–敏捷依赖于客户的反馈，而DevOps涉及到自身（监控工具）的反馈。

工作范围–对于敏捷，工作范围仅是敏捷，而对于DevOps，这是敏捷和对自动化的需求。

问题2： 为什么我们需要DevOps？

答 ：如今，组织正在尝试通过一系列发布方式将小功能传递给客户，而不是发布大功能集。 这样做有很多好处，包括更好的软件质量和快速的客户反馈。

所有这些好处导致更高的客户满意度，这是任何产品开发项目的最重要目标。 为此，公司需要：

增加部署频率

缩短修复时间

新版本的故障率更低

万一新版本崩溃，请有更快的平均恢复时间

DevOps有助于满足所有这些要求，从而实现无缝的软件交付。 像Amazon，Etsy和Google这样的成熟组织已采用DevOps方法，从而实现了以前未知的性能水平。

通过采用DevOps方法，组织可以在一天之内完成数以万计的部署。 此外，这样做还可以提供一流的可靠性，安全性和稳定性。

问题3： 使用DevOps有哪些重要的业务和技术优势？

答 ：DevOps为该表带来了很多业务和技术优势。 下面列出了一些最重要的参数：

商业利益

增强的操作环境稳定性

更快地交付功能

更多时间为产品增值

技术优势

持续交付软件

更快地解决问题

较小的复杂问题

问题4： 您能否列举一些最常用的DevOps工具？

答 ：以下是一些使用最广泛的DevOps工具的列表：

Ansible –配置管理和应用程序部署工具

Chef –配置管理和应用程序部署工具

Docker –容器化工具

Git –版本控制系统（VCS）工具

Jenkins –持续集成（CI）工具

Jira –敏捷的团队协作工具

Nagios –连续监控工具

Puppet –配置管理和应用程序部署工具

硒–连续测试（CT）工具

问题5：硒的作用是什么？

答 ：硒用于DevOps中的连续测试。 该工具专门从事功能和回归形式的测试。

问题7：您对DevOps的反模式有什么了解？

回答 ：当其他组织通常采用的DevOps模式在特定上下文中不起作用而组织仍在继续使用它时，它将导致采用反模式。 换句话说，反模式是关于DevOps的神话。 一些著名的反模式是：

一个组织需要有一个单独的DevOps组

敏捷等于DevOps

DevOps是一个过程

DevOps是开发驱动的发布管理

由于组织独特，因此无法进行DevOps

无法进行DevOps，因为现有人员不适合

DevOps意味着开发人员管理生产

DevOps将解决所有问题

无法在正在进行的DevOps过渡中包含组织的所有方面

在DevOps过渡开始时未定义KPI

通过一个新的DevOps团队来减少与其他组织之间的隔离

问题8：DevOps有一个称为CI的东西。 它是什么，目的是什么？

答 ：DevOps中的CI代表持续集成。CI是一种开发实践，开发人员可以在一天内多次将代码集成到共享存储库中。

开发和测试的持续集成提高了软件的质量，并减少了交付所需的总时间。

如果检查代码的团队成员遇到编译失败，则开发人员将破坏构建。 这样，其他开发人员如果不将编译错误引入自己的工作空间中，就无法与共享源代码存储库进行同步。

这破坏了协作和共享的开发过程。 因此，一旦配置项构建中断，立即识别并纠正问题就很重要。

通常，配置项流程包括每次编译成功时都会运行的一组单元测试，集成测试和回归测试。 如果上述任何测试失败，则CI构建被认为是不稳定的（这在开发正在进行中的敏捷冲刺中很常见）并且没有损坏。

问题9： 我们经常听到DevOps中的左移。 它是什么？

答 ：当在纸上画图时，传统的软件开发生命周期有左右两边。 图的左侧包括设计和开发，而右侧包括生产阶段，压力测试和用户接受度。

在DevOps中向左移动仅意味着需要在右侧执行尽可能多的任务，即通常在应用程序开发过程的结尾发生，并将其纳入DevOps方法的早期阶段。

有几种方法可以完成DevOps中的操作，最值得注意的是：

在每个敏捷冲刺结束时创建准备就绪的工件

在每个版本中都包含静态代码分析例程

正确执行DevOps的级别直接取决于尽可能左移的程度。

问题10：DevOps中的CAMS代表什么？

答 ：首字母缩写词CAMS通常用于描述DevOps方法论的核心信条。 它代表：

文化

断言

测量

共享

问题11： 用于评估DevOps成功的几个KPI是什么？

答 ：关键绩效指标是关键绩效指标的一种合同形式。 为了衡量DevOps流程的成功，可以使用几个KPI。 一些最受欢迎的是：

应用性能

应用程序的使用和流量

自动测试通过率

可用性

改变音量

客户票

缺陷逃逸率

部署频率

部署时间

错误率

部署失败

交货时间

检测时间（MTTD）

平均恢复时间（MTTR）

问题12： 您认为实施DevOps自动化的主要好处是什么？

答 ：以下是实现DevOps自动化的主要好处：

从CD方程式中消除人为错误的可能性（核心收益）

随着任务变得更加可预测和可重复，当出现问题时，很容易识别和纠正。 因此，它可以产生更可靠，更强大的系统

消除CI管道的瓶颈。 这会导致部署频率增加和失败的部署数量减少。 它们都是重要的DevOps KPI

问题13： 您对容器了解什么？

答 ：容器是一种轻量级虚拟化形式，有助于在进程之间提供隔离。 容器比chroot重，但比管理程序轻。

问题14：微服务是DevOps的核心部分。 您可以命名两个流行的Java开发框架来创建微服务吗？

答 ：有几种Java框架允许创建微服务。 但是，Eclipse MicroProfile和Spring Boot作为DevOps中用于创建微服务的两个主要Java开发框架而脱颖而出。

问题15： 您对版本控制系统（VCS）了解什么？ 定义其用途。

答 ：版本控制系统或VCS是一种能够记录一段时间内对一个文件或一组文件所做的更改的系统。Git和Mercurial是两个最受欢迎的版本控制系统。VCS的重要用途是：

检查什么引起了问题的最后修改

比较随着时间的变化

确定谁介绍了新问题以及什么时候提出的

将一个或多个文件还原到某个较早的状态

将整个项目还原到以前的状态

问题16：Git是流行的DevOps工具。 告诉我们您将如何还原已经推送并公开的提交。

答 ：有两种方法可以这样做：

通过创建新的提交来撤消已被推送并公开的提交所做的所有更改。 执行以下命令：
git还原

通过修复或删除新提交中的错误文件，然后将其推送到远程存储库。 对文件进行必要的更改后，使用以下命令将其提交到远程存储库：
git commit -m“提交消息”

问题17： 什么是post mortem会议？

答 ：很多时候需要讨论在DevOps流程中出了什么问题。 为此，安排了验后会议。 这些会议产生了应该采取的步骤，以避免将来安排会议时遇到的相同或一组失败。

问题18： 在资产管理和配置管理之间进行比较。

答 ：监视和维护实体或组的有价值的东西的过程称为资产管理。

配置管理是指控制，识别，计划和验证服务中的配置项以支持变更管理的过程。

问题19：您能否陈述和解释连续测试的各个关键要素？

答 ：连续测试的各种关键要素包括：

高级分析–用于预测和预测未知的未来事件

策略分析–旨在改善测试过程的手段

需求可追溯性–指描述需求以及从需求的起源到部署的整个过程的能力

风险评估–识别可能造成潜在损害的危害和风险因素的方法或过程

服务虚拟化–允许使用虚拟服务代替生产服务。 仿真软件组件以进行简单测试

测试优化–改善整体测试流程

问题20： 请从开发和基础结构方面说明DevOps的核心操作。

答 ：在开发和基础架构方面，DevOps的核心运营是：

应用程序开发–开发能够满足所有客户要求并提供卓越质量水平的产品

代码覆盖率–衡量在运行自动测试时执行的代码的块，线或弧的总数

代码开发–准备产品开发所需的代码库

配置–以最佳方式使用产品

部署–安装要由最终用户使用的软件

编排–安排一些自动化任务

打包–准备发布时涉及的活动

调配–确保基础结构更改随需要的代码及时到达

单元测试–测试单个单元或组件的方法

这样就构成了20个重要的DevOps面试问题的清单。 除了增加获得DevOps职位的机会之外，这些绝对可以帮助您评估并提高您对DevOps的当前了解水平。

1、简述Ceph的优势及其特点？

Ceph是一个分布式的数据对象存储，Ceph相对其他存储系统具有如下优势：

CRUSH算法：ceph摒弃了传统的集中式存储元数据寻址的方案，而使用CRUSH算法完成数据的寻址操作。能够实现各类负载的副本放置规则，例如跨机房、机架感知等。Crush算法有相当强大的扩展性，理论上支持数千个存储节点，从而增强了Ceph弹性扩展和高可用性。

高可用：通过CRUSH算法指定副本的物理存储位置以分隔故障域，支持数据强一致性，ceph可以忍受多种故障场景并自动尝试并行修复。

高扩展性：Ceph本身并没有主控节点，扩展起来比较容易，并且理论上，它的性能会随着磁盘数量的增加而线性增长。

特性丰富：Ceph支持三种调用接口：对象存储，块存储，文件系统挂载。三种方式可以一同使用。

Ceph主要特点如下：

统一存储；

无任何单点故障；

数据多份冗余；

存储容量可扩展；

自动容错及故障自愈。

2、简述Ceph存储体系架构？

Ceph体系架构主要由RADOS和RADOS GW和RBD以及CephFS构成。

RADOS（Reliable, Autonomic Distributed Object Store）是Ceph的底层核心，RADOS本身也是分布式存储系统，CEPH所有的存储功能都是基于RADOS实现。RADOS由两个组件组成：OSD和Monitor。

OSD主要提供存储资源，每一个disk、SSD、RAID group或者一个分区都可以成为一个OSD，而每个OSD还将负责向该对象的复杂节点分发和恢复；

Monitor维护Ceph集群并监控Ceph集群的全局状态，提供一致性的决策。

RADOS GW和RBD：RADOS GateWay、RBD其作用是在librados库的基础上提供抽象层次更高、更便于应用或客户端使用的上层接口。其中，RADOS GW是一个提供与Amazon S3和Swift兼容的RESTful API的gateway，以供相应的对象存储应用开发使用。RBD则提供了一个标准的块设备接口，常用于在虚拟化的场景下为虚拟机创建volume。

CEPHFS：CEPHFS则提供了POSIX接口，用户可直接通过客户端挂载使用。

3、简述Ceph Pool有几种类型？

Ceph存储池Pool是Ceph存储集群用于存储对象的逻辑分区。

Pool中存在一定的数量的PG，PG将对象存储在一组由CRUSH算法确定的osd中。

Ceph使用CRUSH算法将对象分配给池中的一个PG，根据池的配置和CRUSH算法，PG自动映射到一组OSDs。

一个PG里包含一堆对象，一个对象只能属于一个PG。

4、简述Ceph节点的角色？

所有Ceph存储集群的部署都始于部署一个个Ceph节点、网络和Ceph存储集群。Ceph存储集群至少需要一个Ceph Monitor和两个OSD守护进程。而运行Ceph文件系统客户端时，则必须要有元数据服务器（Metadata Server）。

Ceph OSDs：Ceph OSD守护进程（ Ceph OSD ）的功能是存储数据，处理数据的复制、恢复、回填、再均衡，并通过检查其他OSD守护进程的心跳来向Ceph Monitors提供一些监控信息。当Ceph存储集群设定为有2个副本时，至少需要2个OSD守护进程，集群才能达到active+clean状态（Ceph默认有3个副本）。

Monitors：Ceph Monitor维护着展示集群状态的各种图表，包括监视器图、OSD图、归置组（PG）图、和CRUSH 图。

MDSs：Ceph元数据服务器（MDS）为Ceph文件系统存储元数据（也就是说，Ceph块设备和Ceph 对象存储不使用MDS）。元数据服务器使得POSIX文件系统的客户端，可以在不对Ceph存储集群造成负担的前提下，执行诸如ls、find等基本命令。

5、简述Ceph的适应场景？

Ceph的应用场景主要由它的架构确定，Ceph提供对象存储、块存储和文件存储。

LIBRADOS应用

Librados提供了应用程序对RADOS的直接访问，目前Librados已经提供了对C、C++、Java、Python、Ruby和PHP的支持。

RADOSGW应用

此类场景基于Librados之上，增加了HTTP协议，提供RESTful接口并且兼容S3、Swfit接口。RADOSGW将Ceph集群作为分布式对象存储，对外提供服务。

RBD应用

此类场景也是基于Librados之上的，细分为下面两种应用场景。

第一种应用场景为虚拟机提供块设备。通过Librbd可以创建一个块设备（Container），然后通过QEMU/KVM附加到VM上。通过Container和VM的解耦，使得块设备可以被绑定到不同的VM上。

第二种应用场景为主机提供块设备。这种场景是传统意义上的理解的块存储。

以上两种方式都是将一个虚拟的块设备分片存储在RADOS中，都会利用数据条带化提高数据并行传输，都支持块设备的快照、COW（Copy-On-Write）克隆。最重要的是RBD还支持Live migration。

CephFS（Ceph文件系统）

此类应用是基于RADOS实现的PB级分布式文件系统，其中引入MDS（Meta Date Server），它主要为兼容POSIX文件系统提供元数据，比如文件目录和文件元数据。

Docker

1、简述Docker的特性？

Docker主要有如下特性：

标准化

保证一致的运行环境

弹性伸缩，快速扩容

方便迁移

持续集成、持续交付与持续部署

高性能

不需要进行硬件虚拟以及运行完整的操作系统

轻量级

快速启动

隔离性

进程隔离

2、简述Docker容器的几种状态？

Docker容器可以有四种状态：

运行

已暂停

重新启动

已退出

3、简述Dockerfile、Docker镜像和Docker容器的区别？

Dockerfile 是软件的原材料，Docker 镜像是软件的交付品，而 Docker 容器则可以认为是软件的运行态。从应用软件的角度来看，Dockerfile、Docker 镜像与 Docker 容器分别代表软件的三个不同阶段，Dockerfile 面向开发，Docker 镜像成为交付标准，Docker 容器则涉及部署与运维。

4、简述Docker与KVM（虚拟机）的区别？

容器部署简单，虚拟机部署相对复杂。

虚拟化技术依赖物理CPU和内存，是硬件级别的；

而docker构建在操作系统上，利用操作系统的containerization技术，所以docker甚至可以在虚拟机上运行。

容器秒级启动，虚拟机通常分钟级启动。

传统的虚拟化技术在构建系统的时候较为复杂，需要大量的人力；

而docker可以通过Dockfile来构建整个容器，重启和构建速度很快。

容器需要的资源（如磁盘、CPU、内存）相对更少。

容器比较轻便，虚拟机相对较重。

虚拟化系统一般都是指操作系统级概念，比较复杂，称为“系统”；

而docker开源而且轻量，称为“容器”，单个容器适合部署少量应用，比如部署一个redis、一个memcached。

5、简述Docker主要使用的技术？

容器主要使用如下技术：

Cgroup：资源控制

Namespace：访问隔离

rootfs：文件系统隔离

容器引擎（用户态工具）：生命周期控制

6、简述Docker体系架构？

Docker体系相对简单，主要涉及如下5个组件：

Docker客户端 – Docker

docker客户端则扮演着docker服务端的远程控制器，可以用来控制docker的服务端进程。

Docker服务端 – Docker Daemon

docker服务端是一个服务进程，管理着所有的容器。

Docker镜像 – Image

docker镜像，一个能够运行在docker容器上的一组程序文件，是一个只读的模板，不包含任何动态数据。

Docker容器 – Docker Container

docker容器，就是运行程序的载体，容器是镜像运行时的实体。

Docker镜像仓库 -- Registry

Docker仓库是集中存放镜像文件的场所，Docker仓库分为公开仓库（Public）和私有仓库（Private）两种形式。

7、简述Docker如何实现网络隔离？

Docker利用了网络的命名空间特性，实现了不同容器之间的网络隔离。命名空间可以支持网络协议栈的多个实例，独立的协议栈被隔离到不同的命名空间中。

因此处于不同命名空间中的网络栈是完全隔离的，彼此之间无法通信。每个独立的命名空间中可以有自己独立的路由表及独立的iptables设置来提供包转发、NAT及IP包过滤等功能。

8、简述Linux文件系统和Docker文件系统？

Linux文件系统：由bootfs和rootfs组成，bootfs主要包含bootloader和kernel，bootloader主要是引导加载kernel，当kernel被加载到内存之后bootfs就被卸载掉了。rootfs包含的就是典型linux系统中/dev,/proc,/bin,/etc等标准目录。

Docker文件系统：Docker容器是建立在Aufs分层文件系统基础上的，Aufs支持将不同的目录挂载到同一个虚拟文件系统下，并实现一种layer的概念。Aufs将挂载到同一虚拟文件系统下的多个目录分别设置成read-only，read-write以及whiteout-able权限。docker 镜像中每一层文件系统都是read-only。

9、简述Docker网络模式？

Docker使用Linux的Namespaces技术来进行资源隔离，其中Network Namespace实现隔离网络。

一个Network Namespace提供了一份独立隔离的网络环境，包括网卡、路由、Iptable规则等，Docker网络有如下四种模式：

host模式：host模式下容器将不会获得独立的Network Namespace，该模式下与宿主机共用一个Network Namespace。容器将不会虚拟出自己的网卡，不会配置独有的IP等，而是使用宿主机的IP和端口。

container模式：Container 网络模式是 Docker 中一种较为特别的网络的模式，处于container模式下的 Docker 容器会共享其他容器的网络环境，因此，两个或以上的容器之间不存在网络隔离，而配置container模式的容器又与宿主机以及除此之外其他的容器存在网络隔离。

none模式：none模式下，Docker容器拥有自己的Network Namespace，但是，并不为Docker容器进行任何网络配置和构造任何网络环境。Docker 容器采用了none 网络模式，那么容器内部就只能使用loopback网络设备，不会再有其他的网络资源。Docker Container的none网络模式意味着不给该容器创建任何网络环境，容器只能使用127.0.0.1的本机网络。

bridge模式：bridge模式是Docker默认的网络设置，此模式会为每一个容器分配Network Namespace、设置IP等，并将该宿主机上的Docker容器连接到一个虚拟网桥上。

10、简述Docker跨主机通信的网络实现方式？

docker跨主机通信按原理可通过以下三种方式实现：

直接路由方式：直接在不同宿主机之间添加静态路由；

桥接方式（如pipework）：通过静态指定容器IP为宿主机IP同一个网络的形式，即可实现。

Overlay隧道方式：使用overlay网络实现，Overlay网络指在现有网络层之上叠加的虚拟化技术，实现应用在网络上的承载，并能与其他网络业务分离，并且以基于IP的网络技术为主，如flannel、ovs+gre。

11、简述flannel网络模型实现原理？

Flannel为每个host分配一个subnet，容器从subnet中分配IP，这些IP可以在host间路由，容器间无需使用nat和端口映射即可实现跨主机通信。每个subnet都是从一个更大的IP池中划分的，flannel会在每个主机上运flanneld的agent，负责从池子中分配subnet。

Flannel使用etcd存放网络配置、已分配的subnet、host的IP等信息，Flannel数据包在主机间转发是由backend实现的，目前已经支持UDP、VxLAN、host-gw、AWS VPC和GCE路由等多种backend。

高中生也能读懂的Docker入门教程
Docker 入门终极指南：边学边用
10 个冷门但又非常实用的 Docker 使用技巧！
Docker 入门看这一篇就够了！

Apache 与 Nginx

1、简述什么是Apache服务器？

Apache服务器是一个非常流行、功能强大并且开源的Web服务器，基于HTTP超文本传输协议运行，这一协议提供了服务器和客户端Web浏览器通信的标准。它支持SSL、CGI文件、虚拟主机等许多功能特性。

2、简述Apache虚拟主机？

Apache虚拟主机相当于一个在同一台服务器中却相互独立的站点，从而实现一台主机对外提供多个 web 服务，每个虚拟主机之间是独立的，互不影响的。Apache具有两种类型的虚拟主机：基于名称的虚拟主机和基于IP的虚拟主机。

3、简述Apache的Worker MPM和Prefork MPM之间的区别？

它们都是MPM，Worker和Prefork有它们各自在Apache上的运行机制，取决于哪种模式启动Apache。Worker MPM和Prefork MPM基本的区别在于它们产生子进程的处理过程。

1、Prefork MPM中，一个主httpd进行被启动，这个主进程会管理所有其它子进程为客户端请求提供服务。Worker MPM中一个httpd进程被激活，则会使用不同的线程来为客户端请求提供服务。

2、Prefork MPM使用多个子进程，每一个进程带有一个线程，Worker MPM使用多个子进程，每一个进程带有多个线程。

3、Prefork MPM中的连接处理，每一个进程一次处理一个连接而在Worker MPM中每一个线程一次处理一个连接。

4、内存占用Prefork MPM占用庞大的内存，而Worker MPM占用更小的内存。

详解 Linux 环境下部署 HTTPD 服务
如何在 Linux 环境下部署 AWStats 分析系统来监控 Web 站点？
一文读懂 HTTPD 服务的访问控制

4、简述Nginx是什么及其主要特点？

Nginx是一款自由的、开源的、高性能的HTTP服务器和反向代理服务器。可以作为一个HTTP服务器进行网站的发布处理，同时也可以作为反向代理进行负载均衡的实现。其主要特点有：

占有内存少，并发能力强。

Nginx使用基于事件驱动架构，使得其可以支持数以百万级别的TCP连接。

高度的模块化和自由软件许可证使得第三方模块非常丰富。

Nginx是一个跨平台服务器，可以运行在Linux，Windows，FreeBSD，Solaris，AIX，Mac OS等操作系统上。

5、简述Nginx和Apache的差异？

Nginx是一个基于事件的Web服务器，Apache是一个基于流程的服务器；

Nginx所有请求都由一个线程处理，Apache单个线程处理单个请求；

Nginx避免子进程的概念，Apache是基于子进程的；

Nginx在内存消耗和连接方面更好，Apache在内存消耗和连接方面一般；

Nginx的性能和可伸缩性不依赖于硬件，Apache依赖于CPU和内存等硬件；

Nginx支持热部署，Apache不支持热部署；

Nginx对于静态文件处理具有更高效率，Apache相对一般；

Nginx在反向代理场景具有明显优势，Apache相对一般。

6、简述Nginx主要应用的场景？

基于Nginx的特性，Nginx的应用场景主要有：

http服务器：Nginx是一个http服务可以独立提供http服务，可以做网页静态服务器。

虚拟主机：可以实现在一台服务器虚拟出多个网站。

正反代理：负载均衡或加速，当网站的访问量达到一定程度后，单台服务器不能满足用户的请求时，需要用多台服务器集群可以使用Nginx做反向代理，并且多台服务器可以平均分担负载。

7、简述Nginx HTTP连接和请求的关系？

HTTP是建立在TCP上，一次HTTP请求需要先建立TCP三次握手（称为TCP连接），在连接的基础上再进行HTTP请求。

HTTP请求建立在一次TCP连接基础上，对于HTTP会话，一次TCP连接可以建立多次HTTP请求。

8、简述Nginx支持哪些访问控制方式？

连接限制：Nginx自带的limit_conn_module模块（TCP连接频率限制模块）和limit_req_mudule模块（HTTP请求频率限制模块）支持对连接频率以及请求频率、来源进行限制，通常可可以用来防止DDOS攻击。

IP限制：Nginx使用http_access_module模块可实现基于IP的访问控制，但通过代理可以绕过限制。

账号限制：Nginx使用http_auth_basic_module模块可实现用户密码的登录限制。

流量限制：Nginx使用http_core_moduleblock模块可实现客户端传送响应的速率限制。

9、简述Nginx Master进程和Worker节点？

master进程主要用来管理worker进程，包含：接收来自外界的信号，向各worker进程发送信号，监控worker进程的运行状态，当worker进程退出后(异常情况下)，会自动重新启动新的worker进程。

worker进程则是处理基本的网络事件。多个worker进程之间是对等的，他们同等竞争来自客户端的请求，各进程互相之间是独立的。一个请求，只可能在一个worker进程中处理，一个worker进程，不可能处理其它进程的请求。

10、简述Nginx如何处理HTTP请求？

首先，Nginx 在启动时，会解析配置文件，获取需要监听的端口与 IP 地址，然后在 Nginx 的 Master 进程里面先初始化好这个监控的Socket（创建 Socket，设置 addr、绑定ip和端口，然后listen 监听)。

然后，再 fork 出多个子进程出来。

之后，子进程会竞争 accept 新的连接。此时，客户端就可以向 nginx 发起连接了。当客户端与nginx完成TCP三次握手，与 nginx 建立好一个连接后。此时，某一个子进程会 accept 成功，得到这个建立好的连接的 Socket ，然后创建 nginx 对连接的封装。

接着，设置读写事件处理函数，并添加读写事件来与客户端进行数据的交换。

最后，Nginx 或客户端来主动关掉连接，完成整个HTTP请求的处理。

11、简述Nginx对于HTTP请求采用哪两种机制进行处理？

Nginx 是一个高性能的 Web 服务器，能够同时处理大量的并发请求。它结合多进程机制和异步非阻塞机制 。

多进程机制：服务器每当收到一个客户端请求时，就有服务器主进程 （master process）生成一个子进程（worker process）和客户端建立连接进行交互，直到连接断开，该子进程就结束了。

使用进程的好处是各个进程之间相互独立，不需要加锁，减少了使用锁对性能造成影响。

其次，采用独立的进程，可以让进程互相之间不会影响 ，如果一个进程发生异常退出时，其它进程正常工作，master进程则很快启动新的worker进程，确保服务不会中断，从而将风险降到最低。

缺点是操作系统生成一个子进程需要进行 内存复制等操作，在资源和时间上会产生一定的开销。当有大量请求时，会导致系统性能下降 。

异步非阻塞机制：每个工作进程使用异步非阻塞方式，可以处理多个客户端请求 。

当某个工作进程接收到客户端请求以后，调用 IO 进行处理，如果不能立即得到结果，就去处理其他请求（即为非阻塞 ）。而客户端在此期间也无需等待响应，可以进行其他任务（即为 异步 ）。

当IO返回时，就会通知此工作进程。该进程得到通知，暂时挂起当前处理的事务去响应客户端请求 。

12、简述Nginx支持哪些类型的虚拟主机？

对于Nginx而言，每一个虚拟主机相当于一个在同一台服务器中却相互独立的站点，从而实现一台主机对外提供多个 web 服务，每个虚拟主机之间是独立的，互不影响的。通过 Nginx 可以实现虚拟主机的配置，Nginx 支持三种类型的虚拟主机配置：

基于 IP 的虚拟主机（较少使用）

基于域名的虚拟主机

基于端口的虚拟主机

13、简述Nginx缓存及其作用？

缓存对于Web至关重要，尤其对于大型高负载Web站点。Nginx缓存可作为性能优化的一个重要手段，可以极大减轻后端服务器的负载。通常对于静态资源，即较少经常更新的资源，如图片，css或js等进行缓存，从而在每次刷新浏览器的时候，不用重新请求，而是从缓存里面读取，这样就可以减轻服务器的压力。

14、简述Nginx作为代理缓存后，客户端访问的过程？

使用Nginx作为代理缓存后，可加快客户端的访问，其过程大致如下：

第一步：客户端第一次向Nginx请求数据A；

第二步：当Nginx发现缓存中没有数据A时，会向服务端请求数据A；

第三步：服务端接收到Nginx发来的请求，则返回数据A到Nginx，并且缓存在Nginx；

第四步：Nginx返回数据A给客户端应用；

第五步：客户端第二次向Nginx请求数据A；

第六步：当Nginx发现缓存中存在数据A时，则不会请求服务端；

第七步：Nginx把缓存中的数据A返回给客户端应用。

15、简述Nginx代理及其类型？

代理（forward）是一个位于客户端和原始服务器(origin server)之间的服务器，即代理服务器。为了从原始服务器取得内容，客户端向代理服务器发送一个请求并指定目标原始服务器，然后代理服务器向原始服务器转交请求并将获得的内容返回给客户端。

其通常有如下三种代理模式：

正向代理（forward proxy）：一个位于客户端和原始服务器(origin server)之间的服务器，为了从原始服务器取得内容，客户端向代理发送一个请求并指定目标(原始服务器)，然后代理向原始服务器转交请求并将获得的内容返回给客户端。

反向代理（reverse proxy）：指以代理服务器来接受 Internet上的连接请求，然后将请求，发给内部网络上的服务器并将从服务器上得到的结果返回给 Internet 上请求连接的客户端，此时代理服务器对外就表现为一个反向代理服务器。

透明代理

16、简述Nginx盗链及如何防护？

盗链指的是在自己的界面展示非本服务器上的内容，通过技术手段获得其他服务器的资源。绕过他人资源展示页面，在自己页面向用户提供此内容，从而减轻自己服务器的负担，因为真实的空间和流量来自其他服务器。

因此，通常为了避免被盗链，通常Web服务器建议配置防盗链。Nginx防盗链其主要防盗链思路是能区别哪些请求是非正常用户请求，对于非正常用户的请求直接反馈403或重定向至其他页面。

17、简述Nginx负载均衡的意义？

负载均衡是将负载分摊到多个操作单元上执行，从而提高服务的可用性和响应速度，带给用户更好的体验。对于Web应用，通过负载均衡，可以将一台服务器的工作扩展到多台服务器中执行，提高整个网站的负载能力。其本质采用一个调度者，保证所有后端服务器都将性能充分发挥，从而保持服务器集群的整体性能最优，这就是负载均衡。

18、简述Nginx负载均衡的优势？

Nginx作为负载均衡器具有极大的优势，主要体现在：

高并发连接

内存消耗少

配置文件非常简单

成本低廉

支持Rewrite重写规则

内置的健康检查功能

节省带宽

稳定性高

19、简述Nginx负载均衡主要的均衡机制（策略）？

Nginx作为负载均衡器具有极大的优势，其负载均衡策略可以划分为两大类：内置策略和扩展策略，扩展策略为第三方提供。

内置策略

轮询（默认）：Nginx根据请求次数，将每个请求均匀分配到每台服务器；

weight：加权轮询，加权轮询则是在第一种轮询的基础上对后台的每台服务赋予权重，服务器的权重比例越大，被分发到的概率也就越大。

least_conn：最少连接，将请求分配给连接数最少的服务器。Nginx会统计哪些服务器的连接数最少。

ip_hash：IP 哈希，绑定处理请求的服务器。第一次请求时，根据该客户端的IP算出一个HASH值，将请求分配到集群中的某一台服务器上。后面该客户端的所有请求，都将通过HASH算法，找到之前处理这台客户端请求的服务器，然后将请求交给它来处理。

扩展策略

fair：按后端服务器的响应时间来分配请求，响应时间短的优先分配。

url_hash：按访问url的hash结果来分配请求，使每个url定向到同一个后端服务器，后端服务器为缓存时比较有效。

20、简述Nginx负载均衡（反向代理）通过什么方式实现后端RS的健康检查？

nginx负载均衡（反向代理）包含内置的或第三方扩展来实现服务器健康检测的。如果后端某台服务器响应失败，nginx会标记该台服务器失效，在特定时间内，请求不分发到该台服务器上

fail_timeout：该指令定义了多长时间服务器将被标记为失败。在fail_timeout后，服务器还是failed，nginx将检测该服务器是否存活，如果探测成功，将标记为活的。

max_fails：该指令设置在fail_timeout期间内连续的失败尝试。默认情况下，max_fails为1。如果被设置为0，该服务器的健康检测将禁用。

21、简述Nginx动静分离？

为了提高网站的响应速度，减轻程序服务器（Tomcat，Jboss等）的负载，对于静态资源，如图片、js、css等文件，可以在反向代理服务器中进行缓存，这样浏览器在请求一个静态资源时，代理服务器就可以直接处理，而不用将请求转发给后端服务器。对于用户请求的动态文件，如servlet、jsp，则转发给Tomcat，Jboss服务器处理，这就是动静分离。即动态文件与静态文件的分离。

22、简述Nginx动静分离的原理？

动静分离可通过location对请求url进行匹配，将网站静态资源（HTML，JavaScript，CSS，img等文件）与后台应用分开部署，提高用户访问静态代码的速度，降低对后台应用访问。通常将静态资源放到nginx中，动态资源转发到tomcat服务器中。

23、简述Nginx同源策略？

同源策略是一个安全策略。同源，指的是协议，域名，端口相同。浏览器处于安全方面的考虑，只允许本域名下的接口交互，不同源的客户端脚本，在没有明确授权的情况下，不能读写对方的资源。

24、简述Nginx跨域及如何实现？

从一个域名的网页去请求另一个域名的资源，或任何协议、域名、端口有一处不同的请求，就被当作是跨域，即都被当成不同源。

通常基于安全考虑，Nginx启用了同源策略，即限制了从同一个源加载的文档或脚本如何与来自另一个源的资源进行交互。这是一个用于隔离潜在恶意文件的重要安全机制。

Nginx若要实现跨域访问，可通过JSONP和CORS进行实现。

25、简述Nginx重定向及其使用的场景？

重定向(Redirect)指通过各种方法将各种网络请求重新定个方向转到其它位置（如：网页重定向、域名的重定向、路由选择的变化也是对数据报文经由路径的一种重定向）。

URL重写是指通过配置conf文件，以让网站的URL中达到某种状态时则定向/跳转到某个规则，比如常见的伪静态、301重定向、浏览器定向等。当客户端浏览某个网址时，将其访问导向到另一个网址的技术。

其主要场景有如下两个：

将一串很长的网址，转成较短的网址，从而实现便于传播、易于记忆。

调整或更换Web服务器，网址（域名）又必须要变更（如访问目录、访问扩展名HTML变为PHP、访问域名），为了能使旧的访问依旧生效，从而实现自动重定向到新的网站。

26、简述Nginx地址重写、地址转发、反向代理？

地址重写：为了实现地址的标准化，如地址栏中中输入 www.baidu.com. 也可以输入 www.baidu.cn。最后都会被重写到 www.baidu.com 上。浏览器的地址栏也会显示www.baidu.com。即nginx把收到客户端请求的内容所对应的服务器地址发给客户端，让客户端自己去获取，nginx同时返回302正确信息。

地址转发：指在网络数据传输过程中数据分组到达路由器或桥接器后，该设备通过检查分组地址并将数据转发到最近的局域网的过程。

反向代理：当浏览器访问网站时，nginx反向代理服务器会代替客户端向后端服务器查找所需的内容，然后nginx反向代理服务器会把查找的内容返回给客户端。

27、简述Nginx地址重写和地址转发的差异？

地址重写和地址转发有以下不同点：

地址重写会改变浏览器中的地址，使之变成重写成浏览器最新的地址。而地址转发不会改变浏览器的地址的。

地址重写会产生两次请求，而地址转发只会有一次请求。

地址转发一般发生在同一站点项目内部，而地址重写且不受限制。

地址转发的速度比地址重定向快。

28、简述Nginx 301和302重定向及其区别？

301和302状态码都表示重定向，表示浏览器在拿到服务器返回的这个状态码后会自动跳转到一个新的URL地址，这个地址可以从响应的Location首部中获取（客户端输入的地址A瞬间变成了另一个地址B）。其主要差异为：

301：代表永久性转移(Permanently Moved)：旧地址A的资源已经被永久地移除了（这个资源不可访问了），搜索引擎在抓取新内容的同时也将旧的网址交换为重定向之后的网址；

302：代表暂时性转移(Temporarily Moved)：旧地址A的资源还在（仍然可以访问），这个重定向只是临时地从旧地址A跳转到地址B，搜索引擎会抓取新的内容而保存旧的网址。

29、简述Nginx高可用的常见方案？

Keepalived + Nginx 实现Nginx的高可用：通过Keepalived来实现同一个虚拟IP映射到多台Nginx代理服务器，从而实现Nginx的高可用性。

Heartbeat + Nginx 实现Nginx的高可用：通过Heartbeat的心跳检测和资源接管、集群中服务的监测、失效切换等功能，结合Nginx来实现高可用性。

27、简述MySQL索引及其作用？

是数据库管理系统中一个排序的数据结构，根据不同的存储引擎索引分为Hash索引、B+树索引等。常见的InnoDB存储引擎的默认索引实现为：B+树索引。索引可以协助快速查询、更新数据库表中数据。

28、简述MySQL中什么是事务？

事务是一系列的操作，需要要符合ACID特性，即：事务中的操作要么全部成功，要么全部失败。

29、简述MySQL事务之间的隔离？

MySQL事务支持如下四种隔离：

未提交读(Read Uncommitted)：允许脏读，其他事务只要修改了数据，即使未提交，本事务也能看到修改后的数据值。也就是可能读取到其他会话中未提交事务修改的数据。

提交读(Read Committed)：只能读取到已经提交的数据。Oracle等多数数据库默认都是该级别 (不重复读)。

可重复读(Repeated Read)：可重复读。无论其他事务是否修改并提交了数据，在这个事务中看到的数据值始终不受其他事务影响。

串行读(Serializable)：完全串行化的读，每次读都需要获得表级共享锁，读写相互都会阻塞。

30、简述MySQL锁及其作用？

锁机制是为了避免，在数据库有并发事务的时候，可能会产生数据的不一致而诞生的的一个机制。锁从类别上分为：

共享锁：又叫做读锁，当用户要进行数据的读取时，对数据加上共享锁，共享锁可以同时加上多个。

排他锁：又叫做写锁，当用户要进行数据的写入时，对数据加上排他锁，排他锁只可以加一个，他和其他的排他锁,共享锁都相斥。

31、简述MySQL表中为什么建议添加主键？

主键是数据库确保数据行在整张表唯一性的保障，即使数据库中表没有主键，也建议添加一个自增长的ID列作为主键，设定了主键之后，在后续的删改查的时候可能更加快速以及确保操作数据范围安全。

32、简述MySQL所支持的存储引擎？

MySQL支持多种存储引擎，常见的有InnoDB、MyISAM、Memory、Archive等。通常使用InnoDB引擎都是最合适的，InnoDB也是MySQL的默认存储引擎。

33、简述MySQL InnoDB引擎和MyISAM引擎的差异？

InnoDB支持事物，而MyISAM不支持事物。

InnoDB支持行级锁，而MyISAM支持表级锁。

InnoDB支持MVCC, 而MyISAM不支持。

InnoDB支持外键，而MyISAM不支持。

InnoDB不支持全文索引，而MyISAM支持。

34、简述MySQL主从复制过程？

1、Slave上面的IO线程连接上Master，并请求从指定日志文件的指定位置（或者从最开始的日志）之后的日志内容；

2、Master接收到来自Slave的IO线程的请求后，通过负责复制的IO线程根据请求信息读取指定日志指定位置之后的日志信息，返回给Slave端的IO线程。返回信息中除了日志所包含的信息之外，还包括本次返回的信息在Master端binary log文件的名称以及在Binary log中的位置；

3、Slave的IO线程收到信息后，将接收到的日志内容依次写入到Slave端的RelayLog文件（mysql-relay-lin.xxxxx）的最末端，并将读取到的Master端的bin-log的文件名和位置记录到master-info文件中，以便在下一次读取的时候能够明确知道从什么位置开始读取日志；

4、Slave的SQL线程检测到Relay Log中新增加了内容后，会马上解析该Log文件中的内容成为在Master端真实执行时候的那些可执行的查询或操作语句，并在自身执行那些查询或操作语句，这样，实际上就是在master端和Slave端执行了同样的查询或操作语句，所以两端的数据是完全一样的。

35、简述MySQL常见的读写分离方案？

MySQL+Amoeba读写分离方案：Amoeba(变形虫)项目，这个工具致力于MySQL的分布式数据库前端代理层，它主要在应用层访问MySQL的时候充当SQL路由功能。具有负载均衡、高可用性、SQL 过滤、读写分离、可路由相关的到目标数据库、可并发请求多台数据库合并结果。通过Amoeba你能够完成多数据源的高可用、负载均衡、数据切片、读写分离的功能。

MySQL+MMM读写分离方案：MMM即Multi-Master Replication Manager for MySQL，mysql多主复制管理器是关于mysql主主复制配置的监控、故障转移和管理的一套可伸缩的脚本套件(在任何时候只有一个节点可以被写入)。MMM也能对从服务器进行读负载均衡，通过MMM方案能实现服务器的故障转移，从而实现mysql的高可用。MMM不仅能提供浮动IP的功能，如果当前的主服务器挂掉后，会将你后端的从服务器自动转向新的主服务器进行同步复制，不用手工更改同步配置。

36、简述MySQL常见的高可用方案？

MySQL主从复制：Mysql内建的复制功能是构建大型，高性能应用程序的基础。将Mysql的数据分布在多个节点（slaves）之上，复制过程中一个服务器充当主服务器，而一个或多个其它服务器充当从服务器。主服务器将更新写入二进制日志文件，并维护文件的一个索引以跟踪日志循环。这些日志可以记录发送到从服务器的更新。

MySQL双主：参考MySQL主从复制。

MySQL双主多从：参考MySQL主从复制。

MySQL复制+Keepalived高可用：MySQL自身的复制，对外基于Keepalived技术，暴露一个VIP，从而实现高可用。

Heartbeat + MySQL 实现MySQL的高可用：通过Heartbeat的心跳检测和资源接管、集群中服务的监测、失效切换等功能，结合MySQL来实现高可用性。

37、简述MySQL常见的优化措施？

MySQL可通过如下方式优化：

1、开启查询缓存，优化查询。
2、使用explain判断select查询，从而分析查询语句或是表结构的性能瓶颈，然后有针对性的进行优化。
3、为搜索字段建索引
4、对于有限定范围取值的字段，推荐使用 ENUM 而不是 VARCHAR。
5、垂直分表。
6、选择正确的存储引擎。

38、简述MySQL常见备份方式和工具？

MySQL自带

mysqldump：mysqldump支持基于innodb的热备份，使用mysqldump完全备份+二进制日志可以实现基于时间点的恢复，通常适合备份数据比较小的场景。

系统层面

tar备份：可以使用tar之类的系统命令对整个数据库目录进行打包备份。

lvm快照备份：可基于文件系统的LVM制作快照，进行对整个数据库目录所在的逻辑卷备份。

第三方备份工具

可使用其他第三方工具进行备份，如xtrabackup工具，该工具支持innodb的物理热备份，支持完全备份、增量备份，而且速度非常快，支持innodb存储引起的数据在不同数据库之间迁移，支持复制模式下的从机备份恢复备份恢复。

MySQL | MySQL 数据库系统（四）- 数据库的备份与恢复

简述ETCD及其特点？

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

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

简述ETCD适应的场景？

etcd基于其优秀的特点，可广泛的应用于以下场景：

服务发现(Service Discovery)：服务发现主要解决在同一个分布式集群中的进程或服务，要如何才能找到对方并建立连接。本质上来说，服务发现就是想要了解集群中是否有进程在监听udp或tcp端口，并且通过名字就可以查找和连接。

消息发布与订阅：在分布式系统中，最适用的一种组件间通信方式就是消息发布与订阅。即构建一个配置共享中心，数据提供者在这个配置中心发布消息，而消息使用者则订阅他们关心的主题，一旦主题有消息发布，就会实时通知订阅者。通过这种方式可以做到分布式系统配置的集中式管理与动态更新。应用中用到的一些配置信息放到etcd上进行集中管理。

负载均衡：在分布式系统中，为了保证服务的高可用以及数据的一致性，通常都会把数据和服务部署多份，以此达到对等服务，即使其中的某一个服务失效了，也不影响使用。etcd本身分布式架构存储的信息访问支持负载均衡。etcd集群化以后，每个etcd的核心节点都可以处理用户的请求。所以，把数据量小但是访问频繁的消息数据直接存储到etcd中也可以实现负载均衡的效果。

分布式通知与协调：与消息发布和订阅类似，都用到了etcd中的Watcher机制，通过注册与异步通知机制，实现分布式环境下不同系统之间的通知与协调，从而对数据变更做到实时处理。

分布式锁：因为etcd使用Raft算法保持了数据的强一致性，某次操作存储到集群中的值必然是全局一致的，所以很容易实现分布式锁。锁服务有两种使用方式，一是保持独占，二是控制时序。

集群监控与Leader竞选：通过etcd来进行监控实现起来非常简单并且实时性强。

简述什么是Kubernetes？

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

简述Kubernetes和Docker的关系？

Docker 提供容器的生命周期管理和，Docker 镜像构建运行时容器。它的主要优点是将将软件/应用程序运行所需的设置和依赖项打包到一个容器中，从而实现了可移植性等优点。

Kubernetes 用于关联和编排在多个主机上运行的容器。

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

Minikube 是一种可以在本地轻松运行一个单节点 Kubernetes 群集的工具。

Kubectl 是一个命令行工具，可以使用该工具控制Kubernetes集群管理器，如检查群集资源，创建、删除和更新组件，查看应用程序。

Kubelet 是一个代理服务，它在每个节点上运行，并使从服务器与主服务器通信。

简述Kubernetes常见的部署方式？

常见的Kubernetes部署方式有：

简述Kubernetes如何实现集群管理？

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

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

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

  • 容器编排
  • 轻量级
  • 开源
  • 弹性伸缩
  • 负载均衡

Kubernetes常见场景：

  • 快速部署应用
  • 快速扩展应用
  • 无缝对接新的应用功能
  • 节省资源，优化硬件资源的使用

Kubernetes相关特点：

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

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

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节点上，若干相关容器的组合(Kubernetes 之 Pod 实现原理)。Pod内包含的容器运行在同一宿主机上，使用相同的网络命名空间、IP地址和端口，能够通过localhost进行通信。Pod是Kurbernetes进行创建、调度和管理的最小单位，它提供了比容器更高层次的抽象，使得部署和管理更加灵活。一个Pod可以包含一个容器或者多个相关容器。

label：Kubernetes中的Label实质是一系列的Key/Value键值对，其中key与value可自定义。Label可以附加到各种资源对象上，如Node、Pod、Service、RC等。一个资源对象可以定义任意数量的Label，同一个Label也可以被添加到任意数量的资源对象上去。Kubernetes通过Label Selector（标签选择器）查询和筛选资源对象。

Replication Controller：Replication Controller用来管理Pod的副本，保证集群中存在指定数量的Pod副本。集群中副本的数量大于指定数量，则会停止指定数量之外的多余容器数量。反之，则会启动少于指定数量个数的容器，保证数量不变。Replication Controller是实现弹性伸缩、动态扩容和滚动升级的核心。

Deployment：Deployment在内部使用了RS来实现目的，Deployment相当于RC的一次升级，其最大的特色为可以随时获知当前Pod的部署进度。

HPA（Horizontal Pod Autoscaler）：Pod的横向自动扩容，也是Kubernetes的一种资源，通过追踪分析RC控制的所有Pod目标的负载变化情况，来确定是否需要针对性的调整Pod副本数量。

Service：Service(Kubernetes 之服务发现)定义了Pod的逻辑集合和访问该集合的策略，是真实服务的抽象。Service提供了一个统一的服务访问入口以及服务代理和发现机制，关联多个相同Label的Pod，用户不需要了解后台Pod是如何运行。

Volume：Volume是Pod中能够被多个容器访问的共享目录，Kubernetes中的Volume是定义在Pod上，可以被一个或多个Pod中的容器挂载到某个目录下。

Namespace：Namespace用于实现多租户的资源隔离，可将集群内部的资源对象分配到不同的Namespace中，形成逻辑上的不同项目、小组或用户组，便于不同的Namespace在共享使用整个集群的资源的同时还能被分别管理。

简述Kubernetes集群相关组件？

Kubernetes Master控制组件，调度管理整个系统（集群），包含如下组件:

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的主要流程？

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。

  • Always：当容器失效时，由kubelet自动重启该容器；
  • OnFailure：当容器终止运行且退出码不为0时，由kubelet自动重启该容器；
  • Never：不论容器运行状态如何，kubelet都不会重启该容器。

同时Pod的重启策略与控制方式关联，当前可用于管理Pod的控制器包括ReplicationController、Job、DaemonSet及直接管理kubelet管理（静态Pod）。

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

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

简述Kubernetes中Pod的健康检查方式？

对Pod的健康检查可以通过两类探针来检查：LivenessProbe和ReadinessProbe。

LivenessProbe探针：用于判断容器是否存活（running状态），如果LivenessProbe探针探测到容器不健康，则kubelet将杀掉该容器，并根据容器的重启策略做相应处理。若一个容器不包含LivenessProbe探针，kubelet认为该容器的LivenessProbe探针返回值用于是“Success”。

ReadineeProbe探针：用于判断容器是否启动完成（ready状态）。如果ReadinessProbe探针探测到失败，则Pod的状态将被修改。Endpoint Controller将从Service的Endpoint中删除包含该容器所在Pod的Eenpoint。

startupProbe探针：启动检查机制，应用一些启动缓慢的业务，避免业务长时间启动而被上面两类探针kill掉。

简述Kubernetes Pod的LivenessProbe探针的常见方式？

kubelet定期执行LivenessProbe探针来诊断容器的健康状态，通常有以下三种方式：

ExecAction：在容器内执行一个命令，若返回码为0，则表明容器健康。

TCPSocketAction：通过容器的IP地址和端口号执行TCP检查，若能建立TCP连接，则表明容器健康。

HTTPGetAction：通过容器的IP地址、端口号及路径调用HTTP Get方法，若响应的状态码大于等于200且小于400，则表明容器健康。

简述Kubernetes Pod的常见调度方式？

Kubernetes中，Pod通常是容器的载体，主要有如下常见调度方式：

  • Deployment或RC：该调度策略主要功能就是自动部署一个容器应用的多份副本，以及持续监控副本的数量，在集群内始终维持用户指定的副本数量。
  • NodeSelector：定向调度，当需要手动指定将Pod调度到特定Node上，可以通过Node的标签（Label）和Pod的nodeSelector属性相匹配。
  • NodeAffinity亲和性调度：亲和性调度机制极大的扩展了Pod的调度能力，目前有两种节点亲和力表达：
  • requiredDuringSchedulingIgnoredDuringExecution：硬规则，必须满足指定的规则，调度器才可以调度Pod至Node上（类似nodeSelector，语法不同）。
  • preferredDuringSchedulingIgnoredDuringExecution：软规则，优先调度至满足的Node的节点，但不强求，多个优先级规则还可以设置权重值。
  • 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。

Recreate：设置spec.strategy.type=Recreate，表示Deployment在更新Pod时，会先杀掉所有正在运行的Pod，然后创建新的Pod。

RollingUpdate：设置spec.strategy.type=RollingUpdate，表示Deployment会以滚动更新的方式来逐个更新Pod。同时，可以通过设置spec.strategy.rollingUpdate下的两个参数（maxUnavailable和maxSurge）来控制滚动更新的过程。

简述Kubernetes DaemonSet类型的资源特性？

DaemonSet资源对象会在每个Kubernetes集群中的节点上运行，并且每个节点只能运行一个pod，这是它和deployment资源对象的最大也是唯一的区别。因此，在定义yaml文件中，不支持定义replicas。

它的一般使用场景如下：

  • 在去做每个节点的日志收集工作。
  • 监控每个节点的的运行状态。

简述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，可以为一组具有相同功能的容器应用提供一个统一的入口地址，并且将请求负载分发到后端的各个容器应用上。其主要类型有：

  • ClusterIP：虚拟的服务IP地址，该地址用于Kubernetes集群内部的Pod访问，在Node上kube-proxy通过设置的iptables规则进行转发；
  • NodePort：使用宿主机的端口，使能够访问各Node的外部客户端通过Node的IP地址和端口号就能访问服务；
  • LoadBalancer：使用外接负载均衡器完成到服务的负载分发，需要在spec.status.loadBalancer字段指定外部负载均衡器的IP地址，通常用于公有云。

简述Kubernetes Service分发后端的策略？

Service负载分发的策略有：RoundRobin和SessionAffinity

  • 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集群内的服务：

映射Pod到物理机：将Pod端口号映射到宿主机，即在Pod中采用hostPort方式，以使客户端应用能够通过物理机访问容器应用。

映射Service到物理机：将Service端口号映射到宿主机，即在Service中采用nodePort方式，以使客户端应用能够通过物理机访问容器应用。

映射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镜像的下载策略？

K8s的镜像下载策略有三种：Always、Never、IFNotPresent。

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

简述Kubernetes的负载均衡器？

负载均衡器是暴露服务的最常见和标准方式之一。

根据工作环境使用两种类型的负载均衡器，即内部负载均衡器或外部负载均衡器。内部负载均衡器自动平衡负载并使用所需配置分配容器，而外部负载均衡器将流量从外部负载引导至后端容器。

简述Kubernetes各模块如何与API Server通信？

Kubernetes API Server作为集群的核心，负责集群各功能模块之间的通信。集群内的各个功能模块通过API Server将信息存入etcd，当需要获取和操作这些数据时，则通过API Server提供的REST接口（用GET、LIST或WATCH方法）来实现，从而实现各模块之间的信息交互。

如kubelet进程与API Server的交互：每个Node上的kubelet每隔一个时间周期，就会调用一次API Server的REST接口报告自身状态，API Server在接收到这些信息后，会将节点状态信息更新到etcd中。

如kube-controller-manager进程与API Server的交互：kube-controller-manager中的Node Controller模块通过API Server提供的Watch接口实时监控Node的信息，并做相应处理。

如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节点？

Kubernetes Scheduler根据如下两种调度算法将 Pod 绑定到最合适的工作节点：

预选（Predicates）：输入是所有节点，输出是满足预选条件的节点。kube-scheduler根据预选策略过滤掉不满足策略的Nodes。如果某节点的资源不足或者不满足预选策略的条件则无法通过预选。如“Node的label必须与Pod的Selector一致”。

优选（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 会实时采集所在节点的性能指标及在节点上运行的容器的性能指标。

简述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 Policies），Pod才能创建成功。

简述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和IPAM（IP Address  Management）Plugin。CNI Plugin负责为容器配置网络资源，IPAM Plugin负责对容器的IP地址进行分配和管理。IPAM Plugin作为CNI Plugin的一部分，与CNI Plugin协同工作。

简述Kubernetes网络策略？

为实现细粒度的容器间网络访问隔离策略，Kubernetes引入Network Policy。

Network Policy的主要功能是对Pod间的网络通信进行限制和准入控制，设置允许访问或禁止访问的客户端Pod列表。Network Policy定义网络策略，配合策略控制器（Policy Controller）进行策略的实现。

简述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数据持久化的方式有哪些？

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节点进行扩容，从而将应用系统进行水平扩展。主要过程如下：

  • 1、在该Node上安装Docker、kubelet和kube-proxy服务；
  • 2、然后配置kubelet和kubeproxy的启动参数，将Master URL指定为当前Kubernetes集群Master的地址，最后启动这些服务；
  • 3、通过kubelet默认的自动注册机制，新的Worker将会自动加入现有的Kubernetes集群中；
  • 4、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监控并收集该节点上面的系统日志，并将处理过后的日志信息发送给Elasticsearch；
  • Kibana：提供了一个 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，因此在进行关机维护之前，建议先使用kubectl drain将该节点的Pod进行驱逐，然后进行关机维护。

简述Kubernetes集群联邦？

Kubernetes集群联邦可以将多个Kubernetes集群作为一个集群进行管理。因此，可以在一个数据中心/云中创建多个Kubernetes集群，并使用集群联邦在一个地方控制/管理所有集群。

简述Helm及其优势？

Helm 是 Kubernetes 的软件包管理工具。类似 Ubuntu 中使用的apt、Centos中使用的yum 或者Python中的 pip 一样。

Helm能够将一组K8S资源打包统一管理, 是查找、共享和使用为Kubernetes构建的软件的最佳方式。

Helm中通常每个包称为一个Chart，一个Chart是一个目录（一般情况下会将目录进行打包压缩，形成name-version.tgz格式的单一文件，方便传输和存储）。

Helm优势

在 Kubernetes中部署一个可以使用的应用，需要涉及到很多的 Kubernetes 资源的共同协作。使用helm则具有如下优势：

  • 统一管理、配置和更新这些分散的 k8s 的应用资源文件；
  • 分发和复用一套应用模板；
  • 将应用的一系列资源当做一个软件包管理。
  • 对于应用发布者而言，可以通过 Helm 打包应用、管理应用依赖关系、管理应用版本并发布应用到软件仓库。
  • 对于使用者而言，使用 Helm 后不用需要编写复杂的应用部署文件，可以以简单的方式在 Kubernetes 上查找、安装、升级、回滚、卸载应用程序。

5、Kubernetes如何简化容器化部署？

跨主机的容器都需要相互通信。因此，要做到这一点，你需要一些能够负载平衡，扩展和监控容器的东西。由于Kubernetes与云无关并且可以在任何公共/私有提供商上运行，因此可以简化容器化部署程序。

6、什么是kubectl？

Kubectl是一个平台，可以使用该平台将命令传递给集群。因此，它基本上为CLI提供了针对Kubernetes集群运行命令的方法，以及创建和管理Kubernetes组件的各种方法。

7、什么是kubelet？

这是一个代理服务，它在每个节点上运行，并使从服务器与主服务器通信。因此，Kubelet处理PodSpec中提供给它的容器的描述，并确保PodSpec中描述的容器运行正常。可以创建pod、删除pod

8、k8s有哪些组件？

1. etcd保存了整个集群的状态；

2. apiserver提供了资源操作的唯一入口，并提供认证、授权、访问控制、API注册和发现等机制；

3. controller manager负责维护集群的状态，比如故障检测、自动扩展、滚动更新等；

4. scheduler负责资源的调度，按照预定的调度策略将Pod调度到相应的机器上；

5. kubelet负责维护容器的生命周期，同时也负责Volume（CVI）和网络（CNI）的管理；

6. Container runtime负责镜像管理以及Pod和容器的真正运行（CRI）；

7. kube-proxy负责为Service提供cluster内部的服务发现和负载均衡

9、Pod SVC Node Container 之间如何相互访问：

1、同Pod内的容器：同一个Pod的容器共享同一个网络命名空间可以直接进行通讯

2、同Node内不同Pod的容器：多个Pod都关联在同一个Docker0网桥上，通过docker0网桥完成相互通讯。

3、不同Node内Pod的容器：不同Node上的docker0可能会相同，PodIP和docker0是同网段的，所以需要将PodIP和NodeIP进行关联且保障唯一，不同Pod之间的数据通过物理机的端口进行转发即可完成通讯。

二 Kubernetes架构面试题

1、kubernetes控制节点组件有哪些？

Kubernetes控制节点组件：

kube-controller-manager

kube-apiserver

kube-scheduler

Kubernetes工作节点组件：

kubelet和kube-proxy

2、谈谈你对kube-proxy的理解？

kube-proxy是Kubernetes的核心组件，部署在每个Node节点上，它是实现Kubernetes Service的通信与负载均衡机制的重要组件; kube-proxy负责为Pod创建代理服务，从apiserver获取所有server信息，并根据server信息创建代理服务，实现server到Pod的请求路由和转发，从而实现K8s层级的虚拟转发网络。

3、kube-apiserver和kube-scheduler的作用是什么？

kube -apiserver遵循横向扩展架构，是主节点控制平面的前端。将公开Kubernetes主节点组件的所有API，并负责在Kubernetes节点和Kubernetes主组件之间建立通信。

kube-scheduler是调度器，负责根据资源需求选择最合适的节点来运行未调度的pod，并跟踪资源利用率。它确保不在资源已满的节点上调度pod。

4、你能简要介绍一下Kubernetes控制管理器吗？

Controller Manager作为集群内部的管理控制中心，负责集群内的Node、Pod副本、服务端点（Endpoint）、命名空间（Namespace）、服务账号（ServiceAccount）、资源定额（ResourceQuota）的管理，当某个Node意外宕机时，Controller Manager会及时发现并执行自动化修复流程，确保集群始终处于预期的工作状态。

5、Kubernetes如何简化容器化部署？

跨主机的容器都需要相互通信。因此，要做到这一点，你需要一些能够负载平衡，扩展和监控容器的东西。由于Kubernetes与云无关并且可以在任何公共/私有提供商上运行，因此可以简化容器化部署程序。

6、什么是ETCD?

Etcd是用Go编程语言编写的，是一个分布式键值存储，用于协调分布式工作。因此，Etcd存储Kubernetes集群的配置数据，表示在任何给定时间点的集群状态。

7、什么是Ingress，它是如何工作的？

Ingress网络是一组规则，充当Kubernetes集群的入口点。这允许入站连接，可以将其配置为通过可访问的URL，负载平衡流量或通过提供基于名称的虚拟主机从外部提供服务。因此，Ingress是一个API对象，通常通过HTTP管理集群中服务的外部访问，是暴露服务的最有效方式。

8、什么是Headless Service？

Headless Service类似于“普通”服务，但没有群集IP。此服务使您可以直接访问pod，而无需通过代理访问它。

什么是集群联邦？

在联邦集群的帮助下，可以将多个Kubernetes集群作为单个集群进行管理。因此，您可以在数据中心/云中创建多个Kubernetes集群，并使用联邦来在一个位置控制/管理它们。

9、 k8s提供几种服务发现

两种服务发现：

1、环境变量：当创建一个 Pod 的时候，kubelet 会在该 Pod 中注入集群内所有 Service 的相关环境变量。

2、DNS：可以通过 cluster add-on 的方式轻松的创建 CoreDNS 来对集群内的 Service 进行服务发现。

以上两种方式，一个是基于 TCP，DNS 基于 UDP，它们都是建立在四层协议之上。

10、Pod中的应用共享几种资源

1、PID 命名空间：Pod 中的不同应用程序可以看到其他应用程序的进程 ID。

2、网络命名空间：Pod 中的多个容器能够访问同一个IP和端口范围。

3、IPC 命名空间：Pod 中的多个容器能够使用 SystemV IPC 或 POSIX 消息队列进行通信。

4、UTS 命名空间：Pod 中的多个容器共享一个主机名。

5、Volumes（共享存储卷）：Pod 中的各个容器可以访问在 Pod 级别定义的 Volumes。

三 k8s使用场景面试题

场景1

假设一家基于单一架构的公司处理众多产品。现在，随着公司在当今的扩展行业的扩展，他们的单一架构开始引发问题。

您如何看待公司从单一服务转向微服务并部署其服务容器？

解：

由于公司的目标是从单一应用程序转向微服务，它们最终可以逐个构建，并行构建，只需在后台切换配置。然后他们可以将这些内置微服务放在Kubernetes平台上。因此，他们可以从一次或两次迁移服务开始，并监控它们以确保一切运行稳定。一旦他们觉得一切顺利，他们就可以将其余的应用程序迁移到他们的Kubernetes集群中。

场景2：

考虑一家拥有分布式系统的跨国公司，拥有大量数据中心，虚拟机和许多从事各种任务的员工。

您认为这样 的公司如何以与Kubernetes一致的方式管理所有任务？

解：

正如我们所有人都知道IT部门推出了数千个容器，其任务在分布式系统中遍布全球众多节点。

在这种情况下，公司可以使用能够为基于云的应用程序提供敏捷性，横向扩展功能和DevOps实践的东西。

因此，该公司可以使用Kubernetes来定制他们的调度架构并支持多种容器格式。这使得容器任务之间的亲和性成为可能，从而提供更高的效率，并为各种容器网络解决方案和容器存储提供广泛支持。

场景3：

考虑一种情况，即公司希望通过维持最低成本来提高其效率和技术运营速度。

您认为公司将如何实现这一目标？

解：

公司可以通过构建CI/CD管道来实现DevOps方法，但是这里可能出现的一个问题是配置可能需要一段时间才能启动并运行。因此，在实施CI/CD管道之后，公司的下一步应该是在云环境中工作。一旦他们开始处理云环境，他们就可以在集群上安排容器，并可以在Kubernetes的帮助下进行协调。这种方法将有助于公司缩短部署时间，并在各种环境中加快速度。

场景4：

假设一家公司想要修改它的部署方法，并希望建立一个更具可扩展性和响应性的平台。

您如何看待这家公司能够实现这一目标以满足客户需求？

解：

为了给数百万客户提供他们期望的数字体验，公司需要一个可扩展且响应迅速的平台，以便他们能够快速地将数据发送到客户网站。现在，要做到这一点，公司应该从他们的私有数据中心（如果他们使用任何）转移到任何云环境，如AWS。不仅如此，他们还应该实现微服务架构，以便他们可以开始使用Docker容器。一旦他们准备好基础框架，他们就可以开始使用最好的编排平台，即Kubernetes。这将使团队能够自主地构建应用程序并快速交付它们。

场景5：

考虑一家拥有非常分散的系统的跨国公司，期待解决整体代码库问题。

您认为公司如何解决他们的问题？

解：

那么，为了解决这个问题，我们可以将他们的单片代码库转移到微服务设计，然后每个微服务都可以被视为一个容器。因此，所有这些容器都可以在Kubernetes的帮助下进行部署和协调。

场景6：

我们所有人都知道，从单片到微服务的转变解决了开发方面的问题，但却增加了部署方面的问题。

公司如何解决部署方面的问题？

解：

团队可以试验容器编排平台，例如Kubernetes，并在数据中心运行。因此，通过这种方式，公司可以生成模板化应用程序，在五分钟内部署它，并在此时将实际实例集中在暂存环境中。这种Kubernetes项目将有数十个并行运行的微服务，以提高生产率，即使节点出现故障，也可以立即重新安排，而不会影响性能。

场景7：

假设一家公司希望通过采用新技术来优化其工作负载的分配。

公司如何有效地实现这种资源分配？

解：

这个问题的解决方案就是Kubernetes。Kubernetes确保资源得到有效优化，并且只使用特定应用程序所需的那些资源。因此，通过使用最佳容器编排工具，公司可以有效地实现资源分配。

场景8：

考虑一家拼车公司希望通过同时扩展其平台来增加服务器数量。

您认为公司如何处理服务器及其安装？

解：

公司可以采用集装箱化的概念。一旦他们将所有应用程序部署到容器中，他们就可以使用Kubernetes进行编排，并使用像Prometheus这样的容器监视工具来监视容器中的操作。因此，利用容器的这种使用，在数据中心中为它们提供更好的容量规划，因为它们现在将受到更少的限制，因为服务和它们运行的硬件之间存在抽象。

场景9：

考虑一种情况，公司希望向具有各种环境的客户提供所有必需的分发。

您认为他们如何以动态的方式实现这一关键目标？

解：

该公司可以使用Docker环境，组建一个横截面团队，使用Kubernetes构建Web应用程序。这种框架将帮助公司实现在最短的时间内将所需产品投入生产的目标。因此，在这样的机器运行的情况下，公司可以向所有具有各种环境的客户发放电子邮件。

场景10：

假设公司希望在不同的云基础架构上运行各种工作负载，从裸机到公共云。

公司将如何在不同界面的存在下实现这一目标？

解：

该公司可以将其基础设施分解为微服务，然后采用Kubernetes。这将使公司在不同的云基础架构上运行各种工作负载。

四 真实场景面试题总结

1、deployment创建pod流程？

1）、kubectl提交创建pod命令,api响应命令,通过一系列认证授权,把pod数据存储到etcd,创建deployment资源并初始化.

2）、controller通过list-watch机制,监测发现新的deployment,将该资源加入到内部工作队列,发现该资源没有关联的pod和replicaset,启用deployment controller创建replicaset资源,再启用replicaset controller创建pod.

3）、所有controller正常后.将deployment,replicaset,pod资源更新存储到etcd.

4）、scheduler通过list-watch机制,监测发现新的pod,经过主机过滤主机打分规则,将pod绑定(binding)到合适的主机.

5）、将绑定结果存储到etcd                   
6）、kubelet每隔 20s(可以自定义)向kube-apiserver通过NodeName 获取自身Node上所要运行的pod清单.通过与自己的内部缓存进行比较,新增加pod.

7）、启动pod启动容器.

2、你知道HPA吗？HPA有什么缺点？

hpa 是k8s 的自动扩缩容策略。v1 版可支持基于cpu 的扩缩容，v2 版可支持基于 cpu、内存、自定义指标的扩容。默认情况下，pod 是一台台扩容的，所以类似于 微博热搜之类的 突然间 访问量剧增的情况下就显有些无力。所以需要修改k8s 的调度规则。如果波动量比较大的服务容易造成业务抖动。主要是很被动，无法进行提前被容。HPA可针对cpu和内存自定义参数弹性扩容，有5分钟的安全时间，不适合访问量波动大的业务。

3、蓝绿发布和灰度发布k8s怎么实现的？

蓝绿发布通过deployment部署pod，改变service或者ingress切换流量可以实现

灰度发布通过Ingress Controller或者istio可以实现

4、如果一个pod创建过程中一直处于pending状态，你的处理思路是什么？

1）通过describe查看pod详细信息

2）通过logs查看pod日志

通过详细信息和日志基本就可以把问题定位出来了

5、k8s如何实现持久化存储？有几种方式?

emptyDir.hostPath.pv.

storageclass.ceph.nfs.

gluster等都可以实现k8s数据持久化，也可以通过storageclass动态的从nfs provisioner或者ceph provisioner等供应商动态的划分存储做成pv

6、service的type类型有几种？

ClusterIp：集群内部相关访问

NodePort：可以在物理机映射端口

ExternalName：可以对service做软连接

LoadBalancer：使用的是云的slb

7、ceph架构是什么？

Ceph是统一存储系统，支持三种接口：

1）、Object：有原生的API，而且也兼容Swift和S3的API

2）、Block：支持精简配置、快照、克隆

3）、File：Posix接口，支持快照

Ceph也是分布式存储系统，它的特点是：

高扩展性：使用普通x86服务器，支持10~1000台服务器，支持TB到PB级的扩展。

高可靠性：没有单点故障，多数据副本，自动管理，自动修复。

高性能：数据分布均衡，并行化度高。对于objects storage和block storage,不需要元数据服务器。

8、k8s怎么对接ceph？

把ceph rbd或者cephfs做成pv

Storageclass可以动态从ceph provisioner找到ceph，然后生成pv

9、k8s挂载cephfs和ceph rbd适用场景分析

K8s挂载cephfs可以支持跨node节点pod挂载

K8s挂载ceph rbd不支持跨node节点pod挂载

10、k8s有几种探测方式，分别描述下具体作用？

livenessProbe：存活性探测

许多应用程序经过长时间运行，最终过渡到无法运行的状态，除了重启，无法恢复。通常情况下，K8S会发现应用程序已经终止，然后重启应用程序pod。有时应用程序可能因为某些原因（后端服务故障等）导致暂时无法对外提供服务，但应用软件没有终止，导致K8S无法隔离有故障的pod，调用者可能会访问到有故障的pod，导致业务不稳定。K8S提供livenessProbe来检测容器是否正常运行，并且对相应状况进行相应的补救措施。 

readinessProbe：就绪性探测

在没有配置readinessProbe的资源对象中，pod中的容器启动完成后，就认为pod中的应用程序可以对外提供服务，该pod就会加入相对应的service，对外提供服务。但有时一些应用程序启动后，需要较长时间的加载才能对外服务，如果这时对外提供服务，执行结果必然无法达到预期效果，影响用户体验。比如使用tomcat的应用程序来说，并不是简单地说tomcat启动成功就可以对外提供服务的，还需要等待spring容器初始化，数据库连接上等等。

startupProbe: 探测容器中的应用是否已经启动。如果提供了启动探测(startup probe)，则禁用所有其他探测，直到它成功为止。如果启动探测失败，kubelet 将杀死容器，容器服从其重启策略进行重启。如果容器没有提供启动探测，则默认状态为成功Success。

11、 k8s 的 service 与 Ingress 区别

Service是四层代理，只能基于ip和端口代理后端服务

Ingress controller是七层代理，可以通过http或者https的域名基于cookie、地域、请求头、百分比进行代理转发。

Ingress controller代理需要找到对应的Service，由Service向后代理Pod

12、说几个 k8s 的网络插件，说一下他们的差异

flannel：支持地址分配，不支持网络策略 

calico：支持地址分配，支持网络策略。

flannel：

vxlan：#扩展的虚拟局域网

V虚拟的

X扩展的

lan局域网

flannel支持多种后端：

 1、VxLAN：  

(1) vxlan 叠加网络模式

(2) Directrouting

2、host-gw: Host Gateway

#直接路由模式，不推荐，只能在二层网络中，不支持跨网络，如果有成千上万的Pod，容易产生广播风暴

3、UDP：一般不用这个模式，性能差

flannel方案： 需要在每个节点上把发向容器的数据包进行封装后，再用隧道将封装后的数据包发送到运行着目标Pod的node节点上。目标node节点再负责去掉封装，将去除封装的数据包发送到目标Pod上。数据通信性能则大受影响

calico方案：在k8s多个网路解决方案中选择了延迟表现最好的-calico方案

五 学员经典面试题总结

1、请问你做过什么项目?

第一个项目：搭建DevOps流水线

规划阶段：

1.调研DevOps工具链中需要的具体技术，找到最佳实践方案；

2.制定项目完成周期和可实现的目标；

3.项目人员和成本规划

实施阶段：

需要部署的具体服务： jenkins，gitlab，harbor，docker，nexus，sonarqube，kubernetes，tomcat，maven，python，java

测试阶段：

上述服务部署调通之后开始测试，测试通过之后交付到项目组

后期维护管理：

交付成功之后，负责维护和管理，以及日常上线操作

第二个项目：基于Kubernetes的自动化平台建设

1.需求沟通

2.技术选型

3.Kubernetes平台架构设计

4.Prometheus+EFK监控日志系统设计

5.Jenkins CI/CD流设计，推动团队完成自动化平台的建设

2、请问你在做项目的过程中遇到什么问题?是怎么解决的?

第一个问题：

pod调度不到机器上。经排查是时间不同步，etcd注册信息混乱，对etcd数据做了还原，另外公司每天自动备份etcd  数据，防止etcd出现问题，能及时恢复

第二个问题：

Pod状态异常：一直处于pending状态

排查思路： 

物理节点层面分析：

查看节点资源使用情况:如free -m查看内存、top查看CPU使用率、df - h查看磁盘使用情况，这样就可以快速定位节点资源情况，判断是不是节点有问题

查看节点污点: kubectI describe nodes master1 (控制节点名字)，如果节点定义了污点，那么Pod不能容忍污点，就会导致调度失败，如下:

Taints:node-role. kubernetes. io/master :NoSchedule

这个看到的是控制节点的污点，表示不允许Pod调度(如果Pod定义容忍度，则可以实现调度)

Pod本身分析：

在定义pod时， 如果指定了nodeName是不存在的， 那也会调度失败

在定义Pod时，如果定义的资源请求比较大，导致物理节点资源不够也是不会调度的

3、对于k8s对接存储，你了解多少? 

详细问题：可以对接那些储存? PV和PVC之间的区别是什么?可以通过几种方式创建PVC? 你对供应商了解多少?

首先，k8s中的pod 是有生命周期的，如果pod 被删除那么pod 内存储的数据也一并被删除了，也就是说我们的pod 有可能在任意时间死在任意节点上，所以我们需要使用外部存储的方式将数据或者配置永久的存储下来。

K8s 中常用存储有

emptyDir.hostPath.nfs

perstentVolumeClaim.glusterfs

cephfs.configMap.cecret。

emptyDir:是在本机的

/var/lib/volumes/kubelet/pods 下创建一个随机目录，用于存放数据，pod删除，目录删除，达不到数据永久存储的目的

hostPath：将目录挂载的宿主机上的指定目录，pod 删除数据不会被删除，只要下一个pod 依旧调度到这台物理机上，还能访问原pod 数据。

 nfs：nfs 可以解决 hostPath的后面pod 必须调度到同一宿主机的问题。但是nfs会存在单点故障。

PVC 是有用户进行的存储的请求，类似于 pod 会消耗集群的资源。Pv 属于集群级别的资源，不属于任何的命名空间，而pvc 数据命名空间别的资源，我们真正使用的时候是使用的 PVC，就类似于我们的服务是通过 Pod 来运行的，而不是 Node，只是 Pod 跑在 Node 上而已。

创建pvc 的时候我们可以使用动态和静态的方式进行创建，动态创建pvc 的时候，向存储类申请指定容量的PV，存储类再去找到对应的供应商申请创建PV.

供应商有

nfs-provisioner和rbd-provisioner，这些是外部供应商，需要额外安装组件才可以用于Storageclass动态生成pv

4、请您详细描述下创建一个pod,能定义那些字段?

创建pod 的时候我们可经常定义字段有 ：

netadata 字段里可以定义：

name(pod 名称)、labels(pod 的标签)、namespace(s[pod 需要调度的名称空间)；

spec 字段常用定义： affinity(亲和性) ：其中又分为 节点亲和性和pod 亲和性；下面又分为 软亲和性和硬亲和性。

containers(pod 内封装容器的各项信息)：其中主要定义，容器名字、容器镜像、容器端口、容器镜像拉取策略、资源限制、容器挂载内容发、生命周期、存活性探测和就绪性探测。

Volumes (定义容器是挂载到本地还是网络存储以及信息)

Tolerations(容忍度)

serviceAccount  (sa账号信息)

restartPolicy (重启策略)

nodeSelector (通过标签选择器选择node)

nodeName  (通过 node名字选择pod 调度node)  

5、针对devOps,说说你的看法?你了解多少?

Devops可以实现打通开发和运维壁垒 实现开发运维一体化。

整个流程包括 

敏捷开发 -–> 持续集成 -–> 继续交付 -–> 持续部署。

可通过

jenkins+gitlab+sonarqube+maven+nexus+harbor+k8sbr

实现一套完整的 devops 系统，开发提交代码到 github --à jenkins 检测到代码更新 --à 调用 api 在k8s 中创建 

jenkins slave pod --à jenkins slave 

拉取代码 --通过 maven 把拉取的代码进行构建成 war 包或者jar 包， -- 上传代码到 sonarqube 进行代码扫描 --基于 war 包构建 docker image  --把镜像上传到 harbor 仓库 --基于镜像部署到应用开发环境 --  部署应用到测试环境 --部署应用到生产环境。

微海报分享
上一篇 MongoDB企业级分片集群搭建与容灾 MongoDB故障自动切换+备份恢复+配置指南 带资料
下一篇 pod探针与pod探针的检测方式

相关文章

发表评论

后才能评论