Q&A
Q:想问一下，K8s集群高可用方案，master节点要几台，怎么安排跟worker节点的比例
A:最少三台Master节点做高可用，Worker节点根据业务情况加。
（1）理论上，一个k8s集群数量是5000左右的，但是如果节点太多，master节点的负担也越大，所以应该考虑master和slave的节点比，一般而言，1：100~200，就可以了。
（2）如果，这个比例不好把握，那你就用公有云的全托管集群，master节点是公有云提供的，非常大，你根本不用操心，这样，一个Kubernetes集群上千个节点是没有问题的。
Q:etcd怎么备份？有哪些开源方案可以借用？老师们在如何实现etcd备份的？
A:如果磁盘 IO 、网络依赖较高，建议独立部署etcd,
https://github.com/kubesphere/kubekey/blob/235de693d6e68740b573362b8fd3e1226d8c574f/pkg/etcd/templates/backup_script.go
Q:k8s 里面跑 多个微服务，服务之间调用 是走网关（每个微服务对外的域名），还是直接走集群内部的service 域名访问 ，
A:🍀🐌：主要是看《有没有状态》，比如说存储、实例共享状态这种走service，主要是通过kube-proxy，比如说ipvs。可以看看k8s网络实现的两块核心，一块是kube-proxy，一块是网络插件
Q:pod中可以telnet通外界端口？
A:pod可以看成是一个主机的环境，是张磊大佬对虚拟机和容器对比中，我觉得最好的一个比喻,只要从主机到这个《外界》通，如果有calico这种支持网络策略的插件的话也需要策略允许。就当pod是一个小虚拟机，极客时间有个课也提到了，pod可以看成是一个主机的环境
Q:pod中telnet不通外界端口，可以ping通该怎么排查
A:https://blog.csdn.net/fly910905/article/details/122222419
Q:网络插件的选择有什么建议worker 节点120左右
A:calico就很好
为你的项目选择正确的解决方案
根据你的需要，选择要在集群中使用的正确 CNI 插件可能非常简单，也可能稍微复杂一些。如果你的唯一要求是基本的网络解决方案，那么 Flannel 可能是你的最佳选择。虽然它缺乏网络策略和加密等许多高级功能，但与其他 CNI 插件相比，它轻巧、快速且消耗的资源更少。
如果**通过网络策略和加密实现的性能和安全性至关重要，你应该考虑 Calico、Weave 或 Cilium 或像 Canal 这样的混合解决方案。**Canal 使用Calico和Flannel 的组合。Flannel 提供基本的网络连接，并与 Calico 一流的网络策略完美匹配。网络策略对于维护安全集群至关重要，尤其是考虑到网络攻击的风险增加。Calico 的文档包括关于采用零信任网络模型的必读部分。
**Cilium 可以为大规模部署提供优势，并利用 eBPF 来提高可观察性和网络管理效率。**Cilium 仍然是一个年轻的项目，在下面引用的基准测试中，它似乎确实更耗费资源。
说到基准测试，ITNEXT 每年都会发布CNI 插件的基准测试结果集。结果显示我们今天讨论的所有框架以及其他几个框架的性能相似。该研究使用默认配置在具有三个节点的集群上运行基准测试，并测量性能、吞吐量、延迟和资源使用情况等指标。
Q:对于worker节点的计算性能多少比较合适是越多越好吗比如32核心120g内存还是更多的计算能力
A:主要看业务
您应该在集群中使用少量大型节点还是许多小型节点？
一如既往，没有明确的答案。
您要部署到集群的应用程序类型可能会指导您的决策。
例如，如果您的应用程序需要10 GB内存，则可能不应使用小节点 – 集群中的节点应至少具有10 GB内存。
或者，如果您的应用程序需要10倍的复制性以实现高可用性，那么您可能不应该只使用2个节点 – 您的集群应该至少有10个节点。
对于中间的所有场景，它取决于您的具体要求。
在总预算下，平衡节点数和节点配置,节点越大，故障的时候影响越大，节点越小，overhead越大
除此之外再考虑业务负载
Q:请问k8s在项目中落地存储方案怎么选，针对中小企业
A:可以从几个方面考虑： 数据可靠性， 数据可用性， 数据一致性， 存储性能
Q:如果pod异常了，service会将对应的pod ip下线吗？
A:健康检查。service的规则是根据同名的endpoint，endpoint的选择是根据selector和健康检查
Q:目前🈶自建k8s和云容器管理平台，如果目前公司是多云架构(阿里云，华为云，腾讯云)或者混合云架构(阿里云➕idc机房)，是否能做到自建一套k8s管理，是否需要很复杂云原生改造？？或者又是否可以类似用阿里云容器平台都能管理
A:
根据我的经验，云原生的应用和实施，一定要小步，找到业务痛点（部署复杂，服务治理难度大，运维成本高），要让老板感觉能带来效益，有了支持，咱们才有更多的技术理想的落地，毕竟，非大型公司，都是注重效益
https://www.modb.pro/db/153915
Q:Pv的种类选择上有什么考虑推荐的吗
A:
Q:Pod的env里存在同命名空间下所有svc信息，如ip，端口，协议。是起到的是什么作用。在一个大的集群下，是否需要优化，感觉和ipvs条目或iptable条目一样，随着集群变大而越来越多
A:大规模更推荐用ipvs，策略丰富，效率快
做了云原生，可能真的就是开发+运维了，从此就是一位名副其实的DevOps工程师，我做云原生，感觉最大的收获，是离公司业务更进了，以前很多业务接触不到，现在他们要容器化，都会主动给你讲
产品开发测试运维本来就只是产品线上重心不同的环节，可以理解其他的部分当然最好
从业务来说的话，就是要么选择产品来用，组合和修改，那就选择需要的部分就好，要么走产品研发的路线。大部分时候是两条路混杂的，总需要依赖开源的然后修改和二次开发，也需要自己研发打出核心优势
1 Docker 和虚拟机有哪些不同？
答：docker是轻量级的沙盒，在其中运行的只是应用。而虚拟机里面还有额外的独立操作系统运行
2 简述 Kubernetes 和 Docker 的关系？
答:docker通过dockerfile 将应用程序运行所需的设置和依赖打包到一个容器中，从而实现可移植性的优点
Kubernetes 用于关联和编排在多个主机上运行的容器。
3 简述 kube-proxy ipvs 和 iptables 的异同？
相同之处都是基于netfilter内核准发
Iptables是为防火墙而设计的管理工具
Ipvs 专门用于高性能LB集群 – lvs
Iptables
优点
灵活，功能强大（可以在数据包不同阶段对包进行操作）
缺点
表中规则过多时，响应变慢，即规则遍历匹配和更新，呈线性时延
ipvs
工作在内核空间
优点
转发效率高
调度算法丰富：rr，wrr，lc，wlc，ip hash...
缺点
内核支持不全,低版本内核不能使用，需要升级到4.0或5.0以上。
使用iptables与ipvs时机
4 简述kube-proxy 切换为ipvs负载？
5 简述微服务部署中的蓝绿发布?
6 简述蓝绿发布的优势与不足有那些？
优势:
升级切换和回退速度非常快
不足
切换是全量的 需要两倍机器资源
7 简述 Kubernetes 静态 Pod？
由kubelet创建并且总是在kubelet所在node上运行
8 简述 Kubernetes 数据持久化的方式有哪些？
1 emptydir 空目录 临时存储
2 hostpath Docker bind mount 挂载宿主机目录
3 pv 存储 nfs gfs ceph
9 简述dockerfile中copy和add指令有什么区别?
copy一个只复制，add复制并解压 支持url
10.我在每个deployment.yaml中都做了cpu和memory的limits和requests配置（工作节点上的物理资源总是有限的），我发现我们测试环境的k8s集群资源分配到瓶颈了（有些节点已经不能再分配了，但实际使用率较低），请问我该怎么优化k8s集群。
资源浪费分为几个方面，其一是有未被分配到的碎片资源。其次是业务超配，比如业务只需要一个CPU，给分配了十个，超配的资源的就会被浪费掉。资源使用是有规律的波峰波谷，波峰和波谷时资源占用量的差距很大，业务资源使用到波谷时也会算有资源浪费。
