运维常见面试题

OSI七层协议模型

7层是指OSI七层协议模型,从7到1分别为:应用层(Application)、表示层(Presentation)、会话层(Session)、传输层(Transport)、网络层(Network)、数据链路层(Data Link)、物理层(Physical)。

TCP:三次握手与四次挥手

  • 三次握手(建立连接)
    在这里插入图片描述
    第一次:客户端向服务端发送连接建立请求。
    传递两件事:a.希望建立连接。b.指明可用哪个syn同步序列号回应。
    第二次:服务端接收到请求,用一个带有确认应答(ACK)和同步序列号(SYN)标志位的数据段响应客户端,并与客户端建立连接。传递两件事:b.我已收到请求,具备接收能力。a.你可使用该syn来回应我。
    第三次:客户端接收服务端响应后,向服务端发送ack确认包。传递一件事:a.告诉服务端,自己已接收并具有数据传输能力。
    • 状态解释:
      send_syn:发送syn中。
      receive_syn:接到syn包。
      send_ack:发送确认包ack。
      receive_ack:收到确认包ack。
    • 为什么需要三次握手,及场景。
      通过两次握手,客户端与服务端之间可建立连接。假如遭遇网络延迟,客端发出的第一次握手请求,直到客户端超时后才送到服务端,此时服务端返回响应并建立连接,客户端并不知晓,也就不会传输数据因而造成资源浪费。
    • 提炼,第三次握手的必要性。
      a.告诉服务端,客户端具有数据传输能力。(稳定连接)
      b.节省资源消耗。

  • 四次挥手
    • 一方主动关闭
      在这里插入图片描述
    • 双方同时请求关闭
      在这里插入图片描述
      客户端/服务端均可请求关闭连接,且可同时请求。
      请求关闭连接的一方向对方发送FIN包,并进入FIN_WAIT_1状态。接收到关闭请求的一方向对方发送接收确认包ACK为FIN包内容+1,并进入CLOSE_WAIT状态,在向对方发送请求关闭FIN包,进入LAST_ACK状态。接收到最后一个FIN包的一方,向对方发送接收确认包ACK为FIN包内容+1,并进入TIME_WAIT状态,等待2MSL周期后视为确认对方已关闭并释放本方连接。
    • 状态解释。
      从图可清晰的看出,每个状态代表的意思。
      FIN_WAIT_1:即为发送了第一个FIN包,等待回应。
      CLOSE_WAIT:即为接收到了关闭请求,等待关闭。
      FIN_WAIT_2:即为单方关闭请求情况中,接收到回应的关闭请求FIN。
      LAST_ACK:即为已发出最后的关闭请求FIN包,等待对方已收到的回应。
      TIME_WAIT:即等待一个固定时长确保对方已关闭后自己在关闭。
      CLOSED:即为已经关闭连接

HTTP:状态码

分类描述
1**消息,一般是告诉客户端,请求已经收到了,正在处理,别急…
2**处理成功,一般表示:请求收悉、我明白你要的、请求已受理、已经处理完成等信息.
3**重定向到其它地方。它让客户端再发起一个请求以完成整个处理。
4**处理发生错误,责任在客户端,如客户端的请求一个不存在的资源,客户端未被授权,禁止访问等。
5**处理发生错误,责任在服务端,如服务端抛出异常,路由出错,HTTP版本不支持等。
  • 举例
    100 Continue 继续。客户端应继续其请求。
    200 OK: 请求成功。
    302 Found: 临时移动。与301类似。但资源只是临时被移动。客户端应继续使用原有URI。
    400 Bad Request:客户端请求的语法错误,服务器无法理解。
    405 Method Not Allowed:客户端请求中的方法被禁止。
    500 Internal Server Error:服务器内部错误,无法完成请求。

HTTP请求报文与响应报文

  • 请求报文:在这里插入图片描述
    在这里插入图片描述
  • 响应报文 在这里插入图片描述

HTTP中cookie和session的作用

session机制采用的是在服务端保持状态的方案,而cookie机制则是在客户端保持状态的方案,cookie又叫会话跟踪机制。打开一次浏览器到关闭浏览器算一次会话。HTTP协议是一种无状态协议,在数据交换完毕后,服务端和客户端的链接就会关闭,每次交换数据都需要建立新的链接。此时,服务器无法从链接上跟踪会话。cookie可以跟踪会话,弥补HTTP无状态协议的不足。

  • cookie分为会话cookie和持久cookie。
    会话cookie:浏览器关闭则cookie销毁.
    持久cookie:生命周期expires到期,则cookie销毁。
  • cookie的缺点:
    保存在客户端
    存储大小有限
    用户可见可修改

session工作流程,寻找cookie中的session id。根据session id去服务器内存中找到相应的用户资料。如果没有找到则新建,根据资料来判断用户访问的状态。
一般通过redis集群来同步seesion,解决负载均衡指向不同服务器的情况。

