腾讯云私有云平台运维面试

简介: 根据会议将面试问题进行总结,很多问题感觉当时没回答好,这是为啥呢?应该还是不熟练吧,或者不善于表达。将次经历分享出来,大家多练练。

概述

根据会议将面试问题进行总结,很多问题感觉当时没回答好,这是为啥呢?应该还是不熟练吧,或者不善于表达。将次经历分享出来,大家多练练。

JD 岗位描述

私有云平台运维 JD 腾讯云智研发子公司

1.私有云产品的自动化部署及运维交付管理;2.赋能和培养合作伙伴团队,支撑私有云产品部署;


3.产品故障定位和排查,以及维护工作;


4.备注:此岗位为腾讯集团旗下子公司编制岗位。


岗位要求


1.熟练掌握Linux常用命令,熟悉IaaS和常用云产品运维部署,有常见问题的排查经验;


2.掌握shell/python脚本开发,有云平台自动化运维开发经验为加分项;


3.熟悉docker/容器日常运维;熟练掌握K8S运维及故障排查,熟悉其工作机制,熟悉tcs为加分项;


4.熟悉大数据相关服务或者即时通讯领域,大数据要求熟悉hadoop核心组件和框架,熟悉clickhouse使用;即时通讯要求对网络及相关排障比较熟悉;

5.有一定带人或者团队管理经验;

6.备注:此岗位为腾讯集团旗下子公司编制岗位。

一面

HR没有提前约,我只是给了简历。

广东深圳的一个座机打过来就开始问了。


1.你了解虚拟化技术吗?

2.kvm virtualbox

3.你主要做什么运维工作?

4.k8s的有哪些组间?都是什么关系?

5.etcd你了解吗?k8s怎么用?一般存的什么东西?

6.etcd 有30gb数据, follower节点同步数据只有3gb。为什么会这么少呢?(例如有个用了很久的集群etcd member大小超过30g,这时候用一个新的etcd学习那个节点只有3g 是什么原因呢)

7.会不会有一些脏数据呢?

8.k8s遇到最复杂的故障是什么?

9.两个节点上的pod不通可能是什么原因呢?

10.k8s的网络插件有几种?有什么区别和不同?

11.dockerfile编写有哪些注意点?

12.容器的启动命令?

13.helm file原理?有实际写过吗?

14.k8s都有哪些对象?什么场景使用?

15.mysql 集群怎么同步数据?

16.mysql有哪些锁?

17.python有开发哪些脚本?

18.prometheus语法了解多少?

19.cicd 用了哪些组间?

20.ansible playbook会用吗?

21.coredump分析过没有?

22linux内核有没有编译过?

23.tcpdump解决过什么问题?

24.linux 性能优化印象最深刻的是什么?

25.你最大的优点和缺点?

26.最近在看什么书?


结束的很突然,感觉已经挂了

二面

06、21 19:30

面试了27分钟。

江XX


1.自我介绍?

2.k8s master 几个节点?我: 三个,高可用节点?面: 为什么是3个?

3.etcd 的运维?优化?

4.k8s 组件的介绍?关系? <>

5.k8s做过什么优化?


有什么要问的呢?


该岗位的工作职责是什么?


腾讯云 产品交付。侧重于TOB


感受:


这位面试官感觉不是很善言谈。问问题也吞吞吐吐的。遇到这种面试官应该主动出击。


例如谈到master 高可用,为什么要三个节点,因为自建的k8s集群是堆叠式的部署方式,etcd 和 k8s 的master共用。k8s master 高可用主要就是kube-apiserver组件的高可用。因为kube-apiserver是有状态的一个应用。只有它才会和后端etcd进行交互保存数据。之所以要用三个节点,这样有利于etcd的故障恢复。etcd 是一个分布式的KV 键值存储系统,基于raft共识协议,当leader节点挂掉之后,follower会以超过半数为原则进行选主。 如果是两个节点也可以做到高可用,但是raft协议的选主过程可能会经历多轮选举才有结果,这段时间etcd 拒绝写入任何数据。


