目录

一、杭州金柚网

1.1 一面（技术面）2023-02-27

1.1.1 k8s 中 CoreDNS 的工作原理是什么？

1.1.2 k8s 中 ingress controller 和 ingress 的工作原理是什么？

1.1.3 对 k8s 中的 networkpolicy 了降多少

1.1.4 Centos 7 的开机启动顺序

1.1.5 测试 shell 脚本的命令

1.1.6 在 shell 脚本中，常用函数如何导出

1.1.7 MySQL 的事务等级

1.1.8 在 MySQL 中有一张无限大的表，现需要添加一个字段，如何优化或者提高效率

1.1.9 物理防火墙和 LInux 中的 iptables 分别属于七层 OSI 模型的哪一层

1.1.10 服务器中有哪些设备支持热插拔

1.1.11 Prometheus 的解决方案有哪些

1.1.12 在 Prometheus 中，如何监控（未知）中间件或者 pod 数据

1.1.13 在 ELK 中，Logstash 常用插件有哪些

1.1.14 假如有两个日志文件，一个 nginx 日志文件，一个 Linux 系统日志文件，ELK 如何将这两种日志文件的某一个字段以相同的形式输出

---

一、杭州金柚网

1.1 一面（技术面）2023-02-27

1.1.1 k8s 中 CoreDNS 的工作原理是什么？

        CoreDNS 是一个开源的 DNS 服务器，是 Kubernetes 集群中默认的 DNS 服务器，用于实现 Kubernetes 中的服务发现和 DNS 解析功能。其工作原理如下：

1. CoreDNS 在 Kubernetes 集群中以 Deployment 的形式运行，每个节点都会有一个 Pod 运行 CoreDNS。

2. 当容器需要解析服务名称时，它会向节点上的 DNS 解析器发送 DNS 查询请求。

3. DNS 解析器首先会向 CoreDNS 发送 DNS 查询请求，查询请求包含了所需服务的名称和命名空间。

4. CoreDNS 接收到查询请求后，会根据查询请求中的服务名称和命名空间，查找对应的 Kubernetes Service，并返回该 Service 的 Cluster IP 地址列表。

5. DNS 解析器收到 CoreDNS 返回的 Cluster IP 地址列表后，将其中的一个 IP 地址返回给容器。

6. 容器使用返回的 Cluster IP 地址访问该服务。

        需要注意的是，Kubernetes 集群中的 CoreDNS 还支持其他功能，如为 Pod 分配域名、解析外部域名等。这些功能都是通过 CoreDNS 的插件来实现的，可以根据需要进行配置和启用。

1.1.2 k8s 中 ingress controller 和 ingress 的工作原理是什么？

        Ingress 是 Kubernetes 中用于管理 HTTP 和 HTTPS 流量的 API 对象，它定义了一组规则来路由请求到不同的后端服务，可以看作是一种反向代理的实现方式。而 Ingress Controller 则是实现这些规则的控制器，负责将 Ingress 规则转化为实际的负载均衡和路由配置。

Ingress Controller 的工作原理如下：

1. 用户通过 Kubernetes API 创建 Ingress 资源，并指定需要暴露的服务和路由规则。

2. Ingress Controller 监听 Kubernetes API 中的 Ingress 资源，当有新的 Ingress 资源创建时，Ingress Controller 会根据该资源的规则配置生成相应的负载均衡和路由规则。

3. Ingress Controller 根据配置生成负载均衡和路由规则，并将其应用到实际的负载均衡设备（如 Nginx、HAProxy 等）上。

4. 当请求到达负载均衡设备时，根据配置的路由规则将请求转发到相应的后端服务。

        需要注意的是，Ingress Controller 可以通过不同的方式实现，如 Nginx Ingress Controller、Traefik Ingress Controller 等，不同的实现方式会有不同的负载均衡和路由配置方式。同时，Ingress 的规则配置也可以通过不同的 Ingress Controller 实现方式来进行扩展和定制。

1.1.3 对 k8s 中的 networkpolicy 了降多少

        在 Kubernetes 中，网络策略（NetworkPolicy）是一个用于定义和控制 Pod 网络通信的资源对象。网络策略可以让你定义规则，限制哪些 Pod 能够与其他 Pod 通信，以及哪些 Pod 可以被其他 Pod 访问。

        网络策略通过定义网络流量的源和目的 IP 地址、协议和端口等规则来限制 Pod 之间的通信。这样可以增加集群的安全性，防止未经授权的访问和攻击。

        网络策略是一个非常强大的功能，但同时也比较复杂。使用网络策略需要了解网络拓扑、Pod 标签、IP 地址和端口等概念，并且需要注意网络策略对应用程序的影响。因此，在实际应用中，需要谨慎使用网络策略，并根据实际情况进行配置和调整。

