一、自我介绍
现住址、
二、k8s 网络这方面是怎么处理的。
k8s 中的 pod 是有生命周期的，也就是说，它可以在任何时间，死在任何node 上。而新生的 pod ip 跟之前的pod 的 ip 基本上不会是一个。为了不影响 用户使用。所以我们要 通过server 的方式吧pod 共享出去。
k8s 有三类ip :分别为 Node Network （物理节点网络）、 Pod Network（pod容器网络） 、 Cluster Network（集群网络，也称为 Service NetWork ）。
k8s 的网络模式大概可以分为ExternalName, ClusterIP, NodePort, and LoadBalancer 四个模式：（默认是 ClusterIP）
用于，跨名称空间访问。这个
ExternalName：当 service 的type 为 externalName 的时候，直能 pod 访问外部机器，外部机器访问不进来。
ClusterIP：当 service 的type 为 ClusterIP 的时候，服务只能在集群内部访问。（默认的ServiceType）可以访问集群外接数据库。
NodePort: 当 service 的type 为 NodePort 的时候，会讲 service 的IP和端口映射到 物理机的 IP和端口。
LoadBalancer：使用云服务商的负载均衡器。外部的负载均衡器可以路由到 NodePort 服务 和 ClusterIP 服务。
当我们访问一个k8s 集群内部的服务的时候，集群内流量的走向为 ： 用户访问 对外提供服务的 域名 --> 通过各种解析，达到 k8s 集群的工作节点上的 ingress --> ingress 将流量代理到 service:端口上，--> servic 通过寻找 endpointd 里面封装的 pod ip:端口 --> 通过 kube-proxy 在 ipvs 或者 iptables 中封装的规则调度到指定的 pod 上。
三、分布式的服务是怎么去做的，分布式的网络设计到一个集群，k8s 集群之间网络通讯是通过什么实现的。（是否使用第三方插件）
四、大概聊一下
kubernetes master 节点运行组件：
kubectl: k8s 中的命令行工具。
apiService：
etcd: 有一个自动服务发现机制。分布式键值存储系统，用户保存集群状态数据，比如 pod 、service 等对象信息。
kube-contoroller-manager: 处理集群中常规的后台任务，一种资源对应一个控制器，controller-manager 就是负责这些控制器的。
kube-scheduler: 根据自身的调度算法，为新创建的 pod 选择一个 node 节点，可以部署到一个节点上，也可以部署到多个节点上。
kubernetes node 节点组件：
kubelet: kubelet 是master 运行在 node 上的代理 agent,管理pod 的运行周期。比如创建、pod数据卷挂载、下载 serect、获取容器和节点状态信息等等。
kube-proxy: 在node 节点上实现pod 的网络代理，维护网络规则和四层负载均衡
docker 或
五、k8s 网络这方面有了解么？ istio 网络治理。
k8s 提供了部署、升级、扩缩容和有限的流量管理等功能；利用service 的机制来做服务注册和发现，通过 kube-proxy 实现转发和负载均衡。但并不具备上层熔断、限流降级、动态路由、调用链治理等能力。
istio 则很好的补齐了 k8s 在微服务治理上比较不足的这方面的能力。同时基于 k8s 构建的。又不是想 spring cloud netflix 完全从新做一套。
六、k8s 有几套集群啊。集群之间是通过什么通讯的。
k8s 集群通过 service 将 集群内部的pod 以nodeport 的方式挂载出去，或者使用 ingress 的方式吧服务域名搞出去。
七、你们公司使用的k8s 的扩容方式、升级的时候用的是什么策略。
我们公司使用 hpa 的方式 扩容 k8s 集群内需要扩容的 pod 。升级时候使用的是 滚动更新 或者 灰度发布/金丝雀发布，
根据业务情况来定制扩容方式，
滚动更新特点是：用户体验比较平滑。每次发布一部分机器，通过监控或者手工验证的方式确保没有问题在发布下一次。所以过程会比较慢一点。
金丝雀发布的特点是：对服务不是很自信的时候使用这个。先发布一小部分，如果测试没有问题，那么剩下的全部更新。缺点是用户覆盖面比较小，确定问题需要时间。
所以生产环境用的 滚动比较多，之后是金丝雀，蓝绿发布基本不用，这个成本太高了。环境小一点还好说，升级环境大一点的话。就很吃配置了。
八、日志搜集是怎么做的？简单的描述一下。搜集日志的脚本 日志的处理是怎么处理的。
这个是在
九、devops 是怎么做的？流程简单的说一下。
Devops可以实现打通开发和运维壁垒 实现开发运维一体化。整个流程包括 敏捷开发 -–> 持续集成-–> 继续交付 -–> 持续部署。可通过
jenkins+gitlab+sonarqube+maven+nexus+harbor+k8s 实现一套完整的 devops 系统，开发提交代码到 github --à jenkins 检测到代码更新 --> 调用 api 在k8s 中创建 jenkins slave pod --> jenkins slave 拉取代码 -->通过 maven 把拉取的代码进行构建成 war 包或者jar 包， -->上传代码到 sonarqube 进行代码扫描 --> 基于 war 包构建 docker image --> 把镜像上传到 harbor 仓库 --> 基于镜像部署到应用开发环境
十、是怎么把 服务 弄到
首先编写
十一、k8s 的 存储这方面是怎么做的。
我们使用的外部存储是
十二、简单说一下
Prometheus 跟 k8s 共同托管到 cncf 基金会，就足矣证明这个东西是多么靠谱，跟 zabbix 对比 支持的集群更大，zabbix 上线约为 1w ,虽然目前来说使用的人数没有 zabbix 多，但是由于是后起之秀，现在大部分公司都往k8s 方向发展，对于 k8s集群 和容器的监控来说 无疑是最好的选择，而且部署简单。
Prometheus server 定期的从活跃的 目标上获取监控指标数据，目标主机的监控数据可以通过 静态 job 或者 服务发现的方式被采集到，也可以通过 pushgetway 的方式上传数据
Prometheus Server 吧采集到的监控指标数据保存到存储。
Prometheus 采集到的监控指标按照时间序列存储，通过配置告警规则，吧触发的报警发送到 alertmanager。
alertmanager 通过配置的告警信息，将告警邮件发送到指定邮箱，或者 程序。
Prometheus 自带的web ui 界面提供 promQl 查询语言，可查询监控数据
grafana 可接入 Prometheus 数据源，将监控数据图形化展示。
十三、docker 网络模式 简单的说一下。
docker 的网络模式分为四种：
bridge : 为每个容器分配ip,并将容器连接到docker0 的虚拟网桥。
host: 容器共用宿主机的网络和端口
none: 禁用网络
container: 新创建的 容器不会有自己的网卡和接口，而是跟其他已经存在的 容器 共用一个和端口（这两两个容器之间的通讯更高效）
十四、docker 的编译过程。镜像跟 搭建在物理机上的服务有什么区别。namespace 和 cgroup。docker 要拿到物理机的 信息。
镜像搭建到容器上主要的特点就是
可移植：不基于环境要求，什么系统都能运行。
可扩展：扩容方便，不像传统运维还要从新搭建新的集群。这个只需要对pod 进行扩容就行了
他们直接读取 物理机的system 文件。
十五、写过一些什么shell脚本。
比如
定期备份k8s集群 etcd 服务信息。配合 crontab 实现数据备份。
十六、ansible 使用的一些小问题。
集群内机器大于
十七、mysql 数据存储是怎么做的，主从复制 是怎么实现的。如果主从复制的过程中来了一批数据是怎么处理的。
mysql 组从复制采用 mha 架构优点是 故障切换比较快，
1、从库运行 i/o 、sql 线程，
2、i/o 线程会去请求主的binlog,并将得到的 binlong 写到本地的 relay_log（中继日志）文件中。
3、主库会生成一个 log dump 线程，用来給从库 i/o 线程传 binlog
4、sql 线程读取 relay log 文件中的日志，并解析成 sql 语句，一条条执行。
十八、redis 简单的描述一下。
十九、简单的描述
etcd 是k8s 集群中的 高可用的键值对数据。数据以 key-value 的形式存储，
特点是：
- 简单，安装配置简单，而且提供了跟 apiservice 交互。
- 安全，使用ssl 认证。
- 快速，根据官网提供的数据，每秒2k+ 的读取操作。
- 可靠，采用 raft 算法。实现分布式系统数据的可用性和一致性
