11. 打印一个目录下所有包含字符串 A 的行

例如/目录grep -rn "A" ./ 或find ./ -name "*.*" | xargs grep  "A"

例如 a 进程 ps -ef | grep "^a" | grep -v grep | cut -c 9-15 | xargs kill -9 或ps x | grep a | grep -v grep | awk '{print $1}' | xargs kill -9

Linux 服务管理两种方式 service 和 systemctl

systemd 是 Linux 系统最新的初始化系统(init),作用是提高系统的启动速度，尽可能启动较少的进程，尽可能更多进程并发启动。

systemd 对应的进程管理命令是 systemctl

systemctl 命令兼容了 service, systemctl 命令管理 systemd 的资源 Unit

14. 谈下对 IPtables 的了解

iptables 其实不是真正的防火墙，我们可以把它理解成一个客户端代理，用户通过 iptables 这个代理，将用户的安全设定执行到对应的"安全框架"中，这个"安全框架"才是真正的防火墙，这个框架的名字叫 netfilter iptables 其实是一个命令行工具，位于用户空间，我们用这个工具操作真正的框架。

所以说，虽然我们使用 service iptables start 启动 iptables"服务"，但是其实准确的来说，iptables 并没有一个守护进程，所以并不能算是真正意义上的服务，而应该算是内核提供的功能。

iptables 有 4 表 5 链：

•filter 表——过滤数据包•Nat 表——用于网络地址转换（IP、端口）•Mangle 表——修改数据包的服务类型、TTL、并且可以配置路由实现 QOS•Raw 表——决定数据包是否被状态跟踪机制处理•INPUT 链——进来的数据包应用此规则链中的策略•OUTPUT 链——外出的数据包应用此规则链中的策略•FORWARD 链——转发数据包时应用此规则链中的策略•PREROUTING 链——对数据包作路由选择前应用此链中的规则（所有的数据包进来的时侯都先由这个链处理）•POSTROUTING 链——对数据包作路由选择后应用此链中的规则（所有的数据包出来的时侯都先由这个链处理）

15. 给做好的镜像添加一个文件

用 UltraISO PE (光软碟通)软件打开 iso 镜像文件就可以填加了

16. 页面无法访问排查思路场景一：无错误状态码 无错误状态码，多数情况下是“ERRCONNECTIONTIMED_OUT”问题。

出现 ERR_CONNECTION_TIMED_OUT错误原因，可以总结为以下 5 点：

•服务器带宽跑满、存在***•若是云服务器可能存在账号处于欠费状态•服务没有启动•端口没有正常监听•防火墙或者防火墙策略限制 排查思路说明：•使用命令 telnet IP Port 进行测试•如果端口是通的，则排查 查看服务器带宽是否跑满、是否有*** 是否使用的账号处于欠费状态•如果端口不通，则排查：•web 服务没有正常启动•端口没有正常监听•防火墙/安全组拦截•若是 web 服务没有正常启动，需要启动服务•若是端口没有正常监听，需要修改配置文件 = 若是防火墙拦截，需要关闭防火墙进行测试，或者找到相关限制规则进行修改。

场景二：网站访问异常代码 4XX。

排查思路：

•通过查看其配置文件，并检测其配置文件语法，发现语法正常；•通过命令行查看其 web 服务端口运行正常，没有进程僵尸状况；•具体读配置文件，然后再查找客户客户配置文件所指定的具体目录；•例如：网站数据目录等（本案例是客户机器迁移之后，由于阿里磁盘的特性导致盘符改变，客户的数据盘挂载不上，etcfstab 和盘符不匹配）

问题定位到之后，重新以正确的方式挂载客户网站数据；重启服务，问题得以圆满解决；

基于类似问题还可以关注下目录权限等问题。

经验汇总：

针对网站访问报错问题几点排查建议：

•服务器配置文件权限，以及语法的正确性；•配置文件中指定的网站相关目录存在问题，及相关权限问题；•运行 web 服务的用户和相关权限问题；•防火墙的设置问题，导致服务不可达；•服务器服务进程僵死问题；•配置文件中的非法字符问题；（特别是从 windows 平台直接 cp 过来的配置文件容易报错）这样的问题较难排查，可以通过 type 命令或者 file 命令查看文件类型；最好是二进制格式或者 ascii 码，linux 平台可以安装 dos2unix 解决；•服务器的错误日志亦是非常关键的问题突破口；

案例：报错“404 Not Found”

问题原因：

404 报错的具体原因是访问的路径 url 目录在服务上没有找到，如果直接使用 ip 或者域名访问，那么实际访问的页面是站点根目录下的默认文件（配置文件中 index 后指定的文件），如果服务器上站点根目录上没有这个文件，则会出现 404 错误。

