#760 对过去工作的一点总结和反思

个人 工作 2022-01-01

新的一年，岁数又会 +1，在这个一年开始的时候，对过去做个总结，对将来做个展望。

对过去的反思

  1. 工作这么多年，还是缺少拿得出手的项目经历，不足以支撑我对自己的定位或者目标
    工作年限越长，这个问题就会更加突出
    新的一年需要思考思考这个问题
  2. 技术深度不够
    1. 主力开发语言 Python 应该更加深入，完成 CPython 源码阅读
    2. PHP, Node, Golang 需要加强，能够熟练掌握 (主要是软件生态)，使之达到新的线上业务开发的程度
    3. 前端也一样
  3. 知识结构缺乏深入的整理
    1. 比如软件设计的一些思考
  4. 应该对产品方面更加用心一些 img
    现在就是对技术方面过于感兴趣而忽略了产品
    这个问题对于工作来说比较突出，新的一年一定要注意这个问题

今年的计划

前提：工作习惯养成：1. 计划，2. 重要的事情优先完成，3. 不加班 (上班时间完成工作)

如果按平均每天 2h 来计划，全年有 730h。

  1. img 对当前公司业务的梳理, 需要有计划有步骤的推进 (这一项可以在工作中完成)
  2. img 完成 Golang 的学习目标, 达到熟练的程度（第一季度) (60h, 按一个月算)
  3. img CPython 源码阅读 (120h, 按两个月算)
  4. img 英语和数学
    真是 年年列计划, 年年没时间
    英语达到六级词汇, 能不借助工具流利阅读英语资料 (180h, 按每天半小时算)
    数学复习到高等数学, 不用达到应试的程度, 了解相关概念就行 (60h, 按一个月算)
  5. img 计算机网络 (50h)
  6. img Markjour 文章更新速度放缓, 每周一篇就够了 (104h, 按每周两个小时算)
  7. img 对以往知识的总结 (104h，按每周两个小时算)
  8. img 剩下的时间 (52h) 差不多每周 1h, 用来记入其他学习任务。

个人项目的开发不占用这里的学习时间，另外从周末时间里面挤。

可选个人项目

  1. 短网址
  2. 记账
  3. Home Assistant 方向
    我预测未来几年，智能家居会变的很流行
    OpenWrt + Home Assistant 是一个很好的方案
  4. 通用管理后台
  5. 商城
  6. 重构 markjour

#759 IPv6 地址

计算机网络 IPv6 2021-12-30 
$ ip -c -6 addr show dev wlp6s0
3: wlp6s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    inet6 2409:8a4d:c81:c140::5/128 scope global dynamic noprefixroute  # IPv6 稳定地址（分配）
       valid_lft 226977sec preferred_lft 140577sec
    inet6 2409:8a4d:c81:c140:ca67:f46:7f29:1dad/64 scope global temporary dynamic  # IPv6 临时隐私地址
       valid_lft 376sec preferred_lft 376sec
    inet6 2409:8a4d:c81:c140:fcf0:3456:fac4:3b63/64 scope global dynamic mngtmpaddr noprefixroute  # IPv6 稳定地址（本地生成）
       valid_lft 376sec preferred_lft 376sec
    inet6 fe80::56f8:128b:b513:e571/64 scope link noprefixroute  # IPv6 链路本地地址
       valid_lft forever preferred_lft forever

# ipconfig /all
# ipconfig