1.1.4 Centos 7 的开机启动顺序

CentOS 7 的开机启动顺序如下：

1. BIOS/UEFI：计算机开机时首先会运行 BIOS/UEFI，执行 POST（电源自检），并加载操作系统引导程序。

2. GRUB：GRUB 是 CentOS 7 中默认的操作系统引导程序，它会从硬盘加载操作系统内核和初始内存文件系统（initramfs）。

3. Systemd：CentOS 7 中使用 Systemd 作为系统初始化和管理的主要工具，它负责启动和管理系统服务和进程。Systemd 会读取 /etc/systemd/system 目录下的启动单元（Unit）配置文件，并按照配置的顺序启动系统服务。

4. SysV init：为了兼容旧的 SysV init 系统启动脚本，Systemd 也会读取 /etc/init.d 目录下的启动脚本，并按照指定的顺序运行。

5. Login Manager：当系统启动完成后，Login Manager（如 GDM、KDM 等）会启动，用户可以登录到图形界面或终端界面。

        需要注意的是，CentOS 7 中的启动顺序可以通过修改 Systemd 配置文件进行调整，也可以通过在启动单元配置文件中设置依赖关系来控制服务启动顺序。同时，CentOS 7 也支持使用其他的操作系统引导程序和启动管理工具来替代默认的 GRUB 和 Systemd。

1.1.5 测试 shell 脚本的命令

以下是一些测试 shell 脚本时可以使用的命令：

1. bash -n script.sh：检查脚本是否存在语法错误。

2. bash -x script.sh：在运行脚本时，输出每个命令执行的详细信息，以便于调试脚本。

3. bash -e script.sh：在脚本中发生错误时，立即停止脚本的执行。

4. shellcheck script.sh：使用 ShellCheck 工具对脚本进行静态分析，检查是否存在语法错误和不安全的代码。

5. test 命令：可以用来检查脚本的输出是否符合预期，如 test "$(./script.sh)" = "expected_output"。

6. curl 命令：可以用来模拟 HTTP 请求，测试脚本在接收 HTTP 请求时的表现和结果。

7. socat 命令：可以用来模拟网络连接，测试脚本在网络通信时的表现和结果。

8. timeout 命令：可以用来限制脚本的执行时间，以防止脚本无限循环等问题。

        除了以上命令外，还可以使用一些 shell 测试框架如 bash_unit、shUnit2 等，或者一些自动化测试框架如 Selenium 等来辅助进行测试。

1.1.6 在 shell 脚本中，常用函数如何导出

在 shell 脚本中，可以使用以下方式导出常用函数：

• 使用 source 命令加载一个包含常用函数的外部 shell 脚本。例如，在 myfuncs.sh 中定义了一些常用函数，可以在另一个脚本中使用以下命令导入：

source myfuncs.sh

然后就可以在当前脚本中使用 myfuncs.sh 中定义的函数了。

• 直接将常用函数定义在当前脚本中，然后使用 export 命令导出函数。例如，在当前脚本中定义了一个名为 myfunc 的函数，可以使用以下命令导出：

export -f myfunc

然后就可以在当前脚本之外的地方使用 myfunc 函数了。

        需要注意的是，导出函数的前提是这些函数是全局函数，而不是局部函数。另外，导出函数也需要遵循 shell 函数的定义方式，如使用 function 关键字声明函数、使用小括号传递参数等。

1.1.7 MySQL 的事务等级

        在 MySQL 中，事务（transaction）是由一系列的 SQL 语句组成的逻辑操作单元，用于保证数据的一致性、完整性和可靠性。MySQL 支持四个不同的事务隔离级别，它们分别是：

1. READ UNCOMMITTED（读未提交）：在该隔离级别下，一个事务可以读取另一个事务未提交的数据。这样可能导致脏读、不可重复读和幻读问题。

2. READ COMMITTED（读已提交）：在该隔离级别下，一个事务只能读取另一个事务已经提交的数据。这样可以避免脏读问题，但仍可能出现不可重复读和幻读问题。

3. REPEATABLE READ（可重复读）：在该隔离级别下，一个事务在执行期间多次读取同一数据，其结果总是相同的。这样可以避免脏读和不可重复读问题，但仍可能出现幻读问题。

