什么是Overlay网络, 用于解决什么问题 ?
Overlay网络通过在现有网络之上创建一个虚拟网络层, 解决不同主机的容器之间相互通信的问题
如果没有Overlay网络,实现跨主机的容器通信通常需要以下方法:
- 端口映射
- 使用宿主机网络模式
这些方法牺牲了容器网络隔离的优势, 并且可能导致端口冲突问题
以下搭建一个简易的Docker Swarm 集群(一主一从), 探究 Overlay 网络下不同节点上的容器间互相通信的原理
在 Docker 中,默认情况下容器无法直接与外部网络通信。 为了使外部网络能够访问容器内的服务,Docker 提供了端口映射功能,通过将宿主机的端口映射到容器内的端口,外部可以通过宿主机的IP和端口访问容器内的服务
以下通过动手演示, 安装一个Flask容器, 解释端口映射从外部访问容器的原理
1 | . |
Dockerfile
1 | FROM rockylinux:9.3 |
app.py
1 | from flask import Flask |
构建镜像
1 | docker build -t flask-app:1.0 . |
启动容器, 进行端口映射
1 | docker run -d -p 80:5000 flask-app:1.0 |
从外部访问 (192.168.52.203是我的虚拟机IP)
1 | # curl 192.168.52.203 |
Docker 多阶段构建是一种通过在单个 Dockerfile 中定义多个构建阶段的技术。 每个阶段可以使用不同的基础镜像和依赖项,允许开发人员在构建过程中分离应用程序的编译环境与运行环境。 最终生成的镜像只包含运行应用程序所需的文件,而无需携带编译工具链或其他不必要的依赖
通过多阶段构建,可以有效减少镜像体积,提升部署效率
下面通过一个简单的 Go 程序,分别用传统方式和多阶段构建两种方法演示如何构建 Docker 镜像,并观察多阶段构建对镜像大小的显著优化效果
1 | package main |
CoreDNS是一个灵活可扩展的DNS服务器,使用Go语言编写,旨在提供快速、灵活的DNS服务
CoreDNS为Kubernetes集群内部的DNS解析提供服务,使得服务之间能够通过域名互相通信
Kubernetes集群中, CoreDNS是运行在kube-system这个namespace下的Pod
1 | kubectl -n kube-system get pod coredns-66f779496c-b7mmz |
比如服务a访问服务b:
curl b
来访问bcurl b.namespaceb
来访问b以下动手测试
在我之前做的项目里,我们对Microk8s微服务的更新是通过自制tar包的方式做的, tar包存储了镜像和YAML文件。 每次升级时,我们需要先删除所有的YAML资源,然后重新创建新的资源。 这种方式存在以下问题:
了解到Helm可以有效解决以上问题, Helm是Kubernetes 的包管理工具,方便用户快速发现、 共享和使用Kubernetes构建的应用。 以下举例演示如何使用Helm实现安装、升级、回滚操作
本文介绍如何在 Rocky Linux 9.5 上使用 ChartMuseum 搭建一个私有的 Helm Chart 仓库,并启用 HTTPS 和 Basic 认证以提高安全性
myhelmrepo.com
(1) 启动 ChartMuseum 容器
1 | docker run -d \ |
8台Linux虚拟机, Rocky Linux 9.5 x86_64
各个机器IP、主机名、角色如下
1 | 192.168.52.91 k8s-master1 主节点1 |
以下分步搭建kubernetes集群
Helm是Kubernetes的包管理工具,类似于Linux中的apt或yum. Helm通过模板化和版本控制等机制, 帮助用户快速发现、共享和使用Kubernetes应用
在Helm出现之前,部署Kubernetes应用存在以下问题:
1. YAML配置复杂,部署和管理Kubernetes应用不方便
2. 更新或回滚到特定版本较为困难
3. 难以共享或复用k8s配置, 不利于多团队协作
运气不差!