排查步骤：

•测试环境：Nginx 环境•站点跟目录/www/下没有默认 index.html 文件，访问 ip/inde.html,会报 Not Found 错误。

备注：Apache 环境下，404 错误也是同样的原理进行排查。

17. k8s 中 service 什么含义，怎么用

Service 是一种抽象的对象，它定义了一组 Pod 的逻辑集合和一个用于访问它们的策略，一个 Serivce 下面包含的 Pod 集合一般是由 Label Selector 来决定的。假如我们后端运行了 3 个副本，这些副本都是可以替代的，因为前端并不关心它们使用的是哪一个后端服务。

尽管由于各种原因后端的 Pod 集合会发生变化，但是前端却不需要知道这些变化，也不需要自己用一个列表来记录这些后端的服务，Service 的这种抽象就可以帮我们达到这种解耦的目的。

service 为后端 pod 提供一组负载均衡代理

三种 IP：

•Node IP：Node 节点的 IP 地址•Pod IP：Pod 的 IP 地址•Cluster IP：Service 的 IP 地址

首先，Node IP 是 Kubernetes 集群中节点的物理网卡 IP 地址(一般为内网)，所有属于这个网络的服务器之间都可以直接通信，所以 Kubernetes 集群外要想访问 Kubernetes 集群内部的某个节点或者服务，肯定得通过 Node IP 进行通信（这个时候一般是通过外网 IP 了）

然后 Pod IP 是每个 Pod 的 IP 地址，它是 Docker Engine 根据 docker0 网桥的 IP 地址段进行分配的（我们这里使用的是 flannel 这种网络插件保证所有节点的 Pod IP 不会冲突）

最后 Cluster IP 是一个虚拟的 IP，仅仅作用于 Kubernetes Service 这个对象，由 Kubernetes 自己来进行管理和分配地址，当然我们也无法 ping 这个地址，他没有一个真正的实体对象来响应，他只能结合 Service Port 来组成一个可以通信的服务。

定义 Service

定义 Service 的方式和各种资源对象的方式类型一样，假定我们有一组 Pod 服务，它们对外暴露了 80 端口，同时都被打上了 app=myapp 这样的标签，那么我们就可以像下面这样来定义一个 Service 对象：

pod 示例：apiVersion: apps/v1kind: Deploymentmetadata:  name: testspec:  selector:    matchLabels:      app: myapp  replicas: 3  template:    metadata:      labels:        app: myapp    spec:      containers:      - name: nginx        image: nginx:1.7.9        ports:        - containerPort: 80service 基于 pod 的示例：apiVersion: v1kind: Servicemetadata:  name: myservicespec:  selector:    app: myapp  ports:  - protocol: TCP    port: 80    targetPort: 80

然后通过的使用 kubectl create -f myservice.yaml 就可以创建一个名为 myservice 的 Service 对象，它会将请求代理到使用 TCP 端口为 80，具有标签 app=myapp 的 Pod 上，这个 Service 会被系统分配一个我们上面说的 Cluster IP，该 Service 还会持续的监听 selector 下面的 Pod，会把这些 Pod 信息更新到一个名为 myservice 的 Endpoints 对象上去，这个对象就类似于我们上面说的 Pod 集合了。

需要注意的是，Service 能够将一个接收端口映射到任意的 targetPort。默认情况下，targetPort 将被设置为与 port 字段相同的值。可能更有趣的是，targetPort 可以是一个字符串，引用了 backend Pod 的一个端口的名称。因实际指派给该端口名称的端口号，在每个 backend Pod 中可能并不相同，所以对于部署和设计 Service ，这种方式会提供更大的灵活性。另外 Service 能够支持 TCP 和 UDP 协议，默认是 TCP 协议。

kube-proxy

在 Kubernetes 集群中，每个 Node 会运行一个 kube-proxy 进程, 负责为 Service 实现一种 VIP（虚拟 IP，就是我们上面说的 clusterIP）的代理形式，现在的 Kubernetes 中默认是使用的 iptables 这种模式来代理。这种模式，kube-proxy 会监视 Kubernetes master 对 Service 对象和 Endpoints 对象的添加和移除。

对每个 Service，它会添加上 iptables 规则，从而捕获到达该 Service 的 clusterIP（虚拟 IP）和端口的请求，进而将请求重定向到 Service 的一组 backend 中的某一个个上面。对于每个 Endpoints 对象，它也会安装 iptables 规则，这个规则会选择一个 backend Pod。