4. SERIALIZABLE（串行化）：在该隔离级别下，所有事务按照顺序执行，相当于是把所有事务变成串行执行。这种隔离级别可以避免所有类型的并发问题，但会导致性能下降。

        MySQL 默认的事务隔离级别是 REPEATABLE READ，可以通过 SET TRANSACTION ISOLATION LEVEL 语句来修改事务隔离级别。同时，MySQL 还支持通过锁定来实现事务隔离，例如通过 SELECT ... FOR UPDATE 和 SELECT ... LOCK IN SHARE MODE 语句来锁定数据。

1.1.8 在 MySQL 中有一张无限大的表，现需要添加一个字段，如何优化或者提高效率

        在 MySQL 中添加字段可以使用 ALTER TABLE 语句，但是在一张无限大的表上执行 ALTER TABLE 操作可能会非常耗时和占用系统资源，因此需要进行一些优化：

1. 尽可能的减少表的锁定时间：添加字段操作会锁定表，导致其他查询和操作无法执行，因此可以选择在低峰期执行添加字段操作，以减少锁定时间，从而避免对业务造成影响。如果无法确定低峰期，可以尝试使用在线添加字段的方式，比如使用 ALGORITHM=INPLACE 选项，这样可以避免锁定表的操作，减少锁定时间。

2. 将表拆分成多个小表：如果一张表的数据量过大，可以将表拆分成多个小表，然后对每个小表进行添加字段的操作，从而将单个操作的数据量减小到可控范围内。这样可以减少添加字段操作的时间和系统资源的占用。

3. 使用批量添加字段的方式：可以通过多个添加字段的操作批量添加字段，从而减少单个添加字段的时间和系统资源的占用。可以使用 ALTER TABLE ADD COLUMN 的语法进行批量添加字段操作。

4. 选择合适的存储引擎：不同的存储引擎在添加字段时的性能表现不同。比如，MyISAM 存储引擎支持动态列，可以在不改变表结构的情况下添加字段，从而提高添加字段的效率。InnoDB 存储引擎添加字段时需要复制整个表并重建索引，因此在表数据量大的情况下可能会很慢。

5. 增加硬件资源：在添加字段操作时可以增加硬件资源，比如增加 CPU 和内存的数量，或者使用更快的硬盘等。这样可以提高添加字段操作的效率。

        需要注意的是，在进行添加字段操作时需要做好数据备份，以防操作失败或者出现数据丢失等问题。同时，添加字段操作可能会影响其他查询和操作的性能，需要谨慎执行。

1.1.9 物理防火墙和 LInux 中的 iptables 分别属于七层 OSI 模型的哪一层

        物理防火墙的工作原理属于七层 OSI 模型的第一层，即物理层。物理防火墙是通过过滤和限制物理信号，阻止非法的网络流量进入受保护的网络。在这个过程中，物理防火墙不会检查或处理网络数据包的内容，而是专门负责过滤和限制物理信号的传输。

        Linux 中的 iptables 工作原理属于七层 OSI 模型的第三层，即网络层。iptables 是 Linux 中用于管理网络数据包的工具，它通过过滤、转发、修改数据包的目的地址和源地址等信息，来实现网络安全和网络流量控制等功能。这些操作都发生在网络层，因此 iptables 属于 OSI 模型中的网络层。

1.1.10 服务器中有哪些设备支持热插拔

        热插拔（Hot Swap）是指在不关闭电源的情况下，对设备进行拆卸或更换的过程。服务器中的热插拔通常指可以在服务器运行的情况下，将某些硬件设备（如硬盘、电源、风扇、CPU 等）从服务器中拔出或更换新的设备，而不需要关闭服务器或重启操作系统。

服务器中支持热插拔的设备通常包括：

1. 硬盘（Hot Swap Hard Disk Drive）：支持热插拔的硬盘可以在服务器运行时被插入或拔出，而不会影响服务器的正常运行。

2. 电源（Hot Swap Power Supply）：支持热插拔的电源可以在服务器运行时被更换，而不需要关闭服务器或重启操作系统。

3. 风扇（Hot Swap Fan）：支持热插拔的风扇可以在服务器运行时被更换，而不需要关闭服务器或重启操作系统。

4. 内存（Hot Swap Memory）：支持热插拔的内存可以在服务器运行时被插入或拔出，而不会影响服务器的正常运行。

