MENU

文章目录

TI

• 2021 年 03 月 09 日

[toc]

一、linux

系统启动流程

- 内核的引导。
- 运行 init。
- 系统初始化。
- 建立终端 。
- 用户登录系统。

linux文件类型

普通文件类型,目录文件,块设备文件,字符设备,套接字文件,管道文件,链接文件

centos6和7怎么添加程序开机自启动?

将程序可执行脚本加入/etc/rc.local文件中,文件和脚本都需要可执行权限,如果程序需普通用户启动,使用su -普通用户 -c即可

如何升级内核,目前最新版本号多少?

# rpm -import https://www.elrepo.org/RPM-GPG-KEY-elrepo.org
# rpm -Uvh http://www.elrepo.org/elrepo-release-7.0-2.el7.elrepo.noarch.rpm
# yum --disablerepo="*" --enablerepo="elrepo-kernel" list available
# yum -y --enablerepo=elrepo-kernel install kernel-ml.x86_64 kernel-ml-devel.x86_64 

nginx日志访问量前十的ip怎么统计?

awk '{print $1}' access.log |sort | uniq -c | sort -n -r | head -10

删除/var/log/下.log结尾的30天前的日志文件

find /var/log/*.log -type f  -mtime +30 -exec rm -rf {} \; 

ansible有哪些模块?功能是什么?

1.ping模块
检查指定节点机器是否还能连通,用法很简单,不涉及参数,主机如果在线,则回复pong
ansible 10.1.1.113 -m ping
2、raw模块
执行原始的命令,而不是通过模块子系统。在任何情况下,使用shell或命令模块是合适的。给定原始的参数直接通过配置的远程shell运行。可返回标准输出、错误输出和返回代码。此模块没有变更处理程序支持。
3、yum模块
这个模块是RedHat / CentOS作为远端节点的OS的时候,用的最多的。Yum是啥就不多说了,RedHat / CentOS包管理工具
使用`yum’软件包管理器管理软件包,其选项有:
– config_file:yum的配置文件 (optional)
– disable_gpg_check:关闭gpg_check (optional)
– disablerepo:不启用某个源 (optional)
– enablerepo:启用某个源(optional)
– name:要进行操作的软件包的名字,默认最新的程序包,指明要安装的程序包,可以带上版本号,也可以传递一个url或者一个本地的rpm包的路径
– state:状态(present,absent,latest),表示是安装还卸载
   present:默认的,表示为安装
   lastest: 安装为最新的版本
   absent:表示删除
 ansible test -m yum -a ‘name=httpd state=latest’
4、apt模块
这个模块是ubuntu作为远端节点的OS的时候,用的最多的。Apt是啥就不多说了,Ubuntu/Debian的包管理工具。
– deb: 用于安装远程机器上的.deb后缀的软件包(optional)
– install_recommends:这个参数可以控制远程电脑上是否只是下载软件包,还是下载后安装,默认参数为true,设置为false的时候只下载软件包,不安装
– update_cache: 当这个参数为yes的时候等于apt-get update(optional)
– name: apt要下载的软件包名字,支持name=git=1.6 这种制定版本的模式
– state:状态(present,absent,latest),表示是安装还卸载
   present:默认的,表示为安装
   lastest: 安装为最新的版本
   absent:表示删除
5、pip模块
用于管理Python库依赖项,为了使用pip模块,必须提供参数name或者requirements
– chdir: 执行pip命令前cd进入的目录
– name:要安装的Python库的名称或远程包的URL。
– requirements:一个pip requirements.txt文件的路径,它应该是远程系统的本地文件,如果使用chdir选项,则可以将文件指定为相对路径。
– version:指定的Python库的安装版本。
– extra_args:额外的参数传递给pip。
– executable:显式可执行文件或可执行文件的路径名,用于为系统中安装的特定版本的Python运行pip。 例如pip-3.3,如果系统中安装了Python 2.7和3.3,并且想要为Python 3.3安装运行pip。 它不能与“virtualenv”参数一起指定(在2.1中添加)。 默认情况下,它将采用适用于python解释器的版本。 pip3在python 3上,pip2或pip在python 2上。
– virtualenv:要安装到的virtualenv目录的可选路径。 它不能与’executable’参数一起指定(在2.1中添加)。 如果virtualenv不存在,则将在安装软件包之前创建它。 可选的virtualenv_site_packages,virtualenv_command和virtualenv_python选项会影响virtualenv的创建。
– virtualenv_command:用于创建虚拟环境的命令或路径名。 例如pyvenv,virtualenv,virtualenv2,~/bin /virtualenv,/usr/local/bin/virtualenv。
– virtualenv_python:用于创建虚拟环境的Python可执行文件。 例如python3.5,python2.7。 未指定时,将使用用于运行ansible模块的Python版本。 当virtualenv_command使用pyvenv或-m venv模块时,不应使用此参数。
– state:状态(present,absent,latest, forcereinstall),表示是安装还卸载
   present:默认的,表示为安装
   lastest: 安装为最新的版本
   absent:表示删除
   forcereinstall:“forcereinstall”选项仅适用于可ansible 2.1及更高版本。
6、synchronize模块
– 使用rsync同步文件,将主控方目录推送到指定节点的目录下,其参数如下:
– delete: 删除不存在的文件,delete=yes 使两边的内容一样(即以推送方为主),默认no
– src: 要同步到目的地的源主机上的路径; 路径可以是绝对的或相对的。如果路径使用”/”来结尾,则只复制目录里的内容,如果没有使用”/”来结尾,则包含目录在内的整个内容全部复制
– dest:目的地主机上将与源同步的路径; 路径可以是绝对的或相对的。
– dest_port:默认目录主机上的端口 ,默认是22,走的ssh协议。
– mode: push或pull,默认push,一般用于从本机向远程主机上传文件,pull 模式用于从远程主机上取文件。
– rsync_opts:通过传递数组来指定其他rsync选项。
7、template模块
基于模板方式生成一个文件复制到远程主机(template使用Jinjia2格式作为文件模版,进行文档内变量的替换的模块。它的每次使用都会被ansible标记为”changed”状态。)
– backup: 如果原目标文件存在,则先备份目标文件
– src:在ansible控制器上的Jinja2格式化模板的路径。 这可以是相对或绝对的路径。
– dest:将模板渲染到远程机器上的位置。
force:是否强制覆盖,默认为yes
– owner:目标文件属主
– group:目标文件属组
– mode:目标文件的权限模式,模式可以被指定为符号模式(例如,u + rwx或u = rw,g = r,o = r)。
8、copy模块
在远程主机执行复制操作文件。
– src:要复制到远程主机的文件在本地的地址,可以是绝对路径,也可以是相对路径。如果路径是一个目录,它将递归复制。在这种情况下,如果路径使用”/”来结尾,则只复制目录里的内容,如果没有使用”/”来结尾,则包含目录在内的整个内容全部复制,类似于rsync。
– content:用于替代”src”,可以直接设定指定文件的值
– dest:必选项。要将源文件复制到的远程主机的绝对路径,如果源文件是一个目录,那么该路径也必须是个目录
– directory_mode:递归的设定目录的权限,默认为系统默认权限
– force:如果目标主机包含该文件,但内容不同,如果设置为yes,则强制覆盖,如果为no,则只有当目标主机的目标位置不存在该文件时,才复制。默认为yes
– others:所有的file模块里的选项都可以在这里使用
9、user 模块与group模块
user模块是请求的是useradd, userdel, usermod三个指令,goup模块请求的是groupadd, groupdel, groupmod 三个指令。
– home:指定用户的家目录,需要与createhome配合使用。
– groups:指定用户的属组。
– uid:指定用的uid。
– password:指定用户的密码。
注意:指定password参数时,不能使用明文密码,因为后面这一串密码会被直接传送到被管理主机的/etc/shadow文件中,所以需要先将密码字符串进行加密处理。然后将得到的字符串放到password中即可。
echo “123456” | openssl passwd -1 -salt (</dev/urandomtr−dc‘[:alnum:]′|head−c32)−stdin14P4PlFuEur9ObJiT5iHNrb9QnjaIB0
– name:指定用户名。
– createhome:是否创建家目录 yes|no。
– system:是否为系统用户。
– remove:当state=absent时,remove=yes则表示连同家目录一起删除,等价于userdel -r。
– state:是创建还是删除。(present,absent)
– shell:指定用户的shell环境。
– generate_ssh_key:是否为相关用户生成SSH密钥。 这不会覆盖现有的SSH密钥。
– ssh_key_bits:可选择指定要创建的SSH密钥中的位数。
– ssh_key_passphrase:设置SSH密钥的密码。 如果没有提供密码,SSH密钥将默认没有密码。
– ssh_key_file:指定SSH密钥文件名(可选)。 如果这是一个相对的文件名,那么它将是相对于用户的主目录。
– ssh_key_type:指定要生成的SSH密钥的类型(可选)。 可用的SSH密钥类型将取决于目标主机上的实现。
– gid:指定用的gid。
– name:指定用户名。
– state:是创建还是删除。(present,absent)
– system:如果是,则表示创建的组是系统组。
11、get_url 模块
该模块主要用于从http、ftp、https服务器上下载文件(类似于wget),主要有如下选项:
– sha256sum:下载完成后进行sha256 check;
– timeout:下载超时时间,默认10s
– url:下载的URL
– url_password、url_username:主要用于需要用户名密码进行验证的情况
– dest:将文件下载到哪里的绝对路径。如果dest是目录,则使用服务器提供的文件名,或者如果没有提供,将使用远程服务器上的URL的基本名称。
– headers:以格式“key:value,key:value”为请求添加自定义HTTP标头。
12、fetch模块
它用于从远程机器获取文件,并将其本地存储在由主机名组织的文件树中。
– src:远程系统上要获取的文件。 这必须是一个文件,而不是一个目录。 后续版本可能会支持递归提取。
– dest:保存文件的目录。 例如,如果dest目录是/backup,在主机host.example.com上命名为/ etc/profile的src文件将被保存到/backup/host.example.com/etc/profile。
– flat:允许您覆盖将目标文件添加到主机名/ path / to / file的默认行为
13、file模块
file模块主要用于远程主机上的文件操作,file模块包含如下选项:
– force:需要在两种情况下强制创建软链接,一种是源文件不存在但之后会建立的情况下;另一种是目标软链接已存在,需要先取消之前的软链,然后创建新的软链,有两个选项:yes|no
– group:定义文件/目录的属组
– mode:定义文件/目录的权限
– owner:定义文件/目录的属主
– path:必选项,定义文件/目录的路径
– recurse:递归的设置文件的属性,只对目录有效
– src:要被链接的源文件的路径,只应用于state=link的情况
– dest:被链接到的路径,只应用于state=link的情况
– state:
   directory:如果目录不存在,创建目录
   file:即使文件不存在,也不会被创建
   link:创建软链接
   hard:创建硬链接
   touch:如果文件不存在,则会创建一个新的文件,如果文件或目录已存在,则更新其最后修改时间
   absent:删除目录、文件或者取消链接文件
14、unarchive模块
用于解压文件,模块包含如下选项:
– copy:在解压文件之前,是否先将文件复制到远程主机,默认为yes。若为no,则要求目标主机上压缩包必须存在。
– creates:指定一个文件名,当该文件存在时,则解压指令不执行
– dest:远程主机上的一个路径,即文件解压的绝对路径。
– group:解压后的目录或文件的属组
– list_files:如果为yes,则会列出压缩包里的文件,默认为no,2.0版本新增的选项
– mode:解压后文件的权限
– src:如果copy为yes,则需要指定压缩文件的源路径
– owner:解压后文件或目录的属主
15、command 模块和shell
用于在各被管理节点运行指定的命令
shell和command的区别:shell模块可以特殊字符,而command是不支持

nginx性能为什么比apache高?

这得益于Nginx使用了最新的epoll(Linux 2.6内核)和kqueue(freebsd)网络I/O模型,而Apache则使用的是传统的select模型。

目前Linux下能够承受高并发访问的Squid、Memcached都采用的是epoll网络I/O模型。

处理大量的连接的读写,Apache所采用的select网络I/O模型非常低效。


下面用一个比喻来解析Apache采用的select模型和Nginx采用的epoll模型进行之间的区别:

假设你在大学读书,住的宿舍楼有很多间房间,你的朋友要来找你。

select版宿管大妈就会带着你的朋友挨个房间去找,直到找到你为止。

而epoll版宿管大妈会先记下每位同学的房间号,

你的朋友来时,只需告诉你的朋友你住在哪个房间即可,不用亲自带着你的朋友满大楼找人。

如果来了10000个人,都要找自己住这栋楼的同学时,select版和epoll版宿管大妈,谁的效率更高,不言自明。

同理,在高并发服务器中,轮询I/O是最耗时间的操作之一,select和epoll的性能谁的性能更高,同样十分明了。

四层负载和七层负载区别是什么?

所谓四层就是基于IP+端口的负载均衡;七层就是基于URL等应用层信息的负载均衡

lvs有哪些工作模式?哪个性能高?

LVS 三种工作模式原理、以及优缺点比较

一、NAT模式(VS-NAT)
原理:就是把客户端发来的数据包的IP头的目的地址,在负载均衡器上换成其中一台RS的IP地址,并发至此RS来处理,RS处理完成后把数据交给经过负载均衡器,负载均衡器再把数据包的原IP地址改为自己的IP,将目的地址改为客户端IP地址即可期间,无论是进来的流量,还是出去的流量,都必须经过负载均衡器

优点:集群中的物理服务器可以使用任何支持TCP/IP操作系统,只有负载均衡器需要一个合法的IP地址。

缺点:扩展性有限。当服务器节点(普通PC服务器)增长过多时,负载均衡器将成为整个系统的瓶颈,因为所有的请求包和应答包的流向都经过负载均衡器。当服务器节点过多时,大量的数据包都交汇在负载均衡器那,速度就会变慢!

二、IP隧道模式(VS-TUN)
原理:首先要知道,互联网上的大多Internet服务的请求包很短小,而应答包通常很大。那么隧道模式就是,把客户端发来的数据包,封装一个新的IP头标记(仅目的IP)发给RS,RS收到后,先把数据包的头解开,还原数据包,处理后,直接返回给客户端,不需要再经过负载均衡器注意,由于RS需要对负载均衡器发过来的数据包进行还原,所以说必须支持IPTUNNEL协议所以,在RS的内核中,必须编译支持IPTUNNEL这个选项
优点:负载均衡器只负责将请求包分发给后端节点服务器,而RS将应答包直接发给用户。所以,减少了负载均衡器的大量数据流动,负载均衡器不再是系统的瓶颈,就能处理很巨大的请求量,这种方式,一台负载均衡器能够为很多RS进行分发。而且跑在公网上就能进行不同地域的分发。

缺点:隧道模式的RS节点需要合法IP,这种方式需要所有的服务器支持”IP Tunneling”(IP Encapsulation)协议,服务器可能只局限在部分Linux系统上。

三、直接路由模式(VS-DR)
原理:负载均衡器和RS都使用同一个IP对外服务但只有DR对ARP请求进行响应,所有RS对本身这个IP的ARP请求保持静默也就是说,网关会把对这个服务IP的请求全部定向给DR,而DR收到数据包后根据调度算法,找出对应的RS,把目的MAC地址改为RS的MAC(因为IP一致)并将请求分发给这台RS这时RS收到这个数据包,处理完成之后,由于IP一致,可以直接将数据返给客户,则等于直接从客户端收到这个数据包无异,处理后直接返回给客户端由于负载均衡器要对二层包头进行改换,所以负载均衡器和RS之间必须在一个广播域,也可以简单的理解为在同一台交换机上
优点:和TUN(隧道模式)一样,负载均衡器也只是分发请求,应答包通过单独的路由方法返回给客户端。与VS-TUN相比,VS-DR这种实现方式不需要隧道结构,因此可以使用大多数操作系统做为物理服务器。

缺点:(不能说缺点,只能说是不足)要求负载均衡器的网卡必须与物理网卡在一个物理段上

lvs nginx haproxy keeplived区别,优缺点?

lvs

1、抗负载能力强、工作在第4层仅作分发之用,没有流量的产生,这个特点也决定了它在负载均衡软件里的性能最强的;无流量,同时保证了均衡器IO的性能不会受到大流量的影响;
2、工作稳定,自身有完整的双机热备方案,如LVS+Keepalived和LVS+Heartbeat;
3、应用范围比较广,可以对所有应用做负载均衡;
4、配置性比较低,这是一个缺点也是一个优点,因为没有可太多配置的东西,所以并不需要太多接触,大大减少了人为出错的几率
1、软件本身不支持正则处理,不能做动静分离,这就凸显了Nginx/HAProxy+Keepalived的优势。
2、如果网站应用比较庞大,LVS/DR+Keepalived就比较复杂了,特别是后面有Windows Server应用的机器,实施及配置还有维护过程就比较麻烦,相对而言,Nginx/HAProxy+Keepalived就简单多了。

Nginx

1、工作在OSI第7层,可以针对http应用做一些分流的策略。比如针对域名、目录结构。它的正则比HAProxy更为强大和灵活;
2、Nginx对网络的依赖非常小,理论上能ping通就就能进行负载功能,这个也是它的优势所在;
3、Nginx安装和配置比较简单,测试起来比较方便;
4、可以承担高的负载压力且稳定,一般能支撑超过几万次的并发量;
5、Nginx可以通过端口检测到服务器内部的故障,比如根据服务器处理网页返回的状态码、超时等等,并且会把返回错误的请求重新提交到另一个节点;
6、Nginx不仅仅是一款优秀的负载均衡器/反向代理软件,它同时也是功能强大的Web应用服务器。LNMP现在也是非常流行的web环境,大有和LAMP环境分庭抗礼之势,Nginx在处理静态页面、特别是抗高并发方面相对apache有优势;
7、Nginx现在作为Web反向加速缓存越来越成熟了,速度比传统的Squid服务器更快,有需求的朋友可以考虑用其作为反向代理加速器;
1、Nginx不支持url来检测。
2、Nginx仅能支持http和Email,这个它的弱势。
3、Nginx的Session的保持,Cookie的引导能力相对欠缺。

Haproxy

1、HAProxy是支持虚拟主机的,可以工作在4、7层(支持多网段);
2、能够补充Nginx的一些缺点比如Session的保持,Cookie的引导等工作;
3、支持url检测后端的服务器;
4、它跟LVS一样,本身仅仅就只是一款负载均衡软件;单纯从效率上来讲HAProxy更会比Nginx有更出色的负载均衡速度,在并发处理上也是优于Nginx的;
5、HAProxy可以对Mysql读进行负载均衡,对后端的MySQL节点进行检测和负载均衡,不过在后端的MySQL slaves数量超过10台时性能不如LVS;
6、HAProxy的算法较多,达到8种;

三者对比

LVS: 是基于四层的转发
HAproxy: 是基于四层和七层的转发,是专业的代理服务器
Nginx: 是WEB服务器,缓存服务器,又是反向代理服务器,可以做七层的转发

区别: LVS由于是基于四层的转发所以只能做端口的转发
而基于URL的、基于目录的这种转发LVS就做不了

工作选择

HAproxy和Nginx由于可以做七层的转发,所以URL和目录的转发都可以做
在很大并发量的时候我们就要选择LVS,像中小型公司的话并发量没那么大
选择HAproxy或者Nginx足已,由于HAproxy由是专业的代理服务器
配置简单,所以中小型企业推荐使用HAproxy

如下url地址,各个部分的含义

https://www.baidu.com/s?word=123&ie=utf-8

http://www.aspxfans.com:8080/news/index.asp?boardID=5&ID=24618&page=1#name

从上面的URL可以看出,一个完整的URL包括以下几部分:
1、协议部分:该URL的协议部分为“http:”,这代表网页使用的是HTTP协议。在Internet中可以使用多种协议,如HTTP,FTP等等本例中使用的是HTTP协议。在"HTTP"后面的“//”为分隔符

2、域名部分:该URL的域名部分为“www.aspxfans.com”。一个URL中,也可以使用IP地址作为域名使用

3、端口部分:跟在域名后面的是端口,域名和端口之间使用“:”作为分隔符。端口不是一个URL必须的部分,如果省略端口部分,将采用默认端口80

4、虚拟目录部分:从域名后的第一个“/”开始到最后一个“/”为止,是虚拟目录部分。虚拟目录也不是一个URL必须的部分。本例中的虚拟目录是“/news/”

5、文件名部分:从域名后的最后一个“/”开始到“?”为止,是文件名部分,如果没有“?”,则是从域名后的最后一个“/”开始到“#”为止,是文件部分,如果没有“?”和“#”,那么从域名后的最后一个“/”开始到结束,都是文件名部分。本例中的文件名是“index.asp”。文件名部分也不是一个URL必须的部分,如果省略该部分,则使用默认的文件名

6、锚部分:从“#”开始到最后,都是锚部分。本例中的锚部分是“name”。锚部分也不是一个URL必须的部分

7、参数部分:从“?”开始到“#”为止之间的部分为参数部分,又称搜索部分、查询部分。本例中的参数部分为“boardID=5&ID=24618&page=1”。参数可以允许有多个参数,参数与参数之间用“&”作为分隔符

tomcat各个目录含义,如何修改端口,如何修改内存数?

bin、conf、lib、logs、temp、webapps、work
./bin/catalina设置内存
./conf/server.xml可以设置端口

nginx反向代理时,如何使后端获取真正的访问来源ip?

在代理服务器配置文件中添加参数
proxy_set_header  X-Real-IP  $remote_addr;
在后端web服务器配置
set_real_ip_from 192.168.1.1 ;
配置在http内server外

nginx负载均衡算法有哪些?

轮询,轮询加权,IP-hash,fair,url_hash,

如何进行压力测试?

ab

curl命令如何发送https请求?如何查看response头信息?如何发送get和post表单信息?

二、mysql

索引的为什么使查询加快?有啥缺点?

sql语句左外连接 右外连接 内连接 全连接区别
mysql数据备份方式,如何恢复?你们的备份策略是什么?

  1. 如何配置数据库主从同步,实际工作中是否遇到数据不一致问题?如何解决?
  2. mysql约束有哪些?
  3. 二进制日志(binlog)用途?
记录用户操作数据库的详细信息,以便恢复或者查询

mysql数据引擎有哪些?

MyISAM、InnoDB、MERGE、MEMORY(HEAP)、BDB(BerkeleyDB)、EXAMPLE、FEDERATED、ARCHIVE、CSV、BLACKHOLE
最常见的也就是MyISAM和InnoDB了

如何查询mysql数据库存放路径?

查询mysql配置文件中存放路径配置

mysql数据库文件后缀名有哪些?用途什么?
如何修改数据库用户的密码?

mysql -u root -p
Enter password:***
mysql>use mysql;  选择数据库
Database changed 
mysql> UPDATE user SET password=PASSWORD("新密码") WHERE user='你的用户名';
mysql> FLUSH PRIVILEGES;
mysql> quit;

如何修改用户权限?如何查看?

grant all privileges on *.* to testuser@localhost identified by “123456” ;
show grants for test;

三、nosql

redis数据持久化有哪些方式?

RDB
AOF

redis集群方案有哪些?

哨兵,官方的RedisCluster

redis如何进行数据备份与恢复?

使用RDB文件的话,备份敲命令SAVE,BGSAVE。恢复直接重启Redis,它会自动读取备份文件

MongoDB如何进行数据备份?

mongodump,mongorestore

kafka为何比redis rabbitmq快?

他追求的就是高吞吐量,我啥办法,redis对于消息队列只是作为轻量型的支持,如果量大,那么效率还是低的,而rabbitmq可以处理比较重的数据量,但是因为他可靠性好的原因所以,效率肯定比不过kafka。,kafka是牛逼,但是可靠性很低。

四、docker

dockerfile有哪些关键字?用途是什么?

FROM 构建镜像是基于哪个镜像
MAINTAINER 镜像维护者信息
RUN 构建镜像时运行的Shell命令
COPY 拷贝文件或者目录到镜像中
ENV 设置环境变量
USER 为RUN,CMD和ENTERYPOINT执行命令指定运行用户
EXPOSE 声明容器运行的服务端口
HEALTHCHECK 容器中服务健康检查
WORKDIR 为RUN,CMD,ENTRTYPOINT,COPY和ADD设置工作目录
ENTRYPOINT 运行容器时执行,如果有多个ENTRYPOINT指令,最后一个生效
CMD 运行容器时执行,如果有多个CMD指令,最后一个生效

如何减小dockerfile生成镜像体积?

采用Alpine镜像 该镜像非常小,仅几M
能使用&&就不要使用两个RUN
distroless驱除容器中所有不必要的东西

dockerfile中CMD与ENTRYPOINT区别是什么?

如果一起存在那么CMD将会是后者的参数,后者是一定会执行的

dockerfile中COPY和ADD区别是什么?

用法相同,但ADD做的事情COPY有可能做不到,ADD可以是一个连接,但是COPY不可以

docker的cs架构组件有哪些?

Docker CLI(docker),Dockerd,Containerd,Containerd-shim,RunC

docker网络类型有哪些?

NAT,NONE,仅主机,联合网络

如何配置docker远程访问?

修改docker配置文件

/etc/docker/daemon.json
{
  "hosts" : ["unix:///var/run/docker.sock", "tcp://0.0.0.0:2375"]
}

docker核心namespace CGroups 联合文件系统功能是什么?
命令相关:导入导出镜像,进入容器,设置重启容器策略,查看镜像环境变量,查看容器占用资源

save load --restart ,docker exec {containerID} env

构建镜像有哪些方式?

docker commit,Dockerfile
轻量

28、docker的架构与内部组件

五、kubernetes

网络选型需要注意什么
etcd用的什么算法,简单解释—下
pod中penging状态,是什么原因产生的,pod出现问题,排查思路kubernetes发布策略(4种)
手写raft
你们监控用的什么,怎么利用普罗米修斯监控pod信息,k8s状态,如果你来设计相关的监控如何落地如果利用k8s实现滚动更新,我说的配置文件机制
statefulset是怎么实现滚动更新的?

kubectl exec实现的原理?
如何实现schedule水平扩展?为什么k8s要用申明式?
了解过endpointslice吗?怎么实现的?容器的驱逐时间是?
节点notready是什么导致的?notready会发生什么?api-server到etcd怎么保证事件不丢失?
sidecar要保证顺序启动怎么保证?几种方式可以做到?有了解过qos吗?怎么实现的?
详述kube-proxy原理
k8s的pause容器有什么用。是否可以去掉k8s的service和ep是如何关联和相互影响的StatefulSets和operatorl区别

kubernetes基础命令

使用默认补全bash-completion

yum install -y bash-completion
source <(kubectl completion bash)

k8s集群状态

Pending  (pod未调度,或者pod已经调度正在拉去镜像)
Running   (pod已经运行)
Failed    (pod内容运行停止)
success   (pod内运行成功结果)
Unknown    (Master与Node失联)

k8s的重启策略

Always:当容器终止退出后,总是重启容器,默认策略(不做配置的默认策略)
OnFailure:当容器异常退出(退出状态码非0)时,才能重启 (用于一些定时任务,我们已经知道他的他容器启动不需要从启,判定状态码不正常才会重启)
Never:当容器终止退出                                   (特定环境下,在环境下跑过任务,不管成功与否都不重启)

k8s的健康检查的类型

存活检查(livenesProbe):检查失败,将杀死容器,根据Pod的restartPolicy来操作。               (健康检查kubelet会帮你做)
就绪检查(readinessProbe):如果检查失败,K8s会把pod从service endpoints中剔除
启动检查(startProbe)               (1.16版本新加,主要是确定是你的容器是不是启动好了)。现在应用的少

检查方法

httpGet:发送HTTP请求,返回200-400范围状态码为成功
exec:执行shell命令返回状态吗是0为成功
tcpSocKet:发起TCP SocKet建立成功

1.测试集群状态

kubectl get cs
kubectl cluster-info

2.查看资源详细信息

kubectl describe (资源类型)name
3.查看k8s中最新的一些事件
kubectl get event

4.查看k8s的版本

kubectl version

5.打印受支持的api版本

api-versions

6.查看k8s资源

kubectl api-resources

7.对外暴露端口

kubectl expose deployment (暴露名字) --prot=80(容器内部端口) --target-port=8080(程序端口) --type=NodePort

8.查看暴露端口

kubectl    get svc

9.pod扩容

kubectl scale deployment (名称) --replicas=3(扩容成三个)

10.查看pod是否带有标签

kubectl get pods --show-labels

11.通过标签查询pod

kubectl get pods -l app=(名字)

12.查看集群命名空间

kubectl get namespace
-n 是指定命名空间 例如 (kubectl get pods -n kube-system)
k8s默认命名空间
default:默认命名空间
kube-system:k8s系统方面命名空间
kube-public:公开的命名空间,谁都可以访问
kube-node-lease:K8s内部命名空间
作用:将资源对象逻辑上隔离,从而形成多个虚拟集群
资源隔离,权限控制

13.创建命名空间

kubectl create namespace (命名空间名字)

14.创建pod

kubectl create deployment (名字) --image=(镜像名字,或者已经搭建好的环境镜像仓库)-n dafault

15.create命令生成成一个yaml文件

kubectl create deployment (名称)--image=(镜像名字,或者已经搭建好的环境镜像仓库)-n dafault --dry-run=client -o yaml > (要生成的yaml名称).yaml

16.调用yaml删除pods

kubectl delete -f (yaml)

17.删除一个暴露端口ls

kubectl delete svc (名字)

18.用get命令导出yaml

kubectl get deployment (名字) -o yaml > (导出名字).yaml

19.进入pod容器中

kubectl exec -it (pod名称) sh 
kubectl exec -it (pod名称) -c (指定pod名称) sh     (这种适用与一会pod多个容器需要-c指定,如果不指定默认进进入第一个容器)

20.查看pod日志

kubectl logs (pod名称)
kubectl logs (pod名称) -c (一个pod多容器指定)

21.删除一个pod

kubectl get deployment (查看deployment控制器)
kubectl delete deployment (pod名称) 
或者
kubectl delete pod (pod名称)

22.查看service关联的pod

service后面是有一个控制器管理pod的就是endpoints

kubectl get endpoints (可以简写ep)

k8s的集群组件有哪些?功能是什么?

master节点主要由apiserver、controller-manager和scheduler三个组件,以及一个用于集群状态存储的etcd存储服务组成,而每个node节点则主要包含kubelet、kube-proxy及容器引擎等组件。此外,完整的集群服务还依赖于一些附加组件,如kubedns等。
node节点主要有kube-proxy跟kubelet组件。

kubectl命令相关:如何修改副本数,如何滚动更新和回滚,如何查看pod的详细信息,如何进入pod交互?

kubectl scale
kubectl set image deployment web nginx=nginx1.17 --record
kubectl rollout history deploy web # 查看版本记录
kubectl rollout undo deployment web # 回滚到上一个版本
kubectl rollout undo deployment web --to-revision=1 # 也可以回滚到指定版本
kubectl describe pod
kubectl exec  pod -- bash 

etcd数据如何备份?

使用etcd自带的备份快照工具备份!

k8s控制器有哪些?

1:Deployment
2:StatefulSet
3:DaemonSet
4:Job
5:CronJob

哪些是集群级别的资源?

secret,pv,apiserver,etcd

pod状态有哪些?

Pending         等待中
Running         运行中
Succeeded       正常终止
Failed          异常停止
Unkonwn         未知状态

pod创建过程是什么?

step.1
kubectl 向 k8s api server 发起一个create pod 请求(即我们使用Kubectl敲一个create pod命令) 。
step.2
k8s api server接收到pod创建请求后,不会去直接创建pod;而是生成一个包含创建信息的yaml。
step.3
apiserver 将刚才的yaml信息写入etcd数据库。到此为止仅仅是在etcd中添加了一条记录, 还没有任何的实质性进展。
step.4
scheduler 查看 k8s api ,类似于通知机制。
首先判断:pod.spec.Node == null?
若为null,表示这个Pod请求是新来的,需要创建;因此先进行调度计算,找到最“闲”的node。
然后将信息在etcd数据库中更新分配结果:pod.spec.Node = nodeA (设置一个具体的节点)
ps:同样上述操作的各种信息也要写到etcd数据库中中。
step.5
kubelet 通过监测etcd数据库(即不停地看etcd中的记录),发现 k8s api server 中有了个新的Node;
如果这条记录中的Node与自己的编号相同(即这个Pod由scheduler分配给自己了);
则调用node中的docker api,创建container。

pod重启策略有哪些?

always:当容器退出时,总是重启容器,默认策略
onfailure:当容器异常退出(退出状态码非0)时,重启容器
nerver:当容器退出时,从不重启容器

资源探针有哪些?

存活性探针livenessProbe,就绪性探针readinessProbe

requests和limits用途是什么?

最小分配资源,最大分配资源。限定业务容器使用资源的大小

kubeconfig文件包含什么内容,用途是什么?

apiserver地址等,链接apiserver的授权文件

RBAC中role和clusterrole区别,rolebinding和 clusterrolebinding区别?

rolebinding对特定名称空间下的资源进行绑定授权,而clusterrole则是属于对整个集群资源的绑定授权

ipvs为啥比iptables效率高?

在运行超过一千个服务下两者都几乎是相同的表现,但是一千个服务以上,ipvs会比iptables好一些,抛开性能问题不谈,ipvs还有更多的负载均衡算法可供选择,其实iptables也可以达成负载均衡,但是我看过哪个iptables实现负载均衡的流程。单语句就多的可怕。

sc pv pvc用途,容器挂载存储整个流程是什么?

创建pv,创建pvc关联PV,创建pod关联去申请PVC。

nginx ingress的原理本质是什么?

nginx的反向代理

网络类型,描述不同node上的Pod之间的通信流程

k8s集群节点需要关机维护,需要怎么操作

打污点,驱除pod,

启动一个Deployment,Kubernetes做了什么?

1:简述ETCD及其特点?

etcd 是 CoreOS 团队发起的开源项目,是一个管理配置信息和服务发现(service discovery)的项目,它的目标是构建一个高可用的分布式键值(key-value)数据库,基于 Go 语言实现。

特点:

简单:支持 REST 风格的 HTTP+JSON API
安全:支持 HTTPS 方式的访问
快速:支持并发 1k/s 的写操作
可靠:支持分布式结构,基于 Raft 的一致性算法,Raft 是一套通过选举主节点来实现分布式系统一致性的算法。

2:简述ETCD适应的场景?

etcd基于其优秀的特点,可广泛的应用于以下场景:

服务发现(Service Discovery):服务发现主要解决在同一个分布式集群中的进程或服务,要如何才能找到对方并建立连接。本质上来说,服务发现就是想要了解集群中是否有进程在监听udp或tcp端口,并且通过名字就可以查找和连接。
消息发布与订阅:在分布式系统中,最适用的一种组件间通信方式就是消息发布与订阅。即构建一个配置共享中心,数据提供者在这个配置中心发布消息,而消息使用者则订阅他们关心的主题,一旦主题有消息发布,就会实时通知订阅者。通过这种方式可以做到分布式系统配置的集中式管理与动态更新。应用中用到的一些配置信息放到etcd上进行集中管理。
负载均衡:在分布式系统中,为了保证服务的高可用以及数据的一致性,通常都会把数据和服务部署多份,以此达到对等服务,即使其中的某一个服务失效了,也不影响使用。etcd本身分布式架构存储的信息访问支持负载均衡。etcd集群化以后,每个etcd的核心节点都可以处理用户的请求。所以,把数据量小但是访问频繁的消息数据直接存储到etcd中也可以实现负载均衡的效果。
分布式通知与协调:与消息发布和订阅类似,都用到了etcd中的Watcher机制,通过注册与异步通知机制,实现分布式环境下不同系统之间的通知与协调,从而对数据变更做到实时处理。
分布式锁:因为etcd使用Raft算法保持了数据的强一致性,某次操作存储到集群中的值必然是全局一致的,所以很容易实现分布式锁。锁服务有两种使用方式,一是保持独占,二是控制时序。
集群监控与Leader竞选:通过etcd来进行监控实现起来非常简单并且实时性强。

3:简述什么是Kubernetes?

Kubernetes是一个全新的基于容器技术的分布式系统支撑平台。是Google开源的容器集群管理系统(谷歌内部:Borg)。在Docker技术的基础上,为容器化的应用提供部署运行、资源调度、服务发现和动态伸缩等一系列完整功能,提高了大规模容器集群管理的便捷性。并且具有完备的集群管理能力,多层次的安全防护和准入机制、多租户应用支撑能力、透明的服务注册和发现机制、內建智能负载均衡器、强大的故障发现和自我修复能力、服务滚动升级和在线扩容能力、可扩展的资源自动调度机制以及多粒度的资源配额管理能力。

4:简述Kubernetes和Docker的关系?

Docker 提供容器的生命周期管理和,Docker 镜像构建运行时容器。它的主要优点是将将软件/应用程序运行所需的设置和依赖项打包到一个容器中,从而实现了可移植性等优点。

Kubernetes 用于关联和编排在多个主机上运行的容器。

5:简述Kubernetes中什么是Minikube、Kubectl、Kubelet?

Minikube 是一种可以在本地轻松运行一个单节点 Kubernetes 群集的工具。

Kubectl 是一个命令行工具,可以使用该工具控制Kubernetes集群管理器,如检查群集资源,创建、删除和更新组件,查看应用程序。

Kubelet 是一个代理服务,它在每个节点上运行,并使从服务器与主服务器通信。

6:简述Kubernetes常见的部署方式

常见的Kubernetes部署方式有:

kubeadm:也是推荐的一种部署方式
二进制:CentOS 搭建 K8S,一次性成功,收藏了!
minikube:在本地轻松运行一个单节点 Kubernetes 群集的工具。

7:简述Kubernetes如何实现集群管理?

在集群管理方面,Kubernetes将集群中的机器划分为一个Master节点和一群工作节点Node。其中,在Master节点运行着集群管理相关的一组进程kube-apiserver、kube-controller-manager和kube-scheduler,这些进程实现了整个集群的资源管理、Pod调度、弹性伸缩、安全控制、系统监控和纠错等管理能力,并且都是全自动完成的。推荐大家看看:轻松管理 Kubernetes 集群的7个工具。

8:简述Kubernetes的优势、适应场景及其特点?

Kubernetes作为一个完备的分布式系统支撑平台,其主要优势:

容器编排
轻量级
开源
弹性伸缩
负载均衡

9:Kubernetes常见场景

快速部署应用
快速扩展应用
无缝对接新的应用功能
节省资源,优化硬件资源的使用

10:Kubernetes相关特点

可移植: 支持公有云、私有云、混合云、多重云(multi-cloud)。
可扩展: 模块化,、插件化、可挂载、可组合。
自动化: 自动部署、自动重启、自动复制、自动伸缩/扩展。

11:简述Kubernetes的缺点或当前的不足之处?

Kubernetes当前存在的缺点(不足)如下:

安装过程和配置相对困难复杂。
管理服务相对繁琐。
运行和编译需要很多时间。
它比其他替代品更昂贵。
对于简单的应用程序来说,可能不需要涉及Kubernetes即可满足。

12:简述Kubernetes相关基础概念?

master:k8s集群的管理节点,负责管理集群,提供集群的资源数据访问入口。拥有Etcd存储服务(可选),运行Api Server进程,Controller Manager服务进程及Scheduler服务进程。

node(worker):Node(worker)是Kubernetes集群架构中运行Pod的服务节点,是Kubernetes集群操作的单元,用来承载被分配Pod的运行,是Pod运行的宿主机。运行docker eninge服务,守护进程kunelet及负载均衡器kube-proxy。

pod:运行于Node节点上,若干相关容器的组合(Kubernetes 之 Pod 实现原理)。Pod内包含的容器运行在同一宿主机上,使用相同的网络命名空间、IP地址和端口,能够通过localhost进行通信。Pod是Kurbernetes进行创建、调度和管理的最小单位,它提供了比容器更高层次的抽象,使得部署和管理更加灵活。一个Pod可以包含一个容器或者多个相关容器。

label:Kubernetes中的Label实质是一系列的Key/Value键值对,其中key与value可自定义。Label可以附加到各种资源对象上,如Node、Pod、Service、RC等。一个资源对象可以定义任意数量的Label,同一个Label也可以被添加到任意数量的资源对象上去。Kubernetes通过Label Selector(标签选择器)查询和筛选资源对象。

Replication Controller:Replication Controller用来管理Pod的副本,保证集群中存在指定数量的Pod副本。集群中副本的数量大于指定数量,则会停止指定数量之外的多余容器数量。反之,则会启动少于指定数量个数的容器,保证数量不变。Replication Controller是实现弹性伸缩、动态扩容和滚动升级的核心。

Deployment:Deployment在内部使用了RS来实现目的,Deployment相当于RC的一次升级,其最大的特色为可以随时获知当前Pod的部署进度。

HPA(Horizontal Pod Autoscaler):Pod的横向自动扩容,也是Kubernetes的一种资源,通过追踪分析RC控制的所有Pod目标的负载变化情况,来确定是否需要针对性的调整Pod副本数量。

Service:Service(Kubernetes 之服务发现)定义了Pod的逻辑集合和访问该集合的策略,是真实服务的抽象。Service提供了一个统一的服务访问入口以及服务代理和发现机制,关联多个相同Label的Pod,用户不需要了解后台Pod是如何运行。

Volume:Volume是Pod中能够被多个容器访问的共享目录,Kubernetes中的Volume是定义在Pod上,可以被一个或多个Pod中的容器挂载到某个目录下。

Namespace:Namespace用于实现多租户的资源隔离,可将集群内部的资源对象分配到不同的Namespace中,形成逻辑上的不同项目、小组或用户组,便于不同的Namespace在共享使用整个集群的资源的同时还能被分别管理。

13:简述Kubernetes集群相关组件?

Kubernetes Master控制组件,调度管理整个系统(集群),包含如下组件:

Kubernetes API Server:作为Kubernetes系统的入口,其封装了核心对象的增删改查操作,以RESTful API接口方式提供给外部客户和内部组件调用,集群内各个功能模块之间数据交互和通信的中心枢纽。

Kubernetes Scheduler:为新建立的Pod进行节点(node)选择(即分配机器),负责集群的资源调度。

Kubernetes Controller:负责执行各种控制器,目前已经提供了很多控制器来保证Kubernetes的正常运行。

Replication Controller:管理维护Replication Controller,关联Replication Controller和Pod,保证Replication Controller定义的副本数量与实际运行Pod数量一致。

Node Controller:管理维护Node,定期检查Node的健康状态,标识出(失效|未失效)的Node节点。

Namespace Controller:管理维护Namespace,定期清理无效的Namespace,包括Namesapce下的API对象,比如Pod、Service等。

Service Controller:管理维护Service,提供负载以及服务代理。

EndPoints Controller:管理维护Endpoints,关联Service和Pod,创建Endpoints为Service的后端,当Pod发生变化时,实时更新Endpoints。

Service Account Controller:管理维护Service Account,为每个Namespace创建默认的Service Account,同时为Service Account创建Service Account Secret。

Persistent Volume Controller:管理维护Persistent Volume和Persistent Volume Claim,为新的Persistent Volume Claim分配Persistent Volume进行绑定,为释放的Persistent Volume执行清理回收。

Daemon Set Controller:管理维护Daemon Set,负责创建Daemon Pod,保证指定的Node上正常的运行Daemon Pod。

Deployment Controller:管理维护Deployment,关联Deployment和Replication Controller,保证运行指定数量的Pod。当Deployment更新时,控制实现Replication Controller和Pod的更新。

Job Controller:管理维护Job,为Jod创建一次性任务Pod,保证完成Job指定完成的任务数目

Pod Autoscaler Controller:实现Pod的自动伸缩,定时获取监控数据,进行策略匹配,当满足条件时执行Pod的伸缩动作。

14:简述Kubernetes RC的机制?

Replication Controller用来管理Pod的副本,保证集群中存在指定数量的Pod副本。当定义了RC并提交至Kubernetes集群中之后,Master节点上的Controller Manager组件获悉,并同时巡检系统中当前存活的目标Pod,并确保目标Pod实例的数量刚好等于此RC的期望值,若存在过多的Pod副本在运行,系统会停止一些Pod,反之则自动创建一些Pod。

简述Kubernetes Replica Set 和 Replication Controller 之间有什么区别?Replica Set 和 Replication Controller 类似,都是确保在任何给定时间运行指定数量的 Pod 副本。不同之处在于RS 使用基于集合的选择器,而 Replication Controller 使用基于权限的选择器。

15:简述kube-proxy作用?

kube-proxy 运行在所有节点上,它监听 apiserver 中 service 和 endpoint 的变化情况,创建路由规则以提供服务 IP 和负载均衡功能。简单理解此进程是Service的透明代理兼负载均衡器,其核心功能是将到某个Service的访问请求转发到后端的多个Pod实例上。

16:简述kube-proxy iptables原理?

Kubernetes从1.2版本开始,将iptables作为kube-proxy的默认模式。iptables模式下的kube-proxy不再起到Proxy的作用,其核心功能:通过API Server的Watch接口实时跟踪Service与Endpoint的变更信息,并更新对应的iptables规则,Client的请求流量则通过iptables的NAT机制“直接路由”到目标Pod。

17:简述kube-proxy ipvs原理?

IPVS在Kubernetes1.11中升级为GA稳定版。IPVS则专门用于高性能负载均衡,并使用更高效的数据结构(Hash表),允许几乎无限的规模扩张,因此被kube-proxy采纳为最新模式。

在IPVS模式下,使用iptables的扩展ipset,而不是直接调用iptables来生成规则链。iptables规则链是一个线性的数据结构,ipset则引入了带索引的数据结构,因此当规则很多时,也可以很高效地查找和匹配。

可以将ipset简单理解为一个IP(段)的集合,这个集合的内容可以是IP地址、IP网段、端口等,iptables可以直接添加规则对这个“可变的集合”进行操作,这样做的好处在于可以大大减少iptables规则的数量,从而减少性能损耗。

18:简述kube-proxy ipvs和iptables的异同?

iptables与IPVS都是基于Netfilter实现的,但因为定位不同,二者有着本质的差别:iptables是为防火墙而设计的;IPVS则专门用于高性能负载均衡,并使用更高效的数据结构(Hash表),允许几乎无限的规模扩张。

与iptables相比,IPVS拥有以下明显优势:

1、为大型集群提供了更好的可扩展性和性能;
2、支持比iptables更复杂的复制均衡算法(最小负载、最少连接、加权等);
3、支持服务器健康检查和连接重试等功能;
4、可以动态修改ipset的集合,即使iptables的规则正在使用这个集合。

19:简述Kubernetes中什么是静态Pod?

静态pod是由kubelet进行管理的仅存在于特定Node的Pod上,他们不能通过API Server进行管理,无法与ReplicationController、Deployment或者DaemonSet进行关联,并且kubelet无法对他们进行健康检查。静态Pod总是由kubelet进行创建,并且总是在kubelet所在的Node上运行。

20:简述Kubernetes中Pod可能位于的状态?

Pending:API Server已经创建该Pod,且Pod内还有一个或多个容器的镜像没有创建,包括正在下载镜像的过程。
Running:Pod内所有容器均已创建,且至少有一个容器处于运行状态、正在启动状态或正在重启状态。
Succeeded:Pod内所有容器均成功执行退出,且不会重启。
Failed:Pod内所有容器均已退出,但至少有一个容器退出为失败状态。
Unknown:由于某种原因无法获取该Pod状态,可能由于网络通信不畅导致。

21:简述Kubernetes创建一个Pod的主要流程?

Kubernetes中创建一个Pod涉及多个组件之间联动,主要流程如下:

1、客户端提交Pod的配置信息(可以是yaml文件定义的信息)到kube-apiserver。
2、Apiserver收到指令后,通知给controller-manager创建一个资源对象。
3、Controller-manager通过api-server将pod的配置信息存储到ETCD数据中心中。
4、Kube-scheduler检测到pod信息会开始调度预选,会先过滤掉不符合Pod资源配置要求的节点,然后开始调度调优,主要是挑选出更适合运行pod的节点,然后将pod的资源配置单发送到node节点上的kubelet组件上。
5、Kubelet根据scheduler发来的资源配置单运行pod,运行成功后,将pod的运行信息返回给scheduler,scheduler将返回的pod运行状况的信息存储到etcd数据中心。

22:简述Kubernetes中Pod的重启策略?

Pod重启策略(RestartPolicy)应用于Pod内的所有容器,并且仅在Pod所处的Node上由kubelet进行判断和重启操作。当某个容器异常退出或者健康检查失败时,kubelet将根据RestartPolicy的设置来进行相应操作。

Pod的重启策略包括Always、OnFailure和Never,默认值为Always。

Always:当容器失效时,由kubelet自动重启该容器;
OnFailure:当容器终止运行且退出码不为0时,由kubelet自动重启该容器;
Never:不论容器运行状态如何,kubelet都不会重启该容器。

同时Pod的重启策略与控制方式关联,当前可用于管理Pod的控制器包括ReplicationController、Job、DaemonSet及直接管理kubelet管理(静态Pod)。
不同控制器的重启策略限制如下:

RC和DaemonSet:必须设置为Always,需要保证该容器持续运行;
Job:OnFailure或Never,确保容器执行完成后不再重启;
kubelet:在Pod失效时重启,不论将RestartPolicy设置为何值,也不会对Pod进行健康检查。

23:简述Kubernetes中Pod的健康检查方式?

对Pod的健康检查可以通过两类探针来检查:LivenessProbe和ReadinessProbe。

LivenessProbe探针:用于判断容器是否存活(running状态),如果LivenessProbe探针探测到容器不健康,则kubelet将杀掉该容器,并根据容器的重启策略做相应处理。若一个容器不包含LivenessProbe探针,kubelet认为该容器的LivenessProbe探针返回值用于是“Success”。

ReadineeProbe探针:用于判断容器是否启动完成(ready状态)。如果ReadinessProbe探针探测到失败,则Pod的状态将被修改。Endpoint Controller将从Service的Endpoint中删除包含该容器所在Pod的Eenpoint。

startupProbe探针:启动检查机制,应用一些启动缓慢的业务,避免业务长时间启动而被上面两类探针kill掉。

24:简述Kubernetes Pod的LivenessProbe探针的常见方式?

kubelet定期执行LivenessProbe探针来诊断容器的健康状态,通常有以下三种方式:

ExecAction:在容器内执行一个命令,若返回码为0,则表明容器健康。

TCPSocketAction:通过容器的IP地址和端口号执行TCP检查,若能建立TCP连接,则表明容器健康。

HTTPGetAction:通过容器的IP地址、端口号及路径调用HTTP Get方法,若响应的状态码大于等于200且小于400,则表明容器健康。

25:简述Kubernetes Pod的常见调度方式?

Kubernetes中,Pod通常是容器的载体,主要有如下常见调度方式:

Deployment或RC:该调度策略主要功能就是自动部署一个容器应用的多份副本,以及持续监控副本的数量,在集群内始终维持用户指定的副本数量。
NodeSelector:定向调度,当需要手动指定将Pod调度到特定Node上,可以通过Node的标签(Label)和Pod的nodeSelector属性相匹配。
NodeAffinity亲和性调度:亲和性调度机制极大的扩展了Pod的调度能力,目前有两种节点亲和力表达:
requiredDuringSchedulingIgnoredDuringExecution:硬规则,必须满足指定的规则,调度器才可以调度Pod至Node上(类似nodeSelector,语法不同)。
preferredDuringSchedulingIgnoredDuringExecution:软规则,优先调度至满足的Node的节点,但不强求,多个优先级规则还可以设置权重值。
Taints和Tolerations(污点和容忍):
Taint:使Node拒绝特定Pod运行;
Toleration:为Pod的属性,表示Pod能容忍(运行)标注了Taint的Node。

26:简述Kubernetes初始化容器(init container)?

init container的运行方式与应用容器不同,它们必须先于应用容器执行完成,当设置了多个init container时,将按顺序逐个运行,并且只有前一个init container运行成功后才能运行后一个init container。当所有init container都成功运行后,Kubernetes才会初始化Pod的各种信息,并开始创建和运行应用容器。

27:简述Kubernetes deployment升级过程?

初始创建Deployment时,系统创建了一个ReplicaSet,并按用户的需求创建了对应数量的Pod副本。

当更新Deployment时,系统创建了一个新的ReplicaSet,并将其副本数量扩展到1,然后将旧ReplicaSet缩减为2。

之后,系统继续按照相同的更新策略对新旧两个ReplicaSet进行逐个调整。

最后,新的ReplicaSet运行了对应个新版本Pod副本,旧的ReplicaSet副本数量则缩减为0。

28:简述Kubernetes deployment升级策略?

在Deployment的定义中,可以通过spec.strategy指定Pod更新的策略,目前支持两种策略:Recreate(重建)和RollingUpdate(滚动更新),默认值为RollingUpdate。

Recreate:设置spec.strategy.type=Recreate,表示Deployment在更新Pod时,会先杀掉所有正在运行的Pod,然后创建新的Pod。

RollingUpdate:设置spec.strategy.type=RollingUpdate,表示Deployment会以滚动更新的方式来逐个更新Pod。同时,可以通过设置spec.strategy.rollingUpdate下的两个参数(maxUnavailable和maxSurge)来控制滚动更新的过程。

29:简述Kubernetes DaemonSet类型的资源特性?

DaemonSet资源对象会在每个Kubernetes集群中的节点上运行,并且每个节点只能运行一个pod,这是它和deployment资源对象的最大也是唯一的区别。因此,在定义yaml文件中,不支持定义replicas。

它的一般使用场景如下:

在去做每个节点的日志收集工作。
监控每个节点的的运行状态。

30:简述Kubernetes自动扩容机制?

Kubernetes使用Horizontal Pod Autoscaler(HPA)的控制器实现基于CPU使用率进行自动Pod扩缩容的功能。HPA控制器周期性地监测目标Pod的资源性能指标,并与HPA资源对象中的扩缩容条件进行对比,在满足条件时对Pod副本数量进行调整。

HPA原理:

Kubernetes中的某个Metrics Server(Heapster或自定义Metrics Server)持续采集所有Pod副本的指标数据。HPA控制器通过Metrics Server的API(Heapster的API或聚合API)获取这些数据,基于用户定义的扩缩容规则进行计算,得到目标Pod副本数量。

当目标Pod副本数量与当前副本数量不同时,HPA控制器就向Pod的副本控制器(Deployment、RC或ReplicaSet)发起scale操作,调整Pod的副本数量,完成扩缩容操作。

31:简述Kubernetes Service类型?

通过创建Service,可以为一组具有相同功能的容器应用提供一个统一的入口地址,并且将请求负载分发到后端的各个容器应用上。其主要类型有:

ClusterIP:虚拟的服务IP地址,该地址用于Kubernetes集群内部的Pod访问,在Node上kube-proxy通过设置的iptables规则进行转发;
NodePort:使用宿主机的端口,使能够访问各Node的外部客户端通过Node的IP地址和端口号就能访问服务;
LoadBalancer:使用外接负载均衡器完成到服务的负载分发,需要在spec.status.loadBalancer字段指定外部负载均衡器的IP地址,通常用于公有云。

32:简述Kubernetes Service分发后端的策略?

Service负载分发的策略有:RoundRobin和SessionAffinity

RoundRobin:默认为轮询模式,即轮询将请求转发到后端的各个Pod上。

SessionAffinity:基于客户端IP地址进行会话保持的模式,即第1次将某个客户端发起的请求转发到后端的某个Pod上,之后从相同的客户端发起的请求都将被转发到后端相同的Pod上。

33:简述Kubernetes Headless Service?

在某些应用场景中,若需要人为指定负载均衡器,不使用Service提供的默认负载均衡的功能,或者应用程序希望知道属于同组服务的其他实例。Kubernetes提供了Headless Service来实现这种功能,即不为Service设置ClusterIP(入口IP地址),仅通过Label Selector将后端的Pod列表返回给调用的客户端。

34:简述Kubernetes外部如何访问集群内的服务?

对于Kubernetes,集群外的客户端默认情况,无法通过Pod的IP地址或者Service的虚拟IP地址:虚拟端口号进行访问。通常可以通过以下方式进行访问Kubernetes集群内的服务:

映射Pod到物理机:将Pod端口号映射到宿主机,即在Pod中采用hostPort方式,以使客户端应用能够通过物理机访问容器应用。

映射Service到物理机:将Service端口号映射到宿主机,即在Service中采用nodePort方式,以使客户端应用能够通过物理机访问容器应用。

映射Sercie到LoadBalancer:通过设置LoadBalancer映射到云服务商提供的LoadBalancer地址。这种用法仅用于在公有云服务提供商的云平台上设置Service的场景。

35:简述Kubernetes ingress?

Kubernetes的Ingress资源对象,用于将不同URL的访问请求转发到后端不同的Service,以实现HTTP层的业务路由机制。

Kubernetes使用了Ingress策略和Ingress Controller,两者结合并实现了一个完整的Ingress负载均衡器。使用Ingress进行负载分发时,Ingress Controller基于Ingress规则将客户端请求直接转发到Service对应的后端Endpoint(Pod)上,从而跳过kube-proxy的转发功能,kube-proxy不再起作用,全过程为:ingress controller + ingress 规则 ---- services。

同时当Ingress Controller提供的是对外服务,则实际上实现的是边缘路由器的功能。

36:简述Kubernetes镜像的下载策略?

K8s的镜像下载策略有三种:Always、Never、IFNotPresent。

Always:镜像标签为latest时,总是从指定的仓库中获取镜像。
Never:禁止从仓库中下载镜像,也就是说只能使用本地镜像。
IfNotPresent:仅当本地没有对应镜像时,才从目标仓库中下载。默认的镜像下载策略是:当镜像标签是latest时,默认策略是Always;当镜像标签是自定义时(也就是标签不是latest),那么默认策略是IfNotPresent。

37:简述Kubernetes的负载均衡器?

负载均衡器是暴露服务的最常见和标准方式之一。

根据工作环境使用两种类型的负载均衡器,即内部负载均衡器或外部负载均衡器。内部负载均衡器自动平衡负载并使用所需配置分配容器,而外部负载均衡器将流量从外部负载引导至后端容器。

38:简述Kubernetes各模块如何与API Server通信?

Kubernetes API Server作为集群的核心,负责集群各功能模块之间的通信。集群内的各个功能模块通过API Server将信息存入etcd,当需要获取和操作这些数据时,则通过API Server提供的REST接口(用GET、LIST或WATCH方法)来实现,从而实现各模块之间的信息交互。

如kubelet进程与API Server的交互:每个Node上的kubelet每隔一个时间周期,就会调用一次API Server的REST接口报告自身状态,API Server在接收到这些信息后,会将节点状态信息更新到etcd中。

如kube-controller-manager进程与API Server的交互:kube-controller-manager中的Node Controller模块通过API Server提供的Watch接口实时监控Node的信息,并做相应处理。

如kube-scheduler进程与API Server的交互:Scheduler通过API Server的Watch接口监听到新建Pod副本的信息后,会检索所有符合该Pod要求的Node列表,开始执行Pod调度逻辑,在调度成功后将Pod绑定到目标节点上。

39:简述Kubernetes Scheduler作用及实现原理?

Kubernetes Scheduler是负责Pod调度的重要功能模块,Kubernetes Scheduler在整个系统中承担了“承上启下”的重要功能,“承上”是指它负责接收Controller Manager创建的新Pod,为其调度至目标Node;“启下”是指调度完成后,目标Node上的kubelet服务进程接管后继工作,负责Pod接下来生命周期。

Kubernetes Scheduler的作用是将待调度的Pod(API新创建的Pod、Controller Manager为补足副本而创建的Pod等)按照特定的调度算法和调度策略绑定(Binding)到集群中某个合适的Node上,并将绑定信息写入etcd中。

在整个调度过程中涉及三个对象,分别是待调度Pod列表、可用Node列表,以及调度算法和策略。

Kubernetes Scheduler通过调度算法调度为待调度Pod列表中的每个Pod从Node列表中选择一个最适合的Node来实现Pod的调度。随后,目标节点上的kubelet通过API Server监听到Kubernetes Scheduler产生的Pod绑定事件,然后获取对应的Pod清单,下载Image镜像并启动容器。

40:简述Kubernetes Scheduler使用哪两种算法将Pod绑定到worker节点?

Kubernetes Scheduler根据如下两种调度算法将 Pod 绑定到最合适的工作节点:

预选(Predicates):输入是所有节点,输出是满足预选条件的节点。kube-scheduler根据预选策略过滤掉不满足策略的Nodes。如果某节点的资源不足或者不满足预选策略的条件则无法通过预选。如“Node的label必须与Pod的Selector一致”。

优选(Priorities):输入是预选阶段筛选出的节点,优选会根据优先策略为通过预选的Nodes进行打分排名,选择得分最高的Node。例如,资源越富裕、负载越小的Node可能具有越高的排名。

41:简述Kubernetes kubelet的作用?

在Kubernetes集群中,在每个Node(又称Worker)上都会启动一个kubelet服务进程。该进程用于处理Master下发到本节点的任务,管理Pod及Pod中的容器。每个kubelet进程都会在API Server上注册节点自身的信息,定期向Master汇报节点资源的使用情况,并通过cAdvisor监控容器和节点资源。

42:简述Kubernetes kubelet监控Worker节点资源是使用什么组件来实现的?

kubelet使用cAdvisor对worker节点资源进行监控。在 Kubernetes 系统中,cAdvisor 已被默认集成到 kubelet 组件内,当 kubelet 服务启动时,它会自动启动 cAdvisor 服务,然后 cAdvisor 会实时采集所在节点的性能指标及在节点上运行的容器的性能指标。

43:简述Kubernetes如何保证集群的安全性?

Kubernetes通过一系列机制来实现集群的安全控制,主要有如下不同的维度:

基础设施方面:保证容器与其所在宿主机的隔离;

权限方面:

最小权限原则:合理限制所有组件的权限,确保组件只执行它被授权的行为,通过限制单个组件的能力来限制它的权限范围。
用户权限:划分普通用户和管理员的角色。

集群方面:

API Server的认证授权:Kubernetes集群中所有资源的访问和变更都是通过Kubernetes API Server来实现的,因此需要建议采用更安全的HTTPS或Token来识别和认证客户端身份(Authentication),以及随后访问权限的授权(Authorization)环节。
API Server的授权管理:通过授权策略来决定一个API调用是否合法。对合法用户进行授权并且随后在用户访问时进行鉴权,建议采用更安全的RBAC方式来提升集群安全授权。
敏感数据引入Secret机制:对于集群敏感数据建议使用Secret方式进行保护。
AdmissionControl(准入机制):对kubernetes api的请求过程中,顺序为:先经过认证 & 授权,然后执行准入操作,最后对目标对象进行操作。

44:简述Kubernetes准入机制?

在对集群进行请求时,每个准入控制代码都按照一定顺序执行。如果有一个准入控制拒绝了此次请求,那么整个请求的结果将会立即返回,并提示用户相应的error信息。

准入控制(AdmissionControl)准入控制本质上为一段准入代码,在对kubernetes api的请求过程中,顺序为:先经过认证 & 授权,然后执行准入操作,最后对目标对象进行操作。常用组件(控制代码)如下:

AlwaysAdmit:允许所有请求
AlwaysDeny:禁止所有请求,多用于测试环境。
ServiceAccount:它将serviceAccounts实现了自动化,它会辅助serviceAccount做一些事情,比如如果pod没有serviceAccount属性,它会自动添加一个default,并确保pod的serviceAccount始终存在。
LimitRanger:观察所有的请求,确保没有违反已经定义好的约束条件,这些条件定义在namespace中LimitRange对象中。
NamespaceExists:观察所有的请求,如果请求尝试创建一个不存在的namespace,则这个请求被拒绝。

45:简述Kubernetes RBAC及其特点(优势)?

RBAC是基于角色的访问控制,是一种基于个人用户的角色来管理对计算机或网络资源的访问的方法。

相对于其他授权模式,RBAC具有如下优势:

对集群中的资源和非资源权限均有完整的覆盖。
整个RBAC完全由几个API对象完成, 同其他API对象一样, 可以用kubectl或API进行操作。
可以在运行时进行调整,无须重新启动API Server。

46:简述Kubernetes Secret作用?

Secret对象,主要作用是保管私密数据,比如密码、OAuth Tokens、SSH Keys等信息。将这些私密信息放在Secret对象中比直接放在Pod或Docker Image中更安全,也更便于使用和分发。

47:简述Kubernetes Secret有哪些使用方式?

创建完secret之后,可通过如下三种方式使用:

在创建Pod时,通过为Pod指定Service Account来自动使用该Secret。
通过挂载该Secret到Pod来使用它。
在Docker镜像下载时使用,通过指定Pod的spc.ImagePullSecrets来引用它。

48:简述Kubernetes PodSecurityPolicy机制?

Kubernetes PodSecurityPolicy是为了更精细地控制Pod对资源的使用方式以及提升安全策略。在开启PodSecurityPolicy准入控制器后,Kubernetes默认不允许创建任何Pod,需要创建PodSecurityPolicy策略和相应的RBAC授权策略(Authorizing Policies),Pod才能创建成功。

49:简述Kubernetes PodSecurityPolicy机制能实现哪些安全策略?

在PodSecurityPolicy对象中可以设置不同字段来控制Pod运行时的各种安全策略,常见的有:

特权模式:privileged是否允许Pod以特权模式运行。
宿主机资源:控制Pod对宿主机资源的控制,如hostPID:是否允许Pod共享宿主机的进程空间。
用户和组:设置运行容器的用户ID(范围)或组(范围)。
提升权限:AllowPrivilegeEscalation:设置容器内的子进程是否可以提升权限,通常在设置非root用户(MustRunAsNonRoot)时进行设置。
SELinux:进行SELinux的相关配置。    

50:简述Kubernetes网络模型?

Kubernetes网络模型中每个Pod都拥有一个独立的IP地址,并假定所有Pod都在一个可以直接连通的、扁平的网络空间中。所以不管它们是否运行在同一个Node(宿主机)中,都要求它们可以直接通过对方的IP进行访问。设计这个原则的原因是,用户不需要额外考虑如何建立Pod之间的连接,也不需要考虑如何将容器端口映射到主机端口等问题。

同时为每个Pod都设置一个IP地址的模型使得同一个Pod内的不同容器会共享同一个网络命名空间,也就是同一个Linux网络协议栈。这就意味着同一个Pod内的容器可以通过localhost来连接对方的端口。

在Kubernetes的集群里,IP是以Pod为单位进行分配的。一个Pod内部的所有容器共享一个网络堆栈(相当于一个网络命名空间,它们的IP地址、网络设备、配置等都是共享的)。

51:简述Kubernetes CNI模型?

CNI提供了一种应用容器的插件化网络解决方案,定义对容器网络进行操作和配置的规范,通过插件的形式对CNI接口进行实现。CNI仅关注在创建容器时分配网络资源,和在销毁容器时删除网络资源。在CNI模型中只涉及两个概念:容器和网络。

容器(Container):是拥有独立Linux网络命名空间的环境,例如使用Docker或rkt创建的容器。容器需要拥有自己的Linux网络命名空间,这是加入网络的必要条件。

网络(Network):表示可以互连的一组实体,这些实体拥有各自独立、唯一的IP地址,可以是容器、物理机或者其他网络设备(比如路由器)等。

对容器网络的设置和操作都通过插件(Plugin)进行具体实现,CNI插件包括两种类型:CNI Plugin和IPAM(IP Address Management)Plugin。CNI Plugin负责为容器配置网络资源,IPAM Plugin负责对容器的IP地址进行分配和管理。IPAM Plugin作为CNI Plugin的一部分,与CNI Plugin协同工作。

52:简述Kubernetes网络策略?

为实现细粒度的容器间网络访问隔离策略,Kubernetes引入Network Policy。

Network Policy的主要功能是对Pod间的网络通信进行限制和准入控制,设置允许访问或禁止访问的客户端Pod列表。Network Policy定义网络策略,配合策略控制器(Policy Controller)进行策略的实现。

53:简述Kubernetes网络策略原理?

Network Policy的工作原理主要为:policy controller需要实现一个API Listener,监听用户设置的Network Policy定义,并将网络访问规则通过各Node的Agent进行实际设置(Agent则需要通过CNI网络插件实现)。

54:简述Kubernetes中flannel的作用?

Flannel可以用于Kubernetes底层网络的实现,主要作用有:

它能协助Kubernetes,给每一个Node上的Docker容器都分配互相不冲突的IP地址。
它能在这些IP地址之间建立一个覆盖网络(Overlay Network),通过这个覆盖网络,将数据包原封不动地传递到目标容器内。

55:简述Kubernetes Calico网络组件实现原理?

Calico是一个基于BGP的纯三层的网络方案,与OpenStack、Kubernetes、AWS、GCE等云平台都能够良好地集成。

Calico在每个计算节点都利用Linux Kernel实现了一个高效的vRouter来负责数据转发。每个vRouter都通过BGP协议把在本节点上运行的容器的路由信息向整个Calico网络广播,并自动设置到达其他节点的路由转发规则。

Calico保证所有容器之间的数据流量都是通过IP路由的方式完成互联互通的。Calico节点组网时可以直接利用数据中心的网络结构(L2或者L3),不需要额外的NAT、隧道或者Overlay Network,没有额外的封包解包,能够节约CPU运算,提高网络效率。

56:简述Kubernetes共享存储的作用?

Kubernetes对于有状态的容器应用或者对数据需要持久化的应用,因此需要更加可靠的存储来保存应用产生的重要数据,以便容器应用在重建之后仍然可以使用之前的数据。因此需要使用共享存储。

57:简述Kubernetes数据持久化的方式有哪些?

Kubernetes 通过数据持久化来持久化保存重要数据,常见的方式有:

EmptyDir(空目录):没有指定要挂载宿主机上的某个目录,直接由Pod内保部映射到宿主机上。类似于docker中的manager volume。
场景:

只需要临时将数据保存在磁盘上,比如在合并/排序算法中;
作为两个容器的共享存储。

特性:

同个pod里面的不同容器,共享同一个持久化目录,当pod节点删除时,volume的数据也会被删除。
emptyDir的数据持久化的生命周期和使用的pod一致,一般是作为临时存储使用。

Hostpath:将宿主机上已存在的目录或文件挂载到容器内部。类似于docker中的bind mount挂载方式。

特性:增加了pod与节点之间的耦合。

PersistentVolume(简称PV):如基于NFS服务的PV,也可以基于GFS的PV。它的作用是统一数据持久化目录,方便管理。

58:简述Kubernetes PV和PVC?

PV是对底层网络共享存储的抽象,将共享存储定义为一种“资源”。

PVC则是用户对存储资源的一个“申请”。

59:简述Kubernetes PV生命周期内的阶段?

某个PV在生命周期中可能处于以下4个阶段(Phaes)之一。

Available:可用状态,还未与某个PVC绑定。
Bound:已与某个PVC绑定。
Released:绑定的PVC已经删除,资源已释放,但没有被集群回收。
Failed:自动资源回收失败。    

60:简述Kubernetes所支持的存储供应模式?

Kubernetes支持两种资源的存储供应模式:静态模式(Static)和动态模式(Dynamic)。

静态模式:集群管理员手工创建许多PV,在定义PV时需要将后端存储的特性进行设置。

动态模式:集群管理员无须手工创建PV,而是通过StorageClass的设置对后端存储进行描述,标记为某种类型。此时要求PVC对存储的类型进行声明,系统将自动完成PV的创建及与PVC的绑定。

61:简述Kubernetes CSI模型?

Kubernetes CSI是Kubernetes推出与容器对接的存储接口标准,存储提供方只需要基于标准接口进行存储插件的实现,就能使用Kubernetes的原生存储机制为容器提供存储服务。CSI使得存储提供方的代码能和Kubernetes代码彻底解耦,部署也与Kubernetes核心组件分离,显然,存储插件的开发由提供方自行维护,就能为Kubernetes用户提供更多的存储功能,也更加安全可靠。

CSI包括CSI Controller和CSI Node:

CSI Controller的主要功能是提供存储服务视角对存储资源和存储卷进行管理和操作。
CSI Node的主要功能是对主机(Node)上的Volume进行管理和操作。

62:简述Kubernetes Worker节点加入集群的过程?

通常需要对Worker节点进行扩容,从而将应用系统进行水平扩展。主要过程如下:

1、在该Node上安装Docker、kubelet和kube-proxy服务;
2、然后配置kubelet和kubeproxy的启动参数,将Master URL指定为当前Kubernetes集群Master的地址,最后启动这些服务;
3、通过kubelet默认的自动注册机制,新的Worker将会自动加入现有的Kubernetes集群中;
4、Kubernetes Master在接受了新Worker的注册之后,会自动将其纳入当前集群的调度范围。

63:简述Kubernetes Pod如何实现对节点的资源控制?

Kubernetes集群里的节点提供的资源主要是计算资源,计算资源是可计量的能被申请、分配和使用的基础资源。当前Kubernetes集群中的计算资源主要包括CPU、GPU及Memory。CPU与Memory是被Pod使用的,因此在配置Pod时可以通过参数CPU Request及Memory Request为其中的每个容器指定所需使用的CPU与Memory量,Kubernetes会根据Request的值去查找有足够资源的Node来调度此Pod。

通常,一个程序所使用的CPU与Memory是一个动态的量,确切地说,是一个范围,跟它的负载密切相关:负载增加时,CPU和Memory的使用量也会增加。

64:简述Kubernetes Requests和Limits如何影响Pod的调度?

当一个Pod创建成功时,Kubernetes调度器(Scheduler)会为该Pod选择一个节点来执行。对于每种计算资源(CPU和Memory)而言,每个节点都有一个能用于运行Pod的最大容量值。调度器在调度时,首先要确保调度后该节点上所有Pod的CPU和内存的Requests总和,不超过该节点能提供给Pod使用的CPU和Memory的最大容量值。

65:简述Kubernetes Metric Service?

在Kubernetes从1.10版本后采用Metrics Server作为默认的性能数据采集和监控,主要用于提供核心指标(Core Metrics),包括Node、Pod的CPU和内存使用指标。

对其他自定义指标(Custom Metrics)的监控则由Prometheus等组件来完成。

66:简述Kubernetes中,如何使用EFK实现日志的统一管理?

在Kubernetes集群环境中,通常一个完整的应用或服务涉及组件过多,建议对日志系统进行集中化管理,通常采用EFK实现。

EFK是 Elasticsearch、Fluentd 和 Kibana 的组合,其各组件功能如下:

Elasticsearch:是一个搜索引擎,负责存储日志并提供查询接口;
Fluentd:负责从 Kubernetes 搜集日志,每个node节点上面的fluentd监控并收集该节点上面的系统日志,并将处理过后的日志信息发送给Elasticsearch;
Kibana:提供了一个 Web GUI,用户可以浏览和搜索存储在 Elasticsearch 中的日志。

通过在每台node上部署一个以DaemonSet方式运行的fluentd来收集每台node上的日志。Fluentd将docker日志目录/var/lib/docker/containers和/var/log目录挂载到Pod中,然后Pod会在node节点的/var/log/pods目录中创建新的目录,可以区别不同的容器日志输出,该目录下有一个日志文件链接到/var/lib/docker/contianers目录下的容器日志输出。

67:简述Kubernetes如何进行优雅的节点关机维护?

由于Kubernetes节点运行大量Pod,因此在进行关机维护之前,建议先使用kubectl drain将该节点的Pod进行驱逐,然后进行关机维护。

68:简述Kubernetes集群联邦?

Kubernetes集群联邦可以将多个Kubernetes集群作为一个集群进行管理。因此,可以在一个数据中心/云中创建多个Kubernetes集群,并使用集群联邦在一个地方控制/管理所有集群。

69:简述Helm及其优势?

Helm 是 Kubernetes 的软件包管理工具。类似 Ubuntu 中使用的apt、Centos中使用的yum 或者Python中的 pip 一样。

Helm能够将一组K8S资源打包统一管理, 是查找、共享和使用为Kubernetes构建的软件的最佳方式。

Helm中通常每个包称为一个Chart,一个Chart是一个目录(一般情况下会将目录进行打包压缩,形成name-version.tgz格式的单一文件,方便传输和存储)。

Helm优势
在 Kubernetes中部署一个可以使用的应用,需要涉及到很多的 Kubernetes 资源的共同协作。使用helm则具有如下优势:

统一管理、配置和更新这些分散的 k8s 的应用资源文件;
分发和复用一套应用模板;
将应用的一系列资源当做一个软件包管理。
对于应用发布者而言,可以通过 Helm 打包应用、管理应用依赖关系、管理应用版本并发布应用到软件仓库。
对于使用者而言,使用 Helm 后不用需要编写复杂的应用部署文件,可以以简单的方式在 Kubernetes 上查找、安装、升级、回滚、卸载应用程序。

1、什么是k8s?

kubernetes是google在2014年开源的一个容器集群管理系统,简称k8s。k8s应用于容器化应用程序的部署,扩展和管理,目标是让部署容器化应用简单高效。

2、有了docker为什么还要用k8s?

因为docker是单机无法集群,如果docker容器成规模的话,需要投入大量的管理成本,而k8s可以对docker进行集群编排,可以大规模的对docker容器进行管理,例如增删改查、弹性伸缩、负载均衡等等。所以说k8s是用来管理docker的,是相辅相成的关系。

3、master节点和node节点的作用?

master节点是集群控制节点,负责整个集群的控制和管理,基本上kubernetes所有的控制命令都是发给它的,由master节点负责具体的执行过程,所有执行的命令都是在master上执行的。

node节点是工作负载节点,每个node都会被master分配一些工作负载,当某个node宕机,其上的工作负载就会被master自动转移到其他的节点上。

4、k8s组件以及组件功能?

①APIserser:集群的统一入口,集群中各组件的协调者,以restful api接口方式提供给外部客户和内部组件使用,在APIserver中封装了核心对象的增删改查操作,所有对象资源的增删改查和监听操作都交给APIserver处理后再提交到ETCD数据库中。

②scheduler:k8s调度器,根据调度算法为新建立的pod进行节点选择,负责集群的资源调度。也就是说scheduler决定了副本创建在哪个节点上。

③controller-manager:控制器经理,处理集群中常规后台任务,一个资源对应一个控制器,controller-manager就是负责管理这些控制器的。

④etcd:NOSQL数据库,持久化储存,存储k8s所有组件,以及容器的信息,例如访问方式、副本数量、副本位置等。

④kubelet:负责管控容器,kubelet会从api server接受pod的创建请求,启动和停止容器,监控容器的运行状态并汇报给api server。

⑤kube-proxy:负责为pod创建代理服务,kube-proxy会从api server获取所有的service信息,并根据service的信息创建代理服务,实现service到pod的请求路由和转发,从而实现kubernetes层级的虚拟转发网络。

⑥docker engine:docker引擎,负责本机的容器创建和管理工作

5、k8s的特点?

服务发现与负载均衡

存储编排

批量执行

水平扩容

服务拓扑

自动化上线和回滚

自我修复

IPV4和IPV6双协议栈

6、什么是etcd?

etcd是CoreOS团队于2013年6月发起的开源项目,它的目标是构建一个高可用的分布式键值(key-value)数据库。在k8s集群中,负责持久化存储k8s所有的组件以及容器的信息,例如访问方式、副本数量、副本位置等。

7、kube-proxy四层负载和ingress七层负载是什么?

service是四层负载均衡,基于IP+端口进行负载均衡

ingress为七层负载均衡,就是基于URL等应用层信息的负载均衡

8、service的暴露方式?

clusetrIP:在集群内部建立一个稳定的IP地址,只能在集群内部使用,外部无法访问

NodePort:在每个节点上暴露一个端口,也会分配一个内部的IP,外部可以访问,端口范围为30000-32767

LoadBalancer:与NodePort类似,在每个节点上启用一个端口来暴露服务。除此之外,Kubernetes会请求底层云平台上的负载均衡器, 将每个Node([NodeIP]:[NodePort])作为后端添加进去。

9、docker网络原理?

首先创建一个docker0的网桥,使用veth pair创建一对虚拟网卡,一端放到新创建的容器中,并重命名eth0,另一端放到宿主机上,以veth+随机7个字符串命名,并将这个网络设备添加到docker0网桥中,网桥自动为容器分配一个IP,并设置docker0的IP为容器默认网关。所以容器默认网络都加入了这个网桥,因此都可以彼此通信,同时在iptables添加SNAT转换网络段IP,以便容器访问外网。

10、docker网络支持的模式有哪些?

①bridge:默认网络,IP地址段为172.17.0.1/16或者172.18.0.1/16

②host:容器不会获得一个独立的network namespace,而是与宿主机公用一个

③none:获取独立的network namespace,但不为容器进行任何网络配置

④container:与指定的容器使用同一个network namespace,网卡配置也都相同

⑤自定义:自定义网桥,默认与bridge网络一样

11、k8s中创建一个pod,组件是如何进行交互的?

kubectl提交指令给APIserver,APIserver通过etcd查重后,写入etcd中,scheduler接收到事件后,根据调度算法对要新建的pod打上标签,也就是说这个pod要创建到那个节点上,apiserver收到scheduler的调度结果后写入etcd中,node上的kubelet接收到事件后,从APIserver获得到pod的相关信息,然后调用docker api创建pod中所需的容器,创建完成后,kubelet会把这个pod的状态汇报给APIserver,APIserver把状态写入到etcd中。

10、pod的phase的几个状态?

pending(悬决)

running(运行中)

succeeded(成功)

failed(失败)

unknown(未知)

11、service存在的意义?

服务发现:因为在k8s集群中pod是短暂的,所以IP地址经常会发生变更,而service通过标签和pod进行绑定,所以不受IP改变影响。

负载均衡:service会对后方的pod进行四层负载均衡

12、service和pod的关系?

通过label和selecort进行相关联

pod通过service实现负载均衡

13、aufs是什么?

高级多层统一文件系统,是UFS的一种,每个branch可以指定读写和隐藏的权限,一般情况下,aufs只有最上层branch才有读写权限,其他branch均为只读。

14、service中NodePort的端口范围?

30000-32767

15、用户流量是如何到达pod的?

当用户流量到达宿主机后,iptables或者IPVS对该流量转发到相应的规则上去,最终达到pod

16、简述iptables和IPvs?

iptables灵活,功能强大,但是如果规则多的话转发较慢,因为是遍历匹配和更新。

IPVS推荐在大规模集群中使用,他工作在内核态,有更好的性能,而且调度算法丰富,例如rr(轮询),wrr(加权轮询),lc(最少连接),wlc(加权最少连接)等

17、简述TCP三次握手?

第一次握手:建立连接时,A发送syn包(syn=x)到B,并进入syn_sent状态,等待服务器确认。SYN:同步序列号(Synchronize Sequence Numbers)

第二次握手:B收到syn包,必须确认客户的syn(ack=x+1),同时自己也发送一个syn包(syn=y),即syn+ack包,此时B进入syn_recv状态;

第三次握手:A收到B的syn+ack包,向B发送确认包ack(ack=y+1),此包发送完毕以后,A和B进入established(tcp连接成功)状态,完成三次握手。

18、浏览器输入一个地址后,到展示页面中间经历了什么?

(1)浏览器刷入url,先解析url地址是否合法

(2)浏览器检查是否有缓存(浏览器缓存-系统缓存-路由器缓存),如果有,直接显示,如果没有,进行下一步

(3)在发送http请求前,需要域名解析,解析获取队形的IP地址

(4)浏览器向服务器发起tcp连接,与浏览器建立tcp三次握手。

(5)连接成功后,浏览器向服务器发送http请求,请求数据包

(6)服务器收到处理的请求,将数据返回至浏览器

(7)浏览器收到http响应

(8)浏览器解析响应,如果响应可以缓存,则存入缓存

(9)浏览器发送请求获取嵌入在html中的资源(html,css,javascript,图片,音乐等),对于未知类型,会弹出对话框

(10)浏览器发送异步请求

(11)页面全部渲染结束

19、简述lvs四层负载均衡?

20、简述haproxy七层负载均衡?

21、简述keepalived高可用集群?

22、简述正反向代理?

正向代理

只用于代理内部网络对Internet的连接请求,客户机必须指定代理服务器,并将本来要直接发送到Web服务器上的http请求发送到代理服务器中,正向代理指的是客户端代理,是由用户控制并知晓的代理方式,如我不能访问fb,然后使用了某国外服务器作为跳板机,最后成功访问了就是正向代理。

反向代理

指以代理服务器来接受Internet上的连接请求,然后将请求转发给内部网络上的服务器;并将从服务器上得到的结果返回给Internet上请求连接的客户端,此时代理服务器对外就表现为一个服务器,反向代理指的是服务端代理,在大型网站背后并不是只有一台机器提供服务,比如我访问微博,微博的某一个反向代理服务器将我解析到内部服务器的一台机器,然后这台机器给我提供微博的消息(当然实际情况比这个复杂的多),这些对于用户都是不可见的,我们只会感觉只有一台机器与我交互。

24、描述不同node上的Pod之间的通信过程?

25、CPU负载和CPU利用率有什么不同?

  • CPU利用率:显示的是程序在运行期间实时占用的CPU百分比
  • CPU负载:显示的是一段时间内正在使用和等待使用CPU的平均任务数。CPU利用率高,并不意味着负载就一定大。举例来说:如果我有一个程序它需要一直使用CPU的运算功能,那么此时CPU的使用率可能达到100%,但是CPU的工作负载则是趋近于“1”,因为CPU仅负责一个工作嘛!如果同时执行这样的程序两个呢?CPU的使用率还是100%,但是工作负载则变成2了。所以也就是说,当CPU的工作负载越大,代表CPU必须要在不同的工作之间进行频繁的工作切换。

26、pause有什么作用?

为每个容器提供以下功能

  • PID名称空间
  • 网络命名空间
  • IPC命名空间
  • UTS命名空间
  • Pod中各个容器可以访问在Pod级别定义得Volumes

29、Ingress都了解那些控制器?

  • Nginx Controller
  • Traefik

30、pod亲和力

因为在每个节点上都会暴露一个端口,那么每个节点就都需要一个公网IP,所以适合用于云平台

六、prometheus

prometheus对比zabbix有哪些优势?

Zabbix 的成熟度更高,上手更快,但更好的集成导致灵活性较差,问题更大是,监控数据的复杂度增加后,Zabbix 做进一步定制难度很高,即使做好了定制,也没法利用之前收集到的数据了(关系型数据库造成的问题)。Prometheus 基本上是正相反,上手难度大一些,但由于定制灵活度高,数据也有更多的聚合可能,起步后的使用难度远小于 Zabbix。但如果已经对传统监控系统有技术积累的话,还是要谨慎考虑更换监控。
物理机推荐zabbix,云环境推荐prometheus

prometheus组件有哪些,功能是什么?

Prometheus Server:
Prometheus组件中的核心部分,负责实现对监控数据的获取,存储以及查询。
Exporters:
Exporter将监控数据采集的端点通过HTTP服务的形式暴露给Prometheus Server,Prometheus Server通过访问该Exporter提供的Endpoint端点,即可获取到需要采集的监控数据。
AlertManager:
告警组件
PushGateway:
由于Prometheus数据采集基于Pull模型进行设计,因此在网络环境的配置上必须要让Prometheus Server能够直接与Exporter进行通信。

指标类型有哪些?

Counter(计数器):
Counter 类型代表一种样本数据单调递增的指标,即只增不减,除非监控系统发生了重置。
Guage(仪表盘):
Guage 类型代表一种样本数据可以任意变化的指标,即可增可减。guage 通常用于像温度或者内存使用率这种指标数据,也可以表示能随时增加或减少的“总数”,例如:当前并发请求的数量。
Histogram(直方图):固定时间段数据平均值
Summary(摘要):固定时间段数据平均值

在应对上千节点监控时,如何保障性能

根据业务需求,自定义exporter,取消不必要采集的值。或使用联邦,或者Thanos

(降低采集频率,缩小历史数据保存天数,使用集群联邦和远程存储)
简述从添加节点监控到grafana成图的整个流程

在节点安装好exporter之后,在prometheus配置采集任务。然后grafana添加数据源,然后新建dashborad或者导入Grafana官方模板。

在工作中用到了哪些exporter

mysql-exporter node-exporter Cadvisor redis-exporter

七、ELK

Elasticsearch的数据如何备份与恢复?

相应的有脚本

你们项目中使用的logstash过滤器插件是什么?实现哪些功能?

是否用到了filebeat的内置module?用了哪些?

没用

kibana如何自定义图表和仪表盘?

简单

elasticsearch分片副本是什么?你们配置的参数是多少?

八、运维开发

备份系统中所有镜像
编写脚本,定时备份某个库,然后压缩,发送异机

  1. (注意:①公共部分定义函数,如获取时间戳,配置报警接口②异常处理,如数据库大,检测任务是否完成。检测生成文件大小是否是空文件)
  2. 批量获取所有主机的系统信息
  3. t config
    1git gitlab jenkins的CICD流程如何配置

九、日常工作

在日常工作中遇到了什么棘手的问题,如何排查

(①redis弱口令导致中挖矿病毒,排查,优化②k8s中开发的程序在用户上传文件时开启进程,未及时关闭,导致节点超出最大进程数)

CDN文件http,莫名负载增高,es日志文件莫名达到十几个G,内存溢出。莫名机器故障重启。

日常故障处理流程

以首要恢复业务优先,其次查找故障原因,事故定则

修改线上业务配置文件流程

备份业务配置文件,并且附加相关备份说明。修改后的配置文件需增加相关修改注释

业务pv多少?集群规模多少?怎么保障业务高可用? 国内8w, 海外2w , 国内26(20),海外 10。微服务架构

十、开放性问题

你认为初级运维工程师和高级运维工程师的区别?(初级干活的,会操作,顺利完成领导安排的任务。高级优化架构,研究如何避免问题,研究新技术并引用)
你认为未来运维发展方向(自动化,智能化)

添加新评论