wordpress页面添加描述,百度优化培训,东莞网站定制,中国联合网络通信有限公司面试题可以参考:面试题总结
查看系统相关信息
查看系统登陆成功与失败记录
成功#xff1a;last失败#xff1a;lastb
查看二进制文件
hexdump查看进程端口或连接
netstat -nltp
ss -nltp补充#xff1a;pidof与lsof命令
pidof [进程名] #根据 进程名 查询进程id
ls…面试题可以参考:面试题总结
查看系统相关信息
查看系统登陆成功与失败记录
成功last失败lastb
查看二进制文件
hexdump查看进程端口或连接
netstat -nltp
ss -nltp补充pidof与lsof命令
pidof [进程名] #根据 进程名 查询进程id
lsof -i:[端口号] #根据 端口号 查询有哪些连接
lsof -p [进程id] #根据 进程id 查询有哪些连接
lsof -c [进程名称] #根据 进程名称 查询有哪些连接查看CPU相关信息
top 查看每个进程占用CPU的时间平均负载按1键查看每个cpu的具体使用情况按t将进程按照CPU的占用使用从大到小排序uptime 查看CPU的平均负载iostat 主要用来查看磁盘读写状态的也可以查看到cpu的平均负载情况
[rootk8s-master ~]# iostat
Linux 3.10.0-1160.92.1.el7.x86_64 (k8s-master) 11/26/2024 _x86_64_ (8 CPU)avg-cpu: %user %nice %system %iowait %steal %idle2.46 0.00 2.06 1.50 0.04 93.93Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn
sda 284.84 0.64 645.34 1007304 1017702772
sdb 201.55 2.49 711.40 3928223 1121874803
查看内存相关信息
free -h 最常用的系统命令vmstat 查看具体的使用情况
[rootk8s-master ~]# vmstat
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----r b swpd free buff cache si so bi bo in cs us sy id wa st2 0 0 1281692 4252 12091736 0 0 3 172 2 2 2 2 94 2 0查看磁盘相关信息
lsblkdf -Thiostat
查看网卡流量
iftop
我愿称这个命令为最强命令 可以非常清晰的看到每个流量的具体情况谁用谁知道
查看路由相关信息
查看路由
ip route show查看路由表
# 下面两个结果相同
route -n
netstat -nrwatch
[root3 ~]# watch ifconfig eth0Every 2.0s: ifconfig eth0 Sun May 1 21:53:10 2022eth0: flags4163UP,BROADCAST,RUNNING,MULTICAST mtu 1500inet 10.2.3.101 netmask 255.255.255.0 broadcast 10.2.3.255inet6 fe80::546f:77ff:fe6f:78 prefixlen 64 scopeid 0x20linkether 56:6f:77:6f:00:78 txqueuelen 1000 (Ethernet)RX packets 980997 bytes 63958819 (60.9 MiB)RX errors 0 dropped 140820 overruns 0 frame 0TX packets 109994 bytes 6171909 (5.8 MiB)TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0dstat
[root3 ~]# dstat
You did not select any stats, using -cdngy by default.
----total-cpu-usage---- -dsk/total- -net/total- ---paging-- ---system--
usr sys idl wai hiq siq| read writ| recv send| in out | int csw 0 0 100 0 0 0|1277B 1515B| 0 0 | 0 0 | 54 56 0 0 100 0 0 0| 0 0 | 485B 130B| 0 0 | 95 103 0 0 100 0 0 0| 0 0 | 348B 898B| 0 0 | 84 109 0 0 100 0 0 0| 0 0 | 449B 370B| 0 0 | 93 110 0 0 100 0 0 0| 0 0 | 450B 370B| 0 0 | 84 91 0 0 100 0 0 0| 0 0 | 467B 370B| 0 0 | 90 101 0 0 100 0 0 0| 0 0 | 306B 370B| 0 0 | 72 95 q0 0 100 0 0 0| 0 0 | 501B 740B| 0 0 | 69 92 0 0 100 0 0 0| 0 345k| 186B 130B| 0 0 | 78 101 0 0 100 0 0 0| 0 0 | 485B 370B| 0 0 | 70 90sysstat 此命令根据参数的不同,可以查看系统不同的信息,详情请见:https://linux.cn/article-4028-1.html 也可以参考百度文库:https://wenku.baidu.com/view/e89049fdcd2f0066f5335a8102d276a2002960e6.html [root3 ~]# yum -y install sysstat
[root3 ~]# sar -n DEV 1 2 // -n DEV表示查看网络信息,1表示一秒一次,2表示一共两次
Linux 3.10.0-957.el7.x86_64 (3.101-CentOS7.6) 05/01/2022 _x86_64_ (8 CPU)09:59:51 PM IFACE rxpck/s txpck/s rxkB/s txkB/s rxcmp/s txcmp/s rxmcst/s
09:59:52 PM eth0 6.00 0.00 0.42 0.00 0.00 0.00 0.00
09:59:52 PM lo 0.00 0.00 0.00 0.00 0.00 0.00 0.0009:59:52 PM IFACE rxpck/s txpck/s rxkB/s txkB/s rxcmp/s txcmp/s rxmcst/s
09:59:53 PM eth0 6.00 1.00 0.36 0.19 0.00 0.00 0.00
09:59:53 PM lo 0.00 0.00 0.00 0.00 0.00 0.00 0.00Average: IFACE rxpck/s txpck/s rxkB/s txkB/s rxcmp/s txcmp/s rxmcst/s
Average: eth0 6.00 0.50 0.39 0.09 0.00 0.00 0.00
Average: lo 0.00 0.00 0.00 0.00 0.00 0.00 0.00cat直接查看
[root3 ~]# cat /proc/net/dev
Inter-| Receive | Transmitface |bytes packets errs drop fifo frame compressed multicast|bytes packets errs drop fifo colls carrier compressedeth0: 95970470 988296 0 141200 0 0 0 0 6464566 114062 0 0 0 0 0 0lo: 336200 6724 0 0 0 0 0 0 336200 6724 0 0 0 0 0 0proc/net/dev中每一项的含义是 bytes: The total number of bytes of data transmitted or received by the interface.接口发送或接收的数据的总字节数 packets: The total number of packets of data transmitted or received by the interface.接口发送或接收的数据包总数 errs: The total number of transmit or receive errors detected by the device driver.由设备驱动程序检测到的发送或接收错误的总数 drop: The total number of packets dropped by the device driver.设备驱动程序丢弃的数据包总数 fifo: The number of FIFO buffer errors.FIFO缓冲区错误的数量 frame: The number of packet framing errors.分组帧错误的数量 colls: The number of collisions detected on the interface.接口上检测到的冲突数 compressed: The number of compressed packets transmitted or received by the device driver. (This - - appears to be unused in the 2.2.15 kernel.)设备驱动程序发送或接收的压缩数据包数 carrier: The number of carrier losses detected by the device driver.由设备驱动程序检测到的载波损耗的数量 multicast: The number of multicast frames transmitted or received by the device driver.设备驱动程序发送或接收的多播帧数
查看进程
查看进程已运行时间
[root3 ~]# ps -eo pid,lstart,etime,command PID STARTED ELAPSED COMMAND1 Fri Apr 29 14:00:04 2022 2-08:53:16 /usr/lib/systemd/systemd --switched-root --system --deserialize 222 Fri Apr 29 14:00:04 2022 2-08:53:16 [kthreadd]3 Fri Apr 29 14:00:04 2022 2-08:53:16 [ksoftirqd/0]5 Fri Apr 29 14:00:04 2022 2-08:53:16 [kworker/0:0H]6 Fri Apr 29 14:00:04 2022 2-08:53:16 [kworker/u32:0]7 Fri Apr 29 14:00:04 2022 2-08:53:16 [migration/0]8 Fri Apr 29 14:00:04 2022 2-08:53:16 [rcu_bh]进程相关 ## processes 进程管理##ps查看当前系统执行的线程列表进行瞬间状态不是连续状态连续状态需要使用top名称查看 更多常用参数请使用 man ps查看
ps##显示所有进程详细信息
ps aux##-u 显示某个用户的进程列表
ps -f -u www-data ## -C 通过名字或者命令搜索进程
ps -C apache2## --sort 根据进程cpu使用率降序排列查看前5个进程 -pcpu表示降序 pcpu升序
ps aux --sort-pcpu | head -5 ##-f 用树结构显示进程的层次关系父子进程情况下
ps -f --forest -C apache2 ##显示一个父进程的所有子进程
ps -o pid,uname,comm -C apache2
ps --ppid 2359 ##显示一个进程的所有线程 -L 参数
ps -p 3150 -L ##显示进程的执行时间 -o参数
ps -e -o pid,comm,etime ##watch命令可以用来实时捕捉ps显示进程
watch -n 1 ps -e -o pid,uname,cmd,pmem,pcpu --sort-pmem,-pcpu | head -15 ##jobs 查看后台运行的进程 jobs命令执行的结果表示是一个当前的作业减号表是是一个当前作业之后的一个作业jobs -l选项可显示所有任务的PID,jobs的状态可以是running, stopped, Terminated,但是如果任务被终止了killshell 从当前的shell环境已知的列表中删除任务的进程标识也就是说jobs命令显示的是当前shell环境中所起的后台正在运行或者被挂起的任务信息
jobs##查看后台运营的进程号
jobs -p##查看现在被终止或者退出的进程号
jobs -n##kill命令 终止一个前台进程可以使用CtrlC键 kill 通过top或者ps获取进程id号 kill [-s 信号 | -p ] [ -a ] 进程号 ...
##发送指定的信号到相应进程。不指定型号将发送SIGTERM15终止指定进程。关闭进程号12的进程
kill 12##等同于在前台运行PID为123的进程时按下CtrlC键
kill -2 123##如果任无法终止该程序可用“-KILL” 参数其发送的信号为SIGKILL(9) 将强制结束进程
kill -9 123##列出所有信号名称
##HUP 1 终端断线
##INT 2 中断同 Ctrl C
##QUIT 3 退出同 Ctrl \
##TERM 15 终止
##KILL 9 强制终止
##CONT 18 继续与STOP相反 fg/bg命令
##STOP 19 暂停同 Ctrl Z
kill -l##得到指定信号的数值
kill -l KILL##杀死指定用户所有进程
kill -u peidalinux
kill -9 $(ps -ef | grep peidalinux) ##将后台中的命令调至前台继续运行 将进程123调至前台执行
fg 123##将一个在后台暂停的命令变成继续执行
bg 123##该命令可以在你退出帐户/关闭终端之后继续运行相应的进程。nohup就是不挂起的意思 下面输出被重定向到myout.file文件中
nohup command myout.file 21 ##at计划任务在特定的时间执行某项工作在特定的时间执行一次。
## 格式at HH:MM YYYY-MM-DD //HH小时:MM分钟 YYYY年-MM月份-DD日
##HH[am pm]D(天) days //HH小时[am上午pm下午]days天
at 12:00时间 //at命令设定12:00执行一项操作
#atuseradd aaa //在at命令里设定添加用户aaa
#ctrld //退出at命令
#tail -f /etc/passwd //查看/etc/passwd文件后十行是否增加了一个用户aaa##计划任务设定后在没有执行之前我们可以用atq命令来查看系统没有执行工作任务。
atq##启动计划任务后如果不想启动设定好的计划任务可以使用atrm命令删除。
atrm 1 //删除计划任务1##pstree命令列出当前的进程以及它们的树状结构 格式pstree [选项] [pid|user]
pstree##nice命令改变程序执行的优先权等级 应用程序优先权值的范围从-2019数字越小优先权就越高。一般情况下普通应用程序的优先权值CPU使用权值都是0如果让常用程序拥有较高的优先权等级自然启动和运行速度都会快些。需要注意的是普通用户只能在019之间调整应用程序的优先权值只有超级用户有权调整更高的优先权值从-2019。
nice [-n 优先等级][--help][--version][命令]
nice -n 5 ls##sleep命令使进程暂停执行一段时间
date;sleep 1m;date##renice命令 renice命令允许用户修改一个正在运行进程的优先权。利用renice命令可以在命令执行时调整其优先权。
##其中参数number与nice命令的number意义相同。1 用户只能对自己所有的进程使用renice命令。2 root用户可以在任何进程上使用renice命令。3 只有root用户才能提高进程的优先权
renice -5 -p 5200 #PID为5200的进程nice设为-5 ##pmap命令用于显示一个或多个进程的内存状态。其报告进程的地址空间和内存状态信息 #pmap PID
pmap 20367什么是进程间通信列举几种常见的IPC方法
进程间通信Inter-Process Communication, IPC是指操作系统中两个或多个进程之间交换数据和信息的过程。在许多应用程序中不同的进程需要相互通信以实现协作功能例如多进程并发服务器、分布式系统、图形用户界面 (GUI) 应用程序等。
在操作系统中有许多的进程间通信技术包括管道、套接字、共享内存、信号量、消息队列、远程过程调用 (RPC) 等。每种技术都有其优点和缺点具体选择哪种方式要根据实际需求进行选择。
什么是进程调度算法列举几种常见的调度算法
调度算法是指根据系统的资源分配策略所规定的资源分配算法
先来先服务调度算法
时间片轮转调度法
短作业(SJF)优先调度算法
最短剩余时间优先
高响应比优先调度算法
优先级调度算法
多级反馈队列调度算法
如何查看一个进程的打开文件和网络连接
ps -elf #查看进程对应的PID
lsof -p 进程PID
netstat -nltp | grep 进程PID如何设置一个进程的CPU亲和性
taskset 用于设置或查看进程的CPU亲和性即限制程序运行的CPU核心。通过 taskset 命令您可以将一个正在运行的进程或启动一个新进程绑定到指定的CPU核心上。
将进程绑定到指定的CPU核心上 taskset -c CPU列表 命令 cpu列表 是一个逗号分隔的CPU核心列表例如0、0,1、0-3。这个列表指定了要绑定到的CPU核心。命令 是要执行的命令或程序。该命令将在指定的CPU核心上运行。 查看进程的CPU亲和性设置 taskset -p 进程ID将一个已经运行的进程重新绑定到不同的CPU核心上 taskset -cp CPU列表 进程ID
taskset 命令需要在具有足够权限的情况下运行通常需要使用sudo或作为超级用户运行。使用 taskset 可以帮助优化多核处理器上的任务分配但需要小心使用以避免过度绑定或影响系统性能。
以下是一个简单的例子假设我们想要将进程ID为1234的进程绑定到CPU 0上
taskset -pc 0 1234如果你想要将进程绑定到多个CPU上可以指定CPU的列表例如CPU 0和CPU 2
taskset -pc 0,2 1234如果你想要在运行一个新的程序时设置亲和性可以使用taskset来启动程序
taskset -c 0 ./my_program这里的-c选项后面跟着的是CPU的编号。如果你想要将程序绑定到多个CPU可以提供一个逗号分隔的列表。
如何限制一个进程的线程数
1. 进程最大数
定义进程最大数是指系统可以同时运行的进程的最大数量。这个限制通常由内核参数 kernel.pid_max 控制。
调整方法
使用 sysctl 命令临时修改
sudo sysctl -w kernel.pid_max65536永久修改 编辑 /etc/sysctl.conf 文件添加或修改
kernel.pid_max 65536应用更改
sudo sysctl -p2. 最大线程数
定义最大线程数是指一个进程可以创建的最大线程数。线程数的限制通常与系统的可用资源如内存有关而不是直接由一个特定的参数控制。
调整方法
使用 ulimit 命令查看和设置线程数限制。线程数的限制通常是由 max user processes 控制。
# 查看当前用户的最大进程数包括线程
ulimit -u# 设置最大进程数包括线程
ulimit -u 4096要使更改永久生效可以在用户的 shell 配置文件如 ~/.bashrc 或 /etc/security/limits.conf中添加
* hard nproc 4096
* soft nproc 40963. 进程打开的文件数
定义每个进程可以打开的文件数是指单个进程能够同时打开的文件描述符的最大数量。这个限制由 fs.file-max 和每个用户或进程的 nofile 限制控制。
调整方法
查看当前的最大文件数限制
cat /proc/sys/fs/file-max临时修改
sudo sysctl -w fs.file-max100000永久修改 编辑 /etc/sysctl.conf 文件添加或修改
fs.file-max 100000应用更改
sudo sysctl -p对于每个用户的文件描述符限制使用 ulimit 命令
# 查看当前用户的文件数限制
ulimit -n# 设置文件数限制
ulimit -n 65536在 /etc/security/limits.conf 中设置
* hard nofile 65536
* soft nofile 65536总结
通过调整进程最大数、最大线程数和每个进程可以打开的文件数可以有效地提高系统的并发处理能力和资源利用率。在进行这些调整时建议逐步进行并监控系统性能以确保不会引起资源争用或系统不稳定的问题。
查看Linux系统每个IP的连接数
netstat -n | awk /^tcp/{print $5} | awk -F: {print $1} | sort | uniq -c | sort -nrawk数量统计 统计Apache/Nginx日志中某一天不同IP的访问量 统计日志 例如: awk ‘{a[$1]}END{for(i in a){printf(“%d\t%s\n”,a[i],i)}}’ access.log | sort -nr | head -5 [roottest nginx_log]# grep 07/Aug/2012 access.log |awk {a[$1]} END{for(i in a){print i,a[i]} } |sort -k2 -rn |head
222.130.129.42 5761
123.126.51.94 988
123.126.68.22 588
123.114.46.141 418
61.135.249.218 368
110.75.173.162 330
110.75.173.163 327
110.75.173.161 321
110.75.173.160 319
110.75.173.164 314相关解释 {a[$1]} 对每行内容以第一个字段估计就是IP地址吧为数组下标进行计数。若遇第一个字段相同的情况计数累加。用于统计各个IP地址出现的次数。END{for(i in a){printf(“%d\t%s\n”,a[i],i)}} 对数组中的每个下标打印最终统计次数及IP地址中间以TAB分隔。sort -nr 由于之前的打印是次数在前所以这里可以用sort按数字由大到小排序head -5 取前5个即出现次数最多的访问频率最高的 查看inode信息 除了文件本身的文件名称之外,文件所有的信息都在inode中保存. # 查看文件的inode信息
[root3 ~]# stat /etc/passwdFile: ‘/etc/passwd’Size: 1047 Blocks: 8 IO Block: 4096 regular file
Device: fd00h/64768d Inode: 67498799 Links: 1
Access: (0644/-rw-r--r--) Uid: ( 0/ root) Gid: ( 0/ root)
Context: system_u:object_r:passwd_file_t:s0
Access: 2022-05-02 14:01:01.743000000 0800
Modify: 2021-05-25 18:03:10.665000000 0800
Change: 2021-05-25 18:03:10.669000000 0800# 查看文件的inode号码
[root3 ~]# ls -i /etc/passwd
67498799 /etc/passwd性能相关
#查看当前系统load
uptime#查看系统状态和每个进程的系统资源使用状况
top#可视化显示CPU的使用状况
htop#查看每个CPU的负载信息
mpstat -P ALL 1#每隔1秒查看磁盘IO的统计信息
iostat -xkdz 1#每隔一秒查看虚拟内存的使用信息
vmstat 1#查看内存使用统计信息
free#查看网络使用信息
nicstat -z 1#类似vmstat的显示优化的工具
dstat 1#查看系统活动状态比如系统分页统计块设备IO统计等
sar#网络连接状态查看
netstat -s#进程资源使用信息查看
pidstat 1
pidstat -d 1#查看某个进程的系统调用信息 -p后面是进程id-tttT 进程系统后的系统调用时间
strace -tttT -p 12670
#统计IO设备输入输出的系统调用信息
strace -c dd if/dev/zero of/dev/null bs512 count1024k#tcpdump 查看网络数据包
tcpdump -nr /tmp/out.tcpdump#块设备的读写事件信息统计
btrace /dev/sdb #iotop查看某个进程的IO操作统计信息
iotop -bod5#slabtop 查看内核 slab内存分配器的使用信息
slabtop -sc#系统参数设置
sysctl -a#系统性能指标统计信息
perf stat gzip file1
#系统cpu活动状态查看
perf record -a -g -F 997 sleep 10磁盘IO检查 ##iostat是查看磁盘活动统计情况##显示所有设备负载情况 r/s: 每秒完成的读 I/O 设备次数。即 rio/sw/s: 每秒完成的写 I/O 设备次数。即 wio/s等
iostat ##每隔2秒刷新磁盘IO信息并且每次显示3次
iostat 2 3#显示某个磁盘的IO信息
iostat -d sda1##显示tty和cpu信息
iostat -t##以M为单位显示磁盘IO信息
iostat -m##查看TPS和吞吐量信息 kB_read/s每秒从设备drive expressed读取的数据量kB_wrtn/s每秒向设备drive expressed写入的数据量kB_read读取的总数据量kB_wrtn写入的总数量数据量
iostat -d -k 1 1#查看设备使用率%util、响应时间await
iostat -d -x -k 1 1#查看CPU状态
iostat -c 1 3#统计进程(pid)的stat,进程的stat自然包括进程的IO状况
pidstat#只显示IO
pidstat -d 1 #-d IO 信息,-r 缺页及内存信息-u CPU使用率-t 以线程为统计单位1 1秒统计一次
pidstat -u -r -d -t 1#文件级IO分析,查看当前文件由哪些进程打开
lsof
ls /proc/pid/fd#利用 sar 报告磁盘 I/O 信息DEV 正在监视的块设备 tps 每秒钟物理设备的 I/O 传输总量 rd_sec/s 每秒从设备读取的扇区数量 wr_sec/s 每秒向设备写入的扇区数量 avgrq-sz I/O 请求的平均扇区数
#avgqu-sz I/O 请求的平均队列长度 await I/O 请求的平均等待时间单位为毫秒 svctm I/O 请求的平均服务时间单位为毫秒 %util I/O 请求所占用的时间的百分比即设备利用率
sar -pd 10 3 #iotop top的io版
iotop#查看页面缓存信息 其中的Cached 指用于pagecache的内存大小diskcache-SwapCache。随着写入缓存页Dirty 的值会增加 一旦开始把缓存页写入硬盘,Writeback的值会增加直到写入结束。
cat /proc/meminfo #查看有多少个pdflush进程 Linux 用pdflush进程把数据从缓存页写入硬盘
#pdflush的行为受/proc/sys/vm中的参数的控制/proc/sys/vm/dirty_writeback_centisecs (default 500): 1/100秒, 多长时间唤醒pdflush将缓存页数据写入硬盘。默认5秒唤醒2个更多个线程。如果wrteback的时间长于dirty_writeback_centisecs的时间可能会出问题
cat /proc/sys/vm/nr_pdflush_threads#查看I/O 调度器
#调度算法
#noop anticipatory deadline [cfq]
#deadline : deadline 算法保证对既定的IO请求以最小的延迟时间。
#anticipatory有个IO发生后如果又有进程请求IO则产生一个默认6ms猜测时间猜测下一个进程请求IO是干什么。这对于随机读取会造成较大的延时。对数据库应用很糟糕而对于Web Server等则会表现不错。
#cfq: 对每个进程维护一个IO队列各个进程发来的IO请求会被cfq以轮循方式处理对每一个IO请求都是公平。适合离散读的应用。
#noop: 对所有IO请求都用FIFO队列形式处理。默认IO不会存在性能问题。
cat /sys/block/[disk]/queue/scheduler#改变IO调度器
$ echo deadline /sys/block/sdX/queue/scheduler
#提高调度器请求队列的
$ echo 4096 /sys/block/sdX/queue/nr_requests概念
进程与线程
概念
进程 是系统进行资源分配和调度的一个独立单位.是程序的一次执行每个进程都有自己的地址空间、内存、数据栈及其他辅助记录运行轨迹的数据 线程 是进程的一个实体是CPU调度和分派的基本单位,它是比进程更小的能独立运行的基本单位所有的线程运行在同一个进程中共享相同的运行资源和环境线程一般是并发执行的使得实现了多任务的并行和数据共享。
区别
1通常在一个进程中可以包含若干个线程它们可以利用进程所拥有的资源。在引入线程的操作系统中通常都是把进程作为分配资源的基本单位而把线程作为独立运行和独立调度的基本单位。 2线程和进程的区别在于子进程和父进程有不同的代码和数据空间而多个线程则共享数据空间每个线程有自己的执行堆栈和程序计数器为其执行上下文。多线程主要是为了节约CPU时间发挥利用根据具体情况而定。线程的运行中需要使用计算机的内存资源和CPU。 3进程间相互独立同一进程的各线程间共享。某进程内的线程在其它进程不可见。 4线程的上下文切换远大于进程间上下文切换的速度。 5进程是不可执行的实体程序是一个没有生命的实体只有当处理器赋予程序生命时它才能成为一个活动的实体我们称其为进程。
进程和线程的关系
1一个线程只能属于一个进程而一个进程可以有多个线程但至少有一个线程。 2资源分配给进程同一进程的所有线程共享该进程的所有资源。 3处理机分给线程即真正在处理机上运行的是线程。 4线程在执行过程中需要协作同步。不同进程的线程间要利用消息通信的办法实现同步。线程是指进程内的一个执行单元,也是进程内的可调度实体.
进程与线程的区别
1调度线程作为调度和分配的基本单位进程作为拥有资源的基本单位 2并发性不仅进程之间可以并发执行同一个进程的多个线程之间也可并发执行 3拥有资源进程是拥有资源的一个独立单位线程不拥有系统资源但可以访问隶属于进程的资源. 4系统开销在创建或撤消进程时由于系统都要为之分配和回收资源导致系统的开销明显大于创建或撤消线程时的开销。
软链接与硬链接的区别
路径
软链接: 必须是绝对路径硬链接: 可以是相对路径,也可以是绝对路径
权限
软链接: 链接文件权限永远是 777硬链接: 跟源文件权限一致
变更源文件
软链接: 不可以删除与移动源文件硬链接: 可以删除与移动源文件
inode数量
软链接: inode数量与源文件不通硬链接: inode数量与源文件相同
文件与目录
软链接: 对目录与文件都生效硬链接: 只对文件生效
跨文件系统
软链接: 可以跨文件系统硬链接: 不可以跨文件系统
cookie与session的区别 cookie数据保存在客户端session数据保存在服务器端。 session和cookie的作用有点类似都是为了存储用户相关的信息。不同的是cookie是存储在本地浏览器而session存储在服务器。存储在服务器的数据会更加的安全不容易被窃取。但存储在服务器也有一定的弊端就是会占用服务器的资源但现在服务器已经发展至今一些session信息还是绰绰有余的。
CDN访问流程
①当用户点击网站页面上的内容URL经过本地DNS系统解析DNS系统会最终将域名的解析权交给CNAME指向的CDN专用DNS服务器。
②CDN的DNS服务器将CDN的全局负载均衡设备IP地址返回用户。
③用户向CDN的全局负载均衡设备发起内容URL访问请求。
④CDN全局负载均衡设备根据用户IP地址以及用户请求的内容URL选择一台用户所属区域的区域负载均衡设备告诉用户向这台设备发起请求。
⑤区域负载均衡设备会为用户选择一台合适的缓存服务器提供服务选择的依据包括根据用户IP地址判断哪一台服务器距用户最近根据用户所请求的URL中携带的内容名称判断哪一台服务器上有用户所需内容查询各个服务器当前的负载情况判断哪一台服务器尚有服务能力。基于以上这些条件的综合分析之后区域负载均衡设备会向全局负载均衡设备返回一台缓存服务器的IP地址。
⑥全局负载均衡设备把服务器的IP地址返回给用户。
⑦用户向缓存服务器发起请求缓存服务器响应用户请求将用户所需内容传送到用户终端。如果这台缓存服务器上并没有用户想要的内容而区域均衡设备依然将它分配给了用户那么这台服务器就要向它的上一级缓存服务器请求内容直至追溯到网站的源服务器将内容拉到本地。
DNS服务器根据用户IP地址将域名解析成相应节点的缓存服务器IP地址实现用户就近访问。使用CDN服务的网站只需将其域名解析权交给CDN的GSLB设备将需要分发的内容注入CDN就可以实现内容加速了。
进程间如何通信
通信方法无法介于内核态与用户态的原因管道不包括命名管道局限于父子进程间的通信。消息队列在硬、软中断中无法无阻塞地接收数据。信号量无法介于内核态和用户态使用。共享内存需要信号量辅助而信号量又无法使用。
什么是rootkit
入侵者入侵后往往会进行清理脚印和留后门等工作最常使用的后门创建工具就是rootkit。 不要被名字所迷惑这个所谓的“rootkit”可不是给超级用户root用的它是入侵者在入侵了一台主机后用来做创建后门并加以伪装用的程序包。这个程序包里通常包括了日志清理器后门等程序。同时程序包里通常还带有一些伪造的ps、ls、who、w、netstat等原本属于系统本身的程序。这样的话程序员在试图通过这些命令查询系统状况的时候就无法通过这些假的系统程序发觉入侵者的行踪。
在一些黑客组织中,rootkit (或者backdoor) 是一个非常感兴趣的话题。 各种不同的rootkit被开发并发布在internet上。在这些rootkit之中, LKM尤其被人关注, 因为它是利用现代操作系统的模块技术。作为内核的一部分运行,这种rootkit将会越来越比传统技术更加强大更加不易被发觉。一旦被安装运行到目标机器上, 系统就会完全被控制在hacker手中了。甚至系统管理员根本找不到安全隐患的痕迹, 因为他们不能再信任它们的操作系统了。
后门程序的目的就是甚至系统管理员企图弥补系统漏洞的时候也可以给hacker系统的访问权限。
什么是蜜罐
蜜罐技术本质上是一种对攻击方进行欺骗的技术通过布置一些作为诱饵的主机、网络服务或者信息诱使攻击方对它们实施攻击从而可以对攻击行为进行捕获和分析了解攻击方所使用的工具与方法推测攻击意图和动机能够让防御方清晰地了解他们所面对的安全威胁并通过技术和管理手段来增强实际系统的安全防护能力。
蜜罐好比是情报收集系统。蜜罐好像是故意让人攻击的目标引诱黑客前来攻击。所以攻击者入侵后你就可以知道他是如何得逞的随时了解针对服务器发动的最新的攻击和漏洞。还可以通过窃听黑客之间的联系收集黑客所用的种种工具并且掌握他们的社交网络。
Linux中什么是Watchdog
Watchdog在实现上可以是硬件电路也可以是软件定时器能够在系统出现故障时自动重新启动系统。在Linux 内核下, watchdog的基本工作原理是当watchdog启动后(即/dev/watchdog 设备被打开后)如果在某一设定的时间间隔内/dev/watchdog没有被执行写操作, 硬件watchdog电路或软件定时器就会重新启动系统
访问一个网站的流程
用户输入网站按回车 查找本地缓存如果有就打开页面如果没有利用DNS做域名解析递归查询一级一级的向上提交查询请求知道查询到为止 HOSTS表 -- 本地DNS --上层DNS(包括根DNS)
经过了DNS解析知道了网站的IP地址然后建立tcp三次握手; 建立请求后发送请求报文默认请求的是index.html
传送完毕断开连接
三次握手四次挥手
三次握手
由客户端(用户)发送建立TCP连接的请求报文其中报文中包含seq序列号是由发送端随机生成的。并且还将报文中SYN字段置为 1表示需要建立TCP连接请求。服务端(就是百度服务器)会回复客户端(用户)发送的TCP连接请求报文其中包含seq序列号也是由回复端随机生成的 并且将回复报文的SYN字段置1而且会产生ACK验证字段ACK 验证字段数值是在客户端发过来的seq序列号基础上加 1 进行回复: 并且还会回复ack确认控制字段以便客户端收到信息时知晓自己的TCP建立请求已得到了确认。客户端收到服务端发送的TCP建立请求后会使自己的原有序列号加 1 进行再次发送序列号 并且再次回复ACK验证请求在B端发送过来的seq基础上加1进行回复; 同时也会回复 ack 确认控制字段 以便B收到信息时知晓自己的TCP建立请求已经得到了确认。
四次挥手*
*第一次挥手:
Client 发送一个 FIN用来关闭 Client 到 Server 的数据传送Client 进入 FIN_WAIT_1 状态。
第二次挥手:
Server 收到 FIN 后发送一个 ACK 给 Client确认序号为收到序号1(与SYN相同一个FIN占用一个序号)Server 进入 CLOSE_WAIT 状态。
第三次挥手:
Server 发送一个FIN用来关闭 Server 到 Client 的数据传送Server 进入 LAST_ACK 状态。
第四次挥手:
Client 收到 FIN 后Client 进入 TIME_WAIT 状态接着发送一个 ACK 给Server确认序号为收到序号1
Server进入CLOSED状态完成四次挥手. LVS相关
LVS 负载均衡有哪些策略
LVS一共有三种工作模式:
DRTunnelNAT
谈谈你对LVS的理解
LVS是一个虚拟的服务器集群系统在unix系统下实现负载均衡的功能;采用IP负载均衡技术和机遇内容请求分发技术来实现。
LVS采用三层结构分别是: 第一层: 负载调度器 第二层: 服务池 第三层:共享存储
负载调度器(load balancer/ Director)是整个集群的总代理它有两个网卡一个网卡面对访问网站的客户端一个网卡面对整个集群的内部。负责将客户端的请求发送到一组服务器上执行而客户也认为服务是来自这台主的。举个生动的例子集群是个公司负载调度器就是在外接揽生意将接揽到的生意分发给后台的真正干活的真正的主机们。当然需要将活按照一定的算法分发下去让大家都公平的干活。
服务器池(server pool/ Realserver)是一组真正执行客户请求的服务器可以当做WEB服务器。就 是上面例子中的小员工。
共享存储(shared storage)它为服务器池提供一个共享的存储区这样很容易使得服务器池拥有相 同的内容提供相同的服务。一个公司得有一个后台账目吧这才能协调。不然客户把钱付给了A而 换B接待客户因为没有相同的账目。B说客户没付钱那这样就不是客户体验度的问题了。
负载均衡的原理是什么
当客户端发起请求时请求直接发给Director Server(调度器)这时会根据设定的调度算法将请求按照算法的规定智能的分发到真正的后台服务器。以达到将压力均摊。
但是我们知道http的连接时无状态的假设这样一个场景我登录某宝买东西当我看上某款商品时我将它加入购物车但是我刷新了一下页面这时由于负载均衡的原因调度器又选了新的一台服务器为我提供服务我刚才的购物车内容全都不见了这样就会有十分差的用户体验。
所以就还需要一个存储共享这样就保证了用户请求的数据是一样的
LVS由哪两部分组成的
LVS由ipvs和ipvsadm组成 ipvs(ip virtual server): 一段代码工作在内核空间叫ipvs是真正生效实现调度的代码。 ipvsadm: 另外一段是工作在用户空间叫ipvsadm负责为ipvs内核框架编写规则定义谁是集群服务而谁是后端真实的服务器(Real Server)
LVS相关的术语 DS: Director Server。指的是前端负载均衡器节点。 RS: Real Server。后端真实的工作服务器。 VIP: Virtual IP 向外部直接面向用户请求作为用户请求的目标的IP地址。 DIP: Director Server IP主要用于和内部主机通讯的IP地址。 RIP: Real Server IP后端服务器的IP地址。 CIP: Client IP访问客户端的IP地址。
LVS-NAT模式的原理 (1). 当用户请求到达 Director Server此时请求的数据报文会先到内核空间的 PREROUTING 链。 此时报文的源IP为CIP目标IP为VIP (2). PREROUTING检查发现数据包的目标 IP 是本机将数据包送至 INPUT 链 (3). IPVS比对数据包请求的服务是否为集群服务若是修改数据包的目标IP地址为后端服务器 IP 然后将数据包发至POSTROUTING链。 此时报文的源IP为CIP目标IP为RIP (4). POSTROUTING链通过选路将数据包发送给Real Server (5). Real Server比对发现目标为自己的IP开始构建响应报文发回给Director Server。 此时报文的源IP为RIP目标IP为CIP (6). Director Server在响应客户端前此时会将源IP地址修改为自己的VIP地址然后响应给客户端。 此时报文的源IP为VIP目标IP为CIP LVS-NAT模型的特性 RS 应该使用私有地址RS 的网关必须指向 DIP DIP 和 RIP 必须在同一个网段内 请求和响应报文都需要经过 Director Server高负载场景中Director Server 易成为性能瓶颈 支持端口映射 RS 可以使用任意操作系统 缺陷: 对 Director Server 压力会比较大请求和响应都需经过 Director server
LVS-DR模式原理 (1) 当用户请求到达 Director Server此时请求的数据报文会先到内核空间的 PREROUTING 链。 此时报文的源IP为 CIP目标 IP 为 VIP (2) PREROUTING 检查发现数据包的目标IP是本机将数据包送至 INPUT 链 (3) IPVS比对数据包请求的服务是否为集群服务若是将请求报文中的源 MAC 地址修改为 DIP 的 MAC 地址将目标 MAC 地址修改 RIP 的 MAC 地址然后将数据包发至 POSTROUTING 链。 此时的源 IP 和目的 IP 均未修改仅修改了源 MAC 地址为 DIP 的 MAC 地址目标 MAC 地址为 RIP 的 MAC 地址 (4) 由于 DS 和 RS 在同一个网络中所以是通过二层来传输。POSTROUTING 链检查目标 MAC 地址为 RIP 的 MAC 地址那么此时数据包将会发至Real Server。 (5) RS 发现请求报文的 MAC 地址是自己的 MAC 地址就接收此报文。处理完成之后将响应报文通过 lo 接口传送给 eth0 网卡然后向外发出。 此时的源 IP 地址为 VIP目标 IP 为 CIP (6) 响应报文最终送达至客户端 LVS-DR模型的特性
特点: 保证前端路由将目标地址为 VIP 报文统统发给 Director Server而不是 RS RS 可以使用私有地址; 也可以是公网地址如果使用公网地址此时可以通过互联网对RIP进行直接访问 RS 跟 Director Server 必须在同一个物理网络中 所有的请求报文经由 Director Server但响应报文不能经过 Director Server 不支持地址转换也不支持端口映射 RS 可以是大多数常见的操作系统 RS 的网关绝不允许指向DIP(因为我们不允许他经过director) RS 上的 lo 接口配置 VIP 的 IP 地址
缺陷:
RS 和 DS 必须在同一机房中
LVS三种负载均衡模式的比较
三种负载均衡: nattunnelingdr
类目NATTUNDR操作系统任意支持隧道多数(支持non-arp)服务器网络私有网络局域网/广域网局域网服务器数目10-20100大于100服务器网关负载均衡器自己的路由自己的路由效率一般高最高
LVS的负载调度算法
轮叫调度加权轮叫调度最小连接调度加权最小连接调度基于局部性能的最少连接带复制的基于局部性能最小连接目标地址散列调度源地址散列调度
LVS与nginx的区别
lvs的优势(互联网老辛):
抗负载能力强因为 lvs 工作方式的逻辑是非常简单的而且工作在网络的第 4 层仅作请求分发用没有流量所以在效率上基本不需要太过考虑。lvs 一般很少出现故障即使出现故障一般也是其他地方(如内存、CPU等)出现问题导致 lvs 出现问题。配置性低这通常是一大劣势同时也是一大优势因为没有太多的可配置的选项所以除了增减服务器并不需要经常去触碰它大大减少了人为出错的几率。工作稳定因为其本身抗负载能力很强所以稳定性高也是顺理成章的事另外各种 lvs 都有完整的双机热备方案所以一点不用担心均衡器本身会出什么问题节点出现故障的话lvs 会自动判别所以系统整体是非常稳定的。无流量lvs 仅仅分发请求而流量并不从它本身出去所以可以利用它这点来做一些线路分流之用。没有流量同时也保住了均衡器的 IO 性能不会受到大流量的影响。lvs 基本上能支持所有应用因为 lvs 工作在第4层所以它可以对几乎所有应用做负载均衡包括 http、数据库、聊天室等。
nginx与LVS的对比:
nginx工作在网络的第7层所以它可以针对 http 应用本身来做分流策略比如针对域名、目录结构等相比之下 lvs 并不具备这样的功能所以 nginx 单凭这点可以利用的场合就远多于 lvs 了;但 nginx 有用的这些功能使其可调整度要高于lvs所以经常要去触碰由 lvs 的第2条优点来看触碰多了人为出现问题的几率也就会大。nginx对网络的依赖较小理论上只要 ping 得通网页访问正常nginx就能连得通nginx 同时还能区分内外网如果是同时拥有内外网的节点就相当于单机拥有了备份线路; lvs 就比较依赖于网络环境目前来看服务器在同一网段内并且 lvs 使用 direct 方式分流效果较能得到保证。另外注意lvs 需要向托管商至少申请多于一个 ip 来做visual ip。nginx 安装和配置比较简单测试起来也很方便因为它基本能把错误用日志打印出来。lvs 的安装和配置、测试就要花比较长的时间因为同上所述lvs 对网络依赖性比较大很多时候不能配置成功都是因为网络问题而不是配置问题出了问题要解决也相应的会麻烦的多。nginx也同样能承受很高负载且稳定但负载度和稳定度差 lvs 还有几个等级:nginx处理所有流量所以受限于机器 IO 和配置;本身的bug也还是难以避免的;nginx没有现成的双机热备方案所以跑在单机上还是风险比较大单机上的事情全都很难说。nginx 可以检测到服务器内部的故障比如根据服务器处理网页返回的状态码、超时等等并且会把返回错误的请求重新提交到另一个节点。目前 lvs 中 ldirectd 也能支持针对服务器内部的情况来监控但 lvs 的原理使其不能重发请求。比如用户正在上传一个文件而处理该上传的节点刚好在上传过程中出现故障nginx 会把上传切到另一台服务器重新处理而 lvs 就直接断掉了。
两者配合使用:
nginx 用来做 http 的反向代理能够 upsteam 实现 http 请求的多种方式的均衡转发。由于采用的是异步转发可以做到如果一个服务器请求失败立即切换到其他服务器直到请求成功或者最后一台服务器失败为止。这可以最大程度的提高系统的请求成功率。
lvs采用的是同步请求转发的策略。这里说一下同步转发和异步转发的区别。同步转发是在 lvs 服务器接收到请求之后立即 redirect 到一个后端服务器由客户端直接和后端服务器建立连接。异步转发是 nginx 在保持客户端连接的同时发起一个相同内容的新请求到后端等后端返回结果后由 nginx 返回给客户端。
进一步来说:当做为负载均衡服务器的 nginx 和 lvs 处理相同的请求时所有的请求和响应流量都会经过 nginx; 但是使用 lvs 时仅请求流量经过 lvs 的网络响应流量由后端服务器的网络返回。
也就是当作为后端的服务器规模庞大时nginx的网络带宽就成了一个巨大的瓶颈。
但是仅仅使用 lvs 作为负载均衡的话一旦后端接受到请求的服务器出了问题那么这次请求就失败了。 但是如果在lvs的后端在添加一层nginx(多个)每个nginx后端再有几台应用服务器那么结合两者的优势既能避免单nginx的流量集中瓶颈又能避免单lvs时一锤子买卖的问题。
负载均衡的作用有哪些
1、转发功能
按照一定的算法【权重、轮询】将客户端请求转发到不同应用服务器上减轻单个服务器压力提高系统并发量。
2、故障移除
通过心跳检测的方式判断应用服务器当前是否可以正常工作如果服务器期宕掉自动将请求发送到其他应用服务器。
3、恢复添加
如检测到发生故障的应用服务器恢复工作自动将其添加到处理用户请求队伍中。
Nginx与Apache相关
常见问题
nginx负载均衡实现的策略 轮询(默认) 权重 ip_hash fair(第三方插件) url_hash(第三方插件)
nginx做负载均衡用到的模块
upstream 定义负载节点池。location 模块进行URL匹配。proxy模块发送请求给upstream定义的节点池。
负载均衡有哪些实现方式 硬件负载 HTTP重定向负载均衡 DNS负载均衡 反向代理负载均衡 IP层负载均衡 数据链路层负载均衡
web服务有哪些
apachenginxIIStomcatlighttpdweblogic
为什么要用nginx
跨平台、配置简单非阻塞、高并发连接: 处理2-3万并发连接数官方监测能支持5万并发内存消耗小: 开启10个nginx才占150M内存nginx处理静态文件好,耗费内存少内置的健康检查功能: 如果有一个服务器宕机会做一个健康检查再发送的请求就不会发送到宕机的服务器了。重新将请求提交到其他的节点上。节省宽带: 支持GZIP压缩可以添加浏览器本地缓存稳定性高: 宕机的概率非常小接收用户请求是异步的
nginx的性能为什么比apache高
nginx采用的是epoll模型和kqueue网络模型而apache采用的是select模型
举一个例子来解释两种模型的区别:
菜鸟驿站放着很多快件以前去拿快件都是短信通知你有快件然后你去了之后负责菜鸟驿站的人在一堆快递里帮你找直到找到为止。
但现在菜鸟驿站的方式变了他会发你一个地址比如 3-3-5009. 这个就是第三个货架的第三排从做往右第九个。
如果有几百个人同时去找快递这两种方式哪个更有效率不言而喻。
之前还看到这个例子也比较形象: 假设你在大学读书住的宿舍楼有很多间房间你的朋友要来找你。
select版宿管大妈就会带着你的朋友挨个房间去找直到找到你为止。
而epoll版宿管大妈会先记下每位同学的房间号
你的朋友来时只需告诉你的朋友你住在哪个房间即可不用亲自带着你的朋友满大楼找人。
如果来了10000个人都要找自己住这栋楼的同学时select版和epoll版宿管大妈谁的效率更高不言自明。
同理在高并发服务器中轮询I/O是最耗时间的操作之一select和epoll的性能谁的性能更高同样十分明了select 采用的是轮询的方式来处理请求轮询的次数越多耗时也就越多。
nginx和apache的区别
Nginx 轻量级采用 C 进行编写同样的 web 服务会占用更少的内存及资源 抗并发nginx 以 epoll and kqueue 作为开发模型处理请求是异步非阻塞的负载能力比 apache 高很多而 apache 则是阻塞型的。在高并发下 nginx 能保持低资源低消耗高性能 而 apache 在 PHP 处理慢或者前端压力很大的情况下很容易出现进程数飙升从而拒绝服务的现象。 nginx 处理静态文件好静态处理性能比 apache 高三倍以上 nginx 的设计高度模块化编写模块相对简单 nginx 配置简洁正则配置让很多事情变得简单而且改完配置能使用 -t 测试配置有没有问题 apache 配置复杂 重启的时候发现配置出错了会很崩溃 nginx 作为负载均衡服务器支持 7 层负载均衡 七层负载可以有效的防止ddos攻击 nginx本身就是一个反向代理服务器也可以左右邮件代理服务器来使用
Apache
apache 的 rewrite 比 nginx 强大在 rewrite 频繁的情况下用 apacheapache 发展到现在模块超多基本想到的都可以找到apache 更为成熟少 bug nginx 的 bug 相对较多apache 对 PHP 支持比较简单nginx 需要配合其他后端用apache 在处理动态请求有优势nginx 在这方面是鸡肋一般动态请求要 apache 去做nginx 适合静态和反向。apache 仍然是目前的主流拥有丰富的特性成熟的技术和开发社区两者最核心的区别在于 apache 是同步多进程模型一个连接对应一个进程而 nginx 是异步的多个连接(万级别)可以对应一个进程。需要稳定用 apache需要高性能用 nginx
反向代理与正向代理以及区别
正向代理:
所谓的正向代理就是: 需要在用户端去配置的。配置完再去访问具体的服务这叫正向代理
正向代理其实是代理服务器代理了客户端去和目标服务器进行交互。
正向代理的用途: 提高访问速度 隐藏客户真实IP
反向代理:
反向代理是在服务端的不需要访问用户关心。用户访问服务器A, A服务器是代理服务器将用户服务
再转发到服务器B.这就是反向代理
反向代理的作用: 缓存将服务器的响应缓存在自己的内存中减少服务器的压力。 负载均衡将用户请求分配给多个服务器。 访问控制
nginx如何处理http请求
四个步骤:
读取解析请求行;读取解析请求头;开始最重要的部分即多阶段处理; nginx 把请求处理划分成了11个阶段也就是说当 nginx 读取了请求行和请求头之后将请求封装了结构体ngx_http_request_t然后每个阶段的 handler 都会根据这个 ngx_http_request_t对请求进行处理例如重写uri权限控制路径查找生成内容以及记录日志等等; 最后将结果返回给客户端。
也可以这么回答:
首先Nginx 在启动时会解析配置文件得到需要监听的端口与 IP 地址然后在 Nginx 的 Master 进程里面先初始化好这个监控的Socket(创建 Socket设置 addr、reuse 等选项绑定到指定的 ip 地址端口再 listen 监听)。然后再 fork(一个现有进程可以调用 fork 函数创建一个新进程。由 fork 创建的新进程被称为子进程 )出多个子进程出来。之后子进程会竞争 accept 新的连接。此时客户端就可以向 nginx 发起连接了。当客户端与 nginx进行三次握手与 nginx 建立好一个连接后。此时某一个子进程会 accept 成功得到这个建立好的连接的 Socket 然后创建 nginx 对连接的封装即 ngx_connection_t 结构体。接着设置读写事件处理函数并添加读写事件来与客户端进行数据的交换。最后Nginx 或客户端来主动关掉连接到此一个连接就寿终正寝了。
nginx虚拟主机有哪些
基于域名的虚拟主机基于端口的虚拟主机基于 IP 的虚拟主机
apache中的Worker和Prefork的区别
它们都是MPM, Worker 和 prefork 有它们各自在Apache上的运行机制. 它们完全依赖于你想要以哪一 种模式启动你的Apache.
Worker 和 MPM 基本的区别在于它们产生子进程的处理过程, 在 Prefork MPM 中, 一个主 httpd 进行被启动这个主进程会管理所有其它子进程为客户端请求提供服务. 而在worker MPM中一个httpd进程被激活则会使用不同的线程来为客户端请求提供服务.Prefork MPM 使用多个子进程每一个进程带有一个线程; 而 worker MPM 使用多个子进程每一个进程带有多个线程.Prefork MPM中的连接处理, 每一个进程一次处理一个连接而在Worker mpm中每一个线程一次处理一个连接.内存占用 Prefork MPM 占用庞大的内存, 而Worker占用更小的内存
nginx的优化
gzip压缩优化expires缓存网络IO事件模型优化隐藏软件名称和版本号防盗链优化禁止恶意域名解析禁止通过IP地址访问网站HTTP请求方法优化防DOS攻击单IP并发连接的控制与连接速率控制严格设置web站点目录的权限将nginx进程以及站点运行于监牢模式通过robot协议以及HTTP_USER_AGENT防爬虫优化配置错误页面根据错误码指定网页反馈给用户nginx日志相关优化访问日志切割轮询不记录指定元素日志、最小化日志目录权限限制上传到资源目录的程序被访问防止木马入侵系统破坏文件FastCGI参数buffer和cache配置文件的优化php.ini和php-fpm.conf配置文件的优化有关web服务的Linux内核方面深度优化(网络连接、IO、内存等)nginx加密传输优化(SSL)web服务器磁盘挂载及网络文件系统的优化使用nginx cache
nginx的session不同步怎么办
我们可以采用 ip_hash 指令解决这个问题如果客户已经访问了某个服务器当用户再次访问时会将该请求通过哈希算法自动定位到该服务器。即每个访客固定访问一个后端服务器可以解决 session 的问题。
其他办法: 那就是用 spring_sessionredis把session放到缓存中实现 session 共享。
Tomcat相关
Tomcat作为web的优缺点
缺点: tomcat 只能用做 java 服务器处理静态请求的能力不如 nginx 和 apache高并发能力有限
优点:
动态解析容器处理动态请求是编译 JSP/Servlet 的容器轻量级
tomcat的三个端口及作用
8005: 关闭Tomcat通信接口8009: 与其他httpd服务器通信接口用于http服务器的集合8080: 建立httpd连接用如浏览器访问
Tomcat缺省端口是多少怎么修改 找到Tomcat目录下的conf文件夹 进入conf文件夹里面找到server.xml文件 打开server.xml文件 在server.xml文件里面找到下列信息 把Connector标签的8080端口改成你想要的端口
Tomcat的工作模式是什么
Tomcat作为servlet容器有三种工作模式:
独立的servlet容器servlet容器是web服务器的一部分;进程内的servlet容器servlet容器是作为web服务器的插件和java容器的实现web服务器插件在内部地址空间打开一个jvm使得java容器在内部得以运行。反应速度快但伸缩性不足;进程外的servlet容器servlet容器运行于web服务器之外的地址空间并作为web服务器的插件和 java 容器实现的结合。反应时间不如进程内但伸缩性和稳定性比进程内优;
进入Tomcat的请求可以根据Tomcat的工作模式分为如下两类: Tomcat作为应用程序服务器:请求来自于前端的web服务器这可能是Apache, IIS, Nginx等; Tomcat作为独立服务器:请求来自于web浏览器;
Web请求在Tomcat请求中的请求流程
浏览器输入URL地址;查询本机hosts文件寻找IP;查询DNS服务器寻找IP;向该IP发送Http请求;Tomcat容器解析主机名;Tomcat容器解析Web应用;Tomcat容器解析资源名称;Tomcat容器获取资源;Tomcat响应浏览器。
Tomcat优化
Tomcat的运行模式 : bio,nio, apr 一般使用nio模式bio效率低apr对系统配置有一些更高的要求关键配置 maxThreads: 最大线程数默认是200 minspareThread: 最小活跃线程数默认是25 maxqueuesize: 最大等待队列个数影响性能的配置: compression 设置成on开启压缩 禁用AJP连接器: 用nginxTomcat的架构用不到AJP enableLookupsfalse 关闭反查域名直接返回ip提高效率 disableUploadTimeoufalse 上传是否使用超时机制 acceptCount300 , 当前所有可以使用的处理请求都被使用时传入请求连接最大队列长队超过个数不予处理默认是100 keepalive timeout120000 场链接保持时间优化jvm /bin/catalina.sh -server: jvm的server工作模式对应的有client工作模式。使用“java -version”可以查看当前工作 模式 -Xms1024m: 初始Heap大小使用的最小内存 -Xmx1024m: Java heap 最大值使用的最大内存。经验: 设置 Xms 大小等于 Xmx 大小 -XX:NewSize512m:表示新生代初始内存的大小应该小于 -Xms 的值 -XX:MaxNewSize1024M:表示新生代可被分配的内存的最大上限应该小于 -Xmx 的值 -XX:PermSize1024m:设定内存的永久保存区域,内存的永久保存区域VM 存放 Class 和 Meta 信息JVM在运行期间不会清除该区域 -XX:MaxPermSize1024m:设定最大内存的永久保存区域。经验: 设置PermSize大小等于 MaxPermSize大小 -XX:DisableExplicitGC:自动将System.gc() 调用转换成一个空操作即应用中调用System.gc() 会变成一个空操作避免程序员在代码里进行System.gc()这种危险操作。System.gc() 除非是到了万不得也的情况下使用都应该交给 JVM。 fastcgi 和cgi的区别
cgi:
web 服务器会根据请求的内容然后会 fork 一个新进程来运行外部 c 程序(或 perl 脚本…) 这个进程会把处理完的数据返回给 web 服务器最后 web 服务器把内容发送给用户刚才 fork 的进程也随之退出。
如果下次用户还请求该动态脚本那么 web 服务器又再次 fork 一个新进程周而复始的进行
fastcgi:
web 服务器收到一个请求时他不会重新 fork 一个进程(因为这个进程在 web 服务器启动时就开启了而且不会退出)web 服务器直接把内容传递给这个进程(进程间通信但 fastcgi 使用了别的方式tcp 方式通信)这个进程收到请求后进行处理把结果返回给 web 服务器最后自己接着等待下一个请求的到来而不是退出。
Keepalived相关
keepalived 是什么
广义上讲是高可用狭义上讲是主机的冗余和管理
Keepalived起初是为 LVS 设计的专门用来监控集群系统中各个服务节点的状态它根据 TCP/IP 参考模型的第三、第四层、第五层交换机制检测每个服务节点的状态如果某个服务器节点出现异常或者工作出现故障Keepalived 将检测到并将出现的故障的服务器节点从集群系统中剔除这些工作全部是自动完成的不需要人工干涉需要人工完成的只是修复出现故障的服务节点。
后来 Keepalived 又加入了 VRRP 的功能VRRP(VritrualRouterRedundancyProtocol,虚拟路由冗余协议)出现的目的是解决静态路由出现的单点故障问题通过 VRRP 可以实现网络不间断稳定运行因此 Keepalvied 一方面具有服务器状态检测和故障隔离功能另外一方面也有 HAcluster 功能。
所以 keepalived 的核心功能就是健康检查和失败切换。 所谓的健康检查就是采用 tcp 三次握手icmp 请求http 请求udp echo 请求等方式对负载均衡器后面的实际的服务器(通常是承载真实业务的服务器)进行保活;
而失败切换主要是应用于配置了主备模式的负载均衡器利用 VRRP 维持主备负载均衡器的心跳当主负载均衡器出现问题时由备负载均衡器承载对应的业务从而在最大限度上减少流量损失并提供服务的稳定性
如何理解VRRP协议
为什么使用 VRRP ? 主机之间的通信都是通过配置静态路由或者(默认网关)来完成的而主机之间的路由器一旦发生故障通信就会失效因此这种通信模式当中路由器就成了一个单点瓶颈为了解决这个问题就引入了 VRRP 协议。
VRRP 协议是一种容错的主备模式的协议保证当主机的下一跳路由出现故障时由另一台路由器来代替出现故障的路由器进行工作通过 VRRP 可以在网络发生故障时透明的进行设备切换而不影响主机之间的数据通信。
VRRP 的三种状态:
VRRP路由器在运行过程中有三种状态:
Initialize状态: 系统启动后就进入Initialize此状态下路由器不对 VRRP 报文做任何处理;Master状态;Backup状态;
一般主路由器处于Master状态备份路由器处于Backup状态。
keepalived的工作原理
keepalived 采用是模块化设计不同模块实现不同的功能。
keepalived 主要有三个模块分别是 core、check 和 vrrp。
core: 是 keepalived 的核心负责主进程的启动和维护全局配置文件的加载解析等
check: 负责 healthchecker(健康检查)包括了各种健康检查方式以及对应的配置的解析包括LVS的配置解析;可基于脚本检查对IPVS后端服务器健康状况进行检查
vrrp: VRRPD子进程VRRPD 子进程就是来实现 VRRP 协议的
Keepalived 高可用对之间是通过 VRRP 进行通信的 VRRP是通过竞选机制来确定主备的主的优先级高于备因此工作时主会优先获得所有的资源备节点处于等待状态当主宕机的时候备节点就会接管主节点的资源然后顶替主节点对外提供服务
在 Keepalived 服务对之间只有作为主的服务器会一直发送 VRRP 广播包,告诉备它还活着此时备不会抢占主当主不可用时即备监听不到主发送的广播包时就会启动相关服务接管资源保证业务的连续性.接管速度最快
出现脑裂的原因
什么是脑裂? 在高可用(HA)系统中当联系2个节点的“心跳线”断开时本来为一整体、动作协调的HA系统 就分裂成为2个独立的个体。 由于相互失去了联系都以为是对方出了故障。两个节点上的HA软件像“裂脑人”一样争抢“共享 资源”、争起“应用服务”就会发生严重后果。共享资源被瓜分、两边“服务”都起不来了;或者两边 “服务”都起来了但同时读写“共享存储”导致数据损坏
都有哪些原因导致脑裂? 高可用服务器对之间心跳线链路发生故障导致无法正常通信。 因心跳线坏了(包括断了老化)。 因网卡及相关驱动坏了ip配置及冲突问题(网卡直连) 因心跳线间连接的设备故障(网卡及交换机) 因仲裁的机器出问题(采用仲裁的方案) 高可用服务器上开启了 iptables 防火墙阻挡了心跳消息传输。 高可用服务器上心跳网卡地址等信息配置不正确导致发送心跳失败 其他服务配置不当等原因如心跳方式不同心跳广插冲突、软件Bug等。
如何解决keepalived脑裂问题
在实际生产环境中我们从以下方面防止脑裂:
同时使用串行电缆和以太网电缆连接、同时使用两条心跳线路这样一条线路断了另外一条还是好的依然能传送心跳消息当检查脑裂时强行关闭一个心跳节点(这个功能需要特殊设备支持如stonith、fence)相当于备节点接收不到心跳消息通过单独的线路发送关机命令关闭主节点的电源做好对脑裂的监控报警
解决常见方案:
如果开启防火墙一定要让心跳消息通过一般通过允许IP段的形式解决可以拉一条以太网网线或者串口线作为主被节点心跳线路的冗余开发检测程序通过监控软件检测脑裂
Linux系统
常见日志文件与各自的用途
路径用途/var/log/messages内核及公共消息日志/var/log/cron计划任务日志/var/log/dmesg系统引导日志/var/log/maillog邮件系统日志/var/log/secure记录与访问限制相关日志/etc/logrotate.d此目录下是各个服务的日志轮询配置文件
Linux系统的运行级别
0关机1单用户2多用户有网络服务3多用户无网络服务4保留5图形界面6重启
Linux开机过程
1.开机BIOS自检
2.MBR引导
3.grub引导菜单
4.加载内核kernel
5.启动init进程
6.读取inittab文件执行rc.sysinit,rc等脚本
7.启动mingetty进入系统登陆界面
详情请参考链接:Linux开机过程
网络协议
STP协议
主要用途 STP通过阻塞冗余链路来消除桥接网络中可能存在的路径回环 当前活动路径发生故障时STP激活冗余链路恢复网络连通性。
为什么要用STP:
原因交换网络存在环路时引起广播环路广播风暴桥表损坏。
介绍一下ACL和NAT?
ACL 访问控制列表ACL是应用在路由器接口的指令列表规则用来告诉路由器哪些数据包可以接收转发哪些数据包需要拒绝 ACL的工作原理 读取第三层及第四层包头中的信息根据预先定义好的规则对包进行过滤 使用ACL实现网络控制实现访问控制列表的核心技术是包过滤 ACL的两种基本类型标准访问控制列表扩展访问控制列表
NAT
改变IP包头使目的地址源地址或两个地址在包头中被不同地址替换。
NAT有几种方式? 静态NAT 动态NAT PAT
RIP协议
RIP是Routing Information Protocol路由信息协议的简称它是一种较为简单的内部网关协议Interior Gateway Protocol。RIP是一种基于距离矢量Distance-Vector算法的协议它使用跳数Hop Count作为度量来衡量到达目的网络的距离。RIP通过UDP报文进行路由信息的交换使用的端口号为520。
RIP包括RIP-1和RIP-2两个版本RIP-2对RIP-1进行了扩充使其更具有优势。
RIP是一种基于距离矢量Distance-Vector算法的协议它使用跳数Hop Count作为度量值来衡量到达目的地址的距离。在RIP网络中缺省情况下设备到与它直接相连网络的跳数为0通过一个设备可达的网络的跳数为1其余依此类推。也就是说度量值等于从本网络到达目的网络间的设备数量。为限制收敛时间RIP规定度量值取015之间的整数大于或等于16的跳数被定义为无穷大即目的网络或主机不可达。由于这个限制使得RIP不可能在大型网络中得到应用。
静态路由的缺陷
配置量大只能适用于小型网络中维护麻烦无法自动适应网络的拓扑变化
动态路由协议可以根据网络拓扑的变化根据协议来选择路径
动态路由协议分为
内部网关协议运行在同一个AS号内的路由协议。如RIP、OSPF、EIGRP思科设备专用外部网关协议运行在不同AS号之间的路由协议。如BGP
内部网关协议分为
距离矢量协议RIP、EIGRP链路状态协议OSPF
RIP协议属于内部网关协议是一个距离矢量协议工作在UDP的520端口
有类路由协议在发送路由更新的时候是不会携带子网掩码的已经被淘汰
无类路由协议在发送路由更新的时候携带子网掩码。
RIP的两个版本
RIPv1是一个有类路由协议是通过广播255.255.255.255的形式来发送路由更新的。
RIPv2是一个无类路由协议是通过组播224.0.0.9的形式来发送路由更新的。
RIP的选路标准通过跳数来衡量路径RIP认为跳数越少路径越优先。同时这也是它的缺陷因为RIP有可能选择了一条次优路径。
RIPv1的特点
有类别路由协议。广播更新。基于UDP端口号520
RIP是一个基于UDP的路由协议并且RIPv1的数据包不能超过512字节RIP报文头部占用4个字节,而每个路由条目占用20个八位组字节。因此,RIP消息最大为4(25*20)504个字节,再加上8个字节的UDP头部,所以RIP数据报的大小(不含IP包的头部)最大可达512个字节。。RIPv1的协议报文中没有携带掩码信息所以RIPv1在发送和接收路由更新时会根据主类网段掩码和接口地址掩码来处理路由条目。因此RIPv1无法支持路由聚合也不支持不连续子网。RIPv1的协议报文中没有验证字段所以RIPv1也不支持验证。
RIPv2特点
无类别路由协议。组播更新组播地址224.0.0.9基于UDP端口号520.支持外部Tag。支持路由聚合和CIDR支持指定下一跳。支持认证。
OSPF协议
路由协议OSPF全称为Open Shortest Path First也就开放的最短路径优先协议因为OSPF是由IETF开发的它的使用不受任何厂商限制所有人都可以使用所以称为开放的而最短路径优先SPF只是OSPF的核心思想其使用的算法是Dijkstra算法最短路径优先并没有太多特殊的含义并没有任何一个路由协议是最长路径优先的所有协议都会选最短的。
OSPF的流量使用IP协议号89。OSPF工作在单个AS是个绝对的内部网关路由协议Interior Gateway Protocol即IGP。OSPF对网络没有跳数限制支持 Classless Interdomain Routing (CIDR)和Variable-Length Subnet Masks (VLSMs)没有自动汇总功能但可以手工在任意比特位汇总并且手工汇总没有任何条件限制可以汇总到任意掩码长度。OSPF支持认证并且支持明文和MD5认证OSPF不可以通过Offset list来改变路由的metric。OSPF并不会周期性更新路由表而采用增量更新即只在路由有变化时才会发送更新并且只发送有变化的路由信息事实上OSPF是间接设置了周期性更新路由的规则因为所有路由都是有刷新时间的当达到刷新时间阀值时该路由就会产生一次更新默认时间为1800秒即30分钟所以OSPF路由的定期更新周期默认为30分钟。OSPF所有路由的管理距离(Ddministrative Distance)为110OSPF只支持等价负载均衡。距离矢量路由协议的根本特征就是自己的路由表是完全从其它路由器学来的并且将收到的路由条目一丝不变地放进自己的路由表运行距离矢量路由协议的路由器之间交换的是路由表距离矢量路由协议是没有大脑的路由表从来不会自己计算总是把别人的路由表拿来就用而OSPF完全抛弃了这种不可靠的算法OSPF是典型的链路状态路由协议路由器之间交换的并不是路由表而是链路状态OSPF通过获得网络中所有的链路状态信息从而计算出到达每个目标精确的网络路径。
Kubernetes
常见面试题
参考链接: https://www.zhihu.com/question/379143600
1、简述etcd及其特点
etcd是CoreOS团队发起的开源项目是一个管理配置信息和服务发现service discovery的项目它的目标是构建一个高可用的分布式键值key-value数据库基于Go语言实现。
特点
简单支持REST风格的HTTPJSON 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、简述Minikube、Kubectl、Kubelet分别是什么
Minikube是一种可以在本地轻松运行一个单节点Kubernetes群集的工具。
Kubectl是一个命令行工具可以使用该工具控制Kubernetes集群管理器如检查群集资源创建、删除和更新组件查看应用程序。
Kubelet是一个代理服务它在每个节点上运行并使从服务器与主服务器通信。
6、简述Kubernetes常见的部署方式
常见的Kubernetes部署方式有
kubeadm也是推荐的一种部署方式二进制minikube在本地轻松运行一个单节点Kubernetes群集的工具。
7、简述Kubernetes如何实现集群管理
在集群管理方面Kubernetes将集群中的机器划分为一个Master节点和一群工作节点Node。其中在Master节点运行着集群管理相关的一组进程kube-apiserver、kube-controller-manager和kube-scheduler这些进程实现了整个集群的资源管理、Pod调度、弹性伸缩、安全控制、系统监控和纠错等管理能力并且都是全自动完成的。
8、简述Kubernetes的优势、适应场景及其特点
Kubernetes作为一个完备的分布式系统支撑平台其主要优势
容器编排轻量级开源弹性伸缩负载均衡
Kubernetes常见场景
快速部署应用快速扩展应用无缝对接新的应用功能节省资源优化硬件资源的使用
Kubernetes相关特点
可移植支持公有云、私有云、混合云、多重云multi-cloud。可扩展: 模块化,、插件化、可挂载、可组合。自动化: 自动部署、自动重启、自动复制、自动伸缩/扩展。
9、简述Kubernetes的缺点或当前的不足之处
Kubernetes当前存在的缺点不足如下
安装过程和配置相对困难复杂。管理服务相对繁琐。运行和编译需要很多时间。它比其他替代品更昂贵。对于简单的应用程序来说可能不需要涉及Kubernetes即可满足。
10、简述Kubernetes相关基础概念
MasterKubernetes集群的管理节点负责管理集群提供集群的资源数据访问入口。拥有etcd存储服务可选运行Api Server进程Controller Manager服务进程及Scheduler服务进程。NodeworkerNodeworker是Kubernetes集群架构中运行Pod的服务节点是Kubernetes集群操作的单元用来承载被分配Pod的运行是Pod运行的宿主机。运行Docker Eninge服务守护进程kunelet及负载均衡器kube-proxy。Pod运行于Node节点上若干相关容器的组合。Pod内包含的容器运行在同一宿主机上使用相同的网络命名空间、IP地址和端口能够通过localhost进行通信。Pod是Kubernetes进行创建、调度和管理的最小单位它提供了比容器更高层次的抽象使得部署和管理更加灵活。一个Pod可以包含一个容器或者多个相关容器。LabelKubernetes中的Label实质是一系列的Key/Value键值对其中key与value可自定义。Label可以附加到各种资源对象上如Node、Pod、Service、RC等。一个资源对象可以定义任意数量的Label同一个Label也可以被添加到任意数量的资源对象上去。Kubernetes通过Label Selector标签选择器查询和筛选资源对象。Replication ControllerReplication Controller用来管理Pod的副本保证集群中存在指定数量的Pod副本。集群中副本的数量大于指定数量则会停止指定数量之外的多余容器数量。反之则会启动少于指定数量个数的容器保证数量不变。Replication Controller是实现弹性伸缩、动态扩容和滚动升级的核心。DeploymentDeployment在内部使用了RS来实现目的Deployment相当于RC的一次升级其最大的特色为可以随时获知当前Pod的部署进度。HPAHorizontal Pod AutoscalerPod的横向自动扩容也是Kubernetes的一种资源通过追踪分析RC控制的所有Pod目标的负载变化情况来确定是否需要针对性的调整Pod副本数量。ServiceService定义了Pod的逻辑集合和访问该集合的策略是真实服务的抽象。Service提供了一个统一的服务访问入口以及服务代理和发现机制关联多个相同Label的Pod用户不需要了解后台Pod是如何运行。VolumeVolume是Pod中能够被多个容器访问的共享目录Kubernetes中的Volume是定义在Pod上可以被一个或多个Pod中的容器挂载到某个目录下。NamespaceNamespace用于实现多租户的资源隔离可将集群内部的资源对象分配到不同的Namespace中形成逻辑上的不同项目、小组或用户组便于不同的Namespace在共享使用整个集群的资源的同时还能被分别管理。
11、简述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的伸缩动作。
12、简述Kubernetes RC的机制
Replication Controller用来管理Pod的副本保证集群中存在指定数量的Pod副本。当定义了RC并提交至Kubernetes集群中之后Master节点上的Controller Manager组件获悉并同时巡检系统中当前存活的目标Pod并确保目标Pod实例的数量刚好等于此RC的期望值若存在过多的Pod副本在运行系统会停止一些Pod反之则自动创建一些Pod。
13、简述Kubernetes Replica Set和Replication Controller之间有什么区别
Replica Set和Replication Controller类似都是确保在任何给定时间运行指定数量的Pod副本。不同之处在于RS使用基于集合的选择器而Replication Controller使用基于权限的选择器。
14、简述kube-proxy的作用
kube-proxy运行在所有节点上它监听apiserver中service和endpoint的变化情况创建路由规则以提供服务IP和负载均衡功能。简单理解此进程是Service的透明代理兼负载均衡器其核心功能是将到某个Service的访问请求转发到后端的多个Pod实例上。
15、简述kube-proxy iptables的原理
Kubernetes从1.2版本开始将iptables作为kube-proxy的默认模式。iptables模式下的kube-proxy不再起到Proxy的作用其核心功能通过API Server的Watch接口实时跟踪Service与Endpoint的变更信息并更新对应的iptables规则Client的请求流量则通过iptables的NAT机制“直接路由”到目标Pod。
16、简述kube-proxy ipvs的原理
IPVS在Kubernetes1.11中升级为GA稳定版。IPVS则专门用于高性能负载均衡并使用更高效的数据结构Hash表允许几乎无限的规模扩张因此被kube-proxy采纳为最新模式。
在IPVS模式下使用iptables的扩展ipset而不是直接调用iptables来生成规则链。iptables规则链是一个线性的数据结构ipset则引入了带索引的数据结构因此当规则很多时也可以很高效地查找和匹配。
可以将ipset简单理解为一个IP段的集合这个集合的内容可以是IP地址、IP网段、端口等iptables可以直接添加规则对这个“可变的集合”进行操作这样做的好处在于可以大大减少iptables规则的数量从而减少性能损耗。
17、简述kube-proxy ipvs和iptables的异同
iptables与IPVS都是基于Netfilter实现的但因为定位不同二者有着本质的差别iptables是为防火墙而设计的IPVS则专门用于高性能负载均衡并使用更高效的数据结构Hash表允许几乎无限的规模扩张。
与iptables相比IPVS拥有以下明显优势
为大型集群提供了更好的可扩展性和性能支持比iptables更复杂的复制均衡算法最小负载、最少连接、加权等支持服务器健康检查和连接重试等功能可以动态修改ipset的集合即使iptables的规则正在使用这个集合。
18、简述Kubernetes中什么是静态Pod
静态Pod是由kubelet进行管理的仅存在于特定Node的Pod上他们不能通过API Server进行管理无法与ReplicationController、Deployment或者DaemonSet进行关联并且kubelet无法对他们进行健康检查。静态Pod总是由kubelet进行创建并且总是在kubelet所在的Node上运行。
19、简述Kubernetes中Pod可能位于的状态
PendingAPI Server已经创建该Pod且Pod内还有一个或多个容器的镜像没有创建包括正在下载镜像的过程。RunningPod内所有容器均已创建且至少有一个容器处于运行状态、正在启动状态或正在重启状态。SucceededPod内所有容器均成功执行退出且不会重启。FailedPod内所有容器均已退出但至少有一个容器退出为失败状态。Unknown由于某种原因无法获取该Pod状态可能由于网络通信不畅导致。
20、简述Kubernetes创建一个Pod的主要流程
Kubernetes中创建一个Pod涉及多个组件之间联动主要流程如下
客户端提交Pod的配置信息可以是yaml文件定义的信息到kube-apiserver。Apiserver收到指令后通知给controller-manager创建一个资源对象。Controller-manager通过api-server将Pod的配置信息存储到etcd数据中心中。Kube-scheduler检测到Pod信息会开始调度预选会先过滤掉不符合Pod资源配置要求的节点然后开始调度调优主要是挑选出更适合运行Pod的节点然后将Pod的资源配置单发送到Node节点上的kubelet组件上。Kubelet根据scheduler发来的资源配置单运行Pod运行成功后将Pod的运行信息返回给schedulerscheduler将返回的Pod运行状况的信息存储到etcd数据中心。
21、简述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需要保证该容器持续运行JobOnFailure或Never确保容器执行完成后不再重启kubelet在Pod失效时重启不论将RestartPolicy设置为何值也不会对Pod进行健康检查。
22、简述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掉。
23、简述Kubernetes Pod的LivenessProbe探针的常见方式
kubelet定期执行LivenessProbe探针来诊断容器的健康状态通常有以下三种方式
ExecAction在容器内执行一个命令若返回码为0则表明容器健康。TCPSocketAction通过容器的IP地址和端口号执行TCP检查若能建立TCP连接则表明容器健康。HTTPGetAction通过容器的IP地址、端口号及路径调用HTTP Get方法若响应的状态码大于等于200且小于400则表明容器健康。
24、简述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。
25、简述Kubernetes初始化容器init container
init container的运行方式与应用容器不同它们必须先于应用容器执行完成当设置了多个init container时将按顺序逐个运行并且只有前一个init container运行成功后才能运行后一个init container。当所有init container都成功运行后Kubernetes才会初始化Pod的各种信息并开始创建和运行应用容器。
26、简述Kubernetes deployment升级过程
初始创建Deployment时系统创建了一个ReplicaSet并按用户的需求创建了对应数量的Pod副本。当更新Deployment时系统创建了一个新的ReplicaSet并将其副本数量扩展到1然后将旧ReplicaSet缩减为2。之后系统继续按照相同的更新策略对新旧两个ReplicaSet进行逐个调整。最后新的ReplicaSet运行了对应个新版本Pod副本旧的ReplicaSet副本数量则缩减为0。
27、简述Kubernetes deployment升级策略
在Deployment的定义中可以通过spec.strategy指定Pod更新的策略目前支持两种策略Recreate重建和RollingUpdate滚动更新默认值为RollingUpdate。
Recreate设置spec.strategy.typeRecreate表示Deployment在更新Pod时会先杀掉所有正在运行的Pod然后创建新的Pod。RollingUpdate设置spec.strategy.typeRollingUpdate表示Deployment会以滚动更新的方式来逐个更新Pod。同时可以通过设置spec.strategy.rollingUpdate下的两个参数maxUnavailable和maxSurge来控制滚动更新的过程。
28、简述Kubernetes DaemonSet类型的资源特性
DaemonSet资源对象会在每个Kubernetes集群中的节点上运行并且每个节点只能运行一个Pod这是它和Deployment资源对象的最大也是唯一的区别。因此在定义yaml文件中不支持定义replicas。
它的一般使用场景如下
在去做每个节点的日志收集工作。监控每个节点的的运行状态。
29、简述Kubernetes自动扩容机制
Kubernetes使用Horizontal Pod AutoscalerHPA的控制器实现基于CPU使用率进行自动Pod扩缩容的功能。HPA控制器周期性地监测目标Pod的资源性能指标并与HPA资源对象中的扩缩容条件进行对比在满足条件时对Pod副本数量进行调整。
Kubernetes中的某个Metrics ServerHeapster或自定义Metrics Server持续采集所有Pod副本的指标数据。HPA控制器通过Metrics Server的APIHeapster的API或聚合API获取这些数据基于用户定义的扩缩容规则进行计算得到目标Pod副本数量。
当目标Pod副本数量与当前副本数量不同时HPA控制器就向Pod的副本控制器Deployment、RC或ReplicaSet发起scale操作调整Pod的副本数量完成扩缩容操作。
30、简述Kubernetes Service类型
通过创建Service可以为一组具有相同功能的容器应用提供一个统一的入口地址并且将请求负载分发到后端的各个容器应用上。其主要类型有
ClusterIP虚拟的服务IP地址该地址用于Kubernetes集群内部的Pod访问在Node上kube-proxy通过设置的iptables规则进行转发NodePort使用宿主机的端口使能够访问各Node的外部客户端通过Node的IP地址和端口号就能访问服务LoadBalancer使用外接负载均衡器完成到服务的负载分发需要在spec.status.loadBalancer字段指定外部负载均衡器的IP地址通常用于公有云。
31、简述Kubernetes Service分发后端的策略
Service负载分发的策略有RoundRobin和SessionAffinity
RoundRobin默认为轮询模式即轮询将请求转发到后端的各个Pod上。SessionAffinity基于客户端IP地址进行会话保持的模式即第1次将某个客户端发起的请求转发到后端的某个Pod上之后从相同的客户端发起的请求都将被转发到后端相同的Pod上。
32、简述Kubernetes Headless Service
在某些应用场景中若需要人为指定负载均衡器不使用Service提供的默认负载均衡的功能或者应用程序希望知道属于同组服务的其他实例。Kubernetes提供了Headless Service来实现这种功能即不为Service设置ClusterIP入口IP地址仅通过Label Selector将后端的Pod列表返回给调用的客户端。
33、简述Kubernetes外部如何访问集群内的服务
对于Kubernetes集群外的客户端默认情况无法通过Pod的IP地址或者Service的虚拟IP地址虚拟端口号进行访问。通常可以通过以下方式进行访问Kubernetes集群内的服务
映射Pod到物理机将Pod端口号映射到宿主机即在Pod中采用hostPort方式以使客户端应用能够通过物理机访问容器应用。映射Service到物理机将Service端口号映射到宿主机即在Service中采用nodePort方式以使客户端应用能够通过物理机访问容器应用。映射Sercie到LoadBalancer通过设置LoadBalancer映射到云服务商提供的LoadBalancer地址。这种用法仅用于在公有云服务提供商的云平台上设置Service的场景。
34、简述Kubernetes ingress
Kubernetes的Ingress资源对象用于将不同URL的访问请求转发到后端不同的Service以实现HTTP层的业务路由机制。
Kubernetes使用了Ingress策略和Ingress Controller两者结合并实现了一个完整的Ingress负载均衡器。使用Ingress进行负载分发时Ingress Controller基于Ingress规则将客户端请求直接转发到Service对应的后端EndpointPod上从而跳过kube-proxy的转发功能kube-proxy不再起作用全过程为ingress controller ingress 规则 ---- services。
同时当Ingress Controller提供的是对外服务则实际上实现的是边缘路由器的功能。
35、简述Kubernetes镜像的下载策略
Kubernetes的镜像下载策略有三种Always、Never、IFNotPresent。
Always镜像标签为latest时总是从指定的仓库中获取镜像。Never禁止从仓库中下载镜像也就是说只能使用本地镜像。IfNotPresent仅当本地没有对应镜像时才从目标仓库中下载。默认的镜像下载策略是当镜像标签是latest时默认策略是Always当镜像标签是自定义时也就是标签不是latest那么默认策略是IfNotPresent。
36、简述Kubernetes的负载均衡器
负载均衡器是暴露服务的最常见和标准方式之一。
根据工作环境使用两种类型的负载均衡器即内部负载均衡器或外部负载均衡器。内部负载均衡器自动平衡负载并使用所需配置分配容器而外部负载均衡器将流量从外部负载引导至后端容器。
37、简述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绑定到目标节点上。
38、简述Kubernetes Scheduler作用及实现原理
Kubernetes Scheduler是负责Pod调度的重要功能模块Kubernetes Scheduler在整个系统中承担了“承上启下”的重要功能“承上”是指它负责接收Controller Manager创建的新Pod为其调度至目标Node“启下”是指调度完成后目标Node上的kubelet服务进程接管后继工作负责Pod接下来生命周期。
Kubernetes Scheduler的作用是将待调度的PodAPI新创建的Pod、Controller Manager为补足副本而创建的Pod等按照特定的调度算法和调度策略绑定Binding到集群中某个合适的Node上并将绑定信息写入etcd中。
在整个调度过程中涉及三个对象分别是待调度Pod列表、可用Node列表以及调度算法和策略。
Kubernetes Scheduler通过调度算法调度为待调度Pod列表中的每个Pod从Node列表中选择一个最适合的Node来实现Pod的调度。随后目标节点上的kubelet通过API Server监听到Kubernetes Scheduler产生的Pod绑定事件然后获取对应的Pod清单下载Image镜像并启动容器。
39、简述Kubernetes Scheduler使用哪两种算法将Pod绑定到worker节点
Kubernetes Scheduler根据如下两种调度算法将 Pod 绑定到最合适的工作节点
预选Predicates输入是所有节点输出是满足预选条件的节点。kube-scheduler根据预选策略过滤掉不满足策略的Nodes。如果某节点的资源不足或者不满足预选策略的条件则无法通过预选。如“Node的label必须与Pod的Selector一致”。优选Priorities输入是预选阶段筛选出的节点优选会根据优先策略为通过预选的Nodes进行打分排名选择得分最高的Node。例如资源越富裕、负载越小的Node可能具有越高的排名。
40、简述Kubernetes kubelet的作用
在Kubernetes集群中在每个Node又称Worker上都会启动一个kubelet服务进程。该进程用于处理Master下发到本节点的任务管理Pod及Pod中的容器。每个kubelet进程都会在API Server上注册节点自身的信息定期向Master汇报节点资源的使用情况并通过cAdvisor监控容器和节点资源。
41、简述Kubernetes kubelet监控Worker节点资源是使用什么组件来实现的
kubelet使用cAdvisor对worker节点资源进行监控。在Kubernetes系统中cAdvisor已被默认集成到kubelet组件内当kubelet服务启动时它会自动启动cAdvisor服务然后cAdvisor会实时采集所在节点的性能指标及在节点上运行的容器的性能指标。
42、简述Kubernetes如何保证集群的安全性
Kubernetes通过一系列机制来实现集群的安全控制主要有如下不同的维度 基础设施方面保证容器与其所在宿主机的隔离 权限方面 最小权限原则合理限制所有组件的权限确保组件只执行它被授权的行为通过限制单个组件的能力来限制它的权限范围。用户权限划分普通用户和管理员的角色。 集群方面 API Server的认证授权Kubernetes集群中所有资源的访问和变更都是通过Kubernetes API Server来实现的因此需要建议采用更安全的HTTPS或Token来识别和认证客户端身份Authentication以及随后访问权限的授权Authorization环节。API Server的授权管理通过授权策略来决定一个API调用是否合法。对合法用户进行授权并且随后在用户访问时进行鉴权建议采用更安全的RBAC方式来提升集群安全授权。 敏感数据引入Secret机制对于集群敏感数据建议使用Secret方式进行保护。 AdmissionControl准入机制对kubernetes api的请求过程中顺序为先经过认证 授权然后执行准入操作最后对目标对象进行操作。
43、简述Kubernetes准入机制
在对集群进行请求时每个准入控制代码都按照一定顺序执行。如果有一个准入控制拒绝了此次请求那么整个请求的结果将会立即返回并提示用户相应的error信息。
准入控制AdmissionControl准入控制本质上为一段准入代码在对kubernetes api的请求过程中顺序为先经过认证 授权然后执行准入操作最后对目标对象进行操作。常用组件控制代码如下
AlwaysAdmit允许所有请求AlwaysDeny禁止所有请求多用于测试环境。ServiceAccount它将serviceAccounts实现了自动化它会辅助serviceAccount做一些事情比如如果pod没有serviceAccount属性它会自动添加一个default并确保pod的serviceAccount始终存在。LimitRanger观察所有的请求确保没有违反已经定义好的约束条件这些条件定义在namespace中LimitRange对象中。NamespaceExists观察所有的请求如果请求尝试创建一个不存在的namespace则这个请求被拒绝。
44、简述Kubernetes RBAC及其特点优势
RBAC是基于角色的访问控制是一种基于个人用户的角色来管理对计算机或网络资源的访问的方法。
相对于其他授权模式RBAC具有如下优势
对集群中的资源和非资源权限均有完整的覆盖。整个RBAC完全由几个API对象完成 同其他API对象一样 可以用kubectl或API进行操作。可以在运行时进行调整无须重新启动API Server。
45、简述Kubernetes Secret作用
Secret对象主要作用是保管私密数据比如密码、OAuth Tokens、SSH Keys等信息。将这些私密信息放在Secret对象中比直接放在Pod或Docker Image中更安全也更便于使用和分发。
46、简述Kubernetes Secret有哪些使用方式
创建完secret之后可通过如下三种方式使用
在创建Pod时通过为Pod指定Service Account来自动使用该Secret。通过挂载该Secret到Pod来使用它。在Docker镜像下载时使用通过指定Pod的spc.ImagePullSecrets来引用它。
47、简述Kubernetes PodSecurityPolicy机制
Kubernetes PodSecurityPolicy是为了更精细地控制Pod对资源的使用方式以及提升安全策略。在开启PodSecurityPolicy准入控制器后Kubernetes默认不允许创建任何Pod需要创建PodSecurityPolicy策略和相应的RBAC授权策略Authorizing PoliciesPod才能创建成功。
48、简述Kubernetes PodSecurityPolicy机制能实现哪些安全策略
在PodSecurityPolicy对象中可以设置不同字段来控制Pod运行时的各种安全策略常见的有
特权模式privileged是否允许Pod以特权模式运行。宿主机资源控制Pod对宿主机资源的控制如hostPID是否允许Pod共享宿主机的进程空间。用户和组设置运行容器的用户ID范围或组范围。提升权限AllowPrivilegeEscalation设置容器内的子进程是否可以提升权限通常在设置非root用户MustRunAsNonRoot时进行设置。SELinux进行SELinux的相关配置。
49、简述Kubernetes网络模型
Kubernetes网络模型中每个Pod都拥有一个独立的IP地址并假定所有Pod都在一个可以直接连通的、扁平的网络空间中。所以不管它们是否运行在同一个Node宿主机中都要求它们可以直接通过对方的IP进行访问。设计这个原则的原因是用户不需要额外考虑如何建立Pod之间的连接也不需要考虑如何将容器端口映射到主机端口等问题。
同时为每个Pod都设置一个IP地址的模型使得同一个Pod内的不同容器会共享同一个网络命名空间也就是同一个Linux网络协议栈。这就意味着同一个Pod内的容器可以通过localhost来连接对方的端口。
在Kubernetes的集群里IP是以Pod为单位进行分配的。一个Pod内部的所有容器共享一个网络堆栈相当于一个网络命名空间它们的IP地址、网络设备、配置等都是共享的。
50、简述Kubernetes CNI模型
CNI提供了一种应用容器的插件化网络解决方案定义对容器网络进行操作和配置的规范通过插件的形式对CNI接口进行实现。CNI仅关注在创建容器时分配网络资源和在销毁容器时删除网络资源。在CNI模型中只涉及两个概念容器和网络。
容器Container是拥有独立Linux网络命名空间的环境例如使用Docker或rkt创建的容器。容器需要拥有自己的Linux网络命名空间这是加入网络的必要条件。网络Network表示可以互连的一组实体这些实体拥有各自独立、唯一的IP地址可以是容器、物理机或者其他网络设备比如路由器等。
对容器网络的设置和操作都通过插件Plugin进行具体实现CNI插件包括两种类型CNI Plugin和IPAMIP Address ManagementPlugin。CNI Plugin负责为容器配置网络资源IPAM Plugin负责对容器的IP地址进行分配和管理。IPAM Plugin作为CNI Plugin的一部分与CNI Plugin协同工作。
51、简述Kubernetes网络策略
为实现细粒度的容器间网络访问隔离策略Kubernetes引入Network Policy。
Network Policy的主要功能是对Pod间的网络通信进行限制和准入控制设置允许访问或禁止访问的客户端Pod列表。Network Policy定义网络策略配合策略控制器Policy Controller进行策略的实现。
52、简述Kubernetes网络策略原理
Network Policy的工作原理主要为policy controller需要实现一个API Listener监听用户设置的Network Policy定义并将网络访问规则通过各Node的Agent进行实际设置Agent则需要通过CNI网络插件实现。
53、简述Kubernetes中flannel的作用
Flannel可以用于Kubernetes底层网络的实现主要作用有
它能协助Kubernetes给每一个Node上的Docker容器都分配互相不冲突的IP地址。它能在这些IP地址之间建立一个覆盖网络Overlay Network通过这个覆盖网络将数据包原封不动地传递到目标容器内。
54、简述Kubernetes Calico网络组件实现原理
Calico是一个基于BGP的纯三层的网络方案与OpenStack、Kubernetes、AWS、GCE等云平台都能够良好地集成。
Calico在每个计算节点都利用Linux Kernel实现了一个高效的vRouter来负责数据转发。每个vRouter都通过BGP协议把在本节点上运行的容器的路由信息向整个Calico网络广播并自动设置到达其他节点的路由转发规则。
Calico保证所有容器之间的数据流量都是通过IP路由的方式完成互联互通的。Calico节点组网时可以直接利用数据中心的网络结构L2或者L3不需要额外的NAT、隧道或者Overlay Network没有额外的封包解包能够节约CPU运算提高网络效率。
55、简述Kubernetes共享存储的作用
Kubernetes对于有状态的容器应用或者对数据需要持久化的应用因此需要更加可靠的存储来保存应用产生的重要数据以便容器应用在重建之后仍然可以使用之前的数据。因此需要使用共享存储。
56、简述Kubernetes数据持久化的方式有哪些
Kubernetes通过数据持久化来持久化保存重要数据常见的方式有 EmptyDir空目录没有指定要挂载宿主机上的某个目录直接由Pod内保部映射到宿主机上。类似于docker中的manager volume。 场景 只需要临时将数据保存在磁盘上比如在合并/排序算法中作为两个容器的共享存储。 特性 同个pod里面的不同容器共享同一个持久化目录当pod节点删除时volume的数据也会被删除。emptyDir的数据持久化的生命周期和使用的pod一致一般是作为临时存储使用。 Hostpath将宿主机上已存在的目录或文件挂载到容器内部。类似于docker中的bind mount挂载方式。 特性增加了Pod与节点之间的耦合。
PersistentVolume简称PV如基于NFS服务的PV也可以基于GFS的PV。它的作用是统一数据持久化目录方便管理。
57、简述Kubernetes PV和PVC
PV是对底层网络共享存储的抽象将共享存储定义为一种“资源”。
PVC则是用户对存储资源的一个“申请”。
58、简述Kubernetes PV生命周期内的阶段
某个PV在生命周期中可能处于以下4个阶段Phaes之一。
Available可用状态还未与某个PVC绑定。Bound已与某个PVC绑定。Released绑定的PVC已经删除资源已释放但没有被集群回收。Failed自动资源回收失败。
59、简述Kubernetes所支持的存储供应模式
Kubernetes支持两种资源的存储供应模式静态模式Static和动态模式Dynamic。
静态模式集群管理员手工创建许多PV在定义PV时需要将后端存储的特性进行设置。动态模式集群管理员无须手工创建PV而是通过StorageClass的设置对后端存储进行描述标记为某种类型。此时要求PVC对存储的类型进行声明系统将自动完成PV的创建及与PVC的绑定。
60、简述Kubernetes CSI模型
Kubernetes CSI是Kubernetes推出与容器对接的存储接口标准存储提供方只需要基于标准接口进行存储插件的实现就能使用Kubernetes的原生存储机制为容器提供存储服务。CSI使得存储提供方的代码能和Kubernetes代码彻底解耦部署也与Kubernetes核心组件分离显然存储插件的开发由提供方自行维护就能为Kubernetes用户提供更多的存储功能也更加安全可靠。
CSI包括CSI Controller和CSI Node
CSI Controller的主要功能是提供存储服务视角对存储资源和存储卷进行管理和操作。CSI Node的主要功能是对主机Node上的Volume进行管理和操作。
61、简述Kubernetes Worker节点加入集群的过程
通常需要对Worker节点进行扩容从而将应用系统进行水平扩展。主要过程如下
在该Node上安装Docker、kubelet和kube-proxy服务然后配置kubelet和kubeproxy的启动参数将Master URL指定为当前Kubernetes集群Master的地址最后启动这些服务通过kubelet默认的自动注册机制新的Worker将会自动加入现有的Kubernetes集群中Kubernetes Master在接受了新Worker的注册之后会自动将其纳入当前集群的调度范围。
62、简述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的使用量也会增加。
63、简述Kubernetes Requests和Limits如何影响Pod的调度
当一个Pod创建成功时Kubernetes调度器Scheduler会为该Pod选择一个节点来执行。对于每种计算资源CPU和Memory而言每个节点都有一个能用于运行Pod的最大容量值。调度器在调度时首先要确保调度后该节点上所有Pod的CPU和内存的Requests总和不超过该节点能提供给Pod使用的CPU和Memory的最大容量值。
64、简述Kubernetes Metric Service
在Kubernetes从1.10版本后采用Metrics Server作为默认的性能数据采集和监控主要用于提供核心指标Core Metrics包括Node、Pod的CPU和内存使用指标。
对其他自定义指标Custom Metrics的监控则由Prometheus等组件来完成。
65、简述Kubernetes中如何使用EFK实现日志的统一管理
在Kubernetes集群环境中通常一个完整的应用或服务涉及组件过多建议对日志系统进行集中化管理通常采用EFK实现。
EFK是 Elasticsearch、Fluentd 和 Kibana 的组合其各组件功能如下
Elasticsearch是一个搜索引擎负责存储日志并提供查询接口Fluentd负责从 Kubernetes 搜集日志每个Node节点上面的Fluentd监控并收集该节点上面的系统日志并将处理过后的日志信息发送给ElasticsearchKibana提供了一个 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目录下的容器日志输出。
66、简述Kubernetes如何进行优雅的节点关机维护
由于Kubernetes节点运行大量Pod因此在进行关机维护之前建议先使用kubectl drain将该节点的Pod进行驱逐然后进行关机维护。
67、简述Kubernetes集群联邦
Kubernetes集群联邦可以将多个Kubernetes集群作为一个集群进行管理。因此可以在一个数据中心/云中创建多个Kubernetes集群并使用集群联邦在一个地方控制/管理所有集群。
68、简述Helm及其优势
Helm是Kubernetes的软件包管理工具。类似Ubuntu中使用的APT、CentOS中使用的yum 或者Python中的 pip 一样。
Helm能够将一组Kubernetes资源打包统一管理, 是查找、共享和使用为Kubernetes构建的软件的最佳方式。
Helm中通常每个包称为一个Chart一个Chart是一个目录一般情况下会将目录进行打包压缩形成name-version.tgz格式的单一文件方便传输和存储。
在Kubernetes中部署一个可以使用的应用需要涉及到很多的 Kubernetes 资源的共同协作。使用Helm则具有如下优势
统一管理、配置和更新这些分散的Kubernetes的应用资源文件分发和复用一套应用模板将应用的一系列资源当做一个软件包管理。对于应用发布者而言可以通过 Helm 打包应用、管理应用依赖关系、管理应用版本并发布应用到软件仓库。
对于使用者而言使用Helm后不用需要编写复杂的应用部署文件可以以简单的方式在Kubernetes上查找、安装、升级、回滚、卸载应用程序。
69、k8s是什么请说出你的了解
答Kubenetes是一个针对容器应用进行自动部署弹性伸缩和管理的开源系统。主要功能是生产环境中的容器编排。
K8S是Google公司推出的它来源于由Google公司内部使用了15年的Borg系统集结了Borg的精华。
70、K8s架构的组成是什么
答和大多数分布式系统一样K8S集群至少需要一个主节点Master和多个计算节点Node。
主节点主要用于暴露API调度部署和节点的管理计算节点运行一个容器运行环境一般是docker环境类似docker环境的还有rkt同时运行一个K8s的代理kubelet用于和master通信。计算节点也会运行一些额外的组件像记录日志节点监控服务发现等等。计算节点是k8s集群中真正工作的节点。
K8S架构细分
1、Master节点默认不参加实际工作
Kubectl客户端命令行工具作为整个K8s集群的操作入口Api Server在K8s架构中承担的是“桥梁”的角色作为资源操作的唯一入口它提供了认证、授权、访问控制、API注册和发现等机制。客户端与k8s群集及K8s内部组件的通信都要通过Api Server这个组件Controller-manager负责维护群集的状态比如故障检测、自动扩展、滚动更新等Scheduler负责资源的调度按照预定的调度策略将pod调度到相应的node节点上Etcd担任数据中心的角色保存了整个群集的状态
2、Node节点
Kubelet负责维护容器的生命周期同时也负责Volume和网络的管理一般运行在所有的节点是Node节点的代理当Scheduler确定某个node上运行pod之后会将pod的具体信息imagevolume等发送给该节点的kubeletkubelet根据这些信息创建和运行容器并向master返回运行状态。自动修复功能如果某个节点中的容器宕机它会尝试重启该容器若重启无效则会将该pod杀死然后重新创建一个容器Kube-proxyService在逻辑上代表了后端的多个pod。负责为Service提供cluster内部的服务发现和负载均衡外界通过Service访问pod提供的服务时Service接收到的请求后就是通过kube-proxy来转发到pod上的container-runtime是负责管理运行容器的软件比如dockerPod是k8s集群里面最小的单位。每个pod里边可以运行一个或多个container容器如果一个pod中有两个container那么container的USR用户、MNT挂载点、PID进程号是相互隔离的UTS主机名和域名、IPC消息队列、NET网络栈是相互共享的。我比较喜欢把pod来当做豌豆夹而豌豆就是pod中的container
71、容器和主机部署应用的区别是什么
答容器的中心思想就是秒级启动一次封装、到处运行这是主机部署应用无法达到的效果但同时也更应该注重容器的数据持久化问题。
另外容器部署可以将各个服务进行隔离互不影响这也是容器的另一个核心概念。
72、请你说一下kubenetes针对pod资源对象的健康监测机制
答K8s中对于pod资源对象的健康状态检测提供了三类probe探针来执行对pod的健康监测
1 livenessProbe探针
可以根据用户自定义规则来判定pod是否健康如果livenessProbe探针探测到容器不健康则kubelet会根据其重启策略来决定是否重启如果一个容器不包含livenessProbe探针则kubelet会认为容器的livenessProbe探针的返回值永远成功。
2 ReadinessProbe探针
同样是可以根据用户自定义规则来判断pod是否健康如果探测失败控制器会将此pod从对应service的endpoint列表中移除从此不再将任何请求调度到此Pod上直到下次探测成功。
3 startupProbe探针
启动检查机制应用一些启动缓慢的业务避免业务长时间启动而被上面两类探针kill掉这个问题也可以换另一种方式解决就是定义上面两类探针机制时初始化时间定义的长一些即可。
每种探测方法能支持以下几个相同的检查参数用于设置控制检查时间
initialDelaySeconds初始第一次探测间隔用于应用启动的时间防止应用还没启动而健康检查失败periodSeconds检查间隔多久执行probe检查默认为10stimeoutSeconds检查超时时长探测应用timeout后为失败successThreshold成功探测阈值表示探测多少次为健康正常默认探测1次。
上面两种探针都支持以下三种探测方法
1Exec通过执行命令的方式来检查服务是否正常比如使用cat命令查看pod中的某个重要配置文件是否存在若存在则表示pod健康。反之异常。
Exec探测方式的yaml文件语法如下
spec:containers:- name: livenessimage: k8s.gcr.io/busyboxargs:- /bin/sh- -c- touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy; sleep 600livenessProbe: #选择livenessProbe的探测机制exec: #执行以下命令command:- cat- /tmp/healthyinitialDelaySeconds: 5 #在容器运行五秒后开始探测periodSeconds: 5 #每次探测的时间间隔为5秒在上面的配置文件中探测机制为在容器运行5秒后每隔五秒探测一次如果cat命令返回的值为“0”则表示健康如果为非0则表示异常。
2Httpget通过发送http/htps请求检查服务是否正常返回的状态码为200-399则表示容器健康注http get类似于命令curl -I。
Httpget探测方式的yaml文件语法如下
spec:containers:- name: livenessimage: k8s.gcr.io/livenesslivenessProbe: #采用livenessProbe机制探测httpGet: #采用httpget的方式scheme:HTTP #指定协议也支持httpspath: /healthz #检测是否可以访问到网页根目录下的healthz网页文件port: 8080 #监听端口是8080initialDelaySeconds: 3 #容器运行3秒后开始探测periodSeconds: 3 #探测频率为3秒上述配置文件中探测方式为项容器发送HTTP GET请求请求的是8080端口下的healthz文件返回任何大于或等于200且小于400的状态码表示成功。任何其他代码表示异常。
3tcpSocket通过容器的IP和Port执行TCP检查如果能够建立TCP连接则表明容器健康这种方式与HTTPget的探测机制有些类似tcpsocket健康检查适用于TCP业务。
tcpSocket探测方式的yaml文件语法如下
spec:containers:- name: goproxyimage: k8s.gcr.io/goproxy:0.1ports:
- containerPort: 8080
#这里两种探测机制都用上了都是为了和容器的8080端口建立TCP连接readinessProbe:tcpSocket:port: 8080initialDelaySeconds: 5periodSeconds: 10livenessProbe:tcpSocket:port: 8080initialDelaySeconds: 15periodSeconds: 20在上述的yaml配置文件中两类探针都使用了在容器启动5秒后kubelet将发送第一个readinessProbe探针这将连接容器的8080端口如果探测成功则该pod为健康十秒后kubelet将进行第二次连接。
除了readinessProbe探针外在容器启动15秒后kubelet将发送第一个livenessProbe探针仍然尝试连接容器的8080端口如果连接失败则重启容器。
探针探测的结果无外乎以下三者之一
SuccessContainer通过了检查FailureContainer没有通过检查Unknown没有执行检查因此不采取任何措施通常是我们没有定义探针检测默认为成功。
若觉得上面还不够透彻可以移步其官网文档
https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/
73、如何控制滚动更新过程
答可以通过下面的命令查看到更新时可以控制的参数
[rootmaster yaml]# kubectl explain deploy.spec.strategy.rollingUpdatemaxSurge 此参数控制滚动更新过程副本总数超过预期pod数量的上限。可以是百分比也可以是具体的值。默认为1。
上述参数的作用就是在更新过程中值若为3那么不管三七二一先运行三个pod用于替换旧的pod以此类推
maxUnavailable此参数控制滚动更新过程中不可用的Pod的数量。
这个值和上面的值没有任何关系举个例子我有十个pod但是在更新的过程中我允许这十个pod中最多有三个不可用那么就将这个参数的值设置为3在更新的过程中只要不可用的pod数量小于或等于3那么更新过程就不会停止。
74、K8s中镜像的下载策略是什么
答可通过命令“kubectl explain pod.spec.containers”来查看imagePullPolicy这行的解释。
K8s的镜像下载策略有三种Always、Never、IFNotPresent
Always镜像标签为latest时总是从指定的仓库中获取镜像Never禁止从仓库中下载镜像也就是说只能使用本地镜像IfNotPresent仅当本地没有对应镜像时才从目标仓库中下载。默认的镜像下载策略是当镜像标签是latest时默认策略是Always当镜像标签是自定义时也就是标签不是latest那么默认策略是IfNotPresent。
75、image的状态有哪些
RunningPod所需的容器已经被成功调度到某个节点且已经成功运行PendingAPIserver创建了pod资源对象并且已经存入etcd中但它尚未被调度完成或者仍然处于仓库中下载镜像的过程UnknownAPIserver无法正常获取到pod对象的状态通常是其无法与所在工作节点的kubelet通信所致。
76、pod的重启策略是什么
答可以通过命令“kubectl explain pod.spec”查看pod的重启策略。restartPolicy字段
Always但凡pod对象终止就重启此为默认策略。OnFailure仅在pod对象出现错误时才重启
77、Service这种资源对象的作用是什么
答用来给相同的多个pod对象提供一个固定的统一访问接口常用于服务发现和服务访问。
78、版本回滚相关的命令
[rootmaster httpd-web]# kubectl apply -f httpd2-deploy1.yaml --record
#运行yaml文件并记录版本信息
[rootmaster httpd-web]# kubectl rollout history deployment httpd-devploy1
#查看该deployment的历史版本
[rootmaster httpd-web]# kubectl rollout undo deployment httpd-devploy1 --to-revision1
#执行回滚操作指定回滚到版本1
#在yaml文件的spec字段中可以写以下选项用于限制最多记录多少个历史版本
spec:revisionHistoryLimit: 5
#这个字段通过 kubectl explain deploy.spec 命令找到revisionHistoryLimit integer行获得79、标签与标签选择器的作用是什么
标签是当相同类型的资源对象越来越多的时候为了更好的管理可以按照标签将其分为一个组为的是提升资源对象的管理效率。
标签选择器就是标签的查询过滤条件。目前API支持两种标签选择器
基于等值关系的如“”、“”“”、“”注“”也是等于的意思yaml文件中的matchLabels字段基于集合的如in、notin、existsyaml文件中的matchExpressions字段
注in:在这个集合中notin不在这个集合中exists要么全在exists这个集合中要么都不在notexists
使用标签选择器的操作逻辑
在使用基于集合的标签选择器同时指定多个选择器之间的逻辑关系为“与”操作比如- {key: name,operator: In,values: [zhangsan,lisi]} 那么只要拥有这两个值的资源都会被选中使用空值的标签选择器意味着每个资源对象都被选中如标签选择器的键是“A”两个资源对象同时拥有A这个键但是值不一样这种情况下如果使用空值的标签选择器那么将同时选中这两个资源对象空的标签选择器注意不是上面说的空值而是空的都没有定义键的名称将无法选择出任何资源
在基于集合的选择器中使用“In”或者“Notin”操作时其values可以为空但是如果为空这个标签选择器就没有任何意义了。
两种标签选择器类型基于等值、基于集合的书写方法
selector:matchLabels: #基于等值app: nginxmatchExpressions: #基于集合- {key: name,operator: In,values: [zhangsan,lisi]} #key、operator、values这三个字段是固定的- {key: age,operator: Exists,values:} #如果指定为exists那么values的值一定要为空80、常用的标签分类有哪些
标签分类是可以自定义的但是为了能使他人可以达到一目了然的效果一般会使用以下一些分类
版本类标签releasestable稳定版、canary金丝雀版本可以将其称之为测试版中的测试版、beta测试版环境类标签environmentdev开发、qa测试、production生产、op运维应用类appui、as、pc、sc架构类tierfrontend前端、backend后端、cache缓存分区标签partitioncustomerA客户A、customerB客户B品控级别Trackdaily每天、weekly每周。
81、有几种查看标签的方式
答常用的有以下三种查看方式
[rootmaster ~]# kubectl get pod --show-labels #查看pod并且显示标签内容
[rootmaster ~]# kubectl get pod -L env,tier #显示资源对象标签的值
[rootmaster ~]# kubectl get pod -l env,tier #只显示符合键值资源对象的pod而“-L”是显示所有的pod82、添加、修改、删除标签的命令
#对pod标签的操作
[rootmaster ~]# kubectl label pod label-pod abc123 #给名为label-pod的pod添加标签
[rootmaster ~]# kubectl label pod label-pod abc456 --overwrite #修改名为label-pod的标签
[rootmaster ~]# kubectl label pod label-pod abc- #删除名为label-pod的标签
[rootmaster ~]# kubectl get pod --show-labels#对node节点的标签操作
[rootmaster ~]# kubectl label nodes node01 diskssd #给节点node01添加disk标签
[rootmaster ~]# kubectl label nodes node01 disksss –overwrite #修改节点node01的标签
[rootmaster ~]# kubectl label nodes node01 disk- #删除节点node01的disk标签83、DaemonSet资源对象的特性
DaemonSet这种资源对象会在每个k8s集群中的节点上运行并且每个节点只能运行一个pod这是它和deployment资源对象的最大也是唯一的区别。所以在其yaml文件中不支持定义replicas除此之外与Deployment、RS等资源对象的写法相同。
它的一般使用场景如下
在去做每个节点的日志收集工作监控每个节点的的运行状态
84、说说你对Job这种资源对象的了解
答Job与其他服务类容器不同Job是一种工作类容器一般用于做一次性任务。使用常见不多可以忽略这个问题。
#提高Job执行效率的方法
spec:parallelism: 2 #一次运行2个completions: 8 #最多运行8个template:
metadata:85、描述一下pod的生命周期有哪些状态
Pending表示pod已经被同意创建正在等待kube-scheduler选择合适的节点创建一般是在准备镜像Running表示pod中所有的容器已经被创建并且至少有一个容器正在运行或者是正在启动或者是正在重启Succeeded表示所有容器已经成功终止并且不会再启动Failed表示pod中所有容器都是非0不正常状态退出Unknown表示无法读取Pod状态通常是kube-controller-manager无法与Pod通信。
86、创建一个pod的流程是什么
客户端提交Pod的配置信息可以是yaml文件定义好的信息到kube-apiserverApiserver收到指令后通知给controller-manager创建一个资源对象Controller-manager通过api-server将pod的配置信息存储到ETCD数据中心中Kube-scheduler检测到pod信息会开始调度预选会先过滤掉不符合Pod资源配置要求的节点然后开始调度调优主要是挑选出更适合运行pod的节点然后将pod的资源配置单发送到node节点上的kubelet组件上。Kubelet根据scheduler发来的资源配置单运行pod运行成功后将pod的运行信息返回给schedulerscheduler将返回的pod运行状况的信息存储到etcd数据中心。
87、删除一个Pod会发生什么事情
答Kube-apiserver会接受到用户的删除指令默认有30秒时间等待优雅退出超过30秒会被标记为死亡状态此时Pod的状态Terminatingkubelet看到pod标记为Terminating就开始了关闭Pod的工作
关闭流程如下
pod从service的endpoint列表中被移除如果该pod定义了一个停止前的钩子其会在pod内部被调用停止钩子一般定义了如何优雅的结束进程进程被发送TERM信号kill -14当超过优雅退出的时间后Pod中的所有进程都会被发送SIGKILL信号kill -9。
88、K8s的Service是什么
答Pod每次重启或者重新部署其IP地址都会产生变化这使得pod间通信和pod与外部通信变得困难这时候就需要Service为pod提供一个固定的入口。
Service的Endpoint列表通常绑定了一组相同配置的pod通过负载均衡的方式把外界请求分配到多个pod上
89、k8s是怎么进行服务注册的
答Pod启动后会加载当前环境所有Service信息以便不同Pod根据Service名进行通信。
90、k8s集群外流量怎么访问Pod
答可以通过Service的NodePort方式访问会在所有节点监听同一个端口比如30000访问节点的流量会被重定向到对应的Service上面。
91、k8s数据持久化的方式有哪些
答
1EmptyDir空目录
没有指定要挂载宿主机上的某个目录直接由Pod内保部映射到宿主机上。类似于docker中的manager volume。
主要使用场景
只需要临时将数据保存在磁盘上比如在合并/排序算法中作为两个容器的共享存储使得第一个内容管理的容器可以将生成的数据存入其中同时由同一个webserver容器对外提供这些页面。
emptyDir的特性
同个pod里面的不同容器共享同一个持久化目录当pod节点删除时volume的数据也会被删除。如果仅仅是容器被销毁pod还在则不会影响volume中的数据。
总结来说emptyDir的数据持久化的生命周期和使用的pod一致。一般是作为临时存储使用。
2Hostpath
将宿主机上已存在的目录或文件挂载到容器内部。类似于docker中的bind mount挂载方式。
这种数据持久化方式运用场景不多因为它增加了pod与节点之间的耦合。
一般对于k8s集群本身的数据持久化和docker本身的数据持久化会使用这种方式可以自行参考apiService的yaml文件位于/etc/kubernetes/main…目录下。
3PersistentVolume简称PV
基于NFS服务的PV也可以基于GFS的PV。它的作用是统一数据持久化目录方便管理。
在一个PV的yaml文件中可以对其配置PV的大小指定PV的访问模式
ReadWriteOnce只能以读写的方式挂载到单个节点ReadOnlyMany能以只读的方式挂载到多个节点ReadWriteMany能以读写的方式挂载到多个节点。以及指定pv的回收策略recycle清除PV的数据然后自动回收Retain需要手动回收delete删除云存储资源云存储专用
PS这里的回收策略指的是在PV被删除后在这个PV下所存储的源文件是否删除。
若需使用PV那么还有一个重要的概念PVCPVC是向PV申请应用所需的容量大小K8s集群中可能会有多个PVPVC和PV若要关联其定义的访问模式必须一致。定义的storageClassName也必须一致若群集中存在相同的名字、访问模式都一致两个PV那么PVC会选择向它所需容量接近的PV去申请或者随机申请。
Mysql
Mysql性能优化
优化思路
开启慢查询日志查看哪些sql耗时长查看执行慢的sql的执行计划为优化提供方向优化查询sql怎么优化使用【show profils】查看问题sql的使用情况使用方法是啥调整操作系统参数优化怎么调整升级服务硬件什么条件下升级
慢查询日志
1、MySQL的慢查询日志功能默认是关闭的需要手动开启
show variables like %slow_query%
- 【slow_query_log】 是否开启慢查询日志1为开启0为关闭。
- 【slow-query-log-file】新版5.6及以上版本MySQL数据库慢查询日志存储路径。可以不设置
该参数系统则会默认给一个缺省的文件host_name-slow.log
show variables like long_query_time%
- 【long_query_time】 慢查询阈值当查询时间多于设定的阈值时记录日志【单位为秒】。2、临时开启慢查询功能
set global slow_query_log ON;
set global long_query_time 1;3、永久开启慢查询功能
#修改/etc/my.cnf配置文件重启 MySQL, 这种永久生效.
[mysqld]
slow_query_logON
long_query_time1第一行SQL查询执行的具体时间第二行执行SQL查询的连接信息用户和连接IP第三行记录了一些我们比较有用的信息
Query_time这条SQL执行的时间越长则越慢Lock_time在MySQL服务器阶段(不是在存储引擎阶段)等待表锁时间Rows_sent查询返回的行数Rows_examined查询检查的行数越长就当然越费时间
分析慢查询日志的工具
mysqldumpslow工具是MySQL自带的慢查询日志工具
mysqldumpslow -s t -t 10 -g left join /var/lib/mysql/localhost-slow.log常用参数说明
-s是表示按照何种方式排序
al 平均锁定时间ar 平均返回记录时间at 平均查询时间默认c 计数l 锁定时间r 返回记录t 查询时间
-t是top n的意思即为返回前面多少条的数据
-g后边可以写一个正则匹配模式大小写不敏感的
查看执行计划
create table tuser(id int primary key auto_increment,name varchar(100),age int,sex char(1),address varchar(100)
);
alter table tuser add index idx_name_age(name(100),age);
alter table tuser add index idx_sex(sex(1));
insert into tuser(id,name,age,sex,address) values (1,张三,20,1,北京);
insert into tuser(id,name,age,sex,address) values (2,李四,16,1,上海);
insert into tuser(id,name,age,sex,address) values (3,王五,34,1,杭州);
insert into tuser(id,name,age,sex,address) values (4,方六,26,2,广州);
insert into tuser(id,name,age,sex,address) values (5,季七,18,2,上海);explain select * from tuser where id 2id: SELECT 查询的标识符. 每个 SELECT 都会自动分配一个唯一的标识符.select_type: SELECT 查询的类型。普通查询、联合查询(union、union all)、子查询等复杂查询table: 查询的是哪个表partitions: 匹配的分区type: join 类型possible_keys: 此次查询中可能选用的索引key: 此次查询中确切使用到的索引.ref: 哪个字段或常数与 key 一起被使用rows: 显示此查询一共扫描了多少行. 这个是一个估计值.filtered: 表示此查询条件所过滤的数据的百分比extra: 额外的信息
select_type重要
1、simple
不需要union操作或者不包含子查询的简单select查询
2、primary
个需要union操作或者含有子查询的select
3、union
union连接的两个select查询第一个查询是dervied派生表除了第一个表外第二个以后的表select_type都是union
4、dependent union
出现在union 或union all语句中但是这个查询要受到外部查询的影响
5、union result
包含union的结果集在union和union all语句中,因为它不需要参与查询所以id字段为null
6、subquery
除了from字句中包含的子查询外其他地方出现的子查询都可能是subquery
7、dependent subquery
表示这个subquery的查询要受到外部表查询的影响
8、derived
from字句中出现的子查询也叫做派生表其他数据库中可能叫做内联视图或嵌套select
type重要
system表中只有一行数据或者是空表const使用唯一索引或者主键eq_ref唯一性索引扫描对于每个索引键表中只有一条记录与之匹配。ref非唯一性索引扫描返回匹配某个单独值的所有行本质上也是一种索引访问它返回所有匹配某个单独值的行然而它可能会找到多个符合条件的行所以他应该属于查找和扫描的混合体。fulltext全文索引检索要注意全文索引的优先级很高若全文索引和普通索引同时存在时mysql不管代价优先选择使用全文索引ref_or_null与ref方法类似只是增加了null值的比较。unique_subquery用于where中的in形式子查询子查询返回不重复值唯一值index_subquery用于in形式子查询使用到了辅助索引或者in常数列表子查询可能返回重复值可以使用索引将子查询去重。range索引范围扫描常见于使用,,is null,between ,in ,like等运算符的查询中。index_merge表示查询使用了两个以上的索引最后取交集或者并集常见and or的条件使用了不同的索引indexselect结果列中使用到了索引type会显示为index。ALL这个就是全表扫描数据文件然后再在server层进行过滤返回符合要求的记录。
extra重要
Using filesort说明mysql会对数据使用一个外部的索引排序而不是按照表内的索引顺序进行读取。Using temporaryMySQL在对查询结果排序时使用临时表。using index查询时不需要回表查询直接通过索引就可以获取查询的结果数据。使用到了覆盖索引using whereMysql将对storage engine提取的结果进行过滤过滤条件字段无索引Using join buffer使用了连接缓存,比如说在查询的时候多表join的次数非常多那么将配置文件中的缓冲区的joinbuffer调大一些。impossible wherewhere子句的值总是false 不能用来获取任何元组SELECT * FROM t_user WHERE id ‘1’ and id ‘2’
SQL语句优化
为搜索字段where中的条件、排序字段、select查询列创建合适的索引不过要考虑数据业务场景查询多还是增删多尽量建立组合索引并注意组合索引的创建顺序按照顺序组织查询条件、尽量将筛选粒度大的查询条件放到最左边。尽量使用覆盖索引SELECT语句中尽量不要使用*。索引长度尽量短短索引可以节省索引空间使查找的速度得到提升同时内存中也可以装载更多的索引键值。太长的列可以选择建立前缀索引。索引更新不能频繁更新非常频繁的数据不适宜建索引因为维护索引的成本。 order by、group by语句要尽量使用到索引order by的索引生效order by排序应该遵循最左前缀查询如果是使用多个索引字段进行排序那么排序的规则必须相同同是升序或者降序否则索引同样会失效。
LIMIT优化
如果预计SELECT语句的查询结果是一条最好使用 LIMIT 1可以停止全表扫描。处理分页会使用到LIMIT 当翻页到非常靠后的页面的时候偏移量会非常大这时LIMIT的效率会非常差。单表分页时使用自增主键排序之后先使用where条件 id offset值limit后面只写rows select * from (select * from tuser2 where id 1000000 and id 1000500 ORDER BY id) t limit 0, 20
小表驱动大表建议使用left join时以小表关联大表使用join的话第一张表是必须全扫描的以少关联多就可以减少这个扫描次数。避免全表扫描避免mysql放弃索引查询尽量不使用count(*)、尽量使用count主键JOIN两张表的关联字段最好都建立索引WHERE条件中尽量不要使用not in语句合理利用慢查询日志、explain执行计划查询、show profile查看SQL执行时的资源使用情况
profile分析语句
Query Profiler是MySQL自带的一种query诊断分析工具通过它可以分析出一条SQL语句的硬件性能瓶颈在什么地方
show variables like %profil%;profiling ON 表示开启
#开启profile功能
set profiling1; --1是开启、0是关闭show profile: 展示最近一条语句执行的详细资源占用信息,默认显示 Status和Duration两列 show profile 还可根据 show profiles 列表中的 Query_ID ,选择显示某条记录的性能分析信息
服务器层面优化
1、缓冲区优化
设置足够大的innodb_buffer_pool_size 将数据读取到内存中建议innodb_buffer_pool_size设置为总内存大小的3/4或者4/5
2、降低磁盘写入次数
生产环境很多日志是不需要开启的比如通用查询日志、慢查询日志、错误日志使用足够大的写入缓存 innodb_log_file_size0.25 * innodb_buffer_pool_size
3、MySQL数据库配置优化
innodb_buffer_pool_size #总内存大小的3/4或者4/5
innodb_flush_log_at_trx_commit1 #控制redo log刷新到磁盘的策略
sync_binlog1 #每提交1次事务同步写到磁盘中
innodb_max_dirty_pages_pct30 #脏页占innodb_buffer_pool_size的比例时触发刷脏页到磁盘。 推荐值为25%~50%。
innodb_io_capacity200 #后台进程最大IO性能指标。默认200如果SSD调整为5000~20000
innodb_data_file_path #指定innodb共享表空间文件的大小
ong_qurey_time0.3 #慢查询日志的阈值设置单位秒
binlog_formatrow #mysql复制的形式row为MySQL8.0的默认形式。
max_connections200 #调高该参数则应降低interactive_timeout、wait_timeout的值
innodb_log_file_size #过大实例恢复时间长过小造成日志切换频繁。
general_log0 #全量日志建议关闭默认关闭操作系统优化
内核参数优化
CentOS系统针对mysql的参数优化内核相关参数(/etc/sysctl.conf)以下参数可以直接放到sysctl.conf文件的末尾。
增加监听队列上限
net.core.somaxconn 65535
net.core.netdev_max_backlog 65535
net.ipv4.tcp_max_syn_backlog 65535加快TCP连接的回收
net.ipv4.tcp_fin_timeout 10
net.ipv4.tcp_tw_reuse 1
net.ipv4.tcp_tw_recycle 1TCP连接接收和发送缓冲区大小的默认值和最大值:
net.core.wmem_default 87380
net.core.wmem_max 16777216
net.core.rmem_default 87380
net.core.rmem_max 16777216减少失效连接所占用的TCP资源的数量加快资源回收的效率
net.ipv4.tcp_keepalive_time 120
net.ipv4.tcp_keepalive_intvl 30
net.ipv4.tcp_keepalive_probes 3单个共享内存段的最大值
kernel.shmmax 4294967295
#这个参数应该设置的足够大以便能在一个共享内存段下容纳整个的Innodb缓冲池的大小。
#这个值的大小对于64位linux系统可取的最大值为(物理内存值-1)byte建议值为大于物理
内存的一半一般取值大于Innodb缓冲池的大小即可。控制换出运行时内存的相对权重
vm.swappiness 0
#这个参数当内存不足时会对性能产生比较明显的影响
#设置为0表示Linux内核虚拟内存完全被占用才会要使用交换区增加资源限制
打开文件数的限制(/etc/security/limit.conf)
* soft nofile 65535
* hard nofile 65535*表示对所有用户有效
soft表示当前系统生效的设置soft不能大于hard
hard表明系统中所能设定的最大值
nofile表示所限制的资源是打开文件的最大数目
65535限制的数量磁盘调度策略选用deadline
查看调度策略的方法
cat /sys/block/devname/queue/scheduler
修改调度策略的方法
echo /sys/block/devname/queue/scheduler#该模式按进程创建多个队列各个进程发来的IO请求会被cfq以轮循方式处理对每个IO请求都是公平
#的。该策略适合离散读的应用。
cfq (完全公平队列策略Linux2.6.18之后内核的系统默认策略)#deadline包含读和写两个队列确保在一个截止时间内服务请求截止时间是可调整的而默认读
#期限短于写期限。这样就防止了写操作因为不能被读取而饿死的现象deadline对数据库类应用是最好的选择。
deadline (截止时间调度策略)#noop只实现一个简单的FIFO队列倾向饿死读而利于写因此noop对于闪存设备、RAM及嵌入式系统是最好的选择。
noop (电梯式调度策略)#本质上与deadline策略一样但在最后一次读操作之后要等待6ms才能继续进行对其它I/O请求进
#行调度。它会在每个6ms中插入新的I/O操作合并写入流用写入延时换取最大的写入吞吐量。
#anticipatory适合于写入较多的环境比如文件服务器。该策略对数据库环境表现很差。
anticipatory (预料I/O调度策略)服务器硬件优化
尽量选择高频率的内存提升网络带宽使用SSD高速磁盘提升CPU性能对于数据库并发比较高的场景CPU的数量比频率重要对于CPU密集型场景和频繁执行复杂SQL的场景CPU的频率越高越好
Prometheus
知识点总结
HTTP状态码
HTTP 状态码分类
HTTP 状态码由三个十进制数字组成第一个十进制数字定义了状态码的类型。响应分为五类信息响应(100–199)成功响应(200–299)重定向(300–399)客户端错误(400–499)和服务器错误 (500–599)
分类分类描述1**信息服务器收到请求需要请求者继续执行操作2**成功操作被成功接收并处理3**重定向需要进一步的操作以完成请求4**客户端错误请求包含语法错误或无法完成请求5**服务器错误服务器在处理请求的过程中发生了错误
HTTP状态码列表
状态码状态码英文名称中文描述100Continue继续。客户端应继续其请求101Switching Protocols切换协议。服务器根据客户端的请求切换协议。只能切换到更高级的协议例如切换到HTTP的新版本协议200OK请求成功。一般用于GET与POST请求201Created已创建。成功请求并创建了新的资源202Accepted已接受。已经接受请求但未处理完成203Non-Authoritative Information非授权信息。请求成功。但返回的meta信息不在原始的服务器而是一个副本204No Content无内容。服务器成功处理但未返回内容。在未更新网页的情况下可确保浏览器继续显示当前文档205Reset Content重置内容。服务器处理成功用户终端例如浏览器应重置文档视图。可通过此返回码清除浏览器的表单域206Partial Content部分内容。服务器成功处理了部分GET请求300Multiple Choices多种选择。请求的资源可包括多个位置相应可返回一个资源特征与地址的列表用于用户终端例如浏览器选择301Moved Permanently永久移动。请求的资源已被永久的移动到新URI返回信息会包括新的URI浏览器会自动定向到新URI。今后任何新的请求都应使用新的URI代替302Found临时移动。与301类似。但资源只是临时被移动。客户端应继续使用原有URI303See Other查看其它地址。与301类似。使用GET和POST请求查看304Not Modified未修改。所请求的资源未修改服务器返回此状态码时不会返回任何资源。客户端通常会缓存访问过的资源通过提供一个头信息指出客户端希望只返回在指定日期之后修改的资源305Use Proxy使用代理。所请求的资源必须通过代理访问306Unused已经被废弃的HTTP状态码307Temporary Redirect临时重定向。与302类似。使用GET请求重定向400Bad Request客户端请求的语法错误服务器无法理解401Unauthorized请求要求用户的身份认证402Payment Required保留将来使用403Forbidden服务器理解请求客户端的请求但是拒绝执行此请求404Not Found服务器无法根据客户端的请求找到资源网页。通过此代码网站设计人员可设置您所请求的资源无法找到的个性页面405Method Not Allowed客户端请求中的方法被禁止406Not Acceptable服务器无法根据客户端请求的内容特性完成请求407Proxy Authentication Required请求要求代理的身份认证与401类似但请求者应当使用代理进行授权408Request Time-out服务器等待客户端发送的请求时间过长超时409Conflict服务器完成客户端的 PUT 请求时可能返回此代码服务器处理请求时发生了冲突410Gone客户端请求的资源已经不存在。410不同于404如果资源以前有现在被永久删除了可使用410代码网站设计人员可通过301代码指定资源的新位置411Length Required服务器无法处理客户端发送的不带Content-Length的请求信息412Precondition Failed客户端请求信息的先决条件错误413Request Entity Too Large由于请求的实体过大服务器无法处理因此拒绝请求。为防止客户端的连续请求服务器可能会关闭连接。如果只是服务器暂时无法处理则会包含一个Retry-After的响应信息414Request-URI Too Large请求的URI过长URI通常为网址服务器无法处理415Unsupported Media Type服务器无法处理请求附带的媒体格式416Requested range not satisfiable客户端请求的范围无效417Expectation Failed服务器无法满足Expect的请求头信息500Internal Server Error服务器内部错误无法完成请求501Not Implemented服务器不支持请求的功能无法完成请求502Bad Gateway作为网关或者代理工作的服务器尝试执行请求时从远程服务器接收到了一个无效的响应503Service Unavailable由于超载或系统维护服务器暂时的无法处理客户端的请求。延时的长度可包含在服务器的Retry-After头信息中504Gateway Time-out充当网关或代理的服务器未及时从远端服务器获取请求505HTTP Version not supported服务器不支持请求的HTTP协议的版本无法完成处理
