docker和k8s

发布于:2025-02-27 ⋅ 阅读:(14) ⋅ 点赞:(0)

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集群提供了容器化应用的运行环境。

4. k8s创建pod的流程