这时候可以说一些关于如何选主的过程? 面试官没问不代表不能说。就是把整个问题的相关的你知道的都倒出来,这样才有利于面试官对你的理解。


这时候你可以说具体是如何选主的?


etcd leader 节点会不停的和follower节点发送心跳,follower节点有一个election_timeout。多个follower的election_timeout 不会同时开始计时, 当leader 节点发送的心跳follower节点未收到,这时follower节点就开始进行选主,拉取选票,多数同意即可成为leader。这是就会把不通的member踢掉。


加入网络发生了分区?会影响数据写入吗?


3个节点和5个节点如何选择呢?


主要看集群规模,100节点以下建议3个节点,否则5个节点。


为了让运维压力小一点,建议5个节点,这样就允许可以同时down掉两个节点,也不会影响分布式系统的运作。


CAP? 可用性 、 一致性、分区容任性

三面

2023年6月25日19:30:00


谭XX 面试官


问题


共27分钟,面试官有准备几个题目让现场回答。


问答题:


1.你做了和k8s相关的运维工作?面试官让具体说说(我balabala了3分钟)

2.使用的哪个版本?为什么 1.22.10? 有什么考量?

3.master 几个节点 ? 高可用是如何做的?

4.haproxy如何检测节点是否正常?(health check 6443端口)haproxy需要配置vip吗?keepalived 作用?

5.网络插件使用的什么?作用主要是什么?SVC-CIDR / POD-CIDR 在哪里配置?calico 如何给pod分配IP?(这块竟然不深入calico细节…….)

6.监控用什么(prometheus operator)?都配置了哪些指标?pod的内存和cpu是什么组件上报的(kubelet)?


笔试题目:

一共四道题,第一个题目整蒙了,一直没理解面试官的意图


请用kubectl 查询下每个节点CPU剩余的可以调度的资源

k  get node
k describe node master1
request:
cpu: 1000m
k top node
]# k top node
NAME               CPU(cores)   CPU%   MEMORY(bytes)   MEMORY%
k8s-master-node1   487m         13%    5305Mi          35%
k8s-worker-node1   247m         7%     3173Mi          21%
k8s-worker-node2   269m         7%     3455Mi          23%

这里的cpu cores 指的是什么意思?

58941c6c0b8e4531bbce4a412ff198a2.png

实例:


有五个节点每个节点8 个cpu core,创建100个pod,每个pod的request cpu=1000m。


创建这些pod后 调度器如何调度?


request 的资源是启动的时候必须有这么多资源才能调度成功。cpu是可压缩资源,理论上是可以调度上去的。 实验结果表明这个猜想是错误的。


下面但是没答出来,面试官请我去查。

做一个实验: 创建100个pod 每个pod申请一个1core。


实验结果:只设定request的情况下,只能调度成功4个pod。其余pod都无法调度,具体报错为:


Warning FailedScheduling 4m20s (x46 over 65m) default-scheduler 0/3 nodes are available: 1 node(s) had taint {master: nos}, that the pod didn’t tolerate, 2 Insufficient cpu.


这是什么原因呢? cpu不足?


insufficient cpu经过计算之后确实不够了,我的集群是3个节点,每个节点四个cpu。


查询所有pod的requests字段的总和。