无线局域网适配器 WLAN:

   连接特定的 DNS 后缀 . . . . . . . :
   IPv6 地址 . . . . . . . . . . . . : 2409:8a4d:c81:c140::6
   IPv6 地址 . . . . . . . . . . . . : 2409:8a4d:c81:c140:68cd:b350:9fe8:9feb
   临时 IPv6 地址. . . . . . . . . . : 2409:8a4d:c81:c140:757f:88b3:b455:5882
   本地链接 IPv6 地址. . . . . . . . : fe80::68cd:b350:9fe8:9feb%5
   IPv4 地址 . . . . . . . . . . . . : 192.168.1.7
   子网掩码  . . . . . . . . . . . . : 255.255.255.0
   默认网关. . . . . . . . . . . . . : fe80::1%5
                                       192.168.1.1

   DHCP 服务器 . . . . . . . . . . . : 192.168.1.1
   DNS 服务器  . . . . . . . . . . . : 2409:804c:2000:1::1
                                       2409:804c:2000:2::1
                                       192.168.1.1

一、地址格式

IPv4 4 字节, 一般用四个十进制的数字表示，xxx.xxx.xxx.xxx 形式，每一段的范围是 0~255。
IPv6 16 字节，一般用 32 个十六进制数表示，每四个一组，共八组，xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx 形式，每一段的范围是 0000~FFFF。

缩写

  1. 高位的 0 可以省略，比如 0001 就可以写成 1
  2. 全 0 段可以省略，用分号表示，比如 fe80::, :: (全 0), 又比如上面的 2409:8a4d:c81:c140::5
    但是, 只能缩写一次，比如 A:B:0:0:C:D:0:0 不能写成 A:B::C:D::, 只能缩写成 A:B::C:D:0:0 或 A:B:0:0:C:D::

百分号

如果一台机器有多张网卡，都有一个 fe80 的链路地址，操作系统无法区分一个包该走哪张网卡出。

在 IPv4 中，不同网卡一般配置了不同子网，比如 172.16.31.0/24, 172.168.32.0/24。

但是 IPv6 的分配可以自己生成（无状态地址自动配置），大家都在 fe80 段。

百分号后面附加的是 zone index，这个数据是操作系统解释的。Windows 会采用接口号（整型数），而 Linux 习惯端口名称，比如 eth0, enp7s0。
PS: 推荐阅读: 网卡名称的变迁（ethX -> enpXsY）

  • windows: netsh interface ipv6 show address
  • linux: ifconfig

注意：用在 URL 中时，这个百分号应该转义成 %25。

二、前缀

IPv4 有分区的概念，一开始叫做分类网络，ABCDE 五类。后来又有无类网络 (Classless Inter-Domain Routing, CIDR)，取任意长度作前缀，比如 172.16.0.0/12 以 1010 1100 0001 做前缀。

IPv6 也有分区的概念，和 CIDR 一样，可以取任意长度作前缀。
比如 fe80::/10 就是以 1111 1110 10 做前缀。

移动网络给我分配的是 /64 段，听说有地方能拿到更短前缀（V2EX, 2020/07, 电信 IPv6 大家还能拿到/56 么）。

如果拿到更短前缀，就可以自己在家划分子网了。根据现在的实践（SLAAC），一个网络最少需要留 64 位，如果正好分的是 64 位前缀，那么就不能采用 SLAAC 方案了，只能走 DHCP。

无状态自动配置

  1. RS, Router Solicitation
  2. RA, Router Advertisement 路由器告诉机器 IPv6 前缀
  3. NS, Neighbor Solicitation 机器广播自己将要采用某一个 IPv6

#758 转载：免费的编程书籍

阅读 开发者 2021-12-30

语言无关

版本控制

编程艺术

编辑器

编译原理

操作系统

程序员杂谈

大数据

分布式系统

管理和监控

函数式概念

计算机图形学

其它

软件开发方法

设计模式

数据库

项目相关

在线教育

正则表达式

智能系统

IDE

Web

WEB 服务器

语言相关

Android

Assembly

AWK

C

C Sharp

C++

CoffeeScript

Dart

Elasticsearch

Elixir

Erlang

Fortran

Golang

Groovy

Haskell

HTML / CSS

iOS

Java

JavaScript

AngularJS

:information_source: See also … Angular

Backbone.js

D3.js

Electron.js

ExtJS

impress.js

jQuery

