docker和k8s

1. docker的几种网络模式

1.1. bridge 模式（默认）

container有自己的ip，它的ip映射到主机的docker0这个虚拟网卡上，它们能访问外网，外网不能访问它们（外网要访问，可以加通过端口映射，将容器端口映射到主机端口上）。

原理：当 Docker 守护进程启动时，会在主机上创建一个名为docker0的虚拟网桥。容器在使用bridge模式时，会创建一对虚拟网卡，一端在容器内，通常命名为eth0；另一端在主机的docker0网桥上。容器通过docker0网桥与外部网络通信，主机充当容器与外部网络之间的桥梁。
特点：
- 容器拥有独立的 IP 地址，默认情况下，容器可以访问外部网络，但外部网络不能直接访问容器，需要通过端口映射（-p或--publish参数）将容器端口映射到主机端口。
- 不同容器之间可以通过 IP 地址进行通信，它们处于同一个子网中。
适用场景：适用于大多数需要网络隔离和独立 IP 地址的场景，如开发和测试环境中，不同的应用容器可以在bridge模式下独立运行，通过端口映射对外提供服务。

1.2. host模式

container直接使用主机的ip和端口，但注意不能使用已经被占用了的端口。所以同一个主机上，可以启动多个host模式的container，这些container的ip都一样，但端口不能一样，不然会报端口冲突。主机能访问外网，container就能访问；外网能访问主机，外网就能访问container。

原理：容器直接使用主机的网络栈，即容器与主机共享网络命名空间。容器的 IP 地址、端口等网络配置与主机相同，容器内看到的网络环境和主机上看到的完全一样。
特点：
- 容器没有独立的网络栈，网络性能较好，因为不需要进行网络地址转换（NAT）和端口映射。
- 由于容器与主机共享网络，容器内的端口不能与主机上已使用的端口冲突。
适用场景：适用于对网络性能要求较高，且不需要网络隔离的场景，如一些监控类容器，需要直接访问主机的网络接口来收集网络数据。

1.3. none模式

没有网络的模式。

原理：容器拥有自己的网络命名空间，但没有为其配置任何网络接口，即容器完全与外部网络隔离，没有可用的网络连接。
特点：
- 容器处于一个完全封闭的网络环境中，适合那些不需要网络访问的应用，如一些只进行本地文件处理的容器。
- 如果需要为容器提供网络连接，需要手动为其添加网络接口。
适用场景：适用于对安全性要求极高，不允许容器与外部网络有任何通信的场景，或者需要自定义网络配置的场景。

1.4. overlay模式

多个主机上的container之间，创建一个虚拟网络，使得它们像是在同一个局域网中一样。

原理：用于在多个 Docker 主机之间创建一个虚拟的网络，使得不同主机上的容器可以像在同一个局域网中一样进行通信。它基于 VXLAN（虚拟可扩展局域网）等技术，在物理网络之上构建一个逻辑网络。
特点：
- 支持跨主机的容器通信，方便构建分布式应用。
- 需要使用 Docker Swarm 或 Kubernetes 等集群管理工具来进行配置和管理。
适用场景：适用于大规模的容器集群环境，如在多个数据中心或云主机上部署的分布式应用，通过overlay网络可以实现容器之间的无缝通信。

2. k8s的几种service

|--------------|-------------|--------------------|-------------|--------------------|
| 类型 | 访问范围 | 典型使用场景 | 网络层级 | 依赖资源 |
| ClusterIP | 集群内部 | 微服务间通信（如前端调用后端API） | 四层（TCP/UDP） | 无需额外资源 |
| NodePort | 集群外通过节点IP访问 | 开发测试环境、临时外部访问 | 四层 | 节点防火墙需开放端口 |
| LoadBalancer | 公网访问 | 生产环境暴露Web服务 | 四层 | 云厂商负载均衡器(如AWS ELB) |
| ExternalName | 集群内部 | 集成外部服务（如云数据库） | DNS层 | 外部DNS记录 |

3. k8s有哪些核心组件

3.1. 控制平面组件(master)

管理集群的整体状态：

1. kube-apiserver

负责处理接受请求的工作，是Kubernetes控制平面的前端。

对请求进行认证、授权和准入控制，确保只有经过授权的用户或组件才能对集群资源进行操作，保证集群的安全性和稳定性。

支持水平扩缩。可以运行kube-apiserver的多个实例，并在这些实例之间平衡流量。

2. kube-scheduler

查找尚未绑定到节点的Pod，并将每个Pod分配给合适的节点。

3. kube-controller-manager

由多个控制器组成，每个控制器负责维护集群中特定资源的状态。例如，Replication Controller确保指定数量的 Pod 副本始终在运行；Node Controller监控节点的状态，当节点出现故障时进行相应处理。

保证集群的状态与用户定义的期望状态一致，实现集群的自动化管理和自我修复。

4. etcd

是一个高可用的键值存储系统，用于存储k8s集群的所有配置数据和状态信息，如Pod、Service、Deployment等资源的定义和当前状态。

作用：为 Kubernetes 集群提供数据持久化和一致性保证，是集群正常运行的基础数据存储。当某个组件需要获取或更新集群状态时，会从 etcd 中读取或写入数据。

3.2. Node 组件

在每个节点上运行，维护运行的 Pod 并提供 Kubernetes 运行时环境。

1. kubelet

作为节点上的主要代理，负责与控制平面通信，接收和执行控制平面发送的指令。它会根据指令创建、启动、停止Pod及其包含的容器，并监控容器的状态和资源使用情况。

2. kube-proxy

实现服务发现和负载均衡。

它在每个节点上运行，负责将到达Service的流量转发到后端的 Pod 上。通过在节点上设置网络规则（如 iptables 或 ipvs），确保服务的可访问性。

为集群内的服务提供统一访问入口。客户端可通过Service名称和端口访问后端的Pod，无需关心具体Pod的IP地址。

3. 容器运行时（Container Runtime）

负责运行容器。接收kubelet的指令，下载容器镜像，并在节点上创建和运行容器。

是容器运行的基础，为Kubernetes集群提供了容器化应用的运行环境。