5. CPU（Hot Swap CPU）：支持热插拔的 CPU 可以在服务器运行时被更换，而不需要关闭服务器或重启操作系统。

6. 扩展卡（Hot Swap Expansion Card）：支持热插拔的扩展卡可以在服务器运行时被插入或拔出，而不会影响服务器的正常运行。

        需要注意的是，不是所有的设备都支持热插拔，只有支持热插拔的设备才能够在服务器运行的情况下进行拆卸或更换。同时，在进行热插拔操作时需要注意操作规范和注意事项，以免影响设备的正常运行和数据的安全性。

1.1.11 Prometheus 的解决方案有哪些

        Prometheus 是一款开源的监控系统，它提供了广泛的监控能力，支持多种数据采集方式和灵活的数据查询方式，是目前最为流行的监控系统之一。下面介绍一些常见的 Prometheus 的解决方案：

1. 数据采集方案：Prometheus 支持多种数据采集方式，包括主动拉取和被动推送两种方式。其中，主动拉取是指 Prometheus 定时向被监控的目标发起请求，获取数据；被动推送是指被监控的目标将数据推送到 Prometheus 的数据接收端口。常见的数据采集方案有：Prometheus 客户端库、Exporter、Pushgateway 等。

2. 数据存储方案：Prometheus 采用本地存储方式，将采集的数据存储在本地的时间序列数据库中。为了提高可靠性和扩展性，可以使用分布式存储方案，如 Thanos、Cortex、VictoriaMetrics 等。

3. 数据查询方案：Prometheus 提供了灵活的数据查询方式，可以使用 PromQL 查询语言查询数据，还可以通过 Grafana 等可视化工具进行数据展示和查询。为了提高查询效率和支持更多的查询方式，可以使用存储索引方案，如 M3、TimescaleDB 等。

4. 监控告警方案：Prometheus 支持监控告警，可以设置阈值和告警规则，一旦发现异常情况会触发告警，通知相关人员。可以使用 Alertmanager 等告警管理工具进行告警通知的发送和管理。

5. 高可用方案：为了提高可用性和可靠性，可以使用多节点部署方案，如集群模式、分布式模式等，还可以使用数据复制和负载均衡方案，如 Thanos、HAProxy 等。

        总的来说，Prometheus 提供了丰富的监控能力和灵活的配置选项，可以根据不同的需求和场景进行定制化的解决方案。需要根据实际情况进行选择和调整，以达到最佳的监控效果。

1.1.12 在 Prometheus 中，如何监控（未知）中间件或者 pod 数据

在 Prometheus 中，可以通过以下方式监控中间件或者 Pod 的数据：

1. 使用已有的 Exporter：Prometheus 社区已经开发了许多 Exporter，可以用于监控各种中间件或者 Pod。例如，可以使用 Prometheus MySQL Exporter 监控 MySQL 数据库，使用 Prometheus Node Exporter 监控系统资源等。可以在 Prometheus 官方网站上查找更多 Exporter：Exporters and integrations | Prometheus

2. 自定义 Exporter：如果没有现成的 Exporter 可以使用，也可以自己编写一个 Exporter，用于将中间件或者 Pod 的指标暴露给 Prometheus。Prometheus 社区提供了一个基础库，可以用于编写 Exporter：GitHub - prometheus/client_python: Prometheus instrumentation library for Python applications

3. 使用 Service Discovery：如果使用的是 Kubernetes 等容器编排工具，可以使用 Service Discovery 机制自动发现并监控 Pod。可以使用 Kubernetes 的 Service Discovery，也可以使用 Prometheus 自带的 Service Discovery 功能。关于 Service Discovery 的详细信息，可以参考官方文档：Configuration | Prometheus

        无论使用哪种方式，需要在 Prometheus 的配置文件中添加相应的配置，以便 Prometheus 可以从 Exporter 或者 Service Discovery 中获取数据。然后，就可以使用 Prometheus 的查询语言 PromQL 对数据进行查询和分析了。 

        如果没有现成的 Exporter 可以使用，也没有办法自定义 Exporter，可以考虑以下几种方式监控未知的中间件或者 Pod 数据：

1. 使用 Blackbox Exporter：Blackbox Exporter 可以用于监控网络服务，例如 HTTP、TCP 等。可以使用该 Exporter 对中间件或者 Pod 进行网络探测，获取相关的指标数据。关于 Blackbox Exporter 的详细信息，可以参考官方文档：GitHub - prometheus/blackbox_exporter: Blackbox prober exporter