Node.js

React.js

Vue.js

Zepto.js

LaTeX

LISP

Lua

Markdown

MySQL

NoSQL

Perl

PHP

Laravel

Symfony

PostgreSQL

Python

Django

R

reStructuredText

Ruby

Rust

Scala

Scheme

Scratch

Shell

Swift

TypeScript

Angular

:information_source: See also … AngularJS

Deno

VBA (Microsoft Visual Basic Applications)

Vim

Visual Prolog

#757 VPN 重新配置流程

个人 工作 2021-12-27

处于安全原因，每隔几个月重新更换一次 OpenVPN 的配置文件，以防被攻击。运维讲配置文件加密打包分发给每个人，然后大家将其覆盖到现在的目录中。

我是 Linux 环境（Ubuntu, 准备切入 Fedora），这里我记录一下更新流程，下次务必 1 分钟之内切换完成。

  1. 通过密码解压配置文件
ls ~/Documents/Mine/config20211213/
# ca.crt  client.crt  client.key  client.ovpn
  1. 备份之前的证书文件
cd /etc/openvpn
sudo mkdir backup20211227
sudo mv ca.crt client.crt client.key client.ovpn backup20211227/
sudo cp client.conf backup20211227/
  1. 采用新的证书文件
sudo mv ~/Documents/Mine/config20211213/{ca.crt,client.crt,client.key,client.ovpn} /etc/openvpn
sudo chmod 400 /etc/openvpn/{ca.crt,client.crt,client.key,client.ovpn}
  1. 通过和旧的 client.ovpn 文件比对，讲需要修改的地方同步到 /etc/openvpn/client.conf 中
sudo diff client.ovpn backup20211227/client.ovpn
sudo vim /etc/openvpn/client.conf
# w! sudo tee %
  1. 重新启动 OpenVPN，试一下是否配置成功
sudo systemctl restart openvpn@client

#756 转载：正则表达式历史

开发者 正则表达式 2021-12-19

正则表达式在我们日常的软件开发过程中被广泛使用，例如编写 Nginx 配置文件、在 Linux 与 macOS 下查找文件，然而不同软件不同操作系统对于正则的应用有着不一样的行为，主要原因是正则表达式演进过程中，出现 POSIX 与 PCRE 派系之分。

#752 Bing 打不开了

互联网 Bing 搜索引擎 2021-12-17

Bing 是我的默认搜索引擎。但是今天早上发现 Bing 打不开了，只有通过特殊手段才行。

  1. 应监管部门要求，Bing 需要在 30 天内对搜索框的建议功能做出整改，看到很多网友贴出了公告。
  2. https://www4.bing.com 目前可用 (随时会挂)
  3. 切换到谷歌 DNS 之后，Bing 可以正常访问

Update @ 2021-12-19: 必应搜索恢复正常访问（持续时间大约 2 天）。

#751 K8S 核心概念

K8S 2021-12-17

Kubernetes (K8S) 可以通过以下方式判断每个容器需要的资源情况，然后据此进行调度：

可以根据容器所需资源情况调度：

  • 定义 Pod 的资源需求和限制：可以在 Pod 的 YAML 文件中定义每个容器的资源需求和限制，包括 CPU 和内存。
    这样 Kubernetes 调度器就可以根据这些需求来选择节点和分配资源。
  • 监测容器资源使用情况：Kubernetes 可以通过 kubelet 代理监测每个容器的资源使用情况，包括 CPU 和内存使用率。
    这样 Kubernetes 调度器就可以根据容器的实际资源使用情况来调整 Pod 的调度策略。
  • 自动伸缩 Pod：Kubernetes 还可以根据容器的资源使用情况自动伸缩 Pod 的数量。
    可以通过 Horizontal Pod Autoscaler (HPA) 来设置 Pod 的最小和最大副本数，以及触发自动伸缩的 CPU 和内存使用率阈值。
  • 节点亲和性和反亲和性：Kubernetes 可以通过节点亲和性和反亲和性来指定容器在哪些节点上运行，以及在哪些节点上不运行。
    可以通过节点标签和 Pod 标签来实现亲和性和反亲和性。