#  kubectl get pods --all-namespaces -o jsonpath="{range .items[*]}{.metadata.name}{'\t'}{.spec.containers[*].resources.requests.cpu}{'\n'}{end}"
busyboxtest
ingress-demo-app-5967f8fd7d-p8rt7
ingress-demo-app-5967f8fd7d-qsvgz
multi-con
my-static-pod-k8s-master-node1  10m
nginx-app-5ccd894fcb-6k8hj
nginx-app-5ccd894fcb-cfpkf
nginx-app-5ccd894fcb-wqrmp
nginx-dns-8lc8b
nginx-dns-k7ldh
nginx-dns-wd6ff
nginx-test
po      100m
pod-secrets-via-env
pod-secrets-via-file
schedule-test-6cdbf894bd-62l8z  1
schedule-test-6cdbf894bd-6cw8c  1
schedule-test-6cdbf894bd-bm4vv  1
schedule-test-6cdbf894bd-cjnkd  1
schedule-test-6cdbf894bd-m9nl6  1
schedule-test-6cdbf894bd-pzhwl  1
schedule-test-6cdbf894bd-wj7mh  1
schedule-test-6cdbf894bd-wt2t6  1
schedule-test-6cdbf894bd-xnx4c  1
schedule-test-6cdbf894bd-xtskv  1
secret-pod
test
web-server
web-server-f7fcbdc98-rdl6d
web-server-f7fcbdc98-rjmn8
web-server-f7fcbdc98-rw4hr
web-server-f7fcbdc98-xblsj
ingress-nginx-admission-create-n9588
ingress-nginx-admission-patch-rdc86
ingress-nginx-controller-5d886544c7-4rgxp       100m
ingress-nginx-controller-5d886544c7-cjk76       100m
ingress-nginx-controller-5d886544c7-qgbvw       100m
calico-kube-controllers-dcb6dbf69-rdsfn
calico-node-66dw6       250m
calico-node-dz4vc       250m
calico-node-k4tbl       250m
calicoctl
coredns-b9bf78846-rnxpd 100m
coredns-b9bf78846-rvk2b 100m
default-http-backend-5b59f64f64-qf722   10m
etcd-k8s-master-node1   100m
kube-apiserver-k8s-master-node1 250m
kube-controller-manager-k8s-master-node1        200m
kube-proxy-4fqlp
kube-proxy-fglrn
kube-proxy-v9rm6
kube-scheduler-k8s-master-node1 100m
metrics-server-765d987858-q7l7b 100m
tigera-operator-7d7795c47f-2zz8t

计算这些pod的总的requests.cpu 共12120m。

这已经超过了节点cpu的总和。12120m > 12000m。所以shcedule-test pod最多只能调度成功4个。这个实验结果应该是面试官想要的。


突然发现资源真的好浪费呀,节点的cpu资源还有很多。节点cpu 使用不到10%。


这个cpu sum requests其实prometheus也可以看到(这是另外一个集群的.)

sum(namespace_cpu:kube_pod_container_resource_requests:sum{cluster="$cluster"}) / sum(kube_node_status_allocatable{job="kube-state-metrics",resource="cpu",cluster="$cluster"})

a6d63f6128e84f4fb778215f94ca55ca.pngf8b98879ea1d4d509955fb43b492b078.png

3970bd7220df45aaabe2a5f806433f73.png

引申问题?


既然schedule-test pod是guaranteed pod,那么就应该优先调度,besteffort qos的pod不应该被驱逐么?

QoS是当节点承压pod 被驱逐时,kubelet会考虑的事情,而不是调度的时候。


注意: 只写requests.cpu和limit.cpu ,pod的qosClass竟然还是burstable. 同时设定cpu和memory的memory 和limit才会是guaranteed pod。

2.如何查看当前的k8s 都占用了那些网段?

k get po controller-manager -n kube-system

查看controller-manager 的svc CIDR/ pod CIDR . 一般svc 是10.96.0.0/24

pod 的cidr 是10.244/0.0/24

3.shell 找出当前 哪个进程 向 /data 中写入或者读取的 的数据 最多?

iostat -p pid

iotop by 进程的io


ls -l /data 查看是最大的文件

lsof 文件名

查看对应的进程

4.用ansible 批量重启每个节点的kubelet 服务

ansibel k8s-all -m shell -a ‘systemctl restart kubelet’ -k