默认的策略是，随机选择一个 backend。我们也可以实现基于客户端 IP 的会话亲和性，可以将 service.spec.sessionAffinity 的值设置为 "ClientIP" （默认值为 "None"）。

另外需要了解的是如果最开始选择的 Pod 没有响应，iptables 代理能够自动地重试另一个 Pod，所以它需要依赖 readiness probes。

Service 类型

在定义 Service 的时候可以指定一个自己需要的类型的 Service，如果不指定的话默认是 ClusterIP 类型。

可以使用的服务类型如下：

•ClusterIP：通过集群的内部 IP 暴露服务，选择该值，服务只能够在集群内部可以访问，这也是默认的 ServiceType。•NodePort：通过每个 Node 节点上的 IP 和静态端口（NodePort）暴露服务。NodePort 服务会路由到 ClusterIP 服务，这个 ClusterIP 服务会自动创建。通过请求 :，可以从集群的外部访问一个 NodePort 服务。•LoadBalancer：使用云提供商的负载局衡器，可以向外部暴露服务。外部的负载均衡器可以路由到 NodePort 服务和 ClusterIP 服务，这个需要结合具体的云厂商进行操作。•ExternalName：通过返回 CNAME 和它的值，可以将服务映射到 externalName 字段的内容（例如， foo.bar.example.com）。没有任何类型代理被创建，这只有 Kubernetes 1.7 或更高版本的 kube-dns 才支持。

NodePort 类型

如果设置 type 的值为 "NodePort"，Kubernetes master 将从给定的配置范围内（默认：30000-32767）分配端口，每个 Node 将从该端口（每个 Node 上的同一端口）代理到 Service。该端口将通过 Service 的 spec.ports[*].nodePort 字段被指定，如果不指定的话会自动生成一个端口。

需要注意的是，Service 将能够通过 :spec.ports[].nodePort 和 spec.clusterIp:spec.ports[].port 而对外可见。

接下来创建一个 NodePort 的服务

apiVersion: v1kind: Servicemetadata:  name: myservicespec:  selector:    app: myapp  type: NodePort  ports:  - protocol: TCP    port: 80    targetPort: 80    name: myapp-http    nodePort: 32560

创建该 Service:

$ kubectl create -f service-demo.yaml

然后我们可以查看 Service 对象信息：

$ kubectl get svcNAME         TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)        AGEkubernetes   ClusterIP   10.96.0.1       <none>        443/TCP        27dmyservice    NodePort    10.104.57.198   <none>        80:32560/TCP   14h

可以看到 myservice 的 TYPE 类型已经变成了 NodePort，后面的 PORT(S)部分也多了一个 32560 的随机映射端口。

ExternalName

ExternalName 是 Service 的特例，它没有 selector，也没有定义任何的端口和 Endpoint。对于运行在集群外部的服务，它通过返回该外部服务的别名这种方式来提供服务。

kind: ServiceapiVersion: v1metadata:  name: my-service  namespace: prodspec:  type: ExternalName  externalName: my.database.example.com

当查询主机 my-service.prod.svc.cluster.local 时，集群的 DNS 服务将返回一个值为 my.database.example.com 的 CNAME 记录。访问这个服务的工作方式与其它的相同，唯一不同的是重定向发生在 DNS 层，而且不会进行代理或转发。

如果后续决定要将数据库迁移到 Kubernetes 集群中，可以启动对应****的 Pod，增加合适的 Selector 或 Endpoint，修改 Service 的 type，完全不需要修改调用的代码，这样就完全解耦了。

18. 和 K8s 服务端口冲突了怎么处理

k8s 端口被占用报错执行以下命令：kubeadm reset

19. redhat 6.X 版本系统 和 centos 7.X 版本有啥区别？

笔者回答：

•桌面系统（6/GNOE2.x、7/GNOME3.x）•文件系统（6/ext4、7/xfs）•内核版本（6/2.6x、7/3.10x）•防火墙（6/iptables、7/firewalld）•默认数据库（6/mysql、7/mariadb）•启动服务（6/service 启动、7/systemctl 启动） 网卡（6/eth0、7/ens192）等。

20. 说一下你们公司怎么发版的（代码怎么发布的）？

jenkins 配置好代码路径（SVN 或 GIT），然后拉代码，打 tag。需要编译就编译，编译之后推送到发布服务器（jenkins 里面可以调脚本），然后从分发服务器往下分发到业务服务器上。

如果是 php 的项目，可以 rsync 上线，但是 php 也可以用 Jenkins 来操作，php7 之后也是支持编译运行，这样上线之后运行效率更快，而且一定程度上保证了代码的安全。

干货｜面试真题分享一

本文作者：一盏烛光本文来源：