一、K8S 架构概述

K8S 采用主从架构，主要由控制平面（Control Plane）和工作节点（Worker Nodes）构成，这种架构设计使得系统具有良好的可扩展性和稳定性。

  • 控制平面（Master）：作为 K8S 集群的“大脑”，负责全局决策和管理，包含多个关键组件。
    • API Server：是 K8S 的核心接口，提供了一套 RESTful API，用户、客户端工具以及其他组件都通过它来与集群进行交互，实现对集群资源的操作和管理。
    • etcd：用于存储集群的配置信息和状态数据，是一个高可用的键值存储数据库，保证了数据的一致性和持久性。
    • Controller Manager：包含多个控制器，如节点控制器、副本控制器等，它们负责监控集群状态，并根据期望状态进行调整，确保集群始终处于稳定运行状态。
    • Scheduler：负责将待部署的 Pod 调度到合适的工作节点上，它会根据节点的资源情况、Pod 的需求等因素进行综合考量，以实现资源的最优分配。
  • 工作节点（Node）：是运行应用容器的实际服务器，可以是物理机或虚拟机，每个节点都运行着一些必要的组件。
    • Kubelet：作为节点上的代理，负责与控制平面通信，接收并执行 Pod 的部署任务，同时监控容器的运行状态。
    • Kube Proxy：实现服务的网络代理功能，负责将服务的访问请求转发到相应的 Pod 上，确保服务的可访问性。
    • 容器运行时（Container Runtime）：用于运行容器，常见的有 Docker、containerd 等。

二、核心资源对象

在 K8S 中，一切皆为资源对象，通过操作这些对象来管理应用。

  • Pod：是 K8S 中最小的部署单元，它可以包含一个或多个紧密相关的容器。这些容器共享网络和存储资源，通常作为一个整体被调度和管理。例如，一个 Web 应用 Pod 可能包含 Web 服务器容器和日志收集容器。
  • Service：定义了一组 Pod 的访问规则，为这些 Pod 提供了一个稳定的网络接口。无论 Pod 如何动态变化，Service 都能确保客户端可以通过固定的 IP 和端口访问到服务。Service 有多种类型，如 ClusterIP（仅在集群内部可访问）、NodePort（通过节点端口暴露服务）、LoadBalancer（使用云服务商的负载均衡器）等。
  • Deployment：用于管理 Pod 的部署和更新，它定义了 Pod 的期望状态，包括副本数量、镜像版本等。通过 Deployment，可以轻松实现应用的滚动更新、回滚等操作，确保服务的高可用性。例如，当需要更新应用版本时，Deployment 会逐步替换旧的 Pod，而不会导致服务中断。
  • ReplicaSet（RS）：确保指定数量的 Pod 副本始终处于运行状态，它是 Deployment 的底层实现。通常情况下，我们通过 Deployment 来间接管理 ReplicaSet，而不是直接操作 ReplicaSet。
  • StatefulSet：与 Deployment 不同，StatefulSet 用于管理有状态的应用，如数据库。它能保证 Pod 的顺序性和唯一性，为每个 Pod 提供稳定的标识符和持久化存储，确保应用在重启或迁移后能够恢复到正确的状态。
  • DaemonSet：确保每个节点上都运行一个指定的 Pod 副本，常用于部署系统监控、日志收集等需要在每个节点上运行的服务。例如，Prometheus Node Exporter 就可以通过 DaemonSet 部署到每个节点上，以收集节点的性能指标。
  • Job/CronJob：Job 用于执行一次性的任务，当任务完成后，Pod 会被自动终止。CronJob 则用于定时执行任务，类似于 Linux 系统中的 cron 任务，例如每天凌晨备份数据库就可以通过 CronJob 来实现。
  • Namespace：用于在逻辑上划分集群资源，不同 Namespace 中的资源相互隔离。它可以帮助多个团队或项目在同一个集群中共享资源，同时又不会相互干扰。例如，开发环境和生产环境可以分别使用不同的 Namespace。
  • ConfigMap/Secret：用于存储配置信息和敏感数据，如应用的配置文件、数据库密码等。通过将这些信息与容器镜像分离，可以在不修改镜像的情况下，灵活地更新应用的配置。ConfigMap 用于存储非敏感的配置信息，Secret 则用于存储敏感信息，并且会对数据进行加密存储。
  • Volume：为 Pod 提供持久化存储，它可以是本地存储、网络存储（如 NFS、Ceph）等。Volume 使得容器在重启后仍然可以访问到之前的数据，保证了数据的持久性。例如，数据库 Pod 可以使用 Volume 来存储数据文件。