2. 使用 Pushgateway：Pushgateway 是一个中间件，可以用于将临时数据推送到 Prometheus 中。如果无法使用 Exporter 监控中间件或者 Pod，可以使用脚本定期将数据推送到 Pushgateway，然后使用 Prometheus 进行查询和分析。关于 Pushgateway 的详细信息，可以参考官方文档：GitHub - prometheus/pushgateway: Push acceptor for ephemeral and batch jobs.

3. 使用 SNMP Exporter：如果中间件或者 Pod 支持 SNMP 协议，可以使用 SNMP Exporter 进行监控。SNMP Exporter 可以将 SNMP 数据转换为 Prometheus 格式，并暴露给 Prometheus。关于 SNMP Exporter 的详细信息，可以参考官方文档：GitHub - prometheus/snmp_exporter: SNMP Exporter for Prometheus

        需要注意的是，这些方式都只是一些常用的方法，具体应该根据实际情况选择合适的方式进行监控。如果以上方式都无法满足需求，也可以考虑其他自定义的方法，例如使用脚本、自定义 Exporter 等。

1.1.13 在 ELK 中，Logstash 常用插件有哪些

        Logstash 是一个流行的开源数据处理引擎，可以将来自不同数据源的数据集中到一个地方，并对其进行处理、过滤和转换。以下是 Logstash 常用的一些插件：

1. Input 插件：负责接收来自不同来源的数据，包括 file、beats、syslog、http 等。

2. Filter 插件：用于对数据进行处理和转换，例如 grok、mutate、date、json 等。

3. Output 插件：负责将经过处理的数据发送到指定的目标，例如 Elasticsearch、Kafka、stdout、s3 等。

4. Codec 插件：用于对数据进行编解码，例如 plain、json、avro、msgpack 等。

5. Code 插件：可以自定义插件，实现特定的数据处理需求。

6. Third-party 插件：例如 logstash-input-jdbc、logstash-output-kinesis 等，可以通过插件方式集成 Logstash 和其他系统或者服务。

        需要注意的是，Logstash 支持大量的插件，具体使用哪些插件应该根据实际需求进行选择。在使用 Logstash 进行数据处理时，应该仔细查看官方文档，并根据实际情况进行配置和调优。

1.1.14 假如有两个日志文件，一个 nginx 日志文件，一个 Linux 系统日志文件，ELK 如何将这两种日志文件的某一个字段以相同的形式输出

可以通过 Logstash 的 filter 插件对两个不同的日志文件进行解析和过滤，提取出需要的字段，然后输出到 Elasticsearch 中。

具体步骤如下：

1. 配置 Logstash 的 input 插件，分别读取 nginx 日志和 Linux 系统日志文件。

2. 使用 grok filter 插件对两个日志文件进行解析，提取出需要的字段，例如时间、IP、URL 等等。

3. 使用 mutate filter 插件将不同的字段名转换成相同的名称，例如将 nginx 日志中的 "clientip" 字段重命名为 "ip"。

4. 使用 Elasticsearch output 插件将经过处理的日志数据输出到 Elasticsearch 中。

下面是一个简单的示例配置：

input {file {path => "/var/log/nginx/access.log"}file {path => "/var/log/messages"}
}filter {if [path] =~ "nginx" {grok {match => { "message" => "%{COMBINEDAPACHELOG}" }}mutate {rename => { "clientip" => "ip" }}} else if [path] =~ "messages" {grok {match => { "message" => "%{SYSLOGTIMESTAMP:syslog_timestamp} %{SYSLOGHOST:syslog_hostname} %{DATA:syslog_program}(?:\[%{POSINT:syslog_pid}\])?: %{GREEDYDATA:syslog_message}" }}mutate {rename => { "syslog_hostname" => "host" }}}
}output {elasticsearch {hosts => ["localhost:9200"]index => "logs-%{+YYYY.MM.dd}"}
}

        在这个示例中，我们使用了两个 file input 插件，分别读取 nginx 和系统日志文件。然后使用 grok filter 插件对两个日志文件进行解析和提取字段。接着使用 mutate filter 插件将不同的字段名转换成相同的名称。最后使用 Elasticsearch output 插件将处理后的日志数据输出到 Elasticsearch 中，可以使用 Kibana 来进行可视化展示和查询。

        需要注意的是，实际应用中的配置可能会更加复杂和细致，需要根据实际需求进行调整和优化。此外，如果日志数据量较大，还需要考虑数据存储和查询的性能问题。