HR面

最终定级二线中级2. 我觉得表现好一点会是中级3或者高级1.

等我修炼一段时间再面面。

内核? linux 性能调优?网络?etcd? go?

如果懂一些go ,我想定级和薪资应该都有所提升。


相关实践学习
通过Ingress进行灰度发布
本场景您将运行一个简单的应用,部署一个新的应用用于新的发布,并通过Ingress能力实现灰度发布。
容器应用与集群管理
欢迎来到《容器应用与集群管理》课程,本课程是“云原生容器Clouder认证“系列中的第二阶段。课程将向您介绍与容器集群相关的概念和技术,这些概念和技术可以帮助您了解阿里云容器服务ACK/ACK Serverless的使用。同时,本课程也会向您介绍可以采取的工具、方法和可操作步骤,以帮助您了解如何基于容器服务ACK Serverless构建和管理企业级应用。 学习完本课程后,您将能够: 掌握容器集群、容器编排的基本概念 掌握Kubernetes的基础概念及核心思想 掌握阿里云容器服务ACK/ACK Serverless概念及使用方法 基于容器服务ACK Serverless搭建和管理企业级网站应用
目录
相关文章
|
3月前
|
运维 Kubernetes 监控
|
3月前
|
运维 Kubernetes 关系型数据库
云计算运维工程师面试技巧
【8月更文挑战第6天】
399 1
|
4月前
|
弹性计算 运维 自然语言处理
属于Basis运维的、在Linux平台上运行的大模型测评 OS Copilot智能助手测评
OS Copilot是阿里云为Linux打造的智能操作系统助手,基于大模型,助用户进行自然语言问答、命令执行和系统运维。它简化了Linux操作,适合新手和运维人员。测评者作为IT架构师,发现OS Copilot使非技术背景人员也能操作Linux,接入命令可在官方文档找到。测试显示,通过"co"命令可与OS Copilot交互,实现生产任务融合。该工具提高了工作效率,尤其是对于遗忘具体命令时,非常有帮助。文档清晰,适合生产环境使用,值得进一步探索。
101 0
|
6月前
|
运维 Linux 程序员
最全树莓派4B安装64位Linux(不用显示器键盘鼠标),Linux运维面试送分题
最全树莓派4B安装64位Linux(不用显示器键盘鼠标),Linux运维面试送分题
最全树莓派4B安装64位Linux(不用显示器键盘鼠标),Linux运维面试送分题
|
5月前
|
开发框架 运维 前端开发
构建一体化运维平台的八大功能
【6月更文挑战第6天】构建一体化运维平台的关键8个基本功能。
|
5月前
|
设计模式 运维 监控
运维一体化平台的能力要素
【6月更文挑战第7天】一体化运维平台的重要性,旨在建立覆盖运维全生命周期的统一平台,提升效率,保障业务连续性,实现数字化运维管理。
|
6月前
|
弹性计算 运维 监控
【阿里云云原生专栏】自动化运维的艺术:阿里云云原生平台的自动化运维工具集
【5月更文挑战第28天】阿里云云原生平台提供全面的自动化运维工具,涵盖监控告警、资源管理、部署更新、故障自愈、安全管理和数据备份等方面,简化运维工作,增强系统稳定性。通过智能工具集,运维人员能专注于业务优化,实现高效运维,为企业数字化转型提供有力支持。
249 3
|
5月前
|
运维 数据库 网络架构
详尽分享运维网络面试题101道
详尽分享运维网络面试题101道
205 0
|
6月前
|
运维 关系型数据库 MySQL
【运维面试100问】(三)说说你在故障排除方面的经历_运维面试故障排查类面经
【运维面试100问】(三)说说你在故障排除方面的经历_运维面试故障排查类面经
【运维面试100问】(三)说说你在故障排除方面的经历_运维面试故障排查类面经

热门文章

最新文章

下一篇
无影云桌面