session与cookie的区别:

  • 1、存放位置不同

Cookie保存在客户端,Session保存在服务端。

  • 2 、存取方式的不同
    Cookie中只能保管ASCII字符串,假如需求存取Unicode字符或者二进制数据,需求先进行编码。Cookie中也不能直接存取Java对象。若要存储略微复杂的信息,运用Cookie是比拟艰难的。

    而Session中能够存取任何类型的数据,包括而不限于String、Integer、List、Map等。Session中也能够直接保管Java Bean乃至任何Java类,对象等,运用起来十分便当。能够把Session看做是一个Java容器类。

  • 3、安全性(隐私策略)的不同

    Cookie存储在浏览器中,对客户端是可见的,客户端的一些程序可能会窥探、复制以至修正Cookie中的内容。而Session存储在服务器上,对客户端是透明的,不存在敏感信息泄露的风险。 假如选用Cookie,比较好的方法是,敏感的信息如账号密码等尽量不要写到Cookie中。最好是像Google、Baidu那样将Cookie信息加密,提交到服务器后再进行解密,保证Cookie中的信息只要本人能读得懂。而假如选择Session就省事多了,反正是放在服务器上,Session里任何隐私都能够有效的保护。

    • 4、有效期上的不同

    只需要设置Cookie的过期时间属性为一个很大很大的数字,Cookie就可以在浏览器保存很长时间。 由于Session依赖于名为JSESSIONID的Cookie,而Cookie JSESSIONID的过期时间默许为–1,只需关闭了浏览器(一次会话结束),该Session就会失效。

    • 5、对服务器造成的压力不同

    Session是保管在服务器端的,每个用户都会产生一个Session。假如并发访问的用户十分多,会产生十分多的Session,耗费大量的内存。而Cookie保管在客户端,不占用服务器资源。假如并发阅读的用户十分多,Cookie是很好的选择。

    • 6、 跨域支持上的不同

    Cookie支持跨域名访问,例如将domain属性设置为“.baidu.com”,则以“.baidu.com”为后缀的一切域名均能够访问该Cookie。跨域名Cookie如今被普遍用在网络中。而Session则不会支持跨域名访问。Session仅在他所在的域名内有效。


rm -rf避免

  • 方法一:校验rm中使用的变量
    提醒一下,在shell脚本中使用到rm命令并且rm命令的参数中有带有变量时,需要特别注意变量名是否与上面声明的保持一致,还有一种做法就是:在引用变量的时候使用下面的方法,可以确保变量不会为空。
    比如上面的DIRPATH变量,在引用此变量作为rm的参数的时候,使用如下方式:
    rm -rf ${DIRPATH:-default}/bin/
    ${DIRPATH:-default}:表示如果变量DIRPATH没有被声明或者已经声明,但是赋值为空,那么就使用默认值default,否则就使用DIRPATH初始化的值
  • 方法二:回收站,在重定向rm命令
  • 方法三:改用safe-rm命令,在配置文件中配置不会被删除的路径

K8S容灾及高可用

【安全版本】
Kubernetes v1.13.12
Kubernetes v1.14.8
Kubernetes v1.15.5
Kubernetes v1.16.2
  • k8s中需要高可用的组件(包括内置已实现的)以及实现方式?
    在这里插入图片描述
    • https://www.cnblogs.com/ants/p/11489598.html#_labelTop
      http://press.demo.kuboard.cn/install/install-kubernetes.html

    • SLB(LVS+HAProxy)

    • etcd集群
      为什么需要3台物理机以上?
      主要是考虑到了etcd的问题,如果只有两台物理机部署了5个etcd节点,那么部署了3个etcd的那台物理机故障了,则不满足etcd失败容忍度而导致etcd集群宕机,从而导致k8s集群宕机

    • K8S Node (Master / Worker)
      三个 master 组成主节点集群,通过内网 loader balancer 实现负载均衡;至少需要三个 master 节点才可组成高可用集群,否则会出现 脑裂 现象
      多个 worker 组成工作节点集群,通过外网 loader balancer 实现负载均衡

  • k8s中需要常期备份的组件及文件,容灾恢复?
    答:
    • etcd定义及作用:
      基于GO开发的高可用的分布式键值(key-value)数据库,用于服务发现即在同一个分布式集群中的进程或服务如何才能找到对方并建立连接),实现分布式系统数据的可用性和一致性。
      优点:1.支持SSL证书验证,2.提供HTTP API。
      备份方法:通kind: CronJob,挂载/var/lib/etcd,执行etcdctl备份命令。
      恢复:移除损坏的/var/lib/etcd,docker镜像任务挂载/var/lib/etcd,执行etcdctl恢复命令【待恢复的机器上,机器名称和ip地址需要与崩溃前的主节点配置完成一样】。
    • 用户主目录下.kube/config文件(kubectl连接认证)
    • 【2】/etc/kubernetes/目录下的所有文件(证书,manifest文件)
    • 【3】/var/lib/kubelet/目录下所有文件(plugins容器连接认证)
      (2),(3)可通过CronJob进行每日备份,tar。
    • 恢复步骤:
      • kubeadm reset,iptables等
      • 恢复etcd数据
      • 删除/etc/kubernetes/manifest/目录下的文件,及/var/lib/kubelet/pki/目录下的文件
      • 还原【2】【3】
      • kubeadm init
      • 还原./kube/config,执行命令测试。
  • k8s-master集群有哪些组件
    • apiserver:一个api服务器,所有外部与k8s集群的交互都需要经过它。(可水平扩展)
    • controller-manager:执行控制器逻辑(循环通过apiserver监控集群状态做出相应的处理)(一个master集群中只会有一个节点处于激活状态)
    • scheduler:将pod调度到具体的节点上(一个master集群中只会有一个节点处于激活状态)

