目录
十一.docker&k8s
11.1 docker的核心原理
11.2docker的⽹络模式有哪些，默认是⽹络模式是什么
Docker网络模式设置说明host模式–net=host容器和宿主机共享Network namespace。容器的其他方面，如文件体系、历程列表等照旧和宿主机隔离的。网络性能比较好，但是docker host上已经使用的端口就不能再用了，网络的隔离性欠好container模式–net=container:NAME_or_ID容器和另外一个容器共享Network namespace。 kubernetes中的pod就是多个容器共享一个Network namespace。文件体系、历程列表等照旧隔离的。两个容器的历程可以通过lo网卡装备通信（127.0.0.1）none模式–net=none容器有独立的Network namespace，但并没有对其进行任何网络设置，如分配veth pair 和网桥连接，设置IP等。没有办法联网，封闭的网络能保证容器的安全性。bridge模式–net=bridge（默认为该模式）11.3 dockerfile怎样部署⼀个项⽬
1.编写Dockerfile- [root@docker-server nginx]# vim Dockerfile
- FROM centos:7
- MAINTAINER hugo 2763743788@qq.com
- RUN yum install -y vim wget tree lrzsz gcc gcc-c++ automake pcre pcre-devel zlib zlib-devel openssl openssl-devel iproute net-tools iotop
- ADD nginx-1.20.1.tar.gz /usr/local/src/
- RUN cd /usr/local/src/nginx-1.20.1 \
- && ./configure --prefix=/usr/local/nginx --with-http_sub_module \
- && make \
- && make install \
- && cd /usr/local/nginx
- && rm -rf /usr/local/src/nginx-1.20.1* # 清理源代码和压缩包以节省空间
- # ADD nginx.conf /usr/local/nginx/conf/nginx.conf
- RUN useradd -s /sbin/nologin nginx \
- && ln -sv /usr/local/nginx/sbin/nginx /usr/sbin/nginx \
- && echo 'test nginx !' > /usr/local/nginx/html/index.html
- EXPOSE 80 443
- CMD ["nginx", "-g", "daemon off;"]
2.构建Docker镜像- [root@docker-server nginx]# docker build -t nginx:v1 .
- [root@docker-server nginx]# docker images | grep v1
- nginx v1 fbd06c1753c0 8 seconds ago 581MB
- [root@docker-server nginx]# docker run -d -it -p 80:80 nginx:v1
11.5 dockerfile与docker-compose区别
- Dockerfile：主要用于定义单个容器镜像的创建过程，确保镜像的一致性和可重复性。
- Docker-Compose：主要用于定义和协调多个容器服务的部署和服务之间的依靠，简化多容器应用的管理和部署流程。
两者团结使用，可以实现从单个服务的构建到整个多服务应用部署的全链条自动化，是当代容器化应用开辟和部署中不可或缺的工具。
11.6 Dockerfile中的cmd和run的区别
RUN指令在构建镜像的过程中执行。每当Dockerfile被用来构建镜像时，RUN指令指定的命令都会在构建环境中执行，主要用于安装软件包、下载文件、编译应用等，以便为镜像创建所需的文件体系更改。每次RUN执行后，都会创建一个新的镜像层。因此，如果大概的话，最好将多个命令合并为一个RUN指令，以减少镜像的层数和大小。
CMD指令在容器启动时执行。当使用docker run命令运行一个容器时，如果docker run后面没有跟任何额外的命令，那么CMD中指定的命令就会在容器的主历程中执行，主要目的是为容器提供默认的执行命令。它告诉容器在启动时应该运行什么步调。
11.7 docker与虚拟机有何不同
Docker：
- 基于操作体系级别的虚拟化，使用容器来运行应用步调。
- 共享体系的内核，容器之间相互隔离。
- 容器运行在宿主机的操作体系之上，不需要启动独立的操作体系实例。
- 启动速度快,资源开销小
- 更得当需要快速部署和高效资源使用的场景。
- 使用卷（Volumes）和绑定挂载（Bind Mounts）来管理存储，机动但需要额外设置。
- 网络设置相对简朴，默认情况下容器共享宿主机的网络堆栈，但也可以设置独立的网络模式
虚拟机：
- 基于硬件级别的虚拟化，使用 Hypervisor（如 VMware、Hyper-V、KVM 等）来管理虚拟机。
- 每个虚拟机运行一个完整的操作体系,与宿主机操作体系完全独立。
- 启动速度慢,资源开销大，由于有额外的虚拟化层（Hypervisor）
- 适用于运行不同操作体系的场景、多租户环境、需要高度隔离的应用、传统的企业应用部署等。
更得当需要完整操作体系环境的场景。
- 有独立的虚拟硬盘，存储管理较为简朴但不敷机动。
- 网络设置较为复杂，可以通过虚拟网络接口、虚拟互换机等实现复杂的网络拓扑。
11.8 docker容器的几种状态
created（已创建）
restarting（重启中）
running（运行中）
removing（迁移中）
paused（暂停）
exited（制止）
dead（殒命）
11.9 docker的三大组件之间的关系
堆栈是存储镜像的地方，镜像是创建容器的模板，而容器则是镜像运行时的实例
11.10 Docker file中的命令COPY和ADD命令有什么区别
- COPY：仅支持基本的文件复制操作，它将指定的文件或目录从构建上下文复制到镜像中指定的路径。它不会执行任何额外的处理，如不会解压缩或长途下载。
- ADD：除了具有COPY的全部功能外，ADD还更为强大和机动。它可以自动解压缩压缩文件（如.tar、.zip等），大概在构建过程中从URL下载文件并添加到镜像中。
在大多数情况下，如果只需要复制文件而不涉及解压缩或下载，推荐使用COPY指令，由于它更简朴且构建缓存效率更高。
如果需要在构建过程中解压缩文件或从长途URL添加文件，那么ADD指令是更合适的选择。然而，考虑到安全性和可维护性，建议尽大概制止使用ADD从长途URL下载文件，而是使用COPY和RUN（或其他命令）的组合来实现相同的功能。
11.11 Docker的优缺点
Docker的优点
- 轻量级
- 可移植性
- 快速启动和关闭
- 提高开辟效率
- 简化部署和管理
- 资源使用率高
- 良好的隔离性
- 可扩展性强
- Docker容器可以很容易地进行水平扩展，可以根据需求快速添加或删除容器，以适应不同的负载情况。
- 环境一致性
- Docker容器可以确保开辟、测试和生产环境的一致性，从而减少由于环境差异引起的题目。
- 支持微服务架构
- Docker容器提供了一种简朴的方式来构建和部署微服务，通过将各个服务拆分为独立的容器，可以实现更好的可伸缩性和可维护性。
Docker的缺点
- 资源消耗
- Docker镜像的体积较大，大概会占用较多的磁盘空间。此外，每个镜像的运行都需要一个额外的Docker运行时环境，会占用肯定的内存和CPU资源。如果服务器资源有限，大概会导致性能压力。
- 镜像构建和网络传输较慢
- Docker镜像构建是从一个基础镜像开始，逐步构建所需的环境和依靠。
- 难以维护和管理
- 当应用的规模逐渐增大，涉及到多个镜像的组合和协作时，Docker容器的维护和管理大概变得复杂。需要考虑容器之间的依靠关系、服务发现和负载均衡等题目。
- 安全性题目
- 它们与宿主机共享相同的内核。如果容器设置不当或存在漏洞，大概会对整个宿主机造成影响。
11.12 Docker容器意外退出，怎样盘查和处理
查看容器退出状态
- docker ps -a --filter "exited = 0"
- docker logs [container_name(或容器ID)]
- docker inspect --format='{{json .State.Health}}' [container_name]
linux:/var/log/messages或/var/log/syslog
windows:Event Viewer
进入容器进行排查
- docker exec -it [container_name] /bin/bash
- docker top [container_name]
- docker stats [container_name]
- docker inspect [container_name]
搭过
首先，我会为我的应用编写一个Dockerfile。Dockerfile是一个文本文件，包含了从基础镜像开始到运行应用所需的全部命令
使用Dockerfile，我可以通过运行docker build命令来构建我的Docker镜像。
构建完镜像后，我可以使用docker run命令来运行一个容器实例
随着应用的运行，我大概会需要管理我的容器，比如查看正在运行的容器、制止或删除容器等。此外，如果我的应用需要扩展，我可以使用Docker Compose或Kubernetes等工具来编排和管理多个容器
11.14 控制平面和工作平面区别,分别包含哪些组件
控制平面（Control Plane）工作平面（Data Plane）定义与功能Kubernetes的大脑，负责集群的团体管理和协调，提供API服务，运行控制器和调度器。包含全部容器和应用步调的节点，通过与控制平面交互实现部署、扩展和管理。关键组件API Server, etcd, kube-controller-manager, kube-schedulerNode, kubelet, kube-proxy, 容器运行时职责决策和全局控制，维护集群状态和数据一致性。运行容器化应用步调，响应控制平面的指令，管理节点上的资源和网络。11.15 各个组件的原理详解
（标注：根据集群大小，主组件在呆板上托管或分布）
kube-apiserver
kube-apiserver 是 Kubernetes 的核心组件之一，作为全部 REST 操作的前端。它处理全部的 API 请求并更新 etcd 存储的数据。通过 kube-apiserver，用户可以与 Kubernetes 集群进行交互，包括部署应用步调、查询集群状态和管理资源等。API 服务器的计划支持水平扩展，即可以通过部署多个实例来提高性能和容错能力。
etcd
etcd 是一个高可用的键值存储，用于保存 Kubernetes 的全部集群数据。它是 Kubernetes 的后台数据库，存储了集群的状态信息、设置数据和元数据。etcd 提供了一致性和高可用性，确保集群数据的持久性和可靠性。由于 etcd 存储了关键的数据，因此备份等数据掩护步调非常告急。
kube-scheduler
kube-scheduler 负责为新创建的 Pods 选择合适的节点进行运行。它根据资源需求、调度计谋和集群状态等因素，决定 Pods 的分配。调度器会考虑节点的资源使用情况、Pod 的亲和性和反亲和性、数据位置等条件，以优化资源的使用和满足应用的要求。
kube-controller-manager
kube-controller-manager 运行控制器历程，负责管理集群的状态。每个控制器都负责特定的任务，如节点状态监控、Pod 的创建和管理、服务的维护等。虽然每个控制器在逻辑上是独立的，但它们被编译到一个单独的可执行文件中，以简化管理和维护。主要控制器包括：
节点控制器（Node Controller）：负责处理节点故障的通知和响应。
任务控制器（Job Controller）：管理一次性任务的执行，确保 Job 对象下的 Pods 被正确创建和运行。
端点分片控制器（EndpointSlice Controller）：管理 Service 和 Pod 之间的链接。
服务账号控制器（ServiceAccount Controller）：为新的定名空间创建默认服务账号。
cloud-controller-manager
负责与云提供商的 API 进行交互。它将集群的管理与云平台的特定操作分离开来，允许 Kubernetes 集群与云环境集成。主要控制器包括：
节点控制器（Node Controller）：用于检测和处理云环境中节点的终止和删除。
路由控制器（Route Controller）：设置云基础设施中的路由。
服务控制器（Service Controller）：管理云提供商的负载均衡器的创建、更新和删除。
节点组件（Node Components）
节点组件运行在每个集群节点上，负责容器的实际执行和管理。
kubelet
kubelet 是每个节点上的核心组件，负责确保容器在 Pod 中运行并保持康健。它从 API 服务器获取 PodSpec，并确保容器按照这些规格运行。kubelet 监控容器的状态，并向 API 服务器报告节点的状态。kubelet 不管理非 Kubernetes 创建的容器。
kube-proxy
kube-proxy 是集群中的网络代理，负责实现 Kubernetes 服务的网络功能。它维护节点上的网络规则，支持服务的负载均衡和网络转发。kube-proxy 可以使用操作体系的数据包过滤层，也可以通过流量转发实现网络规则，确保 Pod 之间的网络通信顺畅。
容器运行时（Container Runtime）
容器运行时 是 Kubernetes 运行容器的基础组件，管理容器的执行和生命周期。支持的容器运行时包括 containerd、CRI-O 和 Kubernetes CRI 的其他实现。容器运行时负责启动和制止容器，并处理容器的资源管理和监控。
插件（Addons）
插件是扩展 Kubernetes 集群功能的组件，通常运行在 kube-system 定名空间中。它们提供额外的功能和服务，使集群更加全面和机动。
DNS
集群 DNS 是几乎全部 Kubernetes 集群都需要的插件。它为 Kubernetes 服务提供 DNS 记录，使得服务可以通过 DNS 名称进行访问。容器启动时会自动将集群 DNS 服务器包含在其 DNS 搜刮列表中，简化了服务的发现和访问。
Web 界面（仪表盘）
Kubernetes Dashboard 是一个基于 Web 的用户界面，允许用户管理集群和应用步调，并进行故障排除。Dashboard 提供了集群状态的可视化展示，简化了集群的管理操作。
容器资源监控
容器资源监控 插件将容器的时间序列度量值保存到集中数据库中，并提供数据欣赏界面。它帮助用户监控容器的性能和资源使用情况，便于进行优化和故障排查。
集群层面日记
集群层面日记 插件负责将容器的日记数据集中存储，提供搜刮和欣赏接口。通过集中日记存储，用户可以轻松查看和分析日记，支持故障排除和体系监控。
网络插件
网络插件 实现容器网络接口（CNI）规范，负责为 Pod 分配 IP 地址并实现 Pod 之间的网络通信。网络插件确保集群内的网络功能正常运行，为应用提供稳定的网络支持。
11.16 创建一个pod的流程
- 用户通过kubectl或其他api客户端提交pod spec给api server
- api server实验着将pod对象的相关信息存入etcd中，待写入操作执行完成，api server即会返回确认信息至客户端
- api server开始反应etcd中的状态变化
- 全部的kubernetes组件均使用watch机制来跟踪检查api server上的相关的变动
- kube-scheduler（调度器）通过其watch觉察到api server创建了新的pod对象但尚未绑定至任何工作节点
- kube-scheduler为pod对象挑选一个工作节点并将结果信息更新至api server
- 调度结果信息由api server更新至etcd存储体系中，而且api server也开始反映此pod对象的调度结果
- pod被调度到的目标工作节点上的kubelet实验在当前节点上调用docker启动容器，并将容器的结果状态回送至api server
- api server将pod状态信息存入etcd中
- 在etcd确认写入操作乐成完成之后，api server将确认信息发送至相关的kubelet事件将通过它被接收
11.17 删除一个pod的流程
- 用户发送删除pod对象的命令
- api服务器中的pod对象会随着事件的推移而更新，在脱期期内（默认为30秒），pod被视为“dead”
- 将pod标记为terminating状态
- （与第三步同时运行）kubelet在监控到pod对象转为“Terminating”状态的同时启动Pod关闭过程
- （与第三步同时运行）端点控制器监控到pod对象的关闭行为时将其从全部匹配到此端点的service资源的端点列表中移除
- 如果当前Pod对象定义了preStop钩子处理器，则在其标记为“terminating”后即会以同步的方式启动执行；如若脱期期结束后，preStop仍未执行结束，则第2步会被重新执行并额外获取一个时长为2秒的小脱期期。
- Pod对象中的容器历程收到TERM信号。
- 脱期期结束后，若存在任何一个仍在运行的历程，那么Pod对象即会收到SIGKILL信号
- Kubelet请求API Server将此Pod资源的脱期期设置为0从而完成删除操作，它变得对用户不再可见。
11.18 什么是k8s控制器
Kubernetes（k8s）的控制器包括：
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。 |
