最近面试被问到的几个问题,于是整理收集如下:
自动化相关
k8s中master和nodes分别有哪些组件,及作用。
Master节点上面主要由四个模块组成:etcd、api server、controller manager、scheduler
api server:顾名思义提供API,通过rest接口实现各自的功能。如controller通过api来实时监控各个资源状态。
etcd:提供一个键值数据库,用于保存集群网络配置和资源对象的状态信息。数据变更都是通过api server进行。
系统中一共有两个服务需要用到etcd用来协同和存储配置,分别是:
1)网络插件flannel,其它网络插件也需要用到etcd存储网络的配置信息;
2)kubernetes本身,包括各种资源对象的状态和元信息配置。
scheduler:监听新建pod副本信息,并通过调度算法为该pod选择一个最合适的Node节点。会检索到所有符合该pod要求的Node节点,执行pod调度逻辑。调度成功之后,会将pod信息绑定到目标节点上,同时将信息写入到etcd中。一旦绑定,就由Node上的kubelet接手pod的接下来的生命周期管理。如果把scheduler看成一个黑匣子,那么它的输入是pod和由多个Node组成的列表,输出是pod和一个Node的绑定,即将这个pod部署到这个Node上。Kubernetes目前提供了调度算法,但是同样也保留了接口,用户可以根据自己的需求定义自己的调度算法。
controller manager:负责维护集群的状态,比如故障检测、自动扩展、滚动更新等。每个资源一般都对应有一个控制器,这些controller通过api server实时监控各个资源的状态,controller manager就是负责管理这些控制器的。当有资源因为故障导致状态变化,controller就会尝试将系统由“现有状态”恢复到“期待状态”,保证其下每一个controller所对应的资源始终处于期望状态。比如我们通过api server创建一个pod,当这个pod创建成功后,api server的任务就算完成了。而后面保证pod的状态始终和我们预期的一样的重任就由controller manager去保证了。
controller manager 包括运行管理控制器(kube-controller-manager)和云管理控制器(cloud-controller-manager)
----
Node节点,包括kubelet、kube-proxy、container runtime(docker)
kubelet 会监视已分配给节点的pod,负责pod的生命周期管理,同时与Master密切协作,维护和管理该Node上面的所有容器,实现集群管理的基本功能。即Node节点通过kubelet与master组件交互,可以理解为kubelet是Master在每个Node节点上面的agent。本质上,它负责使Pod的运行状态与期望的状态一致。
kube-proxy 是实现service的通信与负载均衡机制的重要组件,将到service的请求转发到后端的pod上。
Container runtime:容器运行环境,目前Kubernetes支持docker和rkt两种容器。
----
参考链接:
https://blog.csdn.net/weixin_38645718/article/details/85931795
https://www.cnblogs.com/linuxk/p/10291178.html
k8s有哪些组件做网络通信、网络如何管理、使用哪种网络连接模式
官方推荐组件flannel,由它统一分配pod的ip
会在网卡上创建一个虚拟网卡flannel0,桥接
pod中容器间如何通信
首先k8s里面容器是存在于pod里面的,所以容器之间通讯,一般分为三种类型:
1. pod内部容器之间
这种情况下容器通讯比较简单,因为k8s pod内部容器是共享网络空间的,所以容器直接可以使用localhost访问其他容器。
k8s在启动容器的时候会先启动一个pause容器,这个容器就是实现这个功能的。
2. pod 与 pod 之间
这种类型又可以分为两种情况:
1) 两个pod在一台主机上面
针对第一种情况,就比较简单了,就是docker默认的docker网桥互连容器。
2) 两个pod分布在不同主机之上
第二种情况需要更为复杂的网络模型了,k8s官方推荐的是使用flannel组建一个大二层扁平网络,pod的ip分配由flannel统一分配,通讯过程也是走flannel的网桥。
每个node上面都会创建一个flannel0虚拟网卡,用于跨node之间通讯。所以也可以直接使用pod id进行通讯。
**跨节点通讯时,发送端数据会从docker0路由到flannel0虚拟网卡,接收端数据会从flannel0路由到docker0,这是因为flannel会添加一个路由**
3. pod 访问service服务
这里涉及到k8s里面一个重要的概念service。它是一个服务的抽象,通过label(k8s会根据service和pod直接的关系创建endpoint,可以通过kubectl get ep查看)关联到后端的pod容器。
Service分配的ip叫cluster ip是一个虚拟ip(相对固定,除非删除service),这个ip只能在k8s集群内部使用,如果service需要对外提供,只能使用Nodeport方式映射到主机上,使用主机的ip和端口对外提供服务。(另外还可以使用LoadBalance方式,但这种方式是在gce这样的云环境里面使用的 )。
节点上面有个kube-proxy进程,这个进程从master apiserver获取信息,感知service和endpoint的创建,然后做两个事:
1. 为每个service 在集群中每个节点上面创建一个随机端口,任何该端口上面的连接会代理到相应的pod
2. 集群中每个节点安装iptables规则,用于clusterip + port路由到上一步定义的随机端口上面,所以集群中每个node上面都有service的转发规则:
----
参考链接:
https://www.cnblogs.com/linyouyi/p/11557771.html
https://blog.csdn.net/nangonghen/article/details/102024843
https://blog.csdn.net/weixin_29115985/article/details/78963125
有状态服务和无状态服务的区别
无状态服务
1. 是指该服务运行的实例不会在本地存储需要持久化的数据,并且多个实例对于同一个请求响应的结果是完全一致的。
2. 多个实例可以共享相同的持久化数据。例如:nginx实例,tomcat实例等
3. 相关的k8s资源有:ReplicaSet、ReplicationController、Deployment等,由于是无状态服务,所以这些控制器创建的pod序号都是随机值。并且在缩容的时候并不会明确缩容某一个pod,而是随机的,因为所有实例得到的返回值都是一样,所以缩容任何一个pod都可以。
有状态服务
1. 有状态服务可以说是 需要数据存储功能的服务、或者指多线程类型的服务,队列等。(mysql数据库、kafka、zookeeper等)
2. 每个实例都需要有自己独立的持久化存储,并且在k8s中是通过申明模板来进行定义。持久卷申明模板在创建pod之前创建,绑定到pod中,模板可以定义多个。
参考链接:
https://www.jianshu.com/p/dd47a3cde390
应用运维相关
nginx如何调用php,通过什么协议
cgi协议。
简单的用户请求流程:
用户访问域名->域名进行DNS解析->请求到对应IP服务器和端口->nginx监听到对应端口的请求->nginx对url进行location匹配->执行匹配location下的规则->nginx转发请求给php->php-fpm的master进程监听到nginx请求->master进程将请求分配给其中一个闲置的worker进程->worker进程执行请求->worker进程返回执行结果给nginx->nginx返回结果给用户
参考链接:
https://blog.csdn.net/u010433704/article/details/93050655
https://segmentfault.com/a/1190000018265488
mysql主从同步原理
MySQL主从复制涉及到三个线程。主服务器(I/O dump thread),从服务器有(I/O thread和SQL thread)。
主库把接收的SQL请求记录到自己binlog日志中,从库的I/O thread去请求主库的binlog日志,并将binlog日志写到中继日志(relay log)中,然后SQL线程负责读取relay log中的内容,最终保证主从数据的一致性。
主库通过I/O dump thread给从库I/O thread传送binlog日志。
相关参考:
https://www.cnblogs.com/fengff/p/11011702.html
服务器负载高排查思路
1.1 定位高负载进程
1.2 定位具体的异常业务
1.3 定位异常线程及具体代码行
相关参考:
https://www.cnblogs.com/linuxprobe-sarah/p/10013150.html
java进程负载高如何处理
如果不是服务器性能问题,就需要排查程序方面。
1.日志追踪。
2.pstack跟踪进程栈。方便排查进程问题,比如发现一个服务一直处于work状态(如假死/死循环/死锁),使用这个命令能定位问题所在。
参考链接:
https://www.cnblogs.com/kongzhongqijing/articles/7685699.html
TCP/UDP的原理和区别
TCP的优点:可靠,稳定。TCP的可靠体现在TCP在传递数据之前,会有三次握手来建立连接,而且在数据传递时,有确认、窗口、重传、拥塞控制机制,在数据传完后,还会断开连接用来节约系统资源。
TCP的缺点:慢,效率低,占用系统资源高,易被攻击TCP在传递数据之前,要先建连接,这会消耗时间,而且在数据传递时,确认机制、重传机制、拥塞控制机制等都会消耗大量的时间,而且要在每台设备上维护所有的传输连接,事实上,每个连接都会占用系统的CPU、内存等硬件资源。而且,因为TCP有确认机制、三次握手机制,这些也导致TCP容易被人利用,实现DOS、DDOS、CC等攻击。
UDP的优点:快,比TCP稍安全UDP没有TCP的握手、确认、窗口、重传、拥塞控制等机制,UDP是一个无状态的传输协议,所以它在传递数据时非常快。没有TCP的这些机制,UDP较TCP被攻击者利用的漏洞就要少一些。但UDP也是无法避免攻击的,比如:UDP Flood攻击……
UDP的缺点:不可靠,不稳定。因为UDP没有TCP那些可靠的机制,在数据传递时,如果网络质量不好,就会很容易丢包。基于上面的优缺点,那么:什么时候应该使用TCP:当对网络通讯质量有要求的时候,比如:整个数据要准确无误的传递给对方,这往往用于一些要求可靠的应用,比如HTTP、HTTPS、FTP等传输文件的协议,POP、SMTP等邮件传输的协议。在日常生活中,常见使用TCP协议的应用如下:浏览器,用的HTTP FlashFXP,用的FTP Outlook,用的POP、SMTP Putty,用的Telnet、SSH QQ文件传输………… 什么时候应该使用UDP:当对网络通讯质量要求不高的时候,要求网络通讯速度能尽量的快,这时就可以使用UDP。比如,日常生活中,常见使用UDP协议的应用如下: QQ语音 QQ视频 TFTP ……
有些应用场景对可靠性要求不高会用到UPD,比如长视频,要求速率
相关参考:
https://www.cnblogs.com/williamjie/p/9390164.html
http中5xx有哪些常见错误
502 Bad Gateway:作为网关或者代理工作的服务器尝试执行请求时,从上游服务器接收到无效的响应。
504 Gateway Timeout:作为网关或者代理工作的服务器尝试执行请求时,未能及时从上游服务器(URI标识出的服务器,例如HTTP、FTP、LDAP)或者辅助服务器(例如DNS)收到响应。
500 Internal Server Error:服务器遭遇异常阻止了当前请求的执行,一般为程序错误。
403 Forbidden:服务器接受请求,但是被拒绝处理。
404 Not Found:服务器未找到任何匹配Request-URI的资源。
原文地址:https://www.cnblogs.com/jiba/p/12578637.html
时间: 2024-10-27 23:00:45