python:魔术方法

  • 构造函数,析构函数
	__init__,__del__,__new__:
	__new__:是用来创建类并返回这个类的实例
	__init__:将传入的参数来初始化该实例。
	__del__:对象生命周期结束时调用。
  • 对象的字符串显示
	__str__,__repr__
	__str__:print(类)
	__repr__:如果没有__str__,则自动调用__repr__
  • format魔术方法
__format__:format(类名时)自动调用__format__
"Name:{b.name}, State:{b.state}, Author:{b.author}".format(b=b)
  • 类的切片操作
__getitem__:如-类['column'],通过字典的方式获取类属性
__setitem__:修改类属性
__delitem__:删除类属性
  • 重复与连接及成员操作符
__add__:类的相加,如-使用哪个属性
__mul__:类的相乘,如-使用哪个属性
__contains__:'something' in Class,返回布尔值。用in来判断类是否包含某属性。
__iter__:类的for,for i in Class,指定迭代属性。

python深拷贝和浅拷贝

  • 模块
import copy
浅拷贝: copy.copy
深拷贝: copy.deepcopy
  • 定义
直接赋值: 其实就是对象的引用(别名),赋值的两边指向的是同一个对象
浅拷贝(copy): 拷贝父对象,不会拷贝对象的内部的子对象
深拷贝(deepcopy):拷贝父对象,同时会开辟空间,逐层拷贝内部子对象
  • 代码解释
浅拷贝
>>>import copy
>>>a = [1,2,3,4,['a','b']]
>>>b = copy.copy(a)
>>>a,b
([1,2,3,4,['a','b']],[1,2,3,4,['a','b']])
>>>a.append(5)
>>>a,b
([1,2,3,4,['a','b'],5],[1,2,3,4,['a','b']])
可以看到a新增了元素5,而浅拷贝的b未新增元素
>>>a[4].append('c')
>>>a,b
([1,2,3,4,['a','b','c'],5],[1,2,3,4,['a','b','c']])
可以看到原对象修改已有元素,也会同时影响浅拷贝对象
#####################################################
深拷贝
>>>import copy
>>>a = [1,2,3,4,['a','b']]
>>>c = copy.deepcopy(a)
>>>a.append(5)
>>>a[4].append('c')
>>>a,c
([1,2,3,4,['a','b','c'],5],[1,2,3,4,['a','b']])
可以看到深拷贝对象未受影响
#####################################################
>>>a = [1,2,3,4,['a','b']]
>>>b = a
>>>b.append(5)
>>>b[4].append('c')
a,b
([1,2,3,4,['a','b','c'],5],[1,2,3,4,['a','b','c'],5])
可以看到赋值,两个变量相同。即简单的拷贝对象的引用,两个对象的id相同
  • 总结
    • 1.赋值: 简单的拷贝对象的引用,两个对象的id相同
    • 2.浅拷贝: 创建一个新的对象,这个心的对象与原对象共享内存中的子对象
    • 3.深拷贝: 创建一个新的组合对象,和原来的对象空间是独立的.新的组合对象和原对象,没有任何的关联.
      虽然实际上会共享不可变的子对象,但是不影响它们的相互独立性

zookeeper集群选举机制

假如集群有5台服务器,并依次启动。

  • server.id越大,在选举算法中权重越大。
  • 选举要超过半数,比如只有1,2两台服务器启动并投票,应服务器总数小于2.5,故1,2均为Looking状态。
  • 依次启动,server.id-3成为领导者。

redis集群种类,选举

三种集群:
1.主从复制,不支持自动容错,在线扩容。
2.哨兵模式,需人工手动选举主节点,难以在线扩容。
3.redis-cluster模式,高可用,读写分离,分布式存储数据。

  • Sentinel节点会定时对redis集群的所有节点发心跳包检测节点是否正常。
  • Sentinel集群需为基数个。
  • redis-cluster集群性能最高。
  • 18
    点赞
  • 262
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值