三、关键术语与机制

  • 标签（Label）与选择器（Selector）：标签是附着在资源对象上的键值对，用于对资源进行分类和标识。选择器则用于根据标签筛选资源对象，是 Service、Deployment 等组件关联 Pod 的重要方式。例如，一个 Service 可以通过标签选择器找到所有具有特定标签的 Pod，并将流量转发给它们。
  • 控制器（Controller）：K8S 中的核心组件，通过持续监控资源的实际状态与期望状态的差异，并进行调整，来实现集群的自修复能力。除了前面提到的 Deployment、ReplicaSet 等控制器，还有 NodeController、ServiceController 等。
  • 声明式 API：K8S 采用声明式 API，用户只需定义资源的期望状态，而无需关心具体的实现过程。系统会自动将实际状态调整为期望状态，这种方式大大简化了应用的部署和管理。例如，用户只需要编写一个 Deployment 的 YAML 文件，指定 Pod 的副本数量和镜像版本，K8S 就会自动创建和管理这些 Pod。
  • 服务发现与负载均衡：K8S 内置了服务发现机制，Service 会自动注册和发现相关的 Pod。同时，Service 还提供了负载均衡功能，将客户端的请求均匀地分发到多个 Pod 上，提高了服务的可用性和性能。
  • 自动扩缩容（HPA/VPA）：Horizontal Pod Autoscaler（HPA）可以根据 CPU、内存等指标自动调整 Pod 的副本数量，以适应应用的负载变化。Vertical Pod Autoscaler（VPA）则可以根据 Pod 的资源使用情况自动调整其资源请求和限制。
  • 滚动更新与回滚：Deployment 支持滚动更新，在更新过程中，会逐步替换旧的 Pod，同时保持服务的正常运行。如果更新出现问题，还可以快速回滚到之前的稳定版本，确保服务的可靠性。

四、新人入门建议

  • 搭建本地环境：使用 Minikube 或 Docker Desktop 搭建本地 K8S 集群，便于动手实践，加深对概念的理解。
  • 学习 YAML 配置：K8S 主要通过 YAML 文件来定义资源对象，熟练掌握 YAML 的语法和结构是非常重要的。
  • 动手实践：从部署简单的应用开始，如 Nginx、MySQL 等，逐步熟悉 Pod、Service、Deployment 等资源的创建和管理。
  • 阅读官方文档：K8S 的官方文档非常详细，是学习的重要资料。可以从入门指南开始，逐步深入学习各个概念和功能。
  • 参与社区：K8S 社区非常活跃，可以通过论坛、博客、社交媒体等渠道与其他开发者交流，获取经验和解决问题。

和 Docker 生态的对比

和虚拟化生态（KVM / OpenStack）的对比

本质是计算机资源的隔离和管理，单技术原理和应用场景有显著差异：

一、核心技术定位对比

