在 Docker 中，默认情况下容器无法直接与外部网络通信。 为了使外部网络能够访问容器内的服务，Docker 提供了端口映射功能，通过将宿主机的端口映射到容器内的端口，外部可以通过宿主机的IP和端口访问容器内的服务

以下通过动手演示, 安装一个Flask容器, 解释端口映射从外部访问容器的原理

安装一个Flask容器

文件结构

1
2
3

.
├── Dockerfile
└── app.py

Dockerfile

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

FROM rockylinux:9.3

RUN dnf update -y && \
    dnf install -y python3 python3-pip && \
    dnf clean all

WORKDIR /app

COPY app.py /app/app.py

RUN pip3 install --no-cache-dir flask

EXPOSE 5000

CMD ["python3", "app.py"]

app.py

1
2
3
4
5
6
7
8
9
10

from flask import Flask

app = Flask(__name__)

@app.route('/')
def hello():
    return "Hello"

if __name__ == '__main__':
    app.run(host='0.0.0.0', port=5000)

构建镜像

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
2

# curl 192.168.52.203
Hello

现金券

100港币4张 + 50港币4张 + 5美元*5张 = 600港币 + 25美元

变现方法

我入金的是港币, 但交易美股时不需要把港币先换成美元再交易, 因为我们可以用港币融资美元直接交易, 融资当天借入当天还掉就行

变现流程如下：

什么是 Docker 多阶段构建

Docker 多阶段构建是一种通过在单个 Dockerfile 中定义多个构建阶段的技术。 每个阶段可以使用不同的基础镜像和依赖项，允许开发人员在构建过程中分离应用程序的编译环境与运行环境。 最终生成的镜像只包含运行应用程序所需的文件，而无需携带编译工具链或其他不必要的依赖
通过多阶段构建，可以有效减少镜像体积，提升部署效率

实例: 多阶段构建压缩 Docker 镜像

下面通过一个简单的 Go 程序，分别用传统方式和多阶段构建两种方法演示如何构建 Docker 镜像，并观察多阶段构建对镜像大小的显著优化效果

准备工作

• 安装 Docker
• 编写一个简单的 Go 程序 hello.go

1
2
3
4
5
6
7

package main

import "fmt"

func main() {
    fmt.Println("Hello, World!")
}

CoreDNS是什么

CoreDNS是一个灵活可扩展的DNS服务器，使用Go语言编写，旨在提供快速、灵活的DNS服务

为什么需要CoreDNS

CoreDNS为Kubernetes集群内部的DNS解析提供服务，使得服务之间能够通过域名互相通信
Kubernetes集群中, CoreDNS是运行在kube-system这个namespace下的Pod

1
2
3

kubectl -n kube-system get pod coredns-66f779496c-b7mmz
NAME                       READY   STATUS    RESTARTS      AGE
coredns-66f779496c-b7mmz   1/1     Running   4 (28m ago)   4d23h

k8s集群中的域名是如何解析的

比如服务a访问服务b:

• 如果a和b在同一个namespace下, 可以直接在pod a中, 通过curl b来访问b
• 如果a和b不在同一个namespace下, 在pod a中需要通过curl b.namespaceb来访问b

以下动手测试

前言

在我之前做的项目里，我们对Microk8s微服务的更新是通过自制tar包的方式做的, tar包存储了镜像和YAML文件。 每次升级时，我们需要先删除所有的YAML资源，然后重新创建新的资源。 这种方式存在以下问题：

• 服务中断：由于需要先删除旧资源再创建新资源，这会导致短暂的服务中断，影响用户体验
• 复杂的回滚逻辑：如果升级失败，回滚到之前的版本变得非常复杂，需要手动恢复旧的YAML文件，并且容易出错

了解到Helm可以有效解决以上问题, Helm是Kubernetes 的包管理工具，方便用户快速发现、 共享和使用Kubernetes构建的应用。 以下举例演示如何使用Helm实现安装、升级、回滚操作

前言

本文介绍如何在 Rocky Linux 9.5 上使用 ChartMuseum 搭建一个私有的 Helm Chart 仓库，并启用 HTTPS 和 Basic 认证以提高安全性

环境准备

• 一台Rocky Linux 9.5 x86_64, 作为Helm Repo, 安装Docker, 域名: myhelmrepo.com
• Kubernetes 集群 v1.28.x, Helm v3.16.0

1. 安装并启动 ChartMuseum

(1) 启动 ChartMuseum 容器

