- Linux基础
- 观察cpu、内存、进程使用情况。动态查看进程变化，监控linux的系统状况
- 查看指定进程id的top信息
- 查看指定进程id的所有线程的top信息
- 统计当前目录下文件的个数（不包括目录）
- 统计当前目录下文件的个数（包括子目录）
- 查看某目录下文件夹(目录)的个数（包括子目录）
- Docker基础
- 查看其父进程信息：
- 查看子进程信息：
- Dockerfile
- 安装vim编辑器
- 安装ifconfig命令查看网络IP
- 安装java8及lib库
- ADD是相对路径jar, 把jdk-8u171-linux-x64.tar.gz添加到容器中, 安装包必须要和Dockerfile文件在同一位置
- 配置java环境变量
- Pod详解
- Pod简介
- pod的原理
- pod的特点
- pod的重启策略
- pod的镜像拉取策略
- kubenetes针对pod资源对象的健康监测机制?（必须记住3重探测方式，重点，经常问）
- 就绪探针与存活探针的区别
- 存活探针的属性参数有哪几个
- pod的就绪探针有哪几种
- pod的就绪探针的属性参数有哪些
- pod的重启策略
- pod创建过程
- K8s创建一个pod的详细流程，涉及的组件怎么通信的？
- pod的终止过程
- pod的生命周期有哪几种？
- pod一致处于pending状态一般有哪些情况，怎么排查？（重点，持续更新）
- DaemonSet资源对象的特性
- 删除一个Pod会发生什么事情
- pod的共享资源
- pod的初始化容器是干什么的
- pod的资源请求、限制如何定义
- pod的定义中有个command和args参数，这两个参数不会和docker镜像的entrypointc冲突吗？
- pause容器作用是什么？
- 标签及标签选择器是什么，如何使用？
- Service详解
- Service是如何与pod关联的？
- Service的域名解析格式、pod的域名解析格式
- Service的类型有哪几种
- Pod到Service的通信？
- 一个应用pod是如何发现service的，或者说，pod里面的容器用于是如何连接service的？
- 如何创建一个service代理外部的服务，或者换句话来说，在K8s集群内的应用如何访问外部的服务，如数据库服务，缓存服务等?
- service、endpoint、kube-proxys三种的关系是什么
- 无头service和普通的service有什么区别，无头service使用场景是什么？
- deployment怎么扩容或缩容
- deployment的更新升级策略有哪些
- deployment的滚动更新策略有两个特别主要的参数，解释一下它们是什么意思？
- deployment更新的命令有哪些
- deployment的更新过程
- deployment的回滚使用什么命令
- 讲一下都有哪些存储卷，作用分别是什么
- pv的访问模式有哪几种
- pv的回收策略有哪几种
- 在pv的生命周期中，一般有几种状态
- pv存储空间不足怎么扩容?
- 存储类的资源回收策略:
- 怎么使一个node脱离集群调度，比如要停机维护单又不能影响业务应用
- K8s生产中遇到什么特别映像深刻的问题吗，问题排查解决思路是怎么样的？（重点）
- K8s生产中遇到什么特别映像深刻的问题吗，问题排查解决思路是怎么样的？（重点）
- kube-proxy原理
- flannel 和 ovs 网络的区别
- K8s集群外流量怎么访问Pod
- K8s 资源限制 QoS
- K8s数据持久化的方式有哪些
- K8s的基本组成部分
- K8s中镜像的下载策略是什么
- 标签与标签选择器的作用是什么
- K8s的负载均衡器
- kubelet 监控 Node 节点资源使用是通过什么组件来实现的
- Pod的状态
- deployment/rs的区别
- rc/rs实现原理
- kubernetes服务发现
- K8s发布（暴露）服务，servcie的类型有那些
- ETCD及其特点
- ETCD适应的场景
- Kubernetes RC的机制
- kube-proxy作用
- kube-proxy iptables原理
- kube-proxy ipvs原理
- kube-proxy ipvs和iptables的异同?
- Kubernetes中什么是静态Pod
- Kubernetes Pod的常见调度方式
- Kubernetes初始化容器（init container）
- Kubernetes deployment升级过程
- Kubernetes deployment升级策略
- Kubernetes DaemonSet类型的资源特性
- Kubernetes自动扩容机制
- Kubernetes Service分发后端的策略
- Kubernetes Headless Service
- Kubernetes外部如何访问集群内的服务
- Kubernetes ingress
- Kubernetes镜像的下载策略
- Kubernetes的负载均衡器
- Kubernetes各模块如何与API Server通信
- Kubernetes Scheduler作用及实现原理
- Kubernetes Scheduler使用哪两种算法将Pod绑定到worker节点
- Kubernetes kubelet的作用
- Kubernetes kubelet监控Worker节点资源是使用什么组件来实现的
- Kubernetes如何保证集群的安全性
- Kubernetes准入机制
- Kubernetes RBAC及其特点（优势）
- Kubernetes Secret作用
- Kubernetes Secret有哪些使用方式
- Kubernetes PodSecurityPolicy机制
- Kubernetes PodSecurityPolicy机制能实现哪些安全策略
- Kubernetes网络模型
- Kubernetes CNI模型
- Kubernetes网络策略
- Kubernetes网络策略原理
- Kubernetes中flannel的作用
- Kubernetes Calico网络组件实现原理
- Kubernetes共享存储的作用
- Kubernetes PV 和 PVC
- Kubernetes PV生命周期内的阶段
- Kubernetes CSI模型
- Kubernetes Worker节点加入集群的过程
- Kubernetes Pod如何实现对节点的资源控制?
- Kubernetes Requests和Limits如何影响Pod的调度
- Kubernetes Metric Service
- Kubernetes中，如何使用EFK实现日志的统一管理
- Kubernetes如何进行优雅的节点关机维护?
- Kubernetes集群联邦?
- Helm及其优势
- 标签与标签选择器的作用
- 什么是Google容器引擎?
- image的状态有那些？
- Service资源对象的作用
- 常用的标签分类有哪些?
- Job资源对象
- K8s是怎么进行服务注册的
- Kubernetes与Docker Swarm的区别如何
- 什么是Container Orchestration?
- 什么是Heapster
- K8s Architecture的不同组件有哪些
- Kubernetes中主节点的工作情况
- kube-apiserver和kube-scheduler的作用
- Kubernetes控制管理器
- Kubernetes有哪些不同类型的服务
- Kubernetes的负载均衡器
- 使用Kubernetes时可以采取哪些最佳安全措施?
- Pod详解
https://blog.csdn.net/crazymakercircle/article/details/128671196
Linux基础
常见命令
查看进程
查看指定进程id的top信息
[root@node4 data]# top-p 1228
查看指定进程id的所有线程的top信息
[root@node4 data]# top -H -p 1228
<br /><br />2. **ps -ef：用于查看全格式的全部进程**1. -e：参数代表显示所有进程2. -f：参数代表全格式3. **查看指定进程：ps -ef | grep pid **3. **ps -aux也是用于查看进程**1. -a：显示当前终端下的所有进程信息，包括其他用户的进程2. -u：使用以用户为主的格式输出进程信息3. -x：显示当前用户在所有终端下的进程4. ps -ef和ps aux，这两者的输出结果差别不大，但展示风格不同，COMMADN列如果过长，aux会截断显示，而ef不会5. 如果想查看进程的CPU占用率和内存占用率，可以使用aux，如果想查看进程的父进程ID和完整的COMMAND命令，可以使用ef<br /><br />**linux的进程有5种状态：**1. （R）运行状态（正在运行或在运行队列中等待[就绪队列]）2. （S）中断状态（休眠中，受阻，在等待某个条件的形成或接受到信号）3. （D）不可中断状态（收到信号不唤醒和不可运行, 进程必须等待直到有中断发生）4. （Z）僵死状态（进程已终止，但进程描述符存在，直到父进程调用wait4()系统调用后释放）5. （T）停止状态（进程收到SIGSTOP、SIGSTP、SIGTIN、SIGTOU信号后停止运行运行）<a name="ZGpwf"></a>### 查看文件大小```sql# 查看磁盘空间[root@node4 data]# df -h文件系统 容量 已用 可用 已用% 挂载点/dev/mapper/centos-root 47G 5.6G 42G 12% /devtmpfs 1.4G 0 1.4G 0% /devtmpfs 1.4G 0 1.4G 0% /dev/shmtmpfs 1.4G 9.5M 1.4G 1% /runtmpfs 1.4G 0 1.4G 0% /sys/fs/cgroup/dev/sda1 1014M 145M 870M 15% /boottmpfs 283M 0 283M 0% /run/user/0# 查看文件大小[root@node4 data]# ll总用量 32-rw-r--r--. 1 root root 166 11月 13 17:46 chaoge.txt-rw-r--r--. 1 root root 142 11月 13 12:38 luffycity1.txt-rw-r--r--. 1 root root 298 11月 13 17:24 luffycity.tx-rw-r--r--. 1 root root 152 11月 12 14:51 luffy.txt-rw-r--r--. 1 root root 1134 11月 12 14:35 pwd.txt-rw-r--r--. 1 root root 38 11月 12 18:56 test1.txt-rw-r--r--. 1 root root 31 11月 12 18:24 test.tx-rw-r--r--. 1 root root 52 11月 12 18:35 test.txt[root@node4 data]#[root@node4 data]# ls -lh pwd.txt-rw-r--r--. 1 root root 1.2K 11月 12 14:35 pwd.txt[root@node4 data]#[root@node4 data]# du -h pwd.txt4.0K pwd.txt[root@node4 data]# wc -c pwd.txt1134 pwd.txt
查找文件
- 打印当前文件夹文件 ls -al a所有文件 l详细信息
- 软链接 ln -s a target 硬链接 ln
- 修改权限 chmod
- 查看文件：
- 移动文件mv 也可以重命名
- 复制文件cp
- 删除文件 rm -r 递归删除 -f删除只读文件 通配符？单个字符，*多个字符，[a-z]字符集
- grep 正则搜索 显示行号-n 查询个数-c 反选-v
- 查看指定进程：ps -ef | grep pid
- 查看命令历史：history
- 查找文件：find [目录] 以名字查找-name “h*”以h开头
- 终止一个进程 kill -9 pid
- 如何防止新人误操作rm -rf
- 做好备份
- 建立回收站机制
- 使用safe-rm替代rm
- 24.156.192.2/24 一共有多少个主机号
- 找进程号为199的进程 ls -ef|grep 199
- 某文件中含关键词的行数 grep -c “key” ./file
- 常用Linux命令（特意问了find命令）
- 该目录下以.log结尾的文件中包含关键词a但不包含关键词b的行数 grep “a” ./file | grep -cv “b”
- grep命令
- Linux管道是什么？用法？
- 说下自己知道的命令；给了一个a.log文件，从里面找出以error开头的；查看某一个进程；查看某一个端口号
- Linux命令：chmod命令，改变文件所有者命令是什么（chown），重定向符，怎么把标准输出和错误分别重定向到两个文件
如何查看端口被占了（netstat/ps）
[root@node4 data]# netstat -anp | grep 4520tcp6 0 0 :::10086 :::* LISTEN 4520/javaunix 3 [ ] STREAM CONNECTED 24520 666/polkitdunix 2 [ ] STREAM CONNECTED 53864 4520/javaunix 2 [ ] STREAM CONNECTED 54067 4520/java[root@node4 data]#[root@node4 data]# ps -ef |grep 4520root 4520 1583 12 22:23 pts/0 00:00:19 java -jar tensquare_eureka_server-1.0-SNAPSHOT.jarroot 4784 4588 0 22:26 pts/1 00:00:00 grep --color=auto 4520
查找当前目录下有多少个文件 ```sql [root@node4 data]# ll 总用量 48 -rw-r—r—. 1 root root 166 11月 13 17:46 chaoge.txt drwxr-xr-x. 2 root root 19 11月 18 20:56 data1 -rw-r—r—. 1 root root 142 11月 13 12:38 luffycity1.txt -rw-r—r—. 1 root root 298 11月 13 17:24 luffycity.tx -rw-r—r—. 1 root root 152 11月 12 14:51 luffy.txt -rw-r—r—. 1 root root 1134 11月 12 14:35 pwd.txt -rw-r—r—. 1 root root 16371 11月 3 2014 safe-rm-0.12.tar.gz -rw-r—r—. 1 root root 38 11月 12 18:56 test1.txt -rw-r—r—. 1 root root 31 11月 12 18:24 test.tx -rw-r—r—. 1 root root 52 11月 12 18:35 test.txt [root@node4 data]# [root@node4 data]# cd data1/ [root@node4 data1]# ll 总用量 0 -rw-r—r—. 1 root root 0 11月 18 20:56 tset1
统计当前目录下文件的个数（不包括目录）
[root@node4 data]# ls -l | grep “^-“ | wc -l 9
统计当前目录下文件的个数（包括子目录）
[root@node4 data]# ls -lR| grep “^-“ | wc -l 10
查看某目录下文件夹(目录)的个数（包括子目录）
[root@node4 data]# ls -lR | grep “^d” | wc -l 1
25. Linux命令：查找统计某一目录下所有.txt文件中某一字符的个数26. Linux命令：查找并删除目录下的某一堆进程怎么做？27. kill后面的参数你了解吗？28. 关闭一个进程指令 kill -9/15 进程号29. 查看一个文档的后100行 tail -n 100 文件名30. 查找带有“txt”的名称，并根据找到的内容进一步查找 find "%txt%" | grep "%txtt"31. linux 添加alias命令，alias在哪里配的？32. 文件中多行文字进行去重，展示去重之后的内容```shell[root@node4 data]# cat chaoge.txtpyyu1 pyyu2 pyyu3 pyyu4 pyyu5pyyu6 pyyu7 pyyu8 pyyu9 pyyu10pyyu1 pyyu2 pyyu3 pyyu4 pyyu5pyyu21 pyyu22 pyyu23 pyyu5 pyyu25# 去重后顺序乱了[root@node4 data]# cat chaoge.txt | sort | uniqpyyu1 pyyu2 pyyu3 pyyu4 pyyu5pyyu21 pyyu22 pyyu23 pyyu5 pyyu25pyyu6 pyyu7 pyyu8 pyyu9 pyyu10[root@node4 data]# cat chaoge.txtpyyu1 pyyu2 pyyu3 pyyu4 pyyu5pyyu6 pyyu7 pyyu8 pyyu9 pyyu10pyyu1 pyyu2 pyyu3 pyyu4 pyyu5pyyu21 pyyu22 pyyu23 pyyu5 pyyu25[root@node4 data]# awk '!x[$0]++' chaoge.txtpyyu1 pyyu2 pyyu3 pyyu4 pyyu5pyyu6 pyyu7 pyyu8 pyyu9 pyyu10pyyu21 pyyu22 pyyu23 pyyu5 pyyu25
- 查询当前目录下包含error的日志
- Linux lnap lamp区别
- Apache和Nginx区别
- 怎么查看服务器上Nginx状态
- PS怎么查看Nginx
- error.log 文件，找到包含error的信息的命令 把这个语句说出来
- vim的全局替换
- linux远程复制
- 查看端口是否被占用：netstat -anp |grep 端口号
- 查看当前所有已经使用的端口情况：netstat -nultp（此处不用加端口号）
-
find命令
用于查找文件，它会去遍历实际硬盘进行查找，而且它允许我们对每个找到的文件进行后续操作，功能非常强大
基本格式：find <何处> <何物> <做什么> 「何处」：指定在哪个目录查找，此目录的所有子目录也会被查找。
- 「何物」：查找什么，可以根据文件的名字来查找，也可以根据其大小来查找，还可以根据其最近访问时间来查找。
- 「做什么」：找到文件后，可以进行后续处理，如果不指定这个参数， find命令只会显示找到的文件
根据文件名查找
find -name "file.txt" --> 当前目录以及子目录下通过名称查找文件find . -name "syslog" --> 当前目录以及子目录下通过名称查找文件find / -name "syslog" --> 整个硬盘下查找syslogfind /var/log -name "syslog" --> 在指定的目录/var/log下查找syslog文件find /var/log -name "syslog*" --> 查找syslog1、syslog2 ... 等文件，通配符表示所有find /var/log -name "*syslog*" --> 查找包含syslog的文件
根据文件大小查找
find /var -size +10M --> /var 目录下查找文件大小超过 10M 的文件find /var -size -50k --> /var 目录下查找文件大小小于 50k 的文件find /var -size +1G --> /var 目录下查找文件大小查过 1G 的文件find /var -size 1M --> /var 目录下查找文件大小等于 1M 的文件
根据文件最近访问时间查找
find -name "*.txt" -atime -7 --> 近7天内访问过的.txt结尾的文件
仅查找目录或文件
find . -name "file" -type f --> 只查找当前目录下的file文件find . -name "file" -type d --> 只查找当前目录下的file目录
操作查找结果
find -name "*.txt" -printf "%p - %u\n" --> 找出所有后缀为txt的文件，并按照 %p - %u\n 格式打印，其中%p=文件名，%u=文件所有者find -name "*.jpg" -delete --> 删除当前目录以及子目录下所有.jpg为后缀的文件，不会有删除提示，因此要慎用find -name "*.c" -exec chmod 600 {} \; --> 对每个.c结尾的文件，都进行 -exec 参数指定的操作，{} 会被查找到的文件替代，\; 是必须的结尾find -name "*.c" -ok chmod 600 {} \; --> 和上面的功能一直，会多一个确认提示
Vim编辑器
跳转到指定行
Vim 编辑的文件中，每一行都有一个行号，行号从1开始，逐一递增。
行号默认是不显示，如果需要它显示的话，可以进入命令模式，然后输入set nu ，如果要隐藏行号的话，使用 set nonu
- 跳转到指定行： 数字+gg ，例如 7gg ，表示跳转到第7行。
- 要跳转到最后一行，按下 G 。
- 要跳转到第一行，按下 gg 。
查找
处于交互模式下，按下 / 键，那么就进入查找模式，输入你要查找的字符串，然后按下回车。光标就会跳转到文件中下一个查找到的匹配处。如果字符串不存在，那么会显示 “pattern not found” 。
- n 跳转到下一个匹配项；
- N 跳转到上一个匹配项。
查找并替换
# 语法:s/旧字符串/新字符串# 实例:s/one/two
# 语法:s/旧字符串/新字符串/g
# 语法:n,m s/旧字符串/新字符串/g# 实例:2,4 s/one/two/g
# 语法:%s/旧字符串/新字符串/g
文件和目录
Linux权限管理
Docker基础
Docker基础
Docker简介
- Docker是一个开源的应用容器引擎，基于 Go 语言并遵从 Apache2.0 协议开源。
- Docker可以让开发者打包他们的应用以及依赖包到一个轻量级、可移植的容器中，然后发布到任何流行的Linux 机器上，也可以实现虚拟化。
- 容器是完全使用沙箱机制，相互之间不会有任何接口，更重要的是容器性能开销极低。
- Docker的应用场景：
- Web应用的自动化打包和发布
- 自动化测试和持续集成、发布
- 在服务型环境中部署和调整数据库或其他的后台应用
- 从头编译或者扩展现有的 OpenShift 或 Cloud Foundry 平台来搭建自己的 PaaS 环境
- Docker的作用
- 面向产品：产品交付
- 面向开发：简化环境配置
- 面向测试：多版本测试
- 面向运维：环境一致性
- 面向架构：自动化扩容（微服务）
- Docker是一个快速交付应用、运行应用的技术
- Docker可以将程序及其依赖、运行环境一起打包为一个镜像，可以迁移到任意Linux操作系统
- 运行时利用沙箱机制形成隔离容器，各个应用互不干扰
-
Docker架构
Docker包括三个基本概念:
Docker镜像（Image）：它是用于创建 Docker容器的模板，就相当于是一个root文件系统。
- 比如官方镜像ubuntu:16.04就包含了完整的一套Ubuntu16.04最小系统的root文件系统
- 镜像是一种轻量级、可执行的独立软件包，它包含运行某个软件所需的所有内容，我们把应用程序和配置依赖打包好形成一个可交付的运行环境（包括代码、运行时需要的库、环境变量和配置文件等），这个打包好的运行环境就是image镜像文件。
- Docker容器（Container）：它是独立运行的一个或一组应用，是镜像运行时的实体。
- 容器是基于镜像创建的，是镜像运行起来之后的一个实例，容器才是真正运行业务程序的地方。如果把镜像比作程序里面的类，那么容器就是对象。
- 镜像和容器的关系：就像是面向对象程序设计中的类和实例一样，镜像是静态的定义，容器是镜像运行时的实体。容器可以被创建、启动、停止、删除、暂停等
- Docker使用客户端-服务器 (C/S) 架构模式，使用远程API来管理和创建Docker容器
- Docker容器通过Docker镜像来创建。
- Docker仓库（Repository）：仓库可看成一个代码控制中心，用来保存镜像
- Docker Hub(https://hub.docker.com)) 提供了庞大的镜像集合供使用。一个 Docker Registry 中可以包含多个仓库（Repository）；每个仓库可以包含多个标签（Tag）；每个标签对应一个镜像。通常，一个仓库会包含同一个软件不同版本的镜像，而标签就常用于对应该软件的各个版本。我们可以通过 <仓库名>:<标签> 的格式来指定具体是这个软件哪个版本的镜像。如果不给出标签，将以 latest 作为默认标签
- 存放镜像的地方，研发工程师打包好镜像之后需要把镜像上传到镜像仓库中去，然后就可以运行有仓库权限的人拉取镜像来运行容器了。
- Docker客户端：它通过命令行或者其他工具使用 Docker SDK (https://docs.docker.com/develop/sdk/)) 与 Docker 的守护进程通信
- Docker主机（Host）：一个物理或者虚拟的机器用于执行Docker守护进程和容器
Docker-Compose项目是Docker官方的开源项目，负责实现对Docker容器集群的快速编排。Docker-Compose 项目由 Python 编写，调用 Docker 服务提供的API来对容器进行管理。因此，只要所操作的平台支持 Docker API，就可以在其上利用Compose 来进行编排管理
Docker基础命令
Docker查看守护进程：systemctl status docker
- Docker启动：systemctl start docker
- Docker设置开机自启：systemctl enable docker.service
- Docker重新启动：systemctl restart docker
- Docker镜像查看：docker image ls
- Docker容器查看：docker ps
- Docker Registry配置和查看：cat /etc/docker/daemon.json ```java cat>/etc/docker/daemon.json<<EOF
{
“registry-mirrors”:[“http://10.24.2.30:5000","https://tnxkcso1.mirrors.aliyuncs.com“],
“insecure-registries”:[“10.24.2.30:5000”]
}
EOF
<a name="buJW9"></a>### Docker的工作原理1. docker使用了常见的CS架构，也就是client-server模式，docker client负责处理用户输入的各种命令，比如docker build、docker run，真正工作的其实是server，也就是docker demon，值得注意的是，docker client和docker demon可以运行在同一台机器上。2. Docker是一个Client-Server结构的系统，Docker守护进程运行在主机上， 然后通过Socket连接从客户端访问，守护进程从客户端接受命令并管理运行在主机上的容器。守护进程和客户端可以运行在同一台机器上。3. docker是一个Client-Server结构的系统，docker守护进程运行在宿主机上，4. 守护进程从客户端接受命令并管理运行在主机上的容器，容器是一个运行时环境，这就是我们说的集装箱。<a name="UFzXE"></a>### Docker的组成部分一个完整的docker有以下几个部分组成：1. docker client：客户端，为用户提供一系列可执行命令，用户用这些命令实现跟docker daemon交互2. docker daemon：守护进程，一般在宿主主机后台运行，等待接收来自客户端的请求消息；3. docker image：镜像，镜像run之后就生成为docker容器4. docker container：容器，一个系统级别的服务，拥有自己的ip和系统目录结构；运行容器前需要本地存在对应的镜像，如果本地不存在该镜像则就去镜像仓库下载。5. docker使用客户端-服务器 (C/S) 架构模式，使用远程api来管理和创建docker容器。docker容器通过 docker镜像来创建。容器与镜像的关系类似于面向对象编程中的对象与类。<a name="ZXctY"></a>### Docker HubDocker hub是一个基于云的注册表服务，允许您链接到代码存储库，构建镜像并测试它们，存储手动推送的镜像以及指向Docker云的链接，以便您可以将镜像部署到主机。它为整个开发流程中的容器镜像发现，分发和变更管理，用户和团队协作以及工作流自动化提供了集中资源。<a name="HxMYR"></a>### Docker的安全性Docker利用了Linux内核中很多安全特性来保证不同容器之间的隔离，并且通过签名机制来对镜像进行验证。大量生产环境的部署证明，Docker虽然隔离性无法与虚拟机相比，但仍然具有极高的安全性。<a name="qrc3R"></a>### Docker如何解决不同系统环境的问题1. Docker将用户程序与所需要调用的系统（比如Ubuntu）函数库一起打包2. Docker运行到不同操作系统时，直接基于打包的库函数，借助于操作系统的Linux内核来进行3. Docker允许开发中将应用、依赖、函数库、配置一起打包，形成可移植镜像4. Docker应用运行在容器中，使用沙箱机制，相互隔离5. Docker镜像中包含完整运行环境，包含系统函数库，仅依赖系统的Linux内核，因此可以在任意Linux操作系统上运行<a name="xx4Mj"></a>## Docker 与 虚拟机区别Docker不是虚拟化方法。它依赖于实际实现基于容器的虚拟化或操作系统级虚拟化的其他工具。为此，Docker最初使用 LXC 驱动程序，然后移动到libcontainer 现在重命名为 runc。<br />Docker主要专注于在应用程序容器内自动部署应用程序。应用程序容器旨在打包和运行单个服务，而系统容器则设计为运行多个进程，如虚拟机。因此，Docker 被视为容器化系统上的容器管理或应用程序部署工具。1. 容器不需要引导操作系统内核，因此可以在不到一秒的时间内创建容器。此功能使基于容器的虚拟化比其他虚拟化方法更加独特和可取。2. 由于基于容器的虚拟化为主机增加了很少或没有开销，因此基于容器的虚拟化具有接近本机的性能。3. 对于基于容器的虚拟化，与其他虚拟化不同，不需要其他软件。4. 主机上的所有容器共享主机的调度程序，从而节省了额外资源的需求。5. 与虚拟机映像相比，容器状态（Docker 或 LXC 映像）的大小很小，因此容器映像很容易分发。6. 容器中的资源管理是通过 cgroup 实现的。Cgroups 不允许容器消耗比分配给它们更多的资源。虽然主机的所有资源都在虚拟机中可见，但无法使用。这可以通过在容器和主机上同时运行 top 或 htop 来实现。所有环境的输出看起来都很相似。<br /><br />1. Docker是一个系统进程，直接与操作系统内核交互；虚拟机是在操作系统中的操作系统2. Docker体积小，启动速度快、性能号；虚拟机体积大、启动速度慢、性能一般3. Docker在不同Linux系统下运行的原理：Docker会将目标应用及其所需要的依赖、函数库、操作系统函数库一起打包，当运行目标应用时，可以直接调用本地函数库，而后直接与本地操作系统内核进行交互，不再关心操作系统类型，从而可以跨系统运行4. 虚拟机是在操作系统中模拟硬件设备，然后运行另一个操作系统，比如在Windows系统里面运行CentOS系统，这样就可以在CentOS系统之上安装依赖、函数库、应用。从而可以实现跨系统的应用部署。运行应用时，会在真实的CentOS系统中运行，会直接调用CentOS系统，然后经过Hypervisor调用外部操作系统，然后调用计算机硬件5. Ubuntu和CentOS都是基于Linux内核，只是系统应用不同，提供的函数有所差异<a name="i9SVE"></a>## Docker与传统虚拟机的区别1. 传统虚拟机是需要**安装整个操作系统**的，然后再在上面安装业务应用，启动应用，通常需要**几分钟去启动应用**，而Docker是直接使用镜像来运行业务容器的，其**容器启动属于秒级别**；2. Docker**需要的资源更少**，Docker在操作系统级别进行虚拟化，Docker容器和内核交互，几乎没有性能损耗，而虚拟机运行着整个操作系统，占用物理机的资源就比较多；3. **Docker更轻量**，Docker的架构可以共用一个内核与共享应用程序库，所占内存极小;同样的硬件环境，Docker运行的镜像数远多于虚拟机数量，对系统的利用率非常高；4. 与虚拟机相比，**Docker隔离性更弱**，**Docker属于进程之间的隔离**，虚拟机可实现系统级别隔离；5. **Docker的安全性也更弱**，Docker的租户root和宿主机root相同，一旦容器内的用户从普通用户权限提升为root权限，它就直接具备了宿主机的root权限，进而可进行无限制的操作。虚拟机租户root权限和宿主机的root虚拟机权限是分离的，并且虚拟机利用如Intel的VT-d和VT-x的ring-1硬件隔离技术，这种技术可以防止虚拟机突破和彼此交互，而容器至今还没有任何形式的硬件隔离；6. Docker的**集中化管理工具还不算成熟**，各种虚拟化技术都有成熟的管理工具，比如：VMware、vCenter提供完备的虚拟机管理能力；7. Docker对业务的**高可用支持是通过快速重新部署实现的**，虚拟化具备负载均衡，高可用、容错、迁移和数据保护等经过生产实践检验的成熟保障机制，Vmware可承诺虚拟机99.999%高可用，保证业务连续性；8. 虚拟化创建是分钟级别的，Docker容器创建是秒级别的，Docker的快速迭代性，决定了无论是开发、测试、部署都可以节省大量时间；9. 虚拟机可以通过镜像实现环境交付的一致性，但镜像分发无法体系化，Docker在Dockerfile中记录了容器构建过程，可在集群中实现快速分发和快速部署。<a name="XICdW"></a>## Docker与LXC (Linux Container)的区别LXC利用Linux上相关技术实现了容器支持； Docker早期版本中使用了LXC技术，后期演化为新的 libcontainer, 在如下的几个方面进行了改进：1. 移植性： 通过抽象容器配置， 容器可以实现从一个平台移植到另一个平台；2. 镜像系统： 基于AUFS的镜像系统为容器的分发带来了很多的便利， 同时共同的镜像层只需要存储一份，实现高效率的存储；3. 版本管理： 类似于Git的版本管理理念， 用户可以更方便地创建、 管理镜像文件；4. 仓库系统： 仓库系统大大降低了镜像的分发和管理的成本；5. 周边工具： 各种现有工具（配置管理、 云平台）对Docker的支持， 以及基于Docker 的PaaS、CI等系统， 让Docker的应用更加方便和多样化。<a name="GSBqG"></a>## Docker镜像1. Docker将应用程序及其所需的依赖、函数库、环境、配置等文件打包在一起，称为镜像2. Docker镜像是Docker容器的源代码，Docker镜像用于创建容器。使用build命令创建镜像。3. Docker镜像其实本质就是一个压缩包，我们可以使用命令将一个Docker镜像中的文件导出，你可以看到这个镜像中的目录结构与 Linux 操作系统的根目录中的内容并没有太多的区别，可以说 Docker 镜像就是一个文件。<a name="TZMPl"></a>### Docker镜像基本命令1. 基于当前容器创建一个新的镜像：docker commit [OPTIONS] 容器ID```java公式：docker commit -m="提交的描述信息" -a="作者" 容器ID 要创建的目标镜像名:[标签名]命令：在容器外执行，记得docker commit -m="ifconfig cmd add" -a="zzyy" a69d7c825c4f zzyyubuntu:1.2
- 将本地镜像推送到阿里云远程仓库 ```java docker login —username=zzyybuy registry.cn-hangzhou.aliyuncs.com
docker tag cea1bb40441c registry.cn-hangzhou.aliyuncs.com/atguiguwh/myubuntu:1.1
docker push registry.cn-hangzhou.aliyuncs.com/atguiguwh/myubuntu:1.1
3. 列出本地主机上的镜像：docker images4. 查找镜像：docker search 镜像名称5. 下载镜像：docker pull 镜像名称6. 删除镜像：docker rmi 镜像ID<a name="totLu"></a>### 保存镜像```javadocker save 镜像id -o /home/mysql.tardocker save 镜像id > /home/mysql.tardocker save docker.io/rancher/rancher-agent -o /home/rancher-agent .tardocker save f29ece87a195 -o /home/rancher-agent.tardocker save docker.io/rancher/rke-tools -o /home/rke-tools-v0.1.52.tar
镜像的分层结构以及分层结构的好处
- 一个新的镜像是从 base镜像 一层一层叠加生成的。
- 每安装一个软件，dockerfile中使用RUM命令，就会在现有镜像的基础上增加一层，这样一层一层的叠加最后构成整个镜像。所以我们docker pull拉取一个镜像的时候会看到docker是一层层拉去的。
分层机构最大的一个好处就是：共享资源。
镜像中的应用程序运行后形成的进程就是容器，只是Docker会给容器做隔离，对外不可见
Docker容器包括应用程序及其所有依赖项，作为操作系统的独立进程运行。
Docker容器基本命令
创建容器：docker run -it 镜像名 /bin/bash
# 创建名为"centos6"的容器，并在容器内部和宿主机中查看容器中的进程信息[root@VM-4-17-centos ~]# docker run -itd -p 80:80 -p 6022:22 docker.io/lemonbar/centos6-ssh:latestUnable to find image 'lemonbar/centos6-ssh:latest' locallylatest: Pulling from lemonbar/centos6-ssha3ed95caeb02: Pull completef79eb1f22352: Pull complete67c1aaa530c8: Pull complete80447774eee7: Pull complete6d67b3a80e5a: Pull completef1819e4b2f8f: Pull complete09712b5b9acc: Pull complete8bc987c5494f: Pull completec42b021d0ff2: Pull completeDigest: sha256:093c2165b3c6fe05d5658343456f9b59bb7ecc690a7d3a112641c86083227dd1Status: Downloaded newer image for lemonbar/centos6-ssh:latesta4f1c9b8abcda78c8764cc285183dfa56cd1aa4ce6d111d4d9e77f3a57f3d5fc
查看运行中的容器：docker ps
- 查看全部容器：docker ps -a
- 启动已停止运行的容器：docker start 容器ID或者容器名
- 重启容器：docker restart 容器ID或者容器名
- 停止容器：docker stop 容器ID或者容器名
- 强制停止容器：docker kill 容器ID或容器名
- 删除已停止的容器：docker rm 容器ID
- 进入docker容器：docker exec -it 容器id /bin/bash
- 退出容器：
- exit：run进去容器，exit退出，容器停止
- ctrl+p+q：run进去容器，ctrl+p+q退出，容器不停止
- 查看容器日志：docker logs 容器ID
- 查看容器内运行的进程：docker top 容器ID
- 查看容器内部细节：docker inspect 容器ID
- 从容器内拷贝文件到主机上：docker cp 容器ID:容器内路径 目的主机路径
查找容器名称的命令：
[root@VM-4-17-centos ~]# docker ps --format "{{.Names}}"determined_curieredisnginx_slavenginx_masternginx_emptyloving_agnesipxc_proxypxc03pxc02pxc01affectionate_austinnostalgic_blackwell
在容器内部查看容器中的进程信息：
[root@VM-4-17-centos ~]# docker exec -it determined_curie ps -efUID PID PPID C STIME TTY TIME CMDroot 1 0 0 08:14 pts/0 00:00:00 /usr/sbin/sshd -Droot 5 0 0 08:16 pts/1 00:00:00 ps -ef
从宿主机操作系统中看到容器的进程信息： ```java [root@VM-4-17-centos ~]# docker top determined_curie UID PID PPID C STIME TTY TIME CMD root 27880 27866 0 16:14 pts/0 00:00:00 /usr/sbin/sshd -D [root@VM-4-17-centos ~]#
查看其父进程信息：
[root@VM-4-17-centos ~]# ps aux | grep 4948 root 17205 1414 0 16:37 pts/0 00:00:00 grep —color=auto 27866 root 27866 5587 0 16:14 ? 00:00:00 docker-containerd-shim -namespace moby -workdir /var/lib/docker/containerd/daemon/io.containerd.runtime.v1.linux/moby/a4f1c9b8abcda78c8764cc285183dfa56cd1aa4ce6d111d4d9e77f3a57f3d5fc -address /var/run/docker/containerd/docker-containerd.sock -containerd-binary /usr/bin/docker-containerd -runtime-root /var/run/docker/runtime-runc root 27880 27866 0 16:14 pts/0 00:00:00 /usr/sbin/sshd -D
查看子进程信息：
[root@VM-4-17-centos ~]# ps aux | grep 27880 root 17777 0.0 0.0 115928 1008 pts/0 S+ 16:38 0:00 grep —color=auto 27880 root 27880 0.0 0.0 66664 3072 pts/0 Ss+ 16:14 0:00 /usr/sbin/sshd -D
<a name="PJZNU"></a>### Docker容器的几种状态四种状态：运行、已暂停、重新启动、已退出<a name="hgp6w"></a>### Docker容器内部机制每个容器都在自己的命名空间中运行，但使用与所有其他容器完全相同的内核。发生隔离是因为内核知道分配给进程的命名空间，并且在API调用期间确保进程只能访问其自己的命名空间中的资源。<a name="nR8Eq"></a>### 进入Docker容器的两种方法1. 进入容器有两种方法：docker attach、docker exec；2. dattach是直接进入容器启动命令的终端，不会启动新的进程；3. exec则是在容器里面打开新的终端，会**启动新的进程**；一般建议已经exec进入容器```java[root@3274412d88ca /]# docker run -d centos /bin/bash -c "while true;do sleep 2;echo I_am_a_container;done"3274412d88ca4f1d1292f6d28d46f39c14c733da5a4085c11c6a854d30d1cde0# attach进入容器[root@3274412d88ca /]# docker attach 3274412d88ca4fCtrl + c 退出，Ctrl + c会直接关闭容器终端，这样容器没有进程一直在前台运行就会死掉了Ctrl + pq 退出（不会关闭容器终端停止容器，仅退出）# exec进入容器[root@3274412d88ca /]# docker exec -it 3274412d88ca /bin/bash# 进入到容器了开启了一个bash进程[root@3274412d88ca /]# ps -efUID PID PPID C STIME TTY TIME CMDroot 1 0 0 05:31 ? 00:00:01 /bin/bash -c while true;do sleep 2;echo I_am_a_container;doneroot 306 0 1 05:41 pts/0 00:00:00 /bin/bashroot 322 1 0 05:41 ? 00:00:00 /usr/bin/coreutils --coreutils-prog-shebang=sleep /usr/bin/sleep 2root 323 306 0 05:41 pts/0 00:00:00 ps -ef# 退出容器，仅退出我们自己的bash窗口[root@3274412d88ca /]# exit
Docker容器之间如何隔离
- Linux中的PID、IPC、网络等资源是全局的，而NameSpace机制是一种资源隔离方案，在该机制下这些资源就不再是全局的了，而是属于某个特定的NameSpace，各个NameSpace下的资源互不干扰。
- 虽然有了NameSpace技术可以实现资源隔离，但进程还是可以不受控的访问系统资源，比如CPU、内存、磁盘、网络等，为了控制容器中进程对资源的访问，Docker采用control groups技术（也就是cgroup），有了cgroup就可以控制容器中进程对系统资源的消耗了，比如你可以限制某个容器使用内存的上限、可以在哪些CPU上运行等等。
-
容器的copy-on-write特性，修改容器里面的内容不会修改镜像
镜像是分层的，镜像的每一层都可以被共享，同时，镜像是只读的。
- 当一个容器启动时，一个新的可写层被加载到镜像的顶部，这一层通常被称作“容器层”，“容器层”之下的都叫“镜像层”。
- 实际上，docker hub中99%的镜像都是通过在base镜像中安装和配置需要的软件构建出来的。新的镜像是从base镜像一层一层叠加生成的，每安装一个软件，就在现有的基础增加一层
- 为什么docker镜像要采用这种分层结构呢？
- 最大的一个好处是：共享资源
- 比如：有多个镜像都从相同的base镜像构建而来，那么docker host只需在磁盘上保存一份base镜像: 同时内存中也只需加载一份base镜像，就可以为所有容器服务了，而其镜像的每一层都可以被共享
- 问题是：如果多个容器共享一份基础镜像，当某个容器修改了基础镜像的内容，比如/etc下的文件，这时其他容器的/etc是否也会被修改？？？ 答案是不会
修改会被限制在单个容器内, 这就是 容器copy-on-write特性
- 所有对容器的改动：无论添加、删除、还是修改文件，都只会发生在容器层中，因为只有容器层是可写的，容器层下面的所有镜像层都是只读的。
- 镜像层数量可能会很多，所有镜像层会联合在一起组成一个统一的文件系统。
- 如果不同层中有一个相同路径的文件，比如 /a，上层的 /a 会覆盖下层的 /a，也就是说用户只能访问到上层中的文件 /a。
- 在容器层中，用户看到的是一个叠加之后的文件系统。
- 添加文件：在容器中创建文件时，新文件被添加到容器层中。
- 读取文件：在容器中读取某个文件时，Docker会从上往下依次在各镜像层中查找此文件。一旦找到，立即将其复制到容器层，然后打开并读入内存。
- 修改文件：在容器中修改已存在的文件时，Docker会从上往下依次在各镜像层中查找此文件。一旦找到，立即将其复制到容器层，然后修改之。
- 删除文件：在容器中删除文件时，Docker也是从上往下依次在镜像层中查找此文件。找到后，会在容器层中记录下此删除操作。
只有当需要修改时才复制一份数据，这种特性被称作Copy-on-Write。可见，容器层保存的是镜像变化的部分，不会对镜像本身进行任何修改。
Dockerfile
Dockerfile简介
从应用软件的角度来看，Dockerfile、Docker镜像与Docker容器分别代表软件的三个不同阶段，
Dockerfile是软件的原材料
- Docker镜像是软件的交付品
- Docker容器则可以认为是软件镜像的运行态，也即依照镜像运行的容器实例
- Dockerfile面向开发，Docker镜像成为交付标准，Docker容器则涉及部署与运维，三者缺一不可，合力充当Docker体系的基石。
- Dockerfile，需要定义一个Dockerfile，Dockerfile定义了进程需要的一切东西。Dockerfile涉及的内容包括执行代码或者是文件、环境变量、依赖包、运行时环境、动态链接库、操作系统的发行版、服务进程和内核进程(当应用进程需要和系统服务和内核进程打交道，这时需要考虑如何设计namespace的权限控制)等等
- Docker镜像，在用Dockerfile定义一个文件之后，docker build时会产生一个Docker镜像，当运行 Docker镜像时会真正开始提供服务
-
基本的Docker使用流程
一切都从Dockerfile开始。Dockerfile是镜像的源代码。
- 创建Dockerfile后，可以构建它以创建容器的镜像。镜像只是“源代码”的“编译版本”，即Dockerfile。
- 获得容器的镜像后，应使用注册表重新分发容器。注册表就像一个git存储库 - 你可以推送和拉取镜像。
接下来，您可以使用该镜像来运行容器。在许多方面，正在运行的容器与虚拟机（但没有管理程序）非常相似。
Dockerfile执行的大致流程
docker从基础镜像运行一个容器
- 执行一条指令并对容器作出修改
- 执行类似docker commit的操作提交一个新的镜像层
- docker再基于刚提交的镜像运行一个新容器
执行dockerfile中的下一条指令直到所有指令都执行完成
Dockerfile构建镜像的过程
首先，创建一个目录用于存放应用程序以及构建过程中使用到的各个文件等
- 然后，在这个目录下创建一个Dockerfile文件，一般建议Dockerfile的文件名就是Dockerfile
- 编写Dockerfile文件，编写指令：
- 使用FORM指令指定基础镜像
- COPY指令复制文件
- RUN指令指定要运行的命令
- ENV设置环境变量
- EXPOSE指定容器要暴露的端口
- WORKDIR设置当前工作目录
- CMD容器启动时运行命令，等等指令构建镜像；
- Dockerfile编写完成就可以构建镜像了，使用docker build -t 镜像名:tag . 命令来构建镜像，最后一个点是表示当前目录，docker会默认寻找当前目录下的Dockerfile文件来构建镜像，如果不使用默认，可以使用 -f 参数来指定dockerfile文件，如：docker build -t 镜像名:tag -f /xx/xxx/Dockerfile
使用docker build命令构建之后，docker就会将当前目录下所有的文件发送给docker daemon，顺序执行Dockerfile文件里的指令，在这过程中会生成临时容器，在临时容器里面安装RUN指定的命令，安装成功后，docker底层会使用类似于docker commit命令来将容器保存为镜像，然后删除临时容器，以此类推，一层层的构建镜像，运行临时容器安装软件，直到最后的镜像构建成功。
Dockerfile构建镜像出现异常的排查思路
首先，Dockerfile是一层一层的构建镜像，期间会产生一个或多个临时容器，构建过程中其实就是在临时容器里面安装应用，如果因为临时容器安装应用出现异常导致镜像构建失败，这时容器虽然被清理掉了，但是期间构建的中间镜像还在，那么我们可以根据异常时上一层已经构建好的临时镜像，将临时镜像运行为容器，然后在容器里面运行安装命令来定位具体的异常。
Dockerfile的基本指令
FROM：指定基础镜像（必须为第一个指令，因为需要指定使用哪个基础镜像来构建镜像）
- MAINTAINER：设置镜像作者相关信息，如作者名字，日期，邮件，联系方式等
- COPY：复制文件到镜像
- ADD：复制文件到镜像
- ENV：设置环境变量；
- EXPOSE：暴露容器进程的端口，仅仅是提示别人容器使用的哪个端口，没有过多作用；
- VOLUME：数据卷持久化，挂载一个目录，用于数据保存和持久化工作
- WORKDIR：设置工作目录，如果目录不在，则会自动创建目录；
- RUN：在容器中运行命令，RUN指令会创建新的镜像层，RUN指令经常被用于安装软件包；
- CMD：指定容器启动后默认运行哪些命令，如果有多个CMD，则只有最后一个生效，另外，CMD指令可以被docker run之后的参数替换；
- ENTRYOINT：指定容器启动时运行哪些命令，如果有多个ENTRYOINT，则只有最后一个生效，另外，如果Dockerfile中同时存在CMD和ENTRYOINT，那么CMD或docker run之后的参数将被当做参数传递给ENTRYOINT
Dockerfile文件示例
```java FROM centos MAINTAINER zzyyzzyybs@126.com
ENV MYPATH /usr/local WORKDIR $MYPATH
安装vim编辑器
RUN yum -y install vim
安装ifconfig命令查看网络IP
RUN yum -y install net-tools
安装java8及lib库
RUN yum -y install glibc.i686
RUN mkdir /usr/local/java
ADD是相对路径jar, 把jdk-8u171-linux-x64.tar.gz添加到容器中, 安装包必须要和Dockerfile文件在同一位置
ADD jdk-8u171-linux-x64.tar.gz /usr/local/java/
配置java环境变量
ENV JAVA_HOME /usr/local/java/jdk1.8.0_171 ENV JRE_HOME $JAVA_HOME/jre ENV CLASSPATH $JAVA_HOME/lib/dt.jar:$JAVA_HOME/lib/tools.jar:$JRE_HOME/lib:$CLASSPATH ENV PATH $JAVA_HOME/bin:$PATH
EXPOSE 80
CMD echo $MYPATH CMD echo “success———————ok” CMD /bin/bash
**利用dockerfile构建镜像：docker build -t 新镜像名字:TAG .**<br /><br />**运行镜像：docker run -it 新镜像名字:TAG **<br /><a name="uAH8u"></a>### Dockerfile中COPY 和 ADD命令的区别ADD会自动解压tar、zip、tgz、xz等归档文件，而COPY不会，同时ADD指令还可以接一个url下载文件地址，一般建议使用COPY复制文件即可，文件在宿主机上是什么样子复制到镜像里面就是什么样子这样比较好<a name="krQmY"></a>## Docker常用命令1. docker pull：拉取或者更新指定镜像2. docker push：将镜像推送至远程仓库3. docker rm：删除容器4. docker rmi：删除镜像5. docker images：列出所有镜像6. docker ps：列出所有可运行的容器7. docker ps -a：列出所有容器8. 启动nginx容器（随机端口映射），并挂载本地文件目录到容器html的命令1. docker run -d -P --name nginx2 -v /home/nginx:/usr/share/nginx/html nginx9. 容器与主机之间的数据拷贝命令1. docker cp命令用于容器与主机之间的数据拷贝2. 主机到容器：docker cp /www 96f7f14e99ab:/www/3. 容器到主机：docker cp 96f7f14e99ab:/www /tmp/10. 当启动容器的时候提示：exec format error？如何解决问题1. 检查启动命令是否有可执行权限，进入容器手工运行脚本进行排查。11. 本地的镜像文件都存放在哪里？1. 与 Docker 相关的本地资源都存放在/var/lib/docker/目录下2. 其中container目录存放容器信息3. graph目录存放镜像信息4. aufs目录下存放具体的内容文件12. 如何退出一个镜像的bash，而不终止它？1. 按Ctrl-p Ctrl-q。13. 退出容器时候自动删除?1. 使用 –rm 选项，例如 sudo docker run –rm -it ubuntu14. 如何批量清理临时镜像文件？1. 可以使用 sudo docker rmi $(sudo docker images -q -f danging=true)命令15. 如何查看镜像支持的环境变量？1. 使用 sudo docker run IMAGE env16. 容器退出后，通过docker ps 命令查看不到，数据会丢失么？1. 容器退出后会处于终止（exited）状态，此时可以通过 docker ps -a 查看，其中数据不会丢失，还可以通过 docker start 来启动，只有删除容器才会清除数据。17. 如何停止所有正在运行的容器？1. 使用 docker kill $(sudo docker ps -q)18. 如何清理批量后台停止的容器？1. 使用 docker rm $（sudo docker ps -a -q）19. 如何临时退出一个正在交互的容器的终端，而不终止它？1. 按 Ctrl+p，后按 Ctrl+q，如果按 Ctrl+c 会使容器内的应用进程终止，进而会使容器终止。<a name="iTCIW"></a>## 如何在生产中监控Docker1. Docker 提供 docker stats 和 docker 事件等工具来监控生产中的 Docker。2. 我们可以使用这些命令获取重要统计数据的报告。3. Docker统计数据：当我们使用容器 ID 调用 docker stats 时，我们获得容器的CPU，内存使用情况等。它类似于 Linux 中的 top 命令。4. Docker事件：Docker 事件是一个命令，用于查看 Docker 守护程序中正在进行的活动流。 一些常见的 Docker事件：attach，commit，die，detach，rename，destroy 等。我们还可以使用各种选项来限制或过滤我们感兴趣的事件。<a name="xE3Rs"></a>## CentOS镜像有几个G，但Docker CentOS镜像才几百兆的原因1. 一个完整的Linux操作系统包含**Linux内核和rootfs根文件系统**，即/dev、/proc/、/bin等目录。CentOS除了rootfs根文件系统，还会**选装很多软件，服务，图形桌面**等，所以CentOS镜像有好几个G也不足为奇2. 而对于容器镜像而言，所有容器都是**共享宿主机的Linux内核**的，docker镜像只需要提供一个很小的**rootfs根文件系统**即可，只需要包含/dev、/proc/、/bin等目录，这是最基本的命令，工具，程序库即可3. 所以，docker镜像才会这么小。<a name="kRoCa"></a># K8s基础<a name="N13hv"></a>## K8s基础<a name="TT20H"></a>### K8s简介1. K8s是kubernetes的简称，其本质是一个开源的**容器编排系统，主要用于管理容器化的应用**，其目标是让部署容器化的应用简单并且高效，Kubernetes提供了应用部署，规划，更新，维护的一种机制。2. 说简单点：K8s就是一个编排容器的系统，一个可以管理容器应用全生命周期的工具，从创建应用，应用的部署，应用提供服务，扩容缩容应用，应用更新，都非常的方便，而且还可以做到故障自愈，3. 所以，K8s是一个非常强大的容器编排系统。<a name="bdgG2"></a>### K8s的组件及其作用K8s主要由master节点和node节点构成。1. master节点负责管理集群，node节点是容器应用真正运行的地方。2. master节点包含的组件有：kube-api-server、kube-controller-manager、kube-scheduler、etcd。3. node节点包含的组件有：kubelet、kube-proxy、container-runtime。1. kube-api-server：简称api-server，api-server是K8s最重要的核心组件之一，它是K8s集群管理的统一访问入口，提供了RESTful API接口，实现了认证、授权和准入控制等安全功能；api-server还是其他组件之间的数据交互和通信的枢纽，其他组件彼此之间并不会直接通信，其他组件对资源对象的增、删、改、查和监听操作都是交由api-server处理后，api-server再提交给etcd数据库做持久化存储，只有api-server才能直接操作etcd数据库，其他组件都不能直接操作etcd数据库，其他组件都是通过api-server间接的读取，写入数据到etcd。2. kube-controller-manager：简称controller-manager，controller-manager是K8s中各种控制器的的管理者，是K8s集群内部的管理控制中心，也是K8s自动化功能的核心；controller-manager内部包含replication controller、node controller、deployment controller、endpoint controller等各种资源对象的控制器，每种控制器都负责一种特定资源的控制流程，而controller-manager正是这些controller的核心管理者。3. kube-scheduler：简称scheduler，scheduler负责集群资源调度，其作用是将待调度的pod通过一系列复杂的调度算法计算出最合适的node节点，然后将pod绑定到目标节点上。shceduler会根据pod的信息，全部节点信息列表，过滤掉不符合要求的节点，过滤出一批候选节点，然后给候选节点打分，选分最高的就是最佳节点，scheduler就会把目标pod安置到该节点。4. Etcd：etcd是一个分布式的键值对存储数据库，主要是用于保存K8s集群状态数据，比如，pod，service等资源对象的信息；etcd可以是单个也可以有多个，多个就是etcd数据库集群，etcd通常部署奇数个实例，在大规模集群中，etcd有5个或7个节点就足够了；另外说明一点，etcd本质上可以不与master节点部署在一起，只要master节点能通过网络连接etcd数据库即可。5. kubelet：每个node节点上都有一个kubelet服务进程，kubelet作为连接master和各node之间的桥梁，负责维护pod和容器的生命周期，当监听到master下发到本节点的任务时，比如创建、更新、终止pod等任务，kubelet 即通过控制docker来创建、更新、销毁容器；6. 每个kubelet进程都会在api-server上注册本节点自身的信息，用于定期向master汇报本节点资源的使用情况。7. kube-proxy：kube-proxy运行在node节点上，在Node节点上实现Pod网络代理，维护网络规则和四层负载均衡工作，kube-proxy会监听api-server中从而获取service和endpoint的变化情况，创建并维护路由规则以提供服务IP和负载均衡功能。简单理解此进程是Service的透明代理兼负载均衡器，其核心功能是将到某个Service的访问请求转发到后端的多个Pod实例上。8. container-runtime：容器运行时环境，即运行容器所需要的一系列程序，目前K8s支持的容器运行时有很多，如docker、rkt或其他，比较受欢迎的是docker，但是新版的K8s已经宣布弃用docker。<a name="rXray"></a>### Kubernetes相关基础概念1. master：K8s集群的管理节点，负责管理集群，提供集群的资源数据访问入口。拥有Etcd存储服务（可选），运行Api Server进程，Controller Manager服务进程及Scheduler服务进程；2. node（worker）：Node（worker）是Kubernetes集群架构中运行Pod的服务节点，是Kubernetes集群操作的单元，用来承载被分配Pod的运行，是Pod运行的宿主机。运行docker eninge服务，守护进程kunelet及负载均衡器kube-proxy；3. pod：运行于Node节点上，若干相关容器的组合。Pod内包含的容器运行在同一宿主机上，使用相同的网络命名空间、IP地址和端口，能够通过localhost进行通信。Pod是Kurbernetes进行创建、调度和管理的最小单位，它提供了比容器更高层次的抽象，使得部署和管理更加灵活。一个Pod可以包含一个容器或者多个相关容器；4. label：Kubernetes中的Label实质是一系列的Key/Value键值对，其中key与value可自定义。Label可以附加到各种资源对象上，如Node、Pod、Service、RC等。一个资源对象可以定义任意数量的Label，同一个Label也可以被添加到任意数量的资源对象上去。Kubernetes通过Label Selector（标签选择器）查询和筛选资源对象；5. Replication Controller：Replication Controller用来管理Pod的副本，保证集群中存在指定数量的Pod副本。集群中副本的数量大于指定数量，则会停止指定数量之外的多余容器数量。反之，则会启动少于指定数量个数的容器，保证数量不变。Replication Controller是实现弹性伸缩、动态扩容和滚动升级的核心；6. Deployment：Deployment在内部使用了RS来实现目的，Deployment相当于RC的一次升级，其最大的特色为可以随时获知当前Pod的部署进度；7. HPA（Horizontal Pod Autoscaler）：Pod的横向自动扩容，也是Kubernetes的一种资源，通过追踪分析RC控制的所有Pod目标的负载变化情况，来确定是否需要针对性的调整Pod副本数量；8. Service：Service定义了Pod的逻辑集合和访问该集合的策略，是真实服务的抽象。Service提供了一个统一的服务访问入口以及服务代理和发现机制，关联多个相同Label的Pod，用户不需要了解后台Pod是如何运行；9. Volume：Volume是Pod中能够被多个容器访问的共享目录，Kubernetes中的Volume是定义在Pod上，可以被一个或多个Pod中的容器挂载到某个目录下；10. Namespace：Namespace用于实现多租户的资源隔离，可将集群内部的资源对象分配到不同的Namespace中，形成逻辑上的不同项目、小组或用户组，便于不同的Namespace在共享使用整个集群的资源的同时还能被分别管理；<a name="Tzbam"></a>### Kubernetes和Docker的关系1. Docker是开源的容器引擎，一种更加轻量级的虚拟化技术2. K8s是容器管理工具，用来管理容器pod的集合，它可以实现容器集群的自动化部署、自动扩缩容、维护等功能<a name="XBtph"></a>### Kubernetes如何实现集群管理1. 在集群管理方面，Kubernetes将集群中的机器划分为一个Master节点和一群工作节点Node。2. 其中，在Master节点运行着集群管理相关的一组进程kube-apiserver、kube-controller-manager和kube-scheduler，这些进程实现了整个集群的资源管理、Pod调度、弹性伸缩、安全控制、系统监控和纠错等管理能力，并且都是全自动完成的；<a name="s9s5L"></a>### Kubernetes的优势、适应场景及其特点1. 优势：容器编排、轻量级、开源、弹性伸缩、负载均衡；2. 场景：快速部署应用、快速扩展应用、无缝对接新的应用功能、节省资源，优化硬件资源的使用；3. 特点：1. 可移植：支持公有云、私有云、混合云、多重云（multi-cloud）2. 可扩展：模块化,、插件化、可挂载、可组合3. 自动化：自动部署、自动重启、自动复制、自动伸缩/扩展<a name="FWuWa"></a>### Kubernetes的缺点或当前的不足之处安装过程和配置相对困难复杂、管理服务相对繁琐、运行和编译需要很多时间、它比其他替代品更昂贵、对于简单的应用程序来说，可能不需要涉及Kubernetes即可满足<a name="WCVf7"></a>### Kubernetes中什么是Minikube、Kubectl、Kubelet1. Minikube是一种可以在本地轻松运行一个单节点 Kubernetes 群集的工具；2. Kubectl是一个命令行工具，可以使用该工具控制Kubernetes集群管理器，如检查群集资源，创建、删除和更新组件，查看应用程序；3. Kubelet是一个代理服务，它在每个节点上运行，并使从服务器与主服务器通信；<a name="hVztX"></a>### kubelet的功能、作用是什么？（重点，经常会问）kubelet部署在每个node节点上的，它主要有4个功能：1. **节点管理：**kubelet启动时会向api-server进行注册，然后会定时的向api-server汇报本节点信息状态，资源使用状态等，这样master就能够知道node节点的资源剩余，节点是否失联等等相关的信息了。master知道了整个集群所有节点的资源情况，这对于 pod 的调度和正常运行至关重要。2. **pod管理：**kubelet负责维护node节点上pod的生命周期，当kubelet监听到master的下发到自己节点的任务时，比如要创建、更新、删除一个pod，kubelet 就会通过CRI（容器运行时接口）插件来调用不同的容器运行时来创建、更新、删除容器；常见的容器运行时有docker、containerd、rkt等等这些容器运行时，我们最熟悉的就是docker了，但在新版本的K8s已经弃用docker了，K8s1.24版本中已经使用containerd作为容器运行时了。3. **容器健康检查：**pod中可以定义启动探针、存活探针、就绪探针等3种，我们最常用的就是存活探针、就绪探针，kubelet 会定期调用容器中的探针来检测容器是否存活，是否就绪，如果是存活探针，则会根据探测结果对检查失败的容器进行相应的重启策略；4. **Metrics Server资源监控：**在node节点上部署Metrics Server用于监控node节点、pod的CPU、内存、文件系统、网络使用等资源使用情况，而kubelet则通过Metrics Server获取所在节点及容器的上的数据。<a name="Gxc29"></a>### kube-api-server的端口是多少？各个pod是如何访问kube-api-server的？1. kube-api-server的端口是8080和6443，前者是http的端口，后者是https的端口，以我本机使用kubeadm安装的K8s为例：2. 在命名空间的kube-system命名空间里，有一个名称为kube-api-master的pod，3. 这个pod就是运行着kube-api-server进程，它绑定了master主机的ip地址和6443端口，但是在default命名空间下，存在一个叫kubernetes的服务，该服务对外暴露端口为443，目标端口6443，4. 这个服务的ip地址是clusterip地址池里面的第一个地址，同时这个服务的yaml定义里面并没有指定标签选择器，5. 也就是说这个kubernetes服务所对应的endpoint是手动创建的，该endpoint也是名称叫做kubernetes，该endpoint的yaml定义里面代理到master节点的6443端口，也就是kube-api-server的IP和端口。6. 这样一来，其他pod访问kube-api-server的整个流程就是：pod创建后嵌入了环境变量，pod获取到了kubernetes这个服务的ip和443端口，请求到kubernetes这个服务其实就是转发到了master节点上的6443端口的kube-api-server这个pod里面。<a name="BWL3m"></a>### K8s中命名空间的作用是什么？1. namespace是kubernetes系统中的一种非常重要的资源，namespace的主要作用是用来实现多套环境的资源隔离，或者说是多租户的资源隔离。2. K8s通过将集群内部的资源分配到不同的namespace中，可以形成逻辑上的隔离，以方便不同的资源进行隔离使用和管理。3. 不同的命名空间可以存在同名的资源，命名空间为资源提供了一个作用域。4. 可以通过K8s的授权机制，将不同的namespace交给不同的租户进行管理，这样就实现了多租户的资源隔离，还可以结合K8s的资源配额机制，限定不同的租户能占用的资源，例如CPU使用量、内存使用量等等来实现租户可用资源的管理。<a name="yN1kg"></a>### K8s提供了大量的REST接口，其中有一个是Kubernetes Proxy API接口，简述一下这个Proxy接口的作用，已经怎么使用。1. kubernetes proxy api接口，从名称中可以得知，proxy是代理的意思，其作用就是代理rest请求；2. Kubernets API server 将接收到的rest请求转发到某个node上的kubelet守护进程的rest接口，由该kubelet进程负责响应。3. 我们可以使用这种Proxy接口来直接访问某个pod，这对于逐一排查pod异常问题很有帮助。下面是一些简单的例子：```javahttp://<kube-api-server>:<api-sever-port>/api/v1/nodes/node名称/proxy/pods #查看指定node的所有pod信息http://<kube-api-server>:<api-sever-port>/api/v1/nodes/node名称/proxy/stats #查看指定node的物理资源统计信息http://<kube-api-server>:<api-sever-port>/api/v1/nodes/node名称/proxy/spec #查看指定node的概要信息http://<kube-api-server>:<api-sever-port>/api/v1/namespace/命名名称/pods/pod名称/pod服务的url/ #访问指定pod的程序页面http://<kube-api-server>:<api-sever-port>/api/v1/namespace/命名名称/servers/svc名称/url/ #访问指定server的url程序页面
Pod详解
Pod简介
- 在kubernetes的世界中，K8s并不直接处理容器，而是使用多个容器共存的理念，这组容器就叫做pod。
- pod是K8s中可以创建和管理的最小单元，是资源对象模型中由用户创建或部署的最小资源对象模型，其他的资源对象都是用来支撑pod对象功能的，比如，pod控制器就是用来管理pod对象的，service或者imgress资源对象是用来暴露pod引用对象的，persistentvolume资源是用来为pod提供存储等等
简而言之，K8s不会直接处理容器，而是pod，pod才是K8s中可以创建和管理的最小单元，也是基本单元。
pod的原理
在微服务的概念里，一般的，一个容器会被设计为运行一个进程，除非进程本身产生子进程，
这样，由于不能将多个进程聚集在同一个单独的容器中，所以需要一种更高级的结构将容器绑定在一起，并将它们作为一个单元进行管理，这就是K8s中pod的背后原理。
pod的特点
每个pod就像一个独立的逻辑机器，K8s会为每个pod分配一个集群内部唯一的IP地址，所以每个pod都拥有自己的IP地址、主机名、进程等；
- 一个pod可以包含1个或多个容器，1个容器一般被设计成只运行1个进程，1个pod只可能运行在单个节点上，即不可能1个pod跨节点运行，pod的生命周期是短暂，也就是说pod可能随时被消亡（如节点异常，pod异常等情况）；
- 每一个pod都有一个特殊的被称为”根容器”的pause容器，也称info容器，pause容器对应的镜像属于K8s平台的一部分，除了pause容器，每个pod还包含一个或多个跑业务相关组件的应用容器；
- 一个pod中的容器共享network命名空间；
- 一个pod里的多个容器共享pod IP，这就意味着1个pod里面的多个容器的进程所占用的端口不能相同，否则在这个pod里面就会产生端口冲突；既然每个pod都有自己的IP和端口空间，那么对不同的两个pod来说就不可能存在端口冲突；
- 应该将应用程序组织到多个pod中，而每个pod只包含紧密相关的组件或进程；
pod是K8s中扩容、缩容的基本单位，也就是说K8s中扩容缩容是针对pod而言而非容器。
pod的重启策略
pod重启容器策略是指针对pod内所有容器的重启策略，不是重启pod，其可以通过restartPolicy字段配置pod重启容器的策略，如下：
Always：当容器终止退出后，总是重启容器，默认策略就是Always。
- OnFailure：当容器异常退出，退出状态码非0时，才重启容器。
Never：当容器终止退出，不管退出状态码是什么，从不重启容器。
pod的镜像拉取策略
pod镜像拉取策略可以通过imagePullPolicy字段配置镜像拉取策略，
主要有3中镜像拉取策略，如下：IfNotPresent: 默认值，镜像在node节点宿主机上不存在时才拉取。
- Always: 总是重新拉取，即每次创建pod都会重新从镜像仓库拉取一次镜像。
Never: 永远不会主动拉取镜像，仅使用本地镜像，需要你手动拉取镜像到node节点，如果node节点不存在镜像则pod启动失败。
kubenetes针对pod资源对象的健康监测机制?（必须记住3重探测方式，重点，经常问）
提供了三类probe（探针）来执行对pod的健康监测：
livenessProbe探针 （存活探针）：
- 可以根据用户自定义规则来判定pod是否健康，用于判断容器是否处于Running状态，
- 如果不是，kubelet就会杀掉该容器，并根据重启策略做相应的处理。如果容器不包含该探针，那么kubelet就会默认返回值都是success
- ReadinessProbe探针：同样是可以根据用户自定义规则来判断pod是否健康，容器服务是否可用（Ready），如果探测失败，控制器会将此pod从对应service的endpoint列表中移除，从此不再将任何请求调度到此Pod上，直到下次探测成功
- startupProbe探针：
- 启动检查机制，应用一些启动缓慢的业务，避免业务长时间启动而被上面两类探针kill掉，
- 这个问题也可以换另一种方式解决，就是定义上面两类探针机制时，初始化时间定义的长一些即可
备注：每种探测方法能支持以下几个相同的检查参数，用于设置控制检查时间：
- initialDelaySeconds：初始第一次探测间隔，用于应用启动的时间，防止应用还没启动而健康检查失败；
- periodSeconds：检查间隔，多久执行probe检查，默认为10s；
- timeoutSeconds：检查超时时长，探测应用timeout后为失败；
successThreshold：成功探测阈值，表示探测多少次为健康正常，默认探测1次。
就绪探针与存活探针的区别
两者作用不一样
存活探针（livenessProbe探针）是将检查失败的容器杀死，创建新的启动容器来保持pod正常工作；
就绪探针（ReadinessProbe探针）是，当就绪探针检查失败，并不重启容器，而是将pod移出endpoint，就绪探针确保了service中的pod都是可用的，确保客户端只与正常的pod交互并且客户端永远不会知道系统存在问题。
存活探针的属性参数有哪几个
存活探针的附加属性参数有以下几个：
initialDelaySeconds：表示在容器启动后延时多久秒才开始探测；
- periodSeconds：表示执行探测的频率，即间隔多少秒探测一次，默认间隔周期是10秒，最小1秒；
- timeoutSeconds：表示探测超时时间，默认1秒，最小1秒，表示容器必须在超时时间范围内做出响应，否则视为本次探测失败；
- successThreshold：表示最少连续探测成功多少次才被认定为成功，默认是1，对于liveness必须是1，最小值是1；
- failureThreshold：表示连续探测失败多少次才被认定为失败，默认是3，连续3次失败，K8s 将根据pod重启策略对容器做出决定；
注意：定义存活探针时，一定要设置initialDelaySeconds属性，该属性为初始延时，如果不设置，默认容器启动时探针就开始探测了，这样可能会存在
应用程序还未启动就绪，就会导致探针检测失败，K8s就会根据pod重启策略杀掉容器然后再重新创建容器的莫名其妙的问题。
在生产环境中，一定要定义一个存活探针。
pod的就绪探针有哪几种
我们知道，当一个pod启动后，就会立即加入service的endpoint ip列表中，并开始接收到客户端的链接请求，
假若此时pod中的容器的业务进程还没有初始化完毕，那么这些客户端链接请求就会失败，为了解决这个问题，kubernetes提供了就绪探针来解决这个问题的。
在pod中的容器定义一个就绪探针，就绪探针周期性检查容器，
如果就绪探针检查失败了，说明该pod还未准备就绪，不能接受客户端链接，则该pod将从endpoint列表中移除，
pod被剔除了, service就不会把请求分发给该pod，
然后就绪探针继续检查，如果随后容器就绪，则再重新把pod加回endpoint列表。
kubernetes提供了3种探测容器的存活探针，如下：
- httpGet：通过容器的IP、端口、路径发送http 请求，返回200-400范围内的状态码表示成功。
- exec：在容器内执行shell命令，根据命令退出状态码是否为0进行判断，0表示健康，非0表示不健康
TCPSocket：与容器的IP、端口建立TCP Socket链接，能建立则说明探测成功，不能建立则说明探测失败
pod的就绪探针的属性参数有哪些
就绪探针的附加属性参数有以下几个：
initialDelaySeconds：延时秒数，即容器启动多少秒后才开始探测，不写默认容器启动就探测；
- periodSeconds ：执行探测的频率（秒），默认为10秒，最低值为1；
- timeoutSeconds ：超时时间，表示探测时在超时时间内必须得到响应，负责视为本次探测失败，默认为1秒，最小值为1；
- failureThreshold ：连续探测失败的次数，视为本次探测失败，默认为3次，最小值为1次；
successThreshold ：连续探测成功的次数，视为本次探测成功，默认为1次，最小值为1次；
pod的重启策略
通过命令“kubectl explain pod.spec”查看pod的重启策略;
Always：但凡pod对象终止就重启，此为默认策略;
OnFailure：仅在pod对象出现错误时才重启;pod创建过程
情况一、使用kubectl run命令创建的pod：
注意：kubectl run 在旧版本中创建的是deployment，但在新的版本中创建的是pod则其创建过程不涉及deployment
如果是单独的创建一个pod，则其创建过程是这样的：
首先，用户通过kubectl或其他api客户端工具提交需要创建的pod信息给apiserver；
- apiserver验证客户端的用户权限信息，验证通过开始处理创建请求生成pod对象信息，并将信息存入etcd，然后返回确认信息给客户端；
- apiserver开始反馈etcd中pod对象的变化，其他组件使用watch机制跟踪apiserver上的变动；
- scheduler发现有新的pod对象要创建，开始调用内部算法机制为pod分配最佳的主机，并将结果信息更新至apiserver；
- node节点上的kubelet通过watch机制跟踪apiserver发现有pod调度到本节点，尝试调用docker启动容器，并将结果反馈apiserver；
- apiserver将收到的pod状态信息存入etcd中。
至此，整个pod创建完毕。
情况二、使用deployment来创建pod：
- 首先，用户使用kubectl create命令或者kubectl apply命令提交了要创建一个deployment资源请求；
- api-server收到创建资源的请求后，会对客户端操作进行身份认证，在客户端的~/.kube文件夹下，已经设置好了相关的用户认证信息，这样api-server会知道我是哪个用户，并对此用户进行鉴权，当api-server确定客户端的请求合法后，就会接受本次操作，并把相关的信息保存到etcd中，然后返回确认信息给客户端。
- apiserver开始反馈etcd中过程创建的对象的变化，其他组件使用watch机制跟踪apiserver上的变动。
- controller-manager组件会监听api-server的信息，controller-manager是有多个类型的，比如Deployment Controller, 它的作用就是负责监听Deployment，此时Deployment Controller发现有新的deployment要创建，那么它就会去创建一个ReplicaSet，一个ReplicaSet的产生，又被另一个叫做ReplicaSet Controller监听到了，紧接着它就会去分析ReplicaSet的语义，它了解到是要依照ReplicaSet的template去创建Pod, 它一看这个Pod并不存在，那么就新建此Pod，当Pod刚被创建时，它的nodeName属性值为空，代表着此Pod未被调度。
- 调度器Scheduler组件开始介入工作，Scheduler也是通过watch机制跟踪apiserver上的变动，发现有未调度的Pod，则根据内部算法、节点资源情况，pod定义的亲和性反亲和性等等，调度器会综合的选出一批候选节点，在候选节点中选择一个最优的节点，然后将pod绑定该该节点，将信息反馈给api-server。
- kubelet组件布署于Node之上，它也是通过watch机制跟踪apiserver上的变动，监听到有一个Pod应该要被调度到自身所在Node上来，kubelet首先判断本地是否在此Pod，如果不存在，则会进入创建Pod流程，创建Pod有分为几种情况，第一种是容器不需要挂载外部存储，则相当于直接docker run把容器启动，但不会直接挂载docker网络，而是通过CNI调用网络插件配置容器网络，如果需要挂载外部存储，则还要调用CSI来挂载存储。kubelet创建完pod，将信息反馈给api-server，api-servier将pod信息写入etcd。
Pod建立成功后，ReplicaSet Controller会对其持续进行关注，如果Pod因意外或被我们手动退出，ReplicaSet Controller会知道，并创建新的Pod，以保持replicas数量期望值。
K8s创建一个pod的详细流程，涉及的组件怎么通信的？
客户端提交创建请求，可以通过 api-server 提供的 restful 接口，或者是通过 kubectl 命令行工具，支持的数据类型包括 JSON 和 YAML；
- api-server 处理用户请求，将 pod 信息存储至 etcd 中；
- kube-scheduler 通过 api-server 提供的接口监控到未绑定的 pod，尝试为 pod 分配 node 节点，主要分为两个阶段，预选阶段和优选阶段，其中预选阶段是遍历所有的 node 节点，根据策略筛选出候选节点，而优选阶段是在第一步的基础上，为每一个候选节点进行打分，分数最高者胜出；
- 选择分数最高的节点，进行 pod binding 操作，并将结果存储至 etcd 中；
随后目标节点的 kubelet 进程通过 api-server 提供的接口监测到 kube-scheduler 产生的 pod 绑定事件，然后从 etcd 获取 pod 清单，下载镜像并启动容器；
pod的终止过程
用户向apiserver发送删除pod对象的命令；
- apiserver中的pod对象信息会随着时间的推移而更新，在宽限期内（默认30s），pod被视为dead；
- 将pod标记为terminating状态；
- kubectl在监控到pod对象为terminating状态了就会启动pod关闭过程；
- endpoint控制器监控到pod对象的关闭行为时将其从所有匹配到此endpoint的server资源endpoint列表中删除；
- 如果当前pod对象定义了preStop钩子处理器，则在其被标记为terminating后会意同步的方式启动执行；
- pod对象中的容器进程收到停止信息；
- 宽限期结束后，若pod中还存在运行的进程，那么pod对象会收到立即终止的信息；
kubelet请求apiserver将此pod资源的宽限期设置为0从而完成删除操作，此时pod对用户已不可见。
pod的生命周期有哪几种？
pod生命周期有的5种状态（也称5种相位），如下：
Pending（挂起）：API server已经创建pod，但是该pod还有一个或多个容器的镜像没有创建，包括正在下载镜像的过程；
- Running（运行中）：Pod内所有的容器已经创建，且至少有一个容器处于运行状态、正在启动括正在重启状态；
- Succeed（成功）：Pod内所有容器均已退出，且不会再重启；
- Failed（失败）：Pod内所有容器均已退出，且至少有一个容器为退出失败状态
Unknown（未知）：某于某种原因apiserver无法获取该pod的状态，可能由于网络通行问题导致；
pod一致处于pending状态一般有哪些情况，怎么排查？（重点，持续更新）
（这个问题被问到的概率非常大）
一个pod一开始创建的时候，它本身就是会处于pending状态，这时可能是正在拉取镜像，正在创建容器的过程。
如果等了一会发现pod一直处于pending状态，
那么我们可以使用kubectl describe命令查看一下pod的Events详细信息。一般可能会有这么几种情况导致pod一直处于pending状态：调度器调度失败。
- Scheduer调度器无法为pod分配一个合适的node节点。
- 而这又会有很多种情况，比如，node节点处在cpu、内存压力，导致无节点可调度；pod定义了资源请求，没有node节点满足资源请求；node节点上有污点而pod没有定义容忍；pod中定义了亲和性或反亲和性而没有节点满足这些亲和性或反亲和性；以上是调度器调度失败的几种情况。
pvc、pv无法动态创建。
- 如果因为pvc或pv无法动态创建，那么pod也会一直处于pending状态，比如要使用StatefulSet 创建redis集群，因为粗心大意，定义的storageClassName名称写错了，那么会造成无法创建pvc，这种情况pod也会一直处于pending状态，或者，即使pvc是正常创建了，但是由于某些异常原因导致动态供应存储无法正常创建pv，那么这种情况pod也会一直处于pending状态。
DaemonSet资源对象的特性
DaemonSet这种资源对象会在每个K8s集群中的节点上运行，并且每个节点只能运行一个pod，这是它和deployment资源对象的最大也是唯一的区别。
所以，在其yaml文件中，不支持定义replicas，
除此之外，与Deployment、RS等资源对象的写法相同,
DaemonSet一般使用的场景有：
- 如果因为pvc或pv无法动态创建，那么pod也会一直处于pending状态，比如要使用StatefulSet 创建redis集群，因为粗心大意，定义的storageClassName名称写错了，那么会造成无法创建pvc，这种情况pod也会一直处于pending状态，或者，即使pvc是正常创建了，但是由于某些异常原因导致动态供应存储无法正常创建pv，那么这种情况pod也会一直处于pending状态。
在去做每个节点的日志收集工作；
-
删除一个Pod会发生什么事情
Kube-apiserver会接受到用户的删除指令，默认有30秒时间等待优雅退出，超过30秒会被标记为死亡状态，
此时Pod的状态Terminating，kubelet看到pod标记为Terminating就开始了关闭Pod的工作;
关闭流程如下： pod从service的endpoint列表中被移除；
- 如果该pod定义了一个停止前的钩子，其会在pod内部被调用，停止钩子一般定义了如何优雅的结束进程；
- 进程被发送TERM信号（kill -14）;
当超过优雅退出的时间后，Pod中的所有进程都会被发送SIGKILL信号（kill -9）
pod的共享资源
PID 命名空间：Pod 中的不同应用程序可以看到其他应用程序的进程 ID；
- 网络命名空间：Pod 中的多个容器能够访问同一个IP和端口范围；
- IPC 命名空间：Pod 中的多个容器能够使用 SystemV IPC 或 POSIX 消息队列进行通信；
- UTS 命名空间：Pod 中的多个容器共享一个主机名；
Volumes（共享存储卷）：Pod 中的各个容器可以访问在 Pod 级别定义的 Volumes；
pod的初始化容器是干什么的
init container，初始化容器用于在启动应用容器之前完成应用容器所需要的前置条件，
初始化容器本质上和应用容器是一样的，但是初始化容器是仅允许一次就结束的任务，初始化容器具有两大特征：初始化容器必须运行完成直至结束，若某初始化容器运行失败，那么kubernetes需要重启它直到成功完成；
初始化容器必须按照定义的顺序执行，当且仅当前一个初始化容器成功之后，后面的一个初始化容器才能运行；
pod的资源请求、限制如何定义
pod的资源请求、资源限制可以直接在pod中定义
主要包括两块内容，limits，限制pod能使用的最大cpu和内存，
requests，pod启动时申请的cpu和内存。
resources: #资源配额limits: #限制最大资源，上限cpu: 2 #CPU限制，单位是code数memory: 2G #内存最大限制requests: #请求资源（最小，下限）cpu: 1 #CPU请求，单位是code数memory: 500G #内存最小请求
pod的定义中有个command和args参数，这两个参数不会和docker镜像的entrypointc冲突吗？
不会。
在pod中定义的command参数用于指定容器的启动命令列表，如果不指定，则默认使用Dockerfile打包时的启动命令，args参数用于容器的启动命令需要的参数列表；
特别说明：
kubernetes中的command、args其实是实现覆盖dockerfile中的ENTRYPOINT的功能的。如果command和args均没有写，那么使用Dockerfile的配置；
- 如果command写了但args没写，那么Dockerfile默认的配置会被忽略，执行指定的command；
- 如果command没写但args写了，那么Dockerfile中的ENTRYPOINT的会被执行，使用当前args的参数；
如果command和args都写了，那么Dockerfile会被忽略，执行输入的command和args。
pause容器作用是什么？
每个pod里运行着一个特殊的被称之为pause的容器，也称根容器，而其他容器则称为业务容器；
- 创建pause容器主要是为了为业务容器提供 Linux命名空间，共享基础：包括 pid、icp、net 等，以及启动 init 进程，并收割僵尸进程；
- 这些业务容器共享pause容器的网络命名空间和volume挂载卷，
- 当pod被创建时，pod首先会创建pause容器，从而把其他业务容器加入pause容器，从而让所有业务容器都在同一个命名空间中，这样可以就可以实现网络共享。
pod还可以共享存储，在pod级别引入数据卷volume，业务容器都可以挂载这个数据卷从而实现持久化存储。
标签及标签选择器是什么，如何使用？
标签是键值对类型，标签可以附加到任何资源对象上，主要用于管理对象，查询和筛选。
- 标签常被用于标签选择器的匹配度检查，从而完成资源筛选；一个资源可以定义一个或多个标签在其上面。
- 标签选择器，标签要与标签选择器结合在一起，标签选择器允许我们选择标记有特定标签的资源对象子集，如pod，并对这些特定标签的pod进行查询，删除等操作。
标签和标签选择器最重要的使用之一在于，在deployment中，在pod模板中定义pod的标签，然后在deployment定义标签选择器，这样就通过标签选择器来选择哪些pod是受其控制的，service也是通过标签选择器来关联哪些pod最后其服务后端pod。
Service详解
Service是如何与pod关联的？
答案是通过标签选择器，每一个由deployment创建的pod都带有标签，这样，service就可以定义标签选择器来关联哪些pod是作为其后端了，就是这样，service就与pod管联在一起了。
Service的域名解析格式、pod的域名解析格式
service的DNS域名表示格式为
. .svc. ， - servicename是service的名称，namespace是service所处的命名空间，clusterdomain是K8s集群设置的域名后缀，一般默认为 cluster.local
- pod的DNS域名格式为：
. .pod. ， - 其中，pod-ip需要使用-将ip直接的点替换掉，namespace为pod所在的命名空间，clusterdomain是K8s集群设置的域名后缀，一般默认为 cluster.local ，
- 演示如下：10-244-1-223.default.pod.cluster.local
对于deployment、daemonsets等创建的pod，还还可以通过
. . .svc. 这样的域名访问。 Service的类型有哪几种
Service的类型一般有4中，分别是：
ClusterIP：表示service仅供集群内部使用，默认值就是ClusterIP类型
- NodePort：表示service可以对外访问应用，会在每个节点上暴露一个端口，这样外部浏览器访问地址为：任意节点的IP：NodePort就能连上service了
- LoadBalancer：表示service对外访问应用，这种类型的service是公有云环境下的service，此模式需要外部云厂商的支持，需要有一个公网IP地址
- ExternalName：这种类型的service会把集群外部的服务引入集群内部，这样集群内直接访问service就可以间接的使用集群外部服务了
一般情况下，service都是ClusterIP类型的，通过ingress接入的外部流量。
Pod到Service的通信？
- K8s在创建服务时为服务分配一个虚拟IP，客户端通过该IP访问服务，服务则负责将请求转发到后端Pod上；
- Service是通过kube-proxy服务进程实现，该进程在每个Node上均运行可以看作一个透明代理兼负载均衡器；
- 对每个TCP类型Service，kube-proxy都会在本地Node上建立一个SocketServer来负责接受请求，然后均匀发送到后端Pod默认采用Round Robin负载均衡算法；
- Service的Cluster IP与NodePort等概念是kube-proxy通过Iptables的NAT转换实现，kube-proxy进程动态创建与Service相关的Iptables规则；
kube-proxy通过查询和监听API Server中Service与Endpoints的变化来实现其主要功能，包括为新创建的Service打开一个本地代理对象，接收请求针对针对发生变化的Service列表，kube-proxy会逐个处理
一个应用pod是如何发现service的，或者说，pod里面的容器用于是如何连接service的？
有两种方式，一种是通过环境变量，另一种是通过service的dns域名方式。
环境变量：
- 当pod被创建之后，K8s系统会自动为容器注入集群内有效的service名称和端口号等信息为环境变量的形式，
- 这样容器应用直接通过取环境变量值就能访问service了，
- 如curl http://${WEBAPP_SERVICE_HOST}:{WEBAPP_SERVICE_PORT}
DNS方式：
- 使用dns域名解析的前提是K8s集群内有DNS域名解析服务器，
- 默认K8s中会有一个CoreDNS作为K8s集群的默认DNS服务器提供域名解析服务器；
- service的DNS域名表示格式为
. .svc. ， - servicename是service的名称，namespace是service所处的命名空间，clusterdomain是K8s集群设置的域名后缀，一般默认为 cluster.local ，
- 这样容器应用直接通过service域名就能访问service了，
- 如wget http://svc-deployment-nginx.default.svc.cluster.local:80，
- 另外，service的port端口如果定义了名称，那么port也可以通过DNS进行解析，
- 格式为：
. . . .svc. 如何创建一个service代理外部的服务，或者换句话来说，在K8s集群内的应用如何访问外部的服务，如数据库服务，缓存服务等?
可以通过创建一个没有标签选择器的service来代理集群外部的服务。
创建service时不指定selector标签选择器，但需要指定service的port端口、端口的name、端口协议等，这样创建出来的service因为没有指定标签选择器就不会自动创建endpoint；
- 手动创建一个与service同名的endpoint，endpoint中定义外部服务的IP和端口，endpoint的名称一定要与service的名称一样，端口协议也要一样，端口的name也要与service的端口的name一样，不然endpoint不能与service进行关联。
- 完成以上两步，K8s会自动将service和同名的endpoint进行关联，
这样，K8s集群内的应用服务直接访问这个service就可以相当于访问外部的服务了。
service、endpoint、kube-proxys三种的关系是什么
service：
- 在kubernetes中，service是一种为一组功能相同的pod提供单一不变的接入点的资源。
- 当service被建立时，service的IP和端口不会改变，这样外部的客户端（也可以是集群内部的客户端）通过service的IP和端口来建立链接，这些链接会被路由到提供该服务的任意一个pod上。
- 通过这样的方式，客户端不需要知道每个单独提供服务的pod地址，这样pod就可以在集群中随时被创建或销毁。
- endpoint：
- service维护一个叫endpoint的资源列表，endpoint资源对象保存着service关联的pod的ip和端口。
- 从表面上看，当pod消失，service会在endpoint列表中剔除pod，当有新的pod加入，service就会将pod ip加入endpoint列表；
- 但是正在底层的逻辑是，endpoint的这种自动剔除、添加、更新pod的地址其实底层是由endpoint controller控制的，endpoint controller负责监听service和对应的pod副本的变化，如果监听到service被删除，则删除和该service同名的endpoint对象，如果监听到新的service被创建或者修改，则根据该service信息获取得相关pod列表，然后创建或更新service对应的endpoint对象，如果监听到pod事件，则更新它所对应的service的endpoint对象。
kube-proxy：
无头service没有cluster ip，在定义service时将 service.spec.clusterIP：None，就表示创建的是无头service。
- 普通的service是用于为一组后端pod提供请求连接的负载均衡，让客户端能通过固定的service ip地址来访问pod，这类的pod是没有状态的，同时service还具有负载均衡和服务发现的功能。普通service跟我们平时使用的nginx反向代理很相识。
- 试想这样一种情况，有6个redis pod ,它们相互之间要通信并要组成一个redis集群，
- 不需要所谓的service负载均衡，这时无头service就是派上用场了，
- 无头service由于没有cluster ip，kube-proxy就不会处理它也就不会对它生成规则负载均衡，无头service直接绑定的是pod 的ip。无头service仍会有标签选择器，有标签选择器就会有endpoint资源。
无头service使用场景：无头service一般用于有状态的应用场景，如Kaka集群、Redis集群等，这类pod之间需要相互通信相互组成集群，不在需要所谓的service负载均衡。
deployment怎么扩容或缩容
直接修改pod副本数即可，可以通过下面的方式来修改pod副本数：
直接修改yaml文件的replicas字段数值，然后kubectl apply -f xxx.yaml来实现更新；
- 使用kubectl edit deployment xxx 修改replicas来实现在线更新；
使用kubectl scale —replicas=5 deployment/deployment-nginx命令来扩容缩容。
deployment的更新升级策略有哪些
deployment的升级策略主要有两种：
Recreate 重建更新：这种更新策略会杀掉所有正在运行的pod，然后再重新创建的pod；
rollingUpdate 滚动更新：这种更新策略，deployment会以滚动更新的方式来逐个更新pod，同时通过设置滚动更新的两个参数maxUnavailable、maxSurge来控制更新的过程。
deployment的滚动更新策略有两个特别主要的参数，解释一下它们是什么意思？
deployment的滚动更新策略，rollingUpdate 策略，主要有两个参数，maxUnavailable、maxSurge。
maxUnavailable：最大不可用数，maxUnavailable用于指定deployment在更新的过程中不可用状态的pod的最大数量，maxUnavailable的值可以是一个整数值，也可以是pod期望副本的百分比，如25%，计算时向下取整。
maxSurge：最大激增数，maxSurge指定deployment在更新的过程中pod的总数量最大能超过pod副本数多少个，maxUnavailable的值可以是一个整数值，也可以是pod期望副本的百分比，如25%，计算时向上取整。
deployment更新的命令有哪些
可以通过三种方式来实现更新deployment
直接修改yaml文件的镜像版本，然后kubectl apply -f xxx.yaml来实现更新；
- 使用kubectl edit deployment xxx 实现在线更新；
- 使用kubectl set image deployment/nginx busybox=busybox nginx=nginx:1.9.1 命令来更新。
deployment的更新过程
deployment是通过控制replicaset来实现，由replicaset真正创建pod副本，每更新一次deployment，都会创建新的replicaset，下面来举例deployment的更新过程：
假设要升级一个nginx-deployment的版本镜像为nginx:1.9，deployment的定义滚动更新参数如下：
通过计算我们得出，3*25%=0.75，maxUnavailable是向下取整，则maxUnavailable=0，maxSurge是向上取整，则maxSurge=1，所以我们得出在整个deployment升级镜像过程中，不管旧的pod和新的pod是如何创建消亡的，pod总数最大不能超过3+maxSurge=4个，最大pod不可用数3-maxUnavailable=3个。replicas: 3deployment.spec.strategy.type: RollingUpdatemaxUnavailable：25%maxSurge：25%
现在具体讲一下deployment的更新升级过程：
使用kubectl set image deployment/nginx nginx=nginx:1.9 —record 命令来更新；
- deployment创建一个新的replaceset，先新增1个新版本pod，此时pod总数为4个，不能再新增了，再新增就超过pod总数4个了；旧=3，新=1，总=4；
- 减少一个旧版本的pod，此时pod总数为3个，这时不能再减少了，再减少就不满足最大pod不可用数3个了；旧=2，新=1，总=3；
- 再新增一个新版本的pod，此时pod总数为4个，不能再新增了；旧=2，新=2，总=4；
- 减少一个旧版本的pod，此时pod总数为3个，这时不能再减少了；旧=1，新=2，总=3；
- 再新增一个新版本的pod，此时pod总数为4个，不能再新增了；旧=1，新=3，总=4；
减少一个旧版本的pod，此时pod总数为3个，更新完成，pod都是新版本了；旧=0，新=3，总=3
deployment的回滚使用什么命令
在升级deployment时kubectl set image 命令加上 —record 参数可以记录具体的升级历史信息，
- 使用kubectl rollout history deployment/deployment-nginx 命令来查看指定的deployment升级历史记录，
如果需要回滚到某个指定的版本，可以使用kubectl rollout undo deployment/deployment-nginx —to-revision=2 命令来实现。
讲一下都有哪些存储卷，作用分别是什么
pv的访问模式有哪几种
pv的访问模式有3种，如下：
ReadWriteOnce，简写：RWO 表示，只仅允许单个节点以读写方式挂载；
- ReadOnlyMany，简写：ROX 表示，可以被许多节点以只读方式挂载；
ReadWriteMany，简写：RWX 表示，可以被多个节点以读写方式挂载；
pv的回收策略有哪几种
主要有3中回收策略：retain 保留、delete 删除、 Recycle回收。
Retain：保留，该策略允许手动回收资源，当删除PVC时，PV仍然存在，PV被视为已释放，管理员可以手动回收卷。
- Delete：删除，如果Volume插件支持，删除PVC时会同时删除PV，动态卷默认为Delete，目前支持Delete的存储后端包括AWS EBS，GCE PD，Azure Disk，OpenStack Cinder等。
Recycle：回收，如果Volume插件支持，Recycle策略会对卷执行rm -rf清理该PV，并使其可用于下一个新的PVC，但是本策略将来会被弃用，目前只有NFS和HostPath支持该策略。（这种策略已经被废弃，不用记）
在pv的生命周期中，一般有几种状态
pv一共有4中状态，分别是：
创建pv后，pv的的状态有以下4种：Available（可用）、Bound（已绑定）、Released（已释放）、Failed（失败）Available，表示pv已经创建正常，处于可用状态；
- Bound，表示pv已经被某个pvc绑定，注意，一个pv一旦被某个pvc绑定，那么该pvc就独占该pv，其他pvc不能再与该pv绑定；
- Released，表示pvc被删除了，pv状态就会变成已释放；
-
pv存储空间不足怎么扩容?
一般的，我们会使用动态分配存储资源，
在创建storageclass时指定参数 allowVolumeExpansion：true，表示允许用户通过修改pvc申请的存储空间自动完成pv的扩容，
- 当增大pvc的存储空间时，不会重新创建一个pv，而是扩容其绑定的后端pv。
这样就能完成扩容了。但是allowVolumeExpansion这个特性只支持扩容空间不支持减少空间。
存储类的资源回收策略:
主要有2中回收策略，delete 删除，默认就是delete策略、retain 保留。
Retain：保留，该策略允许手动回收资源，当删除PVC时，PV仍然存在，PV被视为已释放，管理员可以手动回收卷。
Delete：删除，如果Volume插件支持，删除PVC时会同时删除PV，动态卷默认为Delete，目前支持Delete的存储后端包括AWS EBS，GCE PD，Azure Disk，OpenStack Cinder等。
注意：使用存储类动态创建的pv默认继承存储类的回收策略，当然当pv创建后你也可以手动修改pv的回收策略。怎么使一个node脱离集群调度，比如要停机维护单又不能影响业务应用
K8s生产中遇到什么特别映像深刻的问题吗，问题排查解决思路是怎么样的？（重点）
（此问题被问到的概率高达90%，所以可以自己准备几个自己在生产环境中遇到的问题进行讲解）
前端的lb负载均衡服务器上的keepalived出现过脑裂现象。当时问题现象是这样的，vip同时出现在主服务器和备服务器上，但业务上又没受到影响；
- 这时首先去查看备服务器上的keepalived日志，发现有日志信息显示凌晨的时候备服务器出现了vrrp协议超时，所以才导致了备服务器接管了vip；查看主服务器上的keepalived日志，没有发现明显的报错信息，继续查看主服务器和备服务器上的keepalived进程状态，都是running状态的；查看主服务器上检测脚本所检测的进程，其进程也是正常的，也就是说主服务器根本没有成功执行检测脚本（成功执行检查脚本是会kill掉keepalived进程，脚本里面其实就是配置了检查nginx进程是否存活，如果检查到nginx不存活则kill掉keepalived，这样来实现备服务器接管vip）；
- 排查服务器上的防火墙、selinux，防火墙状态和selinux状态都是关闭着的；
- 使用tcpdump工具在备服务器上进行抓取数据包分析，分析发现，现在确实是备接管的vip，也确实是备服务器也在对外发送vrrp心跳包，所以现在外部流量应该都是流入备服务器上的vip；
- 怀疑：主服务器上设置的vrrp心跳包时间间隔太长，以及检测脚本设置的检测时间设置不合理导致该问题；
- 修改vrrp协议的心跳包时间间隔，由原来的2秒改成1秒就发送一次心跳包；检测脚本的检测时间也修改短一点，同时还修改检测脚本的检测失败的次数，比如连续检测2次失败才认定为检测失败；
- 重启主备上的keepalived，现在keepalived是正常的，主服务器上有vip，备服务器上没有vip；
- 持续观察：第二天又发现keepalived出现过脑裂现象，vip又同时出现在主服务器和备服务器上，又是凌晨的时候备服务器显示vrrp心跳包超时，所以才导致备服务器接管了vip；
- 同样的时间，都是凌晨，vrrp协议超时；很奇怪，很有理由怀疑是网络问题，询问第三方厂家上层路由器是否禁止了vrrp协议，第三方厂家回复，没有禁止vrrp协议；
- 百度、看官方文档求解；
- 百度、看官网文档得知，keepalived有2种传播模式，一种是组播模式，一种是单播模式，keepalived默认在组播模式下工作，主服务器会往主播地址224.0.0.18发送心跳包，当局域网内有多个keepalived实例的时候，如果都用主播模式，会存在冲突干扰的情况，所以官方建议使用单播模式通信，单播模式就是点对点通行，即主向备服务器一对一的发送心跳包；
将keepalived模式改为单播模式，继续观察，无再发生脑裂现象。问题得以解决。
K8s生产中遇到什么特别映像深刻的问题吗，问题排查解决思路是怎么样的？（重点）
参考答案二：测试环境二进制搭建etcd集群，etcd集群出现2个leader的现象。
问题现象就是：刚搭建的K8s集群，是测试环境的，搭建完成之后发现，使用kubectl get nodes 显示没有资源，kubectl get namespace 一会能正常显示全部的命名空间，一会又显示不了命名空间，这种奇怪情况。
- 当时经验不是很足，第一点想到的是不是因为网络插件calico没装导致的，但是想想，即使没有安装网络插件，最多是node节点状态是notready，也不可能是没有资源发现呀；
- 然后想到etcd数据库，K8s的资源都是存储在etcd数据库中的；
- 查看etcd进程服务的启动状态，发现etcd服务状态是处于running状态，但是日志有大量的报错信息，日志大概报错信息就是集群节点的id不匹配，存在冲突等等报错信息；
- 使用etcdctl命令查看etcd集群的健康状态，发现集群是health状态，但是居然显示有2个leader，这很奇怪（当初安装etcd的时候其实也只是简单看到了集群是健康状态，然后没注意到有2个leader，也没太关注etcd服务进程的日志报错信息，以为etcd集群状态是health状态就可以了）
- 现在etcd出现了2个leader，肯定是存在问题的；
- 全部检测一遍etcd的各个节点的配置文件，确认配置文件里面各个参数配置都没有问题，重启etcd集群，报错信息仍未解决，仍然存在2个leader；
- 尝试把其中一个leader节点踢出集群，然后再重新添加它进入集群，仍然是报错，仍然显示有2个leader；
- 尝试重新生成etcd的证书，重新颁发etcd的证书，问题仍然存在，仍然显示有2个leader；日志仍是报错集群节点的id不匹配，存在冲突；
- 计算etcd命令的MD5值，确保各个节点的etcd命令是相同的，确保在scp传输的时候没有损耗等等，问题仍未解决；
- 无解，请求同事，架构师介入帮忙排查问题，仍未解决；
- 删除全部etcd相关的文件，重新部署etcd集群，etcd集群正常了，现在只有一个leader，使用命令kubectl get nodes 查看节点，也能正常显示了；
最终问题的原因也没有定位出来，只能怀疑是环境问题了，由于是刚部署的K8s测试环境，etcd里面没有数据，所以可以删除重新创建etcd集群，如果是线上环境的etcd集群出现这种问题，就不能随便删除etcd集群了，必须要先进行数据备份才能进行其他方法的处理。
kube-proxy原理
集群中每个Node上都会运行一个kube-proxy服务进程，他是Service的透明代理兼均衡负载器，其核心功能是将某个Service的访问转发到后端的多个Pod上。
kube-proxy通过监听集群状态变更，并对本机iptables做修改，从而实现网络路由。
而其中的负载均衡，也是通过iptables的特性实现的。
从V1.8版本开始，用IPVS（IP Virtual Server）模式，用于路由规则的配置，主要优势是：为大型集群提供了更好的扩展性和性能。采用哈希表的数据结构，更高效；
- 支持更复杂的负载均衡算法；
- 支持服务器健康检查和连接重试；
-
flannel 和 ovs 网络的区别
配置是否自动化：OpenvSwitch（ovs）作为开源的交换机软件，相对比较成熟和稳定，支持各种网络隧道和协议，经历了大型项目 OpenStack 的考验，而 flannel 除了支持建立覆盖网络来实现 Pod 到 Pod 之间的无缝通信之外，还跟 docker、K8s 的架构体系紧密结合，flannel 能感知 K8s 中的 service 对象，然后动态维护自己的路由表，并通过 etcd 来协助 docker 对整个 K8s 集群的 docker0 网段进行规范，而 ovs ，这些操作则需要手动完成，假如集群中有 N 个节点，则需要建立 N(N-1)/2 个 Vxlan 或者 gre 连接，这取决于集群的规模，如果集群的规模很大，则必须通过自动化脚本来初始化，避免出错。
是否支持隔离：flannel 虽然很方便实现 Pod 到 Pod 之间的通信，但不能实现多租户隔离，也不能很好地限制 Pod 的网络流量，而 ovs 网络有两种模式：单租户模式和多租户模式，单租户模式直接使用 openvswitch + vxlan 将 K8s 的 pod 网络组成一个大二层，所有的 pod 可以互相通信访问，多租户模式以 Namespace 为维度分配虚拟网络，从而形成一个网络独立用户，一个 Namespace 中的 pod 无法访问其他 Namespace 中的 pod 和 svc 对象；
K8s集群外流量怎么访问Pod
可以通过Service的NodePort方式访问，会在所有节点监听同一个端口，比如：30000，访问节点的流量会被重定向到对应的Service上面；
K8s 资源限制 QoS
Quality of Service（Qos）
主要有三种类别：BestEffort：什么都不设置（CPU or Memory），佛系申请资源；
- Burstable：Pod 中的容器至少一个设置了CPU 或者 Memory 的请求；
Guaranteed：Pod 中的所有容器必须设置 CPU 和 Memory，并且 request 和 limit 值相等；
K8s数据持久化的方式有哪些
EmptyDir（空目录）：没有指定要挂载宿主机上的某个目录，直接由Pod内保部映射到宿主机上。类似于docker中的manager volume；场景有：a.只需要临时将数据保存在磁盘上，比如在合并/排序算法中；b.作为两个容器的共享存储，使得第一个内容管理的容器可以将生成的数据存入其中，同时由同一个webserver容器对外提供这些页面;emptyDir的特性：同个pod里面的不同容器，共享同一个持久化目录，当pod节点删除时，volume的数据也会被删除。如果仅仅是容器被销毁，pod还在，则不会影响volume中的数据。总结来说：emptyDir的数据持久化的生命周期和使用的pod一致。一般是作为临时存储使用。
- Hostpath：将宿主机上已存在的目录或文件挂载到容器内部。类似于docker中的bind mount挂载方式；
PersistentVolume（简称PV）：基于NFS服务的PV，也可以基于GFS的PV。它的作用是统一数据持久化目录，方便管理，PVC是向PV申请应用所需的容量大小，K8s集群中可能会有多个PV，PVC和PV若要关联，其定义的访问模式必须一致。定义的storageClassName也必须一致，若群集中存在相同的（名字、访问模式都一致）两个PV，那么PVC会选择向它所需容量接近的PV去申请，或者随机申请
K8s的基本组成部分
Master节点主要有五个组件，分别是kubectl、api-server、controller-manager、kube-scheduler 和 etcd；
- node节点主要有三个组件，分别是 kubelet、kube-proxy 和 容器运行时 docker 或者 rkt；
- kubectl：客户端命令行工具，作为整个系统的操作入口。
- apiserver：以REST API服务形式提供接口，作为整个系统的控制入口。
- controller-manager：执行整个系统的后台任务，包括节点状态状况、Pod个数、Pods和Service的关联等。
- kube-scheduler：负责节点资源管理，接收来自kube-apiserver创建Pods任务，并分配到某个节点。
- etcd：负责节点间的服务发现和配置共享。
- kube-proxy：运行在每个计算节点上，负责Pod网络代理。定时从etcd获取到service信息来做相应的策略。
- kubelet：运行在每个计算节点上，作为agent，接收分配该节点的Pods任务及管理容器，周期性获取容器状态，反馈给kube-apiserver。
DNS：一个可选的DNS服务，用于为每个Service对象创建DNS记录，这样所有的Pod就可以通过DNS访问服务了。
K8s中镜像的下载策略是什么
可通过命令“kubectl explain pod.spec.containers”来查看imagePullPolicy这行的解释，
K8s的镜像下载策略有三种：Always：镜像标签为latest时，总是从指定的仓库中获取镜像；
- Never：禁止从仓库中下载镜像，也就是说只能使用本地镜像；
IfNotPresent：仅当本地没有对应镜像时，才从目标仓库中下载
标签与标签选择器的作用是什么
标签：是当相同类型的资源对象越来越多的时候，为了更好的管理，可以按照标签将其分为一个组，为的是提升资源对象的管理效率；
-
K8s的负载均衡器
负载均衡器是暴露服务的最常见和标准方式之一。
根据工作环境使用两种类型的负载均衡器，即内部负载均衡器或外部负载均衡器。内部负载均衡器自动平衡负载并使用所需配置分配容器，而外部负载均衡器将流量从外部负载引导至后端容器；kubelet 监控 Node 节点资源使用是通过什么组件来实现的
用Metrics Server提供核心指标，包括Node、Pod的CPU和内存的使用。而Metrics Server需要采集node上的cAdvisor提供的数据资源，
- 当 kubelet 服务启动时，它会自动启动 cAdvisor 服务，然后 cAdvisor 会实时采集所在节点的性能指标及在节点上运行的容器的性能指标。
kubelet 的启动参数 —cadvisor-port 可自定义 cAdvisor 对外提供服务的端口号，默认是 4194
Pod的状态
Pending：已经创建了Pod，但是其内部还有容器没有创建；
- Running：Pod内部的所有容器都已经创建，只有由一个容器还处于运行状态或者重启状态；
- Succeeed：Pod内所有容器均已经成功执行并且退出，不会再重启；
- Failed：Pod内所有容器都退出，但至少有一个为退出失败状态；
Unknown：由于某种原因不能获取该Pod的状态，可能是网络问题
deployment/rs的区别
deployment是rs的超集，提供更多的部署功能，如：回滚、暂停和重启、 版本记录、事件和状态查看、滚动升级和替换升级。
-
rc/rs实现原理
Replication Controller 可以保证Pod始终处于规定的副本数，而当前推荐的做法是使用Deployment+ReplicaSet，
- ReplicaSet 号称下一代的 Replication Controller，当前唯一区别是RS支持set-based selector，
RC是通过ReplicationManager监控RC和RC内Pod的状态，从而增删Pod，以实现维持特定副本数的功能，RS也是大致相同
kubernetes服务发现
环境变量： 当你创建一个Pod的时候，kubelet会在该Pod中注入集群内所有Service的相关环境变量。需要注意: 要想一个Pod中注入某个Service的环境变量，则必须Service要先比该Pod创建；
DNS：可以通过cluster add-on方式轻松的创建KubeDNS来对集群内的Service进行服务发现
K8s发布（暴露）服务，servcie的类型有那些
kubernetes原生的，一个Service的ServiceType决定了其发布服务的方式。
ClusterIP：这是K8s默认的ServiceType。通过集群内的ClusterIP在内部发布服务
- NodePort：这种方式是常用的，用来对集群外暴露Service，你可以通过访问集群内的每个NodeIP:NodePort的方式，访问到对应Service后端的Endpoint。
- LoadBalancer：这也是用来对集群外暴露服务的，不同的是这需要Cloud Provider的支持，比如AWS等。
ExternalName：这个也是在集群内发布服务用的，需要借助KubeDNS(version >= 1.7)的支持，就是用KubeDNS将该service和ExternalName做一个Map，KubeDNS返回一个CNAME记录
ETCD及其特点
etcd是一个分布式的、高可用的、一致的key-value存储数据库，基于Go语言实现，主要用于共享配置和服务发现。
特点：完全复制：集群中的每个节点都可以使用完整的存档；
- 高可用性：Etcd可用于避免硬件的单点故障或网络问题；
- 一致性：每次读取都会返回跨多主机的最新写入；
- 简单：包括一个定义良好、面向用户的API（gRPC）；
- 安全：实现了带有可选的客户端证书身份验证的自动化TLS；
- 快速：每秒10000次写入的基准速度；
-
ETCD适应的场景
服务发现：服务发现要解决的也是分布式系统中最常见的问题之一，即在同一个分布式集群中的进程或服务，要如何才能找到对方并建立连接。本质上来说，服务发现就是想要了解集群中是否有进程在监听udp或tcp端口，并且通过名字就可以查找和连接。
- 消息发布与订阅：在分布式系统中，最实用对的一种组件间的通信方式：消息发布与订阅。构建一个配置共享中心，数据提供者在这个配置中心发布消息，而消息使用者订阅他们关心的主题，一旦主题有消息发布，就会实时通知订阅者。达成集中式管理与动态更新。应用中用到的一些配置信息放到etcd上进行集中管理
- 负载均衡：分布式系统中，为了保证服务的高可用以及数据的一致性，通常都会把数据和服务部署多份，以此达到对等服务，即使其中的某一个服务失效了，也不影响使用。etcd本身分布式架构存储的信息访问支持负载均衡。
- 分布式通知与协调：通过注册与异步通知机制，实现分布式环境下不同系统之间的通知与协调，从而对数据变更做到实时处理。
- 分布式锁：因为etcd使用Raft算法保持了数据的强一致性，某次操作存储到集群中的值必然是全局一致的，所以很容易实现分布式锁。锁服务有两种使用方式，一是保持独占，二是控制时序。
- 分布式队列：分布式队列的常规用法与场景五中所描述的分布式锁的控制时序用法类似，即创建一个先进先出的队列，保证顺序。
集群监控与Leader精选：通过etcd来进行监控实现起来非常简单并且实时性强
Kubernetes RC的机制
Replication Controller用来管理Pod的副本，保证集群中存在指定数量的Pod副本。当定义了RC并提交至Kubernetes集群中之后，Master节点上的Controller Manager组件获悉，并同时巡检系统中当前存活的目标Pod，并确保目标Pod实例的数量刚好等于此RC的期望值，若存在过多的Pod副本在运行，系统会停止一些Pod，反之则自动创建一些Pod
kube-proxy作用
kube-proxy 运行在所有节点上，它监听 apiserver 中 service 和 endpoint 的变化情况，创建路由规则以提供服务 IP 和负载均衡功能。
简单理解此进程是Service的透明代理兼负载均衡器，其核心功能是将到某个Service的访问请求转发到后端的多个Pod实例上
kube-proxy iptables原理
Kubernetes从1.2版本开始，将iptables作为kube-proxy的默认模式。iptables模式下的kube-proxy不再起到Proxy的作用，其核心功能：通过API Server的Watch接口实时跟踪Service与Endpoint的变更信息，并更新对应的iptables规则，Client的请求流量则通过iptables的NAT机制“直接路由”到目标Pod
kube-proxy ipvs原理
IPVS在Kubernetes1.11中升级为GA稳定版
IPVS则专门用于高性能负载均衡，并使用更高效的数据结构（Hash表），允许几乎无限的规模扩张，因此被kube-proxy采纳为最新模式；
- 在IPVS模式下，使用iptables的扩展ipset，而不是直接调用iptables来生成规则链。
- iptables规则链是一个线性的数据结构，ipset则引入了带索引的数据结构，因此当规则很多时，也可以很高效地查找和匹配；
可以将ipset简单理解为一个IP（段）的集合，这个集合的内容可以是IP地址、IP网段、端口等，iptables可以直接添加规则对这个“可变的集合”进行操作，这样做的好处在于可以大大减少iptables规则的数量，从而减少性能损耗
kube-proxy ipvs和iptables的异同?
iptables与IPVS都是基于Netfilter实现的，但因为定位不同，二者有着本质的差别：
- iptables是为防火墙而设计的；IPVS则专门用于高性能负载均衡，并使用更高效的数据结构（Hash表），允许几乎无限的规模扩张。
与iptables相比，IPVS拥有以下明显优势：为大型集群提供了更好的可扩展性和性能；支持比iptables更复杂的复制均衡算法（最小负载、最少连接、加权等）；支持服务器健康检查和连接重试等功能；可以动态修改ipset的集合，即使iptables的规则正在使用这个集合
Kubernetes中什么是静态Pod
静态pod是由kubelet进行管理的仅存在于特定Node的Pod上，他们不能通过API Server进行管理，无法与ReplicationController、Deployment或者DaemonSet进行关联，并且kubelet无法对他们进行健康检查。
静态Pod总是由kubelet进行创建，并且总是在kubelet所在的Node上运行
Kubernetes Pod的常见调度方式
Deployment或RC：该调度策略主要功能就是自动部署一个容器应用的多份副本，以及持续监控副本的数量，在集群内始终维持用户指定的副本数量；
- NodeSelector：定向调度，当需要手动指定将Pod调度到特定Node上，可以通过Node的标签（Label）和Pod的nodeSelector属性相匹配；
- NodeAffinity亲和性调度：亲和性调度机制极大的扩展了Pod的调度能力，目前有两种节点亲和力表达：硬规则，必须满足指定的规则，调度器才可以调度Pod至Node上（类似nodeSelector，语法不同）；软规则，优先调度至满足的Node的节点，但不强求，多个优先级规则还可以设置权重值；
Taints和Tolerations（污点和容忍）：Taint：使Node拒绝特定Pod运行；Toleration：为Pod的属性，表示Pod能容忍（运行）标注了Taint的Node；
Kubernetes初始化容器（init container）
init container的运行方式与应用容器不同，它们必须先于应用容器执行完成，当设置了多个init container时，将按顺序逐个运行，并且只有前一个init container运行成功后才能运行后一个init container。
当所有init container都成功运行后，Kubernetes才会初始化Pod的各种信息，并开始创建和运行应用容器
Kubernetes deployment升级过程
初始创建Deployment时，系统创建了一个ReplicaSet，并按用户的需求创建了对应数量的Pod副本；
- 当更新Deployment时，系统创建了一个新的ReplicaSet，并将其副本数量扩展到1，然后将旧ReplicaSet缩减为2；
- 之后，系统继续按照相同的更新策略对新旧两个ReplicaSet进行逐个调整；
最后，新的ReplicaSet运行了对应个新版本Pod副本，旧的ReplicaSet副本数量则缩减为0
Kubernetes deployment升级策略
在Deployment的定义中，可以通过spec.strategy指定Pod更新的策略，
目前支持两种策略：Recreate（重建）和RollingUpdate（滚动更新）
DaemonSet资源对象会在每个Kubernetes集群中的节点上运行，并且每个节点只能运行一个pod，这是它和deployment资源对象的最大也是唯一的区别。
- 因此，在定义yaml文件中，不支持定义replicas。
它的一般使用场景如下：在去做每个节点的日志收集工作。监控每个节点的的运行状态。
Kubernetes自动扩容机制
Kubernetes使用Horizontal Pod Autoscaler（HPA）的控制器实现基于CPU使用率进行自动Pod扩缩容的功能。
HPA控制器周期性地监测目标Pod的资源性能指标，并与HPA资源对象中的扩缩容条件进行对比，在满足条件时对Pod副本数量进行调整
Kubernetes Service分发后端的策略
RoundRobin：默认为轮询模式，即轮询将请求转发到后端的各个Pod上；
SessionAffinity：基于客户端IP地址进行会话保持的模式，即第1次将某个客户端发起的请求转发到后端的某个Pod上，之后从相同的客户端发起的请求都将被转发到后端相同的Pod上；
Kubernetes Headless Service
在某些应用场景中，若需要人为指定负载均衡器，不使用Service提供的默认负载均衡的功能，或者应用程序希望知道属于同组服务的其他实例。
Kubernetes提供了Headless Service来实现这种功能，即不为Service设置ClusterIP（入口IP地址），仅通过Label Selector将后端的Pod列表返回给调用的客户端
Kubernetes外部如何访问集群内的服务
映射Pod到物理机：将Pod端口号映射到宿主机，即在Pod中采用hostPort方式，以使客户端应用能够通过物理机访问容器应用
- 映射Service到物理机：将Service端口号映射到宿主机，即在Service中采用nodePort方式，以使客户端应用能够通过物理机访问容器应用
映射Service到LoadBalancer：通过设置LoadBalancer映射到云服务商提供的LoadBalancer地址。这种用法仅用于在公有云服务提供商的云平台上设置Service的场景
Kubernetes ingress
K8s的Ingress资源对象，用于将不同URL的访问请求转发到后端不同的Service，以实现HTTP层的业务路由机制。
- K8s使用了Ingress策略和Ingress Controller，两者结合并实现了一个完整的Ingress负载均衡器。
- 使用Ingress进行负载分发时，Ingress Controller基于Ingress规则将客户端请求直接转发到Service对应的后端Endpoint（Pod）上，从而跳过kube-proxy的转发功能，kube-proxy不再起作用，
全过程为：ingress controller + ingress 规则 ——> services
Kubernetes镜像的下载策略
Always：镜像标签为latest时，总是从指定的仓库中获取镜像
- Never：禁止从仓库中下载镜像，也就是说只能使用本地镜像
IfNotPresent：仅当本地没有对应镜像时，才从目标仓库中下载；默认的镜像下载策略是：当镜像标签是latest时，默认策略是Always；当镜像标签是自定义时（也就是标签不是latest），那么默认策略是IfNotPresent
Kubernetes的负载均衡器
根据工作环境使用两种类型的负载均衡器，即内部负载均衡器或外部负载均衡器。
内部负载均衡器自动平衡负载并使用所需配置分配容器，而外部负载均衡器将流量从外部负载引导至后端容器；
Kubernetes各模块如何与API Server通信
K8s 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绑定到目标节点上
Kubernetes Scheduler作用及实现原理
Scheduler是负责Pod调度的重要功能模块，负责接收Controller Manager创建的新Pod，为其调度至目标Node，调度完成后，目标Node上的kubelet服务进程接管后继工作，负责Pod接下来生命周期；
- Scheduler的作用是将待调度的Pod，按照特定的调度算法和调度策略绑定（Binding）到集群中某个合适的Node上，并将绑定信息写入etcd中；
Scheduler通过调度算法调度为待调度Pod列表中的每个Pod从Node列表中选择一个最适合的Node来实现Pod的调度。随后，目标节点上的kubelet通过API Server监听到Kubernetes Scheduler产生的Pod绑定事件，然后获取对应的Pod清单，下载Image镜像并启动容器
Kubernetes Scheduler使用哪两种算法将Pod绑定到worker节点
预选（Predicates）：输入是所有节点，输出是满足预选条件的节点。kube-scheduler根据预选策略过滤掉不满足策略的Nodes。如果某节点的资源不足或者不满足预选策略的条件则无法通过预选
优选（Priorities）：输入是预选阶段筛选出的节点，优选会根据优先策略为通过预选的Nodes进行打分排名，选择得分最高的Node。例如，资源越富裕、负载越小的Node可能具有越高的排名
Kubernetes kubelet的作用
在Kubernetes集群中，在每个Node（又称Worker）上都会启动一个kubelet服务进程。
- 该进程用于处理Master下发到本节点的任务，管理Pod及Pod中的容器。
每个kubelet进程都会在API Server上注册节点自身的信息，定期向Master汇报节点资源的使用情况，并通过cAdvisor监控容器和节点资源
Kubernetes kubelet监控Worker节点资源是使用什么组件来实现的
kubelet使用cAdvisor对worker节点资源进行监控。
在 Kubernetes 系统中，cAdvisor 已被默认集成到 kubelet 组件内，当 kubelet 服务启动时，它会自动启动 cAdvisor 服务，然后 cAdvisor 会实时采集所在节点的性能指标及在节点上运行的容器的性能指标
Kubernetes如何保证集群的安全性
基础设施方面：保证容器与其所在宿主机的隔离；
- 用户权限：划分普通用户和管理员的角色；
- API Server的认证授权：Kubernetes集群中所有资源的访问和变更都是通过Kubernetes API Server来实现的，因此需要建议采用更安全的HTTPS或Token来识别和认证客户端身份（Authentication），以及随后访问权限的授权（Authorization）环节；
- API Server的授权管理：通过授权策略来决定一个API调用是否合法。对合法用户进行授权并且随后在用户访问时进行鉴权，建议采用更安全的RBAC方式来提升集群安全授权；
AdmissionControl（准入机制）：对kubernetes api的请求过程中，顺序为：先经过认证 & 授权，然后执行准入操作，最后对目标对象进行操作
Kubernetes准入机制
在对集群进行请求时，每个准入控制代码都按照一定顺序执行。
如果有一个准入控制拒绝了此次请求，那么整个请求的结果将会立即返回，并提示用户相应的error信息，准入控制（AdmissionControl）准入控制本质上为一段准入代码，在对kubernetes api的请求过程中，顺序为：先经过认证 & 授权，然后执行准入操作，最后对目标对象进行操作。
常用组件（控制代码）如下：AlwaysAdmit：允许所有请求；
- AlwaysDeny：禁止所有请求，多用于测试环境；
- ServiceAccount：它将serviceAccounts实现了自动化，它会辅助serviceAccount做一些事情，比如如果pod没有serviceAccount属性，它会自动添加一个default，并确保pod的serviceAccount始终存在；
- LimitRanger：观察所有的请求，确保没有违反已经定义好的约束条件，这些条件定义在namespace中LimitRange对象中；
NamespaceExists：观察所有的请求，如果请求尝试创建一个不存在的namespace，则这个请求被拒绝
Kubernetes RBAC及其特点（优势）
RBAC是基于角色的访问控制，是一种基于个人用户的角色来管理对计算机或网络资源的访问的方法，
优势：对集群中的资源和非资源权限均有完整的覆盖；
- 整个RBAC完全由几个API对象完成， 同其他API对象一样， 可以用kubectl或API进行操作；
-
Kubernetes Secret作用
Secret对象，主要作用是保管私密数据，比如密码、OAuth Tokens、SSH Keys等信息。
将这些私密信息放在Secret对象中比直接放在Pod或Docker Image中更安全，也更便于使用和分发
Kubernetes Secret有哪些使用方式
在创建Pod时，通过为Pod指定Service Account来自动使用该Secret
- 通过挂载该Secret到Pod来使用它
在Docker镜像下载时使用，通过指定Pod的spc.ImagePullSecrets来引用它
Kubernetes PodSecurityPolicy机制
Kubernetes PodSecurityPolicy是为了更精细地控制Pod对资源的使用方式以及提升安全策略。
在开启PodSecurityPolicy准入控制器后，Kubernetes默认不允许创建任何Pod，需要创建PodSecurityPolicy策略和相应的RBAC授权策略（Authorizing Policies），Pod才能创建成功
Kubernetes PodSecurityPolicy机制能实现哪些安全策略
特权模式：privileged是否允许Pod以特权模式运行
- 宿主机资源：控制Pod对宿主机资源的控制，如hostPID：是否允许Pod共享宿主机的进程空间
- 用户和组：设置运行容器的用户ID（范围）或组（范围）
- 提升权限：AllowPrivilegeEscalation：设置容器内的子进程是否可以提升权限，通常在设置非root用户（MustRunAsNonRoot）时进行设置
-
Kubernetes网络模型
Kubernetes网络模型中每个Pod都拥有一个独立的IP地址，不管它们是否运行在同一个Node（宿主机）中，都要求它们可以直接通过对方的IP进行访问；
- 同时为每个Pod都设置一个IP地址的模型使得同一个Pod内的不同容器会共享同一个网络命名空间，也就是同一个Linux网络协议栈。
这就意味着同一个Pod内的容器可以通过localhost来连接对方的端口；在Kubernetes的集群里，IP是以Pod为单位进行分配的。一个Pod内部的所有容器共享一个网络堆栈
Kubernetes CNI模型
Kubernetes CNI模型是对容器网络进行操作和配置的规范，通过插件的形式对CNI接口进行实现。
- CNI仅关注在创建容器时分配网络资源，和在销毁容器时删除网络资源。
- 容器（Container）：是拥有独立Linux网络命名空间的环境，例如使用Docker或rkt创建的容器。容器需要拥有自己的Linux网络命名空间，这是加入网络的必要条件；
网络（Network）：表示可以互连的一组实体，这些实体拥有各自独立、唯一的IP地址，可以是容器、物理机或者其他网络设备（比如路由器）等
Kubernetes网络策略
为实现细粒度的容器间网络访问隔离策略，K8s引入Network Policy主要功能是对Pod间的网络通信进行限制和准入控制，设置允许访问或禁止访问的客户端Pod列表。
Network Policy定义网络策略，配合策略控制器（Policy Controller）进行策略的实现Kubernetes网络策略原理
Network Policy的工作原理主要为：policy controller需要实现一个API Listener，监听用户设置的Network Policy定义，并将网络访问规则通过各Node的Agent进行实际设置（Agent则需要通过CNI网络插件实现）
Kubernetes中flannel的作用
它能协助Kubernetes，给每一个Node上的Docker容器都分配互相不冲突的IP地址；
它能在这些IP地址之间建立一个覆盖网络（Overlay Network），通过这个覆盖网络，将数据包原封不动地传递到目标容器内
Kubernetes Calico网络组件实现原理
Calico是一个基于BGP的纯三层的网络方案，与OpenStack、Kubernetes、AWS、GCE等云平台都能够良好地集成，Calico在每个计算节点都利用Linux Kernel实现了一个高效的vRouter来负责数据转发。每个vRouter都通过BGP协议把在本节点上运行的容器的路由信息向整个Calico网络广播，并自动设置到达其他节点的路由转发规则；Calico保证所有容器之间的数据流量都是通过IP路由的方式完成互联互通的
Calico节点组网时可以直接利用数据中心的网络结构（L2或者L3），不需要额外的NAT、隧道或者Overlay Network，没有额外的封包解包，能够节约CPU运算，提高网络效率
Kubernetes共享存储的作用
Kubernetes对于有状态的容器应用或者对数据需要持久化的应用，因此需要更加可靠的存储来保存应用产生的重要数据，以便容器应用在重建之后仍然可以使用之前的数据。因此需要使用共享存储
Kubernetes PV 和 PVC
PV是对底层网络共享存储的抽象，将共享存储定义为一种“资源”
-
Kubernetes PV生命周期内的阶段
Available：可用状态，还未与某个PVC绑定；
- Bound：已与某个PVC绑定；
- Released：绑定的PVC已经删除，资源已释放，但没有被集群回收；
-
Kubernetes CSI模型
CSI是Kubernetes推出与容器对接的存储接口标准，存储提供方只需要基于标准接口进行存储插件的实现，就能使用Kubernetes的原生存储机制为容器提供存储服务，CSI使得存储提供方的代码能和Kubernetes代码彻底解耦，部署也与Kubernetes核心组件分离；
CSI包括CSI Controller：的主要功能是提供存储服务视角对存储资源和存储卷进行管理和操作；Node的主要功能是对主机（Node）上的Volume进行管理和操作
Kubernetes Worker节点加入集群的过程
在该Node上安装Docker、kubelet和kube-proxy服务； 然后配置kubelet和kubeproxy的启动参数，将Master URL指定为当前Kubernetes集群Master的地址，最后启动这些服务； 通过kubelet默认的自动注册机制，新的Worker将会自动加入现有的Kubernetes集群中； Kubernetes Master在接受了新Worker的注册之后，会自动将其纳入当前集群的调度范围
Kubernetes Pod如何实现对节点的资源控制?
Kubernetes集群里的节点提供的资源主要是计算资源，计算资源是可计量的能被申请、分配和使用的基础资源。当前Kubernetes集群中的计算资源主要包括CPU、GPU及Memory。
CPU与Memory是被Pod使用的，因此在配置Pod时可以通过参数CPU Request及Memory Request为其中的每个容器指定所需使用的CPU与Memory量，Kubernetes会根据Request的值去查找有足够资源的Node来调度此Pod；
Kubernetes Requests和Limits如何影响Pod的调度
当一个Pod创建成功时，Kubernetes调度器（Scheduler）会为该Pod选择一个节点来执行。对于每种计算资源（CPU和Memory）而言，每个节点都有一个能用于运行Pod的最大容量值。调度器在调度时，首先要确保调度后该节点上所有Pod的CPU和内存的Requests总和，不超过该节点能提供给Pod使用的CPU和Memory的最大容量值；
Kubernetes Metric Service
在Kubernetes从1.10版本后采用Metrics Server作为默认的性能数据采集和监控，主要用于提供核心指标（Core Metrics），包括Node、Pod的CPU和内存使用指标。
对其他自定义指标（Custom Metrics）的监控则由Prometheus等组件来完成
Kubernetes中，如何使用EFK实现日志的统一管理
在Kubernetes集群环境中，通常一个完整的应用或服务涉及组件过多，建议对日志系统进行集中化管理，EFK是 Elasticsearch、Fluentd 和 Kibana 的组合，
- Elasticsearch：是一个搜索引擎，负责存储日志并提供查询接口；
- Fluentd：负责从 Kubernetes 搜集日志，每个node节点上面的fluentd监控并收集该节点上面的系统日志，并将处理过后的日志信息发送给Elasticsearch；
Kibana：提供了一个 Web GUI，用户可以浏览和搜索存储在 Elasticsearch 中的日志
Kubernetes如何进行优雅的节点关机维护?
由于Kubernetes节点运行大量Pod，因此在进行关机维护之前，建议先使用kubectl drain将该节点的Pod进行驱逐，然后进行关机维护
Kubernetes集群联邦?
Kubernetes集群联邦可以将多个Kubernetes集群作为一个集群进行管理。因此，可以在一个数据中心/云中创建多个Kubernetes集群，并使用集群联邦在一个地方控制/管理所有集群
Helm及其优势
Helm 是 Kubernetes 的软件包管理工具，Helm能够将一组K8s资源打包统一管理, 是查找、共享和使用为Kubernetes构建的软件的最佳方式。
Helm中通常每个包称为一个Chart，一个Chart是一个目录，优势：统一管理、配置和更新这些分散的 K8s 的应用资源文件；
- 分发和复用一套应用模板；
- 将应用的一系列资源当做一个软件包管理；
- 对于应用发布者而言，可以通过 Helm 打包应用、管理应用依赖关系、管理应用版本并发布应用到软件仓库；
对于使用者而言，使用 Helm 后不用需要编写复杂的应用部署文件，可以以简单的方式在 Kubernetes 上查找、安装、升级、回滚、卸载应用程序；
标签与标签选择器的作用
标签可以附加在kubernetes任何资源对象之上的键值型数据，常用于标签选择器的匹配度检查，从而完成资源筛选
标签选择器用于表达标签的查询条件或选择标准，Kubernetes API目前支持两个选择器：基于等值关系（equality-based）的标签选项器以及基于集合关系（set-based）的标签选择器
什么是Google容器引擎?
Google Container Engine（GKE）是Docker容器和集群的开源管理平台。这个基于 Kubernetes的引擎仅支持在Google的公共云服务中运行的群集；
image的状态有那些？
Running：Pod所需的容器已经被成功调度到某个节点，且已经成功运行；
- Pending：APIserver创建了pod资源对象，并且已经存入etcd中，但它尚未被调度完成或者仍然处于仓库中下载镜像的过程；
Unknown：APIserver无法正常获取到pod对象的状态，通常是其无法与所在工作节点的kubelet通信所致
Service资源对象的作用
Service就是将多个POD划分到同一个逻辑组中，并统一向外提供服务，POD是通过Label Selector加入到指定的service中。
Service相当于是一个负载均衡器，用户请求会先到达service，再由service转发到它内部的某个POD上，通过 services.spec.type 字段来指定：ClusterIP：用于集群内部访问。该类型会为service分配一个IP，集群内部请求先到达service，再由service转发到其内部的某个POD上；
- NodePort：用于集群外部访问。该类型会将Service的Port映射到集群的每个Node节点上，然后在集群之外，就能通过Node节点上的映射端口访问到这个Service；
- LoadBalancer：用于集群外部访问。该类型是在所有Node节点前又挂了一个负载均衡器，作为集群外部访问的统一入口，外部流量会先到达LoadBalancer，再由它转发到集群的node节点上，通过nodePort再转发给对应的service，最后由service转发到后端Pod中；
- ExternalName：创建一个DNS别名（即CNAME）并指向到某个Service Name上，也就是为某个Service Name添加一条CNAME记录，当有请求访问这个CNAME时会自动解析到这个Service Name上
常用的标签分类有哪些?
答：release（版本）：stable（稳定版）、canary（金丝雀版本）、beta（测试版本）、environment（环境变量）：dev（开发）、qa（测试）、production（生产）、application（应用）：ui、as（application software应用软件）、pc、sc、tier（架构层级）：frontend（前端）、backend（后端）、cache（缓存）、partition（分区）：customerA（客户A）、customerB（客户B）、track（品控级别）：daily（每天）、weekly（每周）；
Job资源对象
- Job控制一组Pod容器，可以通过Job这种资源对象定义并启动一个批处理任务的Job，其中Job所控制的Pod副本是短暂运行的，可以将其视为一组Docker容器，每个Docker容器都仅仅运行一次，当Job控制的所有Pod的副本都运行结束时，对应的Job也就结来。
- Job生成的副本是不能自动重启的，对应的Pod副本的RestartPolicy都被设置为Never。
-
K8s是怎么进行服务注册的
Service创建的时候会向 API Server 用 POST 方式提交一个新的 Service定义，这个请求需要经过认证、鉴权以及其它的准入策略检查过程之后才会放行
- CoreDns会为Service创建一个dns记录，Service 得到一个 ClusterIP（虚拟 IP 地址），并保存到集群数据仓库
-
Kubernetes与Docker Swarm的区别如何
安装和部署：K8s安装很复杂；但是一旦安装完毕，集群就非常强大，Docker Swarm安装非常简单；但是集群不是很强大
- 图形用户界面：K8s有，Docker Swarm无
- 可伸缩性：K8s支持，Docker Swarm 比 K8s 快5倍
- 自动伸缩：K8s有，Docker Swarm无
- 负载均衡：K8s在不同的Pods中的不同容器之间平衡负载流量，需要手动干预，Docker Swarm可以自动平衡集群中容器之间的流量
- 滚动更新回滚：K8s支持，Docker Swarm可以部署滚动更新，但不能自动回滚
- 数据量：K8s可以共享存储卷。只能与其他集装箱在同一Pod，Docker Swarm可以与任何其他容器共享存储卷
日志记录和监控：K8s内置的日志和监控工具，Docker Swarm要用第三方工具进行日志记录和监控
什么是Container Orchestration?
资源编排 - 负责资源的分配，如限制 namespace 的可用资源，scheduler 针对资源的不同调度策略；
- 工作负载编排 - 负责在资源之间共享工作负载，如 Kubernetes 通过不同的 controller 将 Pod 调度到合适的 node 上，并且负责管理它们的生命周期；
服务编排 - 负责服务发现和高可用等，如 Kubernetes 中可用通过 Service 来对内暴露服务，通过 Ingress 来对外暴露服务；容器编排常用的控制器有：Deployment 经常被作为无状态实例控制器使用; StatefulSet 是一个有状态实例控制器; DaemonSet 可以指定在选定的 Node 上跑，每个 Node 上会跑一个副本，它有一个特点是它的 Pod 的调度不经过调度器，在 Pod 创建的时候就直接绑定 NodeName；最后一个是定时任务，它是一个上级控制器，和 Deployment 有些类似，当一个定时任务触发的时候，它会去创建一个 Job ，具体的任务实际上是由 Job 来负责执行的；
什么是Heapster
Heapster 是 K8s 原生的集群监控方案。
Heapster 以 Pod 的形式运行，它会自动发现集群节点、从节点上的 Kubelet 获取监控数据。Kubelet 则是从节点上的 cAdvisor 收集数据；
K8s Architecture的不同组件有哪些
主要有两个组件 – 主节点和工作节点。
- 主节点具有kube-controller-manager，kube-apiserver，kube-scheduler等组件。
-
Kubernetes中主节点的工作情况
主节点是集群控制节点，负责集群管理和控制，包含：
apiserver：rest接口，资源增删改查入口
- controller-manager：所有资源对象的控制中心
- scheduler：负责资源调度，例如pod调度
-
kube-apiserver和kube-scheduler的作用
kube-apiserver：rest接口，增删改查接口，集群内模块通信
kube-scheduler：将待调度的pod按照调度算法绑定到合适的pod，并将绑定信息写入etcd
Kubernetes控制管理器
Kubernetes控制管理器是集群内部的控制中心，负责node、pod、namespace等管理，控制管理器负责管理各种控制器，每个控制器通过api server监控资源对象状态，将现有状态修正到期望状态
Kubernetes有哪些不同类型的服务
ClusterIP
- NodePort
- LoadBalancer
-
Kubernetes的负载均衡器
内部负载均衡器：自动平衡负载并使用所需配置分配容器
-
使用Kubernetes时可以采取哪些最佳安全措施?
确保容器本身安全
- 锁定容器的Linux内核
- 使用基于角色的访问控制（RBAC）
- 保守秘密的辛勤工作
- 保持网络安全
若有收获，就点个赞吧
0 人点赞