维度 KVM/OpenStack 虚拟化生态 K8S 容器编排
资源抽象层级 基于硬件虚拟化（CPU、内存、磁盘），抽象出虚拟机（VM） 基于操作系统级虚拟化，抽象出容器（Container）
隔离粒度 操作系统级隔离（每个 VM 有独立内核） 进程级隔离（共享宿主机内核）
核心目标 实现物理服务器资源的池化与虚拟机管理，支持传统应用迁移 解决容器化应用的规模化部署与微服务管理
典型场景 企业传统应用上云、虚拟机集群管理、私有云基础设施建设 云原生应用开发、微服务架构、弹性伸缩场景

二、技术架构与实现原理

  • 虚拟化生态（KVM/OpenStack）

    • KVM（Kernel-based Virtual Machine）

      • 定位：Linux 内核原生支持的硬件虚拟化技术，属于 Type 1 hypervisor（裸金属虚拟化）。
      • 核心组件：
        • KVM 模块：运行在宿主机内核中，负责创建和管理虚拟机（VM）。
        • QEMU：模拟虚拟机的硬件设备（如网卡、磁盘），与 KVM 协同工作。
        • VM：包含独立的操作系统、应用程序和配置，通过镜像（如 qcow2）存储。
      • 隔离机制：通过 CPU 虚拟化（Intel VT-x/AMD-V）、内存分页技术（EPT/MMU）实现硬件资源隔离，每个 VM 拥有独立内核。

    • OpenStack

      • 定位：开源云计算管理平台，用于编排虚拟化资源（VM、网络、存储），构建私有云或公有云。
      • 核心组件：
        • Nova：计算节点管理，负责 VM 的创建、调度和生命周期管理。
        • Neutron：网络服务，为 VM 提供虚拟网络功能（如 IP 分配、负载均衡）。
        • Cinder/Glance：存储与镜像服务，管理 VM 的持久化存储和镜像分发。
      • 特点：通过 API 接口实现对 KVM 等 hypervisor 的统一管理，支持大规模 VM 集群的资源调度。

    • K8S 与容器技术

      • 核心架构（与虚拟化的关联）：
        • 节点（Node）：可以是物理服务器或虚拟机（VM），K8S 不关心底层基础设施，仅要求节点运行容器运行时（如 Docker、containerd）。
        • 容器隔离：基于 Linux 命名空间（Namespace）隔离进程空间，通过控制组（Cgroup）限制资源使用，共享宿主机内核，因此资源占用远低于 VM。
        • 编排能力：通过 YAML 声明式配置，实现容器化应用的自动部署、扩缩容和故障恢复，无需手动管理底层服务器。

三、关键特性对比详解

  1. 资源占用与性能

    • 虚拟化（KVM）：
      • 每个 VM 需加载独立操作系统内核，内存占用通常为数百 MB 到数 GB（如 Ubuntu VM 至少占用 512MB 内存）。
      • 启动时间以秒为单位（10~30 秒），性能接近物理机（因硬件虚拟化开销较小）。
    • 容器（K8S）：
      • 容器共享宿主机内核，内存占用可低至 10MB（如 Alpine 镜像的容器）。
      • 启动时间毫秒级（100ms 内），适合快速启停和弹性扩缩容（如应对突发流量）。

  2. 隔离性与安全性

    • 虚拟化：
      • 隔离性强，VM 之间完全隔离（包括内核、驱动），一个 VM 的故障不会影响其他 VM。
      • 安全性高，适合多租户环境（如公有云），可通过硬件虚拟化技术（如 Intel SGX）增强隔离。
    • 容器：
      • 隔离性较弱，依赖宿主机内核的安全性（若内核存在漏洞，可能导致容器逃逸）。
      • 安全性需通过额外机制增强（如 Seccomp、AppArmor 限制容器权限），更适合同租户内的微服务隔离。

  3. 部署与管理复杂度

    • OpenStack + KVM：
      • 部署复杂，需配置计算、网络、存储等多个组件，运维门槛高（如 Neutron 网络配置易出错）。
      • 管理 VM 时需手动配置镜像、网络策略、存储挂载，适合静态资源分配场景（如固定业务负载）。
    • K8S：
      • 声明式管理，通过 YAML 定义应用“期望状态”（如副本数、资源限制），系统自动实现。
      • 支持应用级灰度发布、滚动更新，无需停机即可升级服务，适合快速迭代的互联网应用。

  4. 应用迁移与兼容性

    • 虚拟化：
      • 适合传统单体应用上云，无需修改代码即可迁移（如 Windows 应用通过 VM 运行）。
      • 对 legacy 应用兼容性好，但资源利用率低（如单台物理机运行多个低负载 VM）。
    • 容器：
      • 要求应用支持容器化改造（如拆分微服务、无状态设计），传统应用需重构才能发挥优势。
      • 资源利用率高（单节点可运行数百个容器），但对有状态应用（如数据库）的支持需额外存储方案。