1
2
3
4
5
6
7
8
9

docker run -d \
  --name private-helm-repo \
  -p 8080:8080 \
  --restart=always \
  -e STORAGE=local \
  -e STORAGE_LOCAL_ROOTDIR=/charts \
  -v /charts:/charts \
  --user root \
  swr.cn-north-4.myhuaweicloud.com/ddn-k8s/ghcr.io/helm/chartmuseum:v0.16.2

集群规划

8台Linux虚拟机, Rocky Linux 9.5 x86_64

• 主节点(3个): 2CPU, 3G内存, 20G硬盘
• 工作节点(2个): 2CPU, 3G内存, 20G硬盘
• LB(2个): 1CPU, 2G内存, 10G硬盘

各个机器IP、主机名、角色如下

1
2
3
4
5
6
7
8
9
10
11

192.168.52.91 k8s-master1 主节点1
192.168.52.92 k8s-master2 主节点2
192.168.52.93 k8s-master3 主节点3

192.168.52.101 k8s-slave1 从节点1
192.168.52.102 k8s-slave2 从节点2
192.168.52.103 k8s-slave3 从节点3

192.168.52.80 k8s-lb1 HAProxy
192.168.52.81 k8s-lb2 HAProxy
192.168.52.88 www.petertest.com Virtual IP(VIP)

以下分步搭建kubernetes集群

• 搭建一主一从集群
• 添加负载均衡(HAProxy)
• 搭建三主三从集群(三主三从两LB)

什么是Helm? Helm解决了哪些问题?

Helm是Kubernetes的包管理工具，类似于Linux中的apt或yum. Helm通过模板化和版本控制等机制, 帮助用户快速发现、共享和使用Kubernetes应用

在Helm出现之前，部署Kubernetes应用存在以下问题:
1. YAML配置复杂，部署和管理Kubernetes应用不方便

• 问题：需要编写大量YAML文件定义Kubernetes资源。 随着项目规模增长, 维护这些配置文件变得困难, 尤其是在多环境部署时
• Helm解决方案: 通过Helm模板功能，开发者可以创建一个Chart, 包含所有必要的Kubernetes资源定义, 并使用变量代替硬编码值

2. 更新或回滚到特定版本较为困难

• 问题：缺乏版本控制功能，难以更新或回滚到指定版本。如果直接修改线上 YAML 文件，可能导致问题且难以恢复到稳定状态
• Helm解决方案: Helm 通过Release概念支持版本控制，每次部署或更新应用时都会创建一个新的Release. 如果新版本出现问题, 可以通过helm rollback快速回滚到之前的稳定版本

3. 难以共享或复用k8s配置, 不利于多团队协作

• 问题：在一个团队内部，不同项目可能有相似需求（如都需要部署同一套系统）。然而，由于缺少有效的共享机制，每个项目需要从头开始配置，浪费了大量时间精力
• Helm解决方案: Helm Charts 可以通过仓库共享，每个人可以从仓库中下载官方或其他团队成员发布的Charts，也可以上传自己的Charts，实现了Kubernetes配置的共享和复用

快速上手Helm

Helm的三个基本概念

• Chart, 一个Helm安装包，包含了运行一个应用所需要的镜像、依赖和资源定义等
• Release, 在Kubernetes集群上运行的一个Chart实例
• Repository, 发布和存储Chart的仓库

运气不差！

背景

早期，客户的On-premises网关设备（基于CentOS 7）采用增量升级方案进行固件更新。 这种方案存在两个主要问题：

• 一旦升级过程中出现问题，客户只能重新安装系统，严重影响用户体验。
• 部分客户未开启自动升级功能，为了支持所有客户的升级需求，升级包必须保存从初始版本到最新版本的所有增量文件。随着版本迭代，升级包变得越来越大，难以维护。

为了解决这些问题，需要为客户网关设备设计一种新的升级方案。

A/B系统升级简介

A/B分区升级机制允许设备在不同分区上安装和运行系统的不同版本，从而实现无缝更新。这种方法常用于移动设备、物联网设备以及其他需要高可用性和减少停机时间的场景中。例如，Android系统、Chrome OS及许多嵌入式和IoT设备都采用了A/B系统升级方法。其主要优点包括：

• 无缝更新：可以在系统运行期间进行更新，唯一的宕机发生在设备重启到更新后分区时。
• 故障恢复：如果升级失败，设备仍可工作在旧分区，并允许客户继续尝试升级。