四、适用场景对比

  • 推荐使用虚拟化（KVM/OpenStack）的场景：

    • 传统企业应用迁移：如 ERP、OA 等单体应用，无法容器化改造，需通过 VM 保留原有运行环境。
    • 多租户公有云/私有云：需强隔离性的场景（如金融、政府行业），避免租户间资源冲突或安全漏洞。
    • GPU 等特殊硬件管理：通过 VM 独占 GPU 资源（如深度学习训练），KVM 支持更成熟的硬件直通技术。
    • 长生命周期服务：如数据库集群、中间件服务，无需频繁启停，更关注稳定性而非弹性。

  • 推荐使用 K8S + 容器的场景：

    • 云原生微服务架构：如电商平台、社交应用，拆分为多个微服务，通过 K8S 实现自动调度和故障恢复。
    • 弹性伸缩与峰值流量：如双十一促销、直播平台，支持秒级扩缩容 hundreds of Pod，按需分配资源。
    • CI/CD 与快速迭代：开发测试环境中，容器镜像可快速构建部署，配合 K8S 的滚动更新实现持续交付。
    • 资源利用率优先场景：如云计算厂商的 Serverless 服务，通过容器高密度部署提升硬件利用率。

五、技术协同与混合部署

K8S 与虚拟化并非对立，而是常以混合形态存在：

  1. K8S 运行在虚拟机上：

    • 多数生产环境中，K8S 集群的节点本身是 VM（如通过 OpenStack 创建），利用 VM 的隔离性实现集群资源的安全划分。
    • 例如：企业用 OpenStack 构建私有云，在 VM 上部署 K8S，既享受 VM 的稳定性，又利用 K8S 管理容器化应用。

  2. 容器与 VM 的互补场景：

    • VM 运行有状态服务：如数据库、大数据集群，利用 VM 的强隔离性保障数据安全。
    • 容器运行无状态服务：如 Web 前端、API 服务，通过 K8S 实现弹性扩缩容。

  3. 新型技术融合：

    • Kata Containers：结合 VM 和容器优势，用轻量级 VM 包裹容器，实现“容器的便捷性 + VM 的隔离性”，适合对安全性要求高的容器场景。
    • OpenStack 对 K8S 的支持：OpenStack 社区推出 Magnum 组件，支持在 OpenStack 上部署 K8S 集群，简化云原生应用的基础设施管理。

六、技术演进与未来趋势

  • 虚拟化的定位：从“通用计算平台”转向“特殊场景刚需”，如强隔离、传统应用兼容、硬件直通等领域仍不可替代。
  • K8S 的扩张：成为云原生时代的“操作系统”，不仅管理容器，还通过 Project Krustlet 等项目尝试管理 VM、物理机等异构资源。
  • 混合架构常态化：企业 IT 环境将同时存在 VM 和容器，K8S 可能成为统一的资源编排层，而 OpenStack 专注于基础设施虚拟化。