云服务器适合安装k8s吗

⑴ 服务器搭建k8s内存需要多大

你好！2gb或者4gb都行
1.什么是k8s？
k8s是一个docker容器管理工具
它是一个全新的基于容器技术的分布式架构领先方案，是开源的容器集群管理系统。
在docker的基础上，为容器化的应用提供部署运行，资源调度，服务发现和动态伸缩等一系列完整功能
2.----k8s的优势：
a，容器编排
b，轻量级
c，开源
d，弹性伸缩
e，负载均衡
二：k8s的核心功能
1.自愈: 重新启动失败的容器，在节点不可用时，替换和重新调度节点上的容器，对用户定义的健康检查不响应的容器会被中止，并且在容器准备好服务之前不会把其向客户端广播。
弹性伸缩: 通过监控容器的cpu的负载值,如果这个平均高于80%,增加容器的数量,如果这个平均低于10%,减少容器的数量
服务的自动发现和负载均衡: 不需要修改您的应用程序来使用不熟悉的服务发现机制，Kubernetes 为容器提供了自己的 IP 地址和一组容器的单个 DNS 名称，并可以在它们之间进行负载均衡。
滚动升级和一键回滚: Kubernetes 逐渐部署对应用程序或其配置的更改，同时监视应用程序运行状况，以确保它不会同时终止所有实例。 如果出现问题，Kubernetes会为您恢复更改，利用日益增长的部署解决方案的生态系统。

⑵ 什么是K8S

‍

k8s是什么?

Kubernetes 是一个可移植的，可扩展的开源容器编排平台，用于管理容器化的工作负载和服务，方便了声明式配置和自动化。它拥有一个庞大且快速增长的生态系统。Kubernetes 的服务，支持和工具广泛可用。

为什么现在流行使用容器?

早期: 在物理服务器上面部署应用程序存在资源分配问题,因为其不能在物理服务器中的应用程序定义资源边界,导致应用程序资源利用不足而无法扩展.

后来: 为了解决该问题,引入了虚拟化技术, 虚拟化技术是指允许你在单个物理服务器的 CPU 上运行多个虚拟机,可以让多个应用程序在虚拟机之间进行隔离,具有一定的安全性, 每一个虚拟机就是一台完整的计算机, 在虚拟化硬件之上运行所有组件.

现在: 多数在物理服务器上面部署应用程序都是采kubectl用容器的方式,容器类似于虚拟机,它们都具有自己的文件系统、CPU、内存、进程空间等, 且由于它们与基础架构分离，因此可以跨云和 OS 发行版本进行移植。基于此特点被企业大范围使用.

为什么需要使用k8s容器?

若出现这样一个环境: 在生产环境中如果一个容器发生故障,则我们需要手动去启动另外一个容器,这样的操作是对我们的管理员来说是不太方便的, 若一个容器出现故障,另一个容器可以自动启动容器接管故障的容器,这样是最好的.

k8s就可以实现该效果,Kubernetes 提供了一个可弹性运行分布式系统的框架。 Kubernetes 会满足你的扩展要求、故障转移、部署模式等。

k8s功能: 服务发现和负载均衡, 存储编排, 自动部署和回滚, 自动完成装箱计算, 自我修复, 密钥与配置管理

名词解释

secret

Secret有三种类型：

• Service Account：用来访问Kubernetes API，由Kubernetes自动创建，并且会自动挂载到Pod的目录中；
• /run/secrets/kubernetes.io/serviceaccount
• Opaque：base64编码格式的Secret，用来存储密码、密钥等；
• kubernetes.io/dockerconfigjson：用来存储私有docker registry的认证信息。

k8s的组成

k8s是由组件,API,对象等组成.

包含所有相互关联组件的 Kubernetes 集群图如下:

组件

• 控制平面组件
  • kube-apiserver: 为k8s的api服务器,公开了所有Kubernetes API, 其他所有组件都必须通过它提供的API来操作资源数据.
    • 保证集群状态访问的安全
    • 隔离集群状态访问的方式和后端存储实现的方式：API Server是状态访问的方式，不会因为后端存储技术etcd的改变而改变。
  • etcd: 为k8s的键值数据库,保存了k8s所有集群数据的后台数据库。
  • kube-scheler: 收集和分析当前Kubernetes集群中所有Node节点的资源(内存、CPU)负载情况，然后依此分发新建的Pod到Kubernetes集群中可用的节点。 kube-controller-manager: 在主节点上运行 控制器 的组件。
  • cloud-controller-manager: 云控制器管理器是指嵌入特定云的控制逻辑的 控制平面组件
• Node 组件
  • kubelet: 一个在集群中每个节点（node）上运行的代理。 它保证容器（containers）都 运行在 Pod 中。
  • kube-proxy: kube-proxy是集群中每个节点上运行的网络代理,维护节点上的网络规则。这些网络规则允许从集群内部或外部的网络会话与 Pod 进行网络通信。
  • 容器运行时: 负责运行容器的软件。
• 插件(Addons)
  • DNS: 集群 DNS 是一个 DNS 服务器，和环境中的其他 DNS 服务器一起工作，它为 Kubernetes 服务提供 DNS 记录。
  • Web 界面（仪表盘）: Dashboard 是Kubernetes 集群的通用的、基于 Web 的用户界面。
  • 容器资源监控: 容器资源监控 将关于容器的一些常见的时间序列度量值保存到一个集中的数据库中，并提供用于浏览这些数据的界面。
  • 集群层面日志: 集群层面日志 机制负责将容器的日志数据 保存到一个集中的日志存储中，该存储能够提供搜索和浏览接口。

API

Kubernetes 控制面 的核心是 API 服务器。 API 服务器负责提供 HTTP API，以供用户、集群中的不同部分和集群外部组件相互通信。

对象

Kubernetes对象是Kubernetes系统中的持久实体。Kubernetes使用这些实体来表示集群的状态.

具体来说，他们可以描述：

• 容器化应用正在运行(以及在哪些节点上)
• 这些应用可用的资源
• 关于这些应用如何运行的策略，如重新策略，升级和容错

Kubernetes 架构

Kubernetes 架构由节点,控制面到节点通信, 控制器, 云控制器管理器组成.

master 流程图

• Kubecfg将特定的请求，比如创建Pod，发送给Kubernetes Client。
• Kubernetes Client将请求发送给API server。
• API Server根据请求的类型，比如创建Pod时storage类型是pods，然后依此选择何种REST Storage API对请求作出处理。
• REST Storage API对的请求作相应的处理。
• 将处理的结果存入高可用键值存储系统Etcd中。
• 在API Server响应Kubecfg的请求后，Scheler会根据Kubernetes Client获取集群中运行Pod及Minion/Node信息。
• 依据从Kubernetes Client获取的信息，Scheler将未分发的Pod分发到可用的Minion/Node节点上。

节点

节点可以是一个虚拟机或者物理机器，取决于所在的集群配置。 每个节点包含运行 Pods 所需的服务， 这些 Pods 由 控制面 负责管理.

节点上的组件包括 kubelet、 容器运行时以及 kube-proxy。

节点状态

可以使用 kubectl 来查看节点状态和其他细节信息：

kubectl describe node <�节点名称>

一个节点包含以下信息:

• 地址
  • HostName：由节点的内核设置。可以通过 kubelet 的 —hostname-override 参数覆盖。
  • ExternalIP：通常是节点的可外部路由（从集群外可访问）的 IP 地址。
  • InternalIP：通常是节点的仅可在集群内部路由的 IP 地址。
• 状况(conditions 字段描述了所有 Running 节点的状态)
  • Ready 如节点是健康的并已经准备好接收 Pod 则为 True；False 表示节点不健康而且不能接收 Pod；Unknown 表示节点控制器在最近 node-monitor-grace-period 期间（默认 40 秒）没有收到节点的消息
  • DiskPressure为True则表示节点的空闲空间不足以用于添加新 Pod, 否则为 False
  • MemoryPressure为True则表示节点存在内存压力，即节点内存可用量低，否则为 False
  • PIDPressure为True则表示节点存在进程压力，即节点上进程过多；否则为 False
  • NetworkUnavailable为True则表示节点网络配置不正确；否则为 False
• 容量与可分配
  • 描述节点上的可用资源：CPU、内存和可以调度到节点上的 Pod 的个数上限。
• 信息
  • 关于节点的一般性信息，例如内核版本、Kubernetes 版本（kubelet 和 kube-proxy 版本）、 Docker 版本（如果使用了）和操作系统名称。这些信息由 kubelet 从节点上搜集而来。

控制面到节点通信

• 节点到控制面
  • apiserver在安全的 HTTPS 端口（443）上监听远程连接请求
  • 以客户端证书的形式将客户端凭据提供给 kubelet
• 控制面到节点
  • API 服务器到 kubelet连接用于
    • 获取 Pod 日志
    • 挂接（通过 kubectl）到运行中的 Pod
    • 提供 kubelet 的端口转发功能。
    • (注: 在连接状态下, 默认apiserver 不检查 kubelet 的服务证书。容易受到中间人攻击，不安全.)
  • apiserver 到节点、Pod 和服务
    • SSH 隧道(目前已经废弃)
      • 产生原因: 若无服务证书, 又要求避免在非受信网络或公共网络上进行连接,则可以在apiserver 和 kubelet 之间使用ssh隧道.
      • Kubernetes 支持使用 SSH 隧道来保护从控制面到节点的通信路径。
    • Konnectivity 服务
      • 为ssh隧道的替代品, Konnectivity 服务提供 TCP 层的代理，以便支持从控制面到集群的通信。

控制器

在 Kubernetes 中，控制器通过监控集群 的公共状态，并致力于将当前状态转变为期望的状态。

举个例子: 当前室内温度为20度, 我们通过调节遥控器,使其温度上升至24度, 这20度到24度的变化即为让其从当前状态接近期望状态。

控制器模式分为直接控制和通过API服务器来控制.

云控制器管理器

云控制器管理器是指嵌入特定云的控制逻辑的 控制平面组件。 云控制器管理器允许您链接聚合到云提供商的应用编程接口中， 并分离出相互作用的组件与您的集群交互的组件。

云控制器管理器中的控制器包括：

• 节点控制器
  • 节点控制器负责在云基础设施中创建了新服务器时为之 创建 节点（Node）对象。 节点控制器从云提供商获取当前租户中主机的信息。
  • 执行功能:
    • 针对控制器通过云平台驱动的 API 所发现的每个服务器初始化一个 Node 对象
    • 利用特定云平台的信息为 Node 对象添加注解和标签
    • 获取节点的网络地址和主机名
    • 检查节点的健康状况。
• 路由控制器
  • Route 控制器负责适当地配置云平台中的路由，以便 Kubernetes 集群中不同节点上的 容器之间可以相互通信。
• 服务控制器
  • 服务（Service）与受控的负载均衡器、 IP 地址、网络包过滤、目标健康检查等云基础设施组件集成。 服务控制器与云驱动的 API 交互，以配置负载均衡器和其他基础设施组件。

Kubernetes 安全性

云原生安全

云原生安全4个C: 云(Cloud)、集群(Cluster)、容器(Container)和代码(Code)

云原生安全模型的每一层都是基于下一个最外层，代码层受益于强大的基础安全层（云、集群、容器）。我们无法通过在代码层解决安全问题来为基础层中糟糕的安全标准提供保护。

基础设施安全

Kubetnetes 基础架构关注领域

建议

通过网络访问 API 服务（控制平面)

所有对 Kubernetes 控制平面的访问不允许在 Internet 上公开，同时应由网络访问控制列表控制，该列表包含管理集群所需的 IP 地址集。

通过网络访问 Node（节点)

节点应配置为 仅能 从控制平面上通过指定端口来接受（通过网络访问控制列表）连接，以及接受 NodePort 和 LoadBalancer 类型的 Kubernetes 服务连接。如果可能的话，这些节点不应完全暴露在公共互联网上。

Kubernetes 云访问提供商的 API

每个云提供商都需要向 Kubernetes 控制平面和节点授予不同的权限集。为集群提供云提供商访问权限时，最好遵循对需要管理的资源的最小特权原则。Kops 文档提供有关 IAM 策略和角色的信息。

访问 etcd

对 etcd（Kubernetes 的数据存储）的访问应仅限于控制平面。根据配置情况，你应该尝试通过 TLS 来使用 etcd。更多信息可以在 etcd 文档中找到。

etcd 加密

在所有可能的情况下，最好对所有驱动器进行静态数据加密，但是由于 etcd 拥有整个集群的状态（包括机密信息），因此其磁盘更应该进行静态数据加密。

集群组件安全

• 运行的应用程序的安全性关注领域
  • 访问控制授权(访问 Kubernetes API)
  • 认证方式
  • 应用程序 Secret 管理 (并在 etcd 中对其进行静态数据加密)
  • Pod 安全策略
  • 服务质量（和集群资源管理）
  • 网络策略
  • Kubernetes Ingress 的 TLS 支持

容器安全

• 容器安全性关注领域
  • 容器搭建配置(配置不当,危险挂载, 特权用户)
  • 容器服务自身缺陷
  • Linux内核漏洞
  • 镜像签名和执行

代码安全

• 代码安全关注领域
  • 仅通过 TLS 访问(流量加密)
  • 限制通信端口范围
  • 第三方依赖性安全
  • 静态代码分析
  • 动态探测攻击(黑盒)

Kubernetes架构常见问题

Kubernetes ATTACK 矩阵

信息泄露

云账号AK泄露

API凭证（即阿里云AccessKey）是用户访问内部资源最重要的身份凭证。用户调用API时的通信加密和身份认证会使用API凭证.

API凭证是云上用户调用云服务API、访问云上资源的唯一身份凭证。

API凭证相当于登录密码，用于程序方式调用云服务API.

k8s configfile泄露

kubeconfig文件所在的位置:

$HOME/.kube/config

Kubeconfig文件包含有关Kubernetes集群的详细信息，包括它们的位置和凭据。

云厂商会给用户提供该文件,以便于用户可以通过kubectl对集群进行管理. 如果攻击者能够访问到此文件（如办公网员工机器入侵、泄露到Github的代码等），就可以直接通过API Server接管K8s集群，带来风险隐患。

Master节点SSH登录泄露

常见的容器集群管理方式是通过登录Master节点或运维跳板机，然后再通过kubectl命令工具来控制k8s。

云服务器提供了通过ssh登陆的形式进行登陆master节点.

若Master节点SSH连接地址泄露,攻击者可对ssh登陆进行爆破,从而登陆上ssh,控制集群.

容器组件未鉴权服务

Kubernetes架构下常见的开放服务指纹如下:

• kube-apiserver: 6443, 8080
• kubectl proxy: 8080, 8081
• kubelet: 10250, 10255, 4149
• dashboard: 30000
• docker api: 2375
• etcd: 2379, 2380
• kube-controller-manager: 10252
• kube-proxy: 10256, 31442
• kube-scheler: 10251
• weave: 6781, 6782, 6783
• kubeflow-dashboard: 8080

注:前六个重点关注: 一旦被控制可以直接获取相应容器、相应节点、集群权限的服务

了解各个组件被攻击时所造成的影响

组件分工图:

假如用户想在集群里面新建一个容器集合单元, 流程如下:

1. 用户与 kubectl进行交互,提出需求(例: kubectl create -f pod.yaml)
2. kubectl 会读取 ~/.kube/config 配置，并与 apiserver 进行交互，协议：http/https
3. apiserver 会协同 ETCD, kube-controller-manager, scheler 等组件准备下发新建容器的配置给到节点，协议：http/https
4. apiserver 与 kubelet 进行交互，告知其容器创建的需求，协议：http/https；
5. kubelet 与Docker等容器引擎进行交互，创建容器，协议：http/unix socket.
6. 容器已然在集群节点上创建成功

攻击apiserver

apiserver介绍:
在Kubernetes中,对于未鉴权对apiserver, 能访问到 apiserver 一般情况下就能获取了集群的权限.

在攻击者眼中Kubernetes APIServer

• 容器编排K8S总控组件
• pods, services, secrets, serviceaccounts, bindings, componentstatuses, configmaps,
• endpoints, events, limitranges, namespaces, nodes, persistentvolumeclaims,
• persistentvolumes, podtemplates, replicationcontrollers, resourcequotas …
• 可控以上所有k8s资源
• 可获取几乎所有容器的交互式shell
• 利用一定技巧可获取所有容器母机的交互式shell

默认情况下apiserver都有鉴权:

未鉴权配置如下:

对于这类的未鉴权的设置来说，访问到 apiserver 一般情况下就获取了集群的权限：

如何通过apiserver来进行渗透,可参考:https://Kubernetes.io/docs/reference/generated/kubectl/kubectl-commands

攻击kubelet

每一个Node节点都有一个kubelet(每个节点上运行的代理)服务，kubelet监听了10250，10248，10255等端口。

10250端口,是kubelet与apiserver进行通信对主要端口, 通过该端口,kubelet可以知道当前应该处理的任务.该端口在最新版Kubernetes是有鉴权的, 但在开启了接受匿名请求的情况下，不带鉴权信息的请求也可以使用10250提供的能力, 在Kubernetes早期,很多挖矿木马基于该端口进行传播.

在配置文件中,若进行如下配置,则可能存在未授权访问漏洞.

/var/bin/kubulet/config/yaml

若10250端口存在未授权访问漏洞,我们可以直接访问/pods进行查看

根据在pods中获取的信息,我们可以在容器中执行命令

curl -Gks https://host:10250/exec/{namespace}/{podname}/{containername} -d 'input=1' -d 'output=1' -d 'tty=1' -d 'command=whoami'

上述命令得到websocket地址，连接websocket得到命令结果：

使用wscat工具连接websocket

wscat -c “https://X.X.X.X:10250/{websocket}” --no-check

即可得到我们执行命令的结果.

获取token

/var/run/secrets/kubernetes.io/serviceaccount

然后即可访问kube-api server,获取集群权限

curl -ks -H "Authorization: Bearer ttps://master:6443/api/v1/namespaces/{namespace}/secrets

"

攻击kubelet总体步骤如下:

• 访问pods获取信息
• 获取namespace、podsname、containername
• 执行exec获取token
• /var/run/secrets/kubernetes.io/serviceaccount
• 利用Token访问API Server进行对pods操作。

攻击dashboard

dashboard登陆链接如下:

http://xxx.xxx.xxx.xxx:xxxx/api/v1/namespaces/kubernetes-dashboard/services/https:kubernetes-dashboard:/proxy/#/login

dashboard界面如下:

dashboard是Kubernetes官方推出的控制Kubernetes的图形化界面.在Kubernetes配置不当导致dashboard未授权访问漏洞的情况下，通过dashboard我们可以控制整个集群。

默认情况下, dashboard是需要进行鉴权操作的,当用户开启了enable-skip-login时可以在登录界面点击Skip跳过登录进入dashboard.

通过skip登陆的dashboard默认是没有操作集群的权限,因为Kubernetes使用RBAC(Role-based access control)机制进行身份认证和权限管理，不同的serviceaccount拥有不同的集群权限。

但有些开发者为了方便或者在测试环境中会为Kubernetes-dashboard绑定cluster-admin这个ClusterRole（cluster-admin拥有管理集群的最高权限）.

为Kubernetes-dashboard绑定cluster-admin 设置如下:

1. 新建dashboard-admin.yaml内容
2. apiVersion: rbac.authorization.k8s.io/v1kind: ClusterRoleBindingmetadata: name: kubernetes-dashboardroleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: cluster-adminsubjects : kind: ServiceAccount name: kubernetes-dashboard namespace: kubernetes-dashboard
3. kubectl create -f dashboard-admin.yaml

后通过skip登陆dashboard便有了管理集群的权限.

创建Pod控制node节点,该pod主要是将宿主机根目录挂载到容器tmp目录下。

新建一个Pod如下:

通过该容器的tmp目录管理node节点的文件

攻击etcd

Kubernetes默认使用了etcd v3来存储数据, 若能na
etcd对内暴露2379端口，本地127.0.0.1可免认证访问. 其他地址要带—endpoint参数和cert进行认证。

未授权访问流程:

• 检查是否正常链接
• etcdctl endpoint health
• 读取service account token
• etcdctl get / --prefix --keys-only | grep /secrets/kube-system/clusterrole
• 通过token认访问API-Server端口6443，接管集群：
• kubectl --insecure-skip-tls-verify -s https://127.0.0.1:6443/ --token="[ey...]" -n kube-system get pods

攻击docker remote api(Docker daemon公网暴露)

2375是docker远程操控的默认端口，通过这个端口可以直接对远程的docker 守护进程进行操作。Docker 守护进程默认监听2375端口且未鉴权.

当机器以方式启动daemon时，可以在外部机器对该机器的docker daemon进行直接操作：

docker daemon -H=0.0.0.0:2375

之后依次执行systemctl daemon-reload、systemctl restart docker

外部主机使用 即可操作暴露2375端口的主机.

-H

因此当你有访问到目标Docker API 的网络能力或主机能力的时候，你就拥有了控制当前服务器的能力。我们可以利用Docker API在远程主机上创建一个特权容器，并且挂载主机根目录到容器.

检测目标是否存在docker api未授权访问漏洞的方式也很简单，访问http://[host]:[port]/info路径是否含有ContainersRunning、DockerRootDir等关键字。

攻击kubectl proxy

二次开发所产生的问题

管理Kubernetes无论是使用 kubectl 或 Kubernetes dashboard 的UI功能，其实都是间接在和 APIServer 做交互.

如果有需求对k8s进行二次开发的话,大部分的开发功能请求了 APIServer 的 Rest API 从而使功能实现的。

例如:

• 给用户销毁自己POD的能力
• DELETE https://apiserver:8443/api/v1/namespaces/default/pods/sleep-75c6fd99c-g5kss

类似于这样去调用apiserver, 攻击者若修改namespace、pod和容器名, 那么即可造成越权.

推荐工具

Kube-Hunter扫描漏洞

kube-hunter是一款用于寻找Kubernetes集群中的安全漏洞扫描器

下载地址: https://github.com/aquasecurity/kube-hunter

CDK(强推)

CDK是一款为容器环境定制的渗透测试工具，在已攻陷的容器内部提供零依赖的常用命令及PoC/EXP。集成Docker/K8s场景特有的 逃逸、横向移动、持久化利用方式，插件化管理。

下载地址: https://github.com/cdk-team/CDK/wiki/CDK-Home-CN

参考链接

https://developer.aliyun.com/article/765449?groupCode=aliyunsecurity
https://xz.aliyun.com/t/4276#toc-2
https://www.secrss.com/articles/29544
https://kubernetes.io/zh/docs/concepts/workloads/pods/#what-is-a-pod
https://www.huweihuang.com/kubernetes-notes/concepts/architecture/kubernetes-architecture.html
https://www.kubernetes.org.cn/service-account
https://www.aquasec.com/cloud-native-academy/cloud-native-applications/cloud-native-infrastructure/
https://www.cdxy.me/?p=827

⑶ 云计算时代操作系统Kubernetes之PV，PVC存储体系

我们前边的关于存储卷的讨论，都是在讲如何将网络存储设备挂载到我们的应用程序POD中，而在实际项目上，我们必须对集群所提供存储技术和类型有深入的理解，才能顺利完成将支持类型的volume挂载到容器中，供应用程序来持久化数据。

举个例子，如果你使用的是托管的阿里巴巴ACK集群，需要使用OSS存储类型，那么你就必须定义对应的Persistent Volume，当我们将应用迁移到自己数据中心后，就需要定义数据中心Kubernetes环境支持的Persistent Volume对象，因此这种直接定义PV的方式，灵活性太差了。为了能在其他云平台上使用PV，我们就必须修改YAML文件，以适配新的环境。

我们一直强调Kubernetes标准化了应用程序的部署，特别是在多个云平台之间的跨云部署场景，每次都修改PV才能完成部署很明显有悖于我们介绍的Kubernetes理念。幸运的是，Kubernetes已经考虑了这个问题，并且提供了一种更加便利的机制来给POD增加存储资源。而我们通常把这种机制叫做PV/PVC体系。

理想情况下对于开发人员而言，部署应用程序到Kubernetes集群就不应该关心具体的存储技术和细节，就如同Kubernetes将工作节点进行抽象类型，开发人员面对的只有POD，而基础设施相关的部分应该让专业人士来处理，比如集群的运维人员和专业的devops团队。

正因为如此，我们在部署应用到Kuberntes集群的时候，我们很少直接设置具体存储的细节，而是通过一种间接的方式来使用PV提供的存储能力，如下图所示，这就把POD和底层具体的存储系统进行了解耦，POD的定义中不用在包含和具体基础设施相关的配置信息：

很多公司内部都会自己搭建NFS文件存储服务器，我们来举个例子，假设在POD中我们要使用NFS文件服务来共享数据，那么在volume的定义中就需要包含NFS文件服务器的IP地址和要挂载的目录路径，如下图所示：

注：网络文件系统（NFS）是文件系统之上的一个网络抽象，允许远程客户端以和本地文件系统类似的方式来通过网络进行数据访问。NFS允许在多个用户之间共享公共文件系统，并提供数据集中的优势，来最小化所需的存储空间。

这样做的结果是，我们将POD和具体的集群存储细节进行了耦合，从而降低了灵活性。如果我们要将如上这个POD部署到另外一个集群中，那么我们就需要修改NFS文件服务器的IP地址，修改YAML文件可能会产生错误，因此这种方式本质上说明POD跨Kubernetes集群部署的灵活性不足。如下图所示：

由于这个原因，我们需要将环境相关的配置信息抽取到另外一个叫PV的对象中，来解耦POD和具体存储信息，提升POD的兼容性。Kubernetes平台用PersistentVolume对象来代表集群中可以用来存储数据的volume，如下图所示，PersistentVolume对象将底层存储机制的详细信息从POD的YAML文件中解耦：

由于POD中不再包含基础设施相关的配置信息，兼容性得到了极大的提升。当然这些配置信息还是需要的，只是被转移到PV对象上而已。本上上来看，这其实并不是什么新技术。但是计算机从发展之初，通过增加一层来解决问题的方法，可以说是屡试不爽，我们应该在自己的架构设计中，多多考虑这样的思想，当然需要考虑复杂性和合理性，并不是说中间层越多越好。

笔者在上篇文章中介绍过使用阿里云OSS存储卷类型的例子，如果你还有印象的话，应该记得我们的配置文件中使用persistentVolumeClaim对象来定义数据卷，如下图所示。在Kubernetes平台中，通常POD间接的通过PVC映射到PV对象，这就让PV从POD的生命周期中进一步解耦。

如上图所示，PersistentVolumeClaim对象表示用户对存储资源的需求，由于用户在使用存储资源的时候，并不清楚集群中有哪些类型的Volume，因此Kubernetes就引入了这个PVC对象，来简化使用PV的复杂度。这样的话我们只需要在定义POD的时候，使用PVC对象即可，而在PVC对象的定义中，我们需要声明存储的需求，比如存储空间大小，访问模式等。

当POD运行完成退出的时候，会删除PVC，底层的PV会被释放，释放后的PV就可以被其他的PVC使用。接下来我们通过一个实际的例子看看如何定义PCV和PV存储模式。

比如我们现在已经在集群中创建了一个PV对象，指向NFS文件存储服务器；有一个PVC对象绑定到PV对象，这样我们就可以直接在POD的YAML中，数据卷定义部分直接指定PVC对象，不用设置详细的NFS文件服务器IP地址等。

如下图所示，当POD被调度到具体的工作节点时，Kubernetes负责通过PVC引用到PV对象，然后使用PV对象中配置的NFS文件服务器的信息将对应的目录挂载到容器中。

如上图所示，POD在创建的时候，会通过PVC引用的PV对象来定位到存储资源的具体信息，并将指定的目录挂载到容器实例上。表面看，通过三个对象来挂载存储资源很明显比一个要复杂，但是你有没有深入思考过Kubernetes为什么要如此设计？

其实这里最大的好处就是“解耦”，或者叫消除依赖。通过增加PV和PVC这两个对象，基础设施相关的信息和应用的部署YAML解耦了，让专业的人，集群管理员来负责PV的创建，开发人员的时间就可以放在更具价值的开发上，如果要部署，只需要使用PCV来声明自己的需求就可以了。如下图所示，我们来看看集群管理员开发人员是如何配合在一起，各司其职，成功将应用部署到Kubernetes集群上：

如上图所示，开发人员不用再面对具体底层的存储资源配置细节，集群管理员统一负责配置和管理所有的存储资源，并且在Kubernetes平台上通过创建PV对象来提供给应用程序使用。当开发人员在部署应用的时候，通过创建PVC来声明具体要使用的资源需求，比如直接指定PV对象的名称，或者指定请求的存储空间大小和访问模式，Kubernetes基于这些信息完成绑定。

接下来我们就可以在POD中定义volume的时候使用PCV，当POD被创建的时候，POD中运行的容器实例就可以将存储设备attach到工作节点，并将指定的目录挂载到容器的文件目录树中。大家需要特别注意的是，在PVC/PV模式下，开发人员不需要了解底层具体的存储设备信息，这部分工作属于专业人士集群管理员，开发人员只需要通过PVC来声明应用的存储资源需求。

进一步讲，如果我们的集群是托管实例，那么管理员甚至都不需要自己手动来进行PV的创建和管理，我们可以通过云平台提供的自动化volume提供机制，在有需要的时候，自动创建PersistentVolume和PersistentVolumeClaim对象，提供给应用程序使用。

通过上边的内容，相信读者对PVC/PV有全面的了解了，接下来我们来通过实际的例子来验证一下。由于笔者使用的Kubernetes环境支持的存储资源非常有限，但是又需要通过具体的例子来说明这些对象如何使用，笔者决定暂缓这部分内容到后续专门介绍如何在阿里云ACK上使用PV/PCV。

好了，今天的内容就这么多了，我们下篇文章会介绍云原生模式中一个非常重要的概念，如何让应用无状态，或者说如何管理应用程序的配置信息，敬请期待！

⑷ 从云计算到云原生：从概念到落地

云计算最近几年已经火得不行， 云原生 （Cloud Native）这个概念又来了，如果上云不“原生”，那就等于白上云。究竟什么是云原生？云原生有何优势？怎么从“不原生”一步一步做到云原生？本文将给出切实可行的云原生落地指南。

我们先从云计算说起 。在云计算普及之前，一个应用想要发布到互联网，就需要企业自己先买几台服务器，找一个IDC机房，租几个机架，把服务器放进去。接下来就是装Linux系统，部署应用。我们就假定用Java写了Web应用，怎么部署上去呢？先配置Tomcat服务器，在把编译好的war包上传到服务器，有用FTP的，安全意识高一点的会选SCP，然后配置Nginx、MySQL这些服务，最后一通调试，把应用跑起来，就算齐活。

这种物理机配合自搭网络环境、自搭Linux、自配环境的方式，有很多缺点，但最主要的问题有这么几个：

解决方案是上云 。上云不能解决所有问题，但部分解决了前两个问题：

但是如果仅仅满足上云，把物理机换成虚拟机，把物理网换成虚拟专用网（VPC），是远远不够的。这些是计算资源和网络资源层面的简化。应用方面，如果延续旧的一套开发、测试、部署流程，做不到快速迭代。

要做到快速迭代，敏捷开发，就需要DevOps，即开发运维由一个团队负责，开发阶段，就要把部署、运维的工作考虑进去，而不是发布一个war包或者jar包后扔给运维不管了。

重开发、轻部署，直接后果就是缺少自动化发布流程。想要把部署规范化，就需要整体考虑一系列问题。

还是以Java应用为例，如果是手动部署，那么就上传war包到服务器，覆盖原有的版本，重启Tomcat，再测试。如果发现有严重问题要回滚怎么办？把老版本再传一遍，然后重启Tomcat。

手动部署，每次部署都是一次生死考验，所以最好不要安排在半夜，以免手抖敲错了命令，本来中断10分钟的服务，变成了灾备恢复，中断3天。

稍微靠谱一点的是写脚本部署，但各家写出来的脚本都有各家特色，不通用，不易维护，所以更好的方式是用成熟的部署方案，比如Ansible，把脚本标准化，比如做成蓝绿发布，把服务器分组，比如A、B两组，先把流量切到B组，升级A组服务器，有问题就回滚，没问题了，再把流量切到A组，升级B组服务器，最后，恢复正常流量，整个部署完成。

但是回滚这个事情，远没有那么简单。做过开发的同学都知道，升级新版本，一般要加配置，改配置，如果回滚到旧版本，忘了把配置改回去，那旧版本可能也不能正常工作。

上云，除了物理变虚拟，简化运维外，最重要的特点——弹性计算，一定要充分利用。

理论指导实践，实践完善理论。如果我们分析大多数基于互联网的应用，可以看到，一个应用，通常用到的资源如下：

上云后，云服务商通常都提供托管的数据库，以及大规模存储系统（S3），可解决存储资源问题。通过云服务商提供的负载均衡（Load Balancer），也无需自行部署Nginx等网关，免去了运维的问题。各种标准的业务组件如Redis、Kafka等，均可直接租用云服务商提供的资源。

我们重点讨论计算资源，也就是云上的虚拟机资源。对于应用来说，可以设计成有状态和无状态两种。一个应用在一台虚拟机内跑着，如果有本地文件的修改，它就是有状态的。有状态的应用既不利于扩展，也不利于部署。反过来，如果一个应用在运行期数据总是存在数据库或者缓存集群，本地文件无任何修改，它就是无状态的。

无状态的应用对应的虚拟机实际上就是不变的计算资源。这里的“不变”非常重要，它是指，一台虚拟机通过一个固定的镜像（预先内置好必要的支持环境，如JRE等）启动后，部署一个应用（对应一个war包或者jar包），该虚拟机状态就不再变化了，直接运行到销毁。

有的同学会问：如果给这台虚拟机重新部署一个新的应用版本，它的状态不就发生了变化？

确实如此。为了确保虚拟机的不变性，一旦启动后部署了某个版本，就不允许再重新部署。这样一来，对虚拟机这种计算资源来说，就具有了不变性。不变性意味着某个虚拟机上的应用版本是确定的，与之打包的配置文件是确定的，不存在今天是版本1，明天变成版本2，后天回滚到版本1的情况。

计算资源不变，能确保启动一台虚拟机，对应发布的应用版本和配置是确定的且不变的，对于运维、排错非常重要。

那么如何在保持计算资源不变的前提下发布新版本？

我们以AWS的CodeDeploy服务为例，假设一组正在运行的某应用v1集群包含3台虚拟机：

现在，我们要把应用从v1升级到v2，绝不能直接把现有的3台虚拟机的应用直接升级，而是由CodeDeploy服务启动3台新的一模一样的虚拟机，只是部署的应用是v2。现在，一共有6台虚拟机，其中3台运行v1版本，另外3台运行v2版本，但此刻负载均衡控制的网络流量仍然导向v1集群，用户感受不到任何变化：

v2集群部署成功后，做一些自动化冒烟测试和内网测试，如果有问题，直接销毁，相当于本次部署失败，但无需回滚。如果没有问题，通过负载均衡把流量从v1集群切到v2，用户可无感知地直接访问v2版本：

稳定一段时间（例如15分钟）后，销毁v1集群。至此，整个升级完成。

上述的蓝绿部署就是CodeDeploy的一种标准部署流程。CodeDeploy也支持灰度发布，适用于更大规模的应用。

把计算资源不可变应用到部署上，实际上是充分利用了弹性计算这个优势，短时间创建和销毁虚拟机，只有上云才能做到，并且针对云计算，把部署流程变得更加简单可靠，每天发几个版本甚至几十、几百个版本都变得可能，DevOps能落地，有点“云原生”的味道了。

说到AWS的CodeDeploy，最早我使用AWS时，对于它的计费采用Reserved Instance预付模型感到很不理解，租用一台虚拟机，按国内阿里云、腾讯云包年包月预付享折扣不是更直观吗？如果仅仅把上云变成租用虚拟机，那就完全丧失了弹性计算的优势，相当于租用了一台虚拟机在里面自己折腾。AWS的Reserved Instance计费并不绑定某一台虚拟机，而是一种规格的虚拟机。

我们还是举例说明，如果我们有1台2v4G规格的虚拟机，并购买了1年的Reserved Instance，那么，我随时可以销毁这台虚拟机，并重新创建一台同样规格的新的虚拟机，Reserved Instance计费会自动匹配到新的虚拟机上，这样才能实现计算资源不变，频繁实施蓝绿部署，真正把部署变成一种云服务。最近阿里云终于推出了节省计划的付费模式，有点真正的云计算的付费味道了，但是腾讯云、华为云还停留在包年包月和按量付费这两种原始租赁模型。

讲了这么多自动化部署，实际上一个指导思想就是如何充分利用云的弹性计算资源。从充分利用云的弹性资源为出发点，设计一整套开发、部署、测试的流程，就是云原生。弹性资源利用得越充分，云原生的“浓度”就越高，就越容易实施小步快跑的快速迭代。

那么虚拟机是不是弹性最好的计算资源呢？从应用的角度看，显然容器是一种比虚拟机更具弹性，更加抽象，也更容易部署的计算资源。

容器和虚拟机相比，它实际上是一种资源隔离的进程，运行在容器中的应用比独占一个虚拟机消耗的资源更少，启动速度更快。此外，容器的镜像包含了完整的运行时环境，部署的时候，无需考虑任何额外的组件，比其他任何部署方式都简单。使用容器，开发部署流程就变成了开发，生成镜像，推送至Docker Hub或云服务商提供的Registry，直接启动容器，整个过程大大简化。

使用容器比使用CodeDeploy部署还要更加简单，因为CodeDeploy需要在虚拟机镜像中预置Agent，由于没有统一的发布标准，还需要配置CodeDeploy，告诉它去哪拉取最新版本，这又涉及到一系列权限配置。而容器作为标准的部署方案，连发布系统都以Registry对各个镜像版本进行了有效管理，所以部署非常简单。

容器作为一种弹性计算资源，也应遵循计算不变性，即不要给容器挂载可变的存储卷。一组不变的容器集群才能更容易地升级。容器的运行方式本身就遵循了不变性原则，因为通过一个镜像启动一个容器，在运行过程中，是不可能换一个镜像的。容器本身也强烈不建议应用写入数据到文件系统，因为重启后这些修改将全部丢失。

容器的启动和销毁非常容易，不过，容器的管理却并不简单。容器的管理涉及到创建、调度、弹性扩容、负载均衡、故障检测等等，Kubernetes作为事实上的容器编排标准平台，已经成为各个云服务商的标配。

如果要直接使用K8s，在云环境中首先要有一组虚拟机资源作为底层资源，然后搭建K8s环境，定义好容器编排并启动容器。云服务商几乎都提供托管的K8s服务，但直接管理K8s仍然需要非常熟悉K8s的工程师。

还有一种更简单的使用容器的方式，即完全将底层虚拟机和K8s托管给云服务商，企业客户只需关心如何部署容器，底层的K8s和虚拟机对企业不可见或者无需关心。AWS的Elastic Container和阿里云的弹性容器均为此类服务。对于中小规模的应用来说，计算资源直接使用容器，再配合云服务商提供的负载均衡，托管的数据库、消息系统、日志系统等组件服务，应该是目前最“云原生”的一种方案。

最后，我们总结一下云原生的特点：

所谓云原生，就是在上云的过程中，充分发挥云平台的弹性计算、弹性存储的优势，尽量把应用设计成适合云计算的架构，把部署设计成简单易用的流程，这样才能实现业务快速上线，快速迭代。

云原生是一个大方向，在上云的过程中，逐步改造应用架构和部署流程，从手动往自动转，逐步增加计算资源的弹性，就能把云原生一步步落地。

⑸ kubernetes 提供什么功能

Kubernetes，是开源容器应用自动化部署技术，也就是大家经常说的k8s。

Kubernetes（k8s）是自动化容器操作的开源平台，这些操作包括部署，调度和节点集群间扩展。如果你曾经用过Docker容器技术部署容器，那么可以将Docker看成Kubernetes内部使用的低级别组件。Kubernetes不仅仅支持Docker，还支持Rocket，这是另一种容器技术。

使用Kubernetes可以：

• 自动化容器的部署和复制

• 随时扩展或收缩容器规模

• 将容器组织成组，并且提供容器间的负载均衡

• 很容易地升级应用程序容器的新版本

• 提供容器弹性，如果容器失效就替换它，等等...

它有这些特点：

• 可移植：支持公有云，私有云，混合云，多重云 multi-cloud

• 可扩展：模块化，插件化，可挂载，可组合

• 自动化：自动部署，自动重启，自动复制，自动伸缩/扩展

如果还有想要了解的可以到官网或是相关教程视频中看看，比如B站这个视频教程：

⑹ 好雨云帮为什么采用K8s，而不用Docker Swarm

用过就知道了K8s比Docker Swarm还是要强一些些的……k8s api简直不要太好用……

⑺ K8S安装和创建集群终极教程（单master多worker）

本文会以 最简单 、 最直接 、 最完整 的方式记录kubernetes（下面统称K8S）单master多工作节点（worker nodes）的集群步骤

首先要简单了解一下本文的3个核心概念：

内存建议至少4G

问：如何查看主机名？

答：执行命令hostname

问：如何修改主机名？

答：永久生效的做法：执行命令vi /etc/hostname，把第一行去掉（不能注释掉，要去掉），然后重新写上自定义的主机名（注意命名规范），保存并重启后生效；

临时生效的做法：执行以下命令

问：如何查看MAC地址？

答：执行命令ip link，然后看你的第一网卡

问：如何查看proct_uuid？

答：执行命令sudo cat /sys/class/dmi/id/proct_uuid

注意：30000-32767这个端口范围是我们创建服务的端口必须要设置的一个范围（如果设置范围以外的会有限制提示并创建失败），这是K8S规定的。

另外，如果你要直接关闭防火墙可以执行

⑥必须禁用Swap

Swap total大于0，说明Swap分区是开启的

问：如何关闭Swap？

答：编辑文件/etc/fstab，在swap行前面加上#号注释， 保存并重启服务器

再次查看分区状态，已生效

常见的容器引擎（Container runtime，简称runtime）：

本文使用的容器引擎是Docker

安装完成后查看版本：

当出现可能跟Docker引擎相关的奇怪异常时可以尝试把Docker卸载干净并重新安装，但一定要注意镜像、容器、卷或配置文件这些是否需要备份。

下面记录卸载Docker引擎的步骤：

①卸载 Docker Engine、CLI 和 Containerd 包：

②主机上的映像、容器、卷或自定义配置文件不会自动删除。删除所有镜像、容器和卷：

③配置文件如果有不合法的字符时会导致启动失败，我们需要将其删除然后重建

此时Docker引擎已卸载干净

官网用的是谷歌的yum源，因为国内是连不上的，所以这里替换成阿里提供的yum源

①安装

从安装信息中可以看到版本号是1.22

Installing:

kubeadm x86_64 1.22.4-0 kubernetes 9.3 M

kubectl x86_64 1.22.4-0 kubernetes 9.7 M

kubelet x86_64 1.22.4-0 kubernetes 20 M

②启动

这就是一个驱动程序，注意cgroup和cgroupfs不要混淆了

引用官方的一段话

“由于 kubeadm 把 kubelet 视为一个系统服务来管理，所以对基于 kubeadm 的安装， 我们推荐使用 systemd 驱动，不推荐 cgroupfs 驱动。”

kubeadm默认是使用systemd 驱动，而我们的Docker默认驱动是cgroupfs（docker info可以查看），所以需要将Docker的驱动改成systemd

①编辑Docker配置文件

②重启Docker服务

再次docker info查看驱动信息已变成了systemd

工作节点（worker nodes）的最小配置就到这里了

①镜像源参数说明

默认情况下, kubeadm 会从 k8s.gcr.io 仓库拉取镜像，国内是拉不了的。官方文档明确表示允许你使用其他的 imageRepository 来代替 k8s.gcr.io。

--image-repository 你的镜像仓库地址

接下来我找了一些国内的镜像源，并简单做了下分析

综合上述统计，我选择阿里云的镜像源

②ip地址范围参数说明

--pod-network-cidr =192.168.0.0/16

注意:如果192.168.0.0/16已经在您的网络中使用，您必须选择一个不同的pod网络CIDR，在上面的命令中替换192.168.0.0/16。

集群初始化命令：

因为我用的是演示机器，所以这里把完整的执行信息都贴出来方便查阅，平时工作中一定要注意保护好敏感的信息（我的ip地址范围是自定义的便于下面的功能演示，另外初次init需要下载镜像文件，一般需要等几分钟）

如上所示，集群初始化成功，此时一定要注意看上面执行结果最后的那部分操作提示，我已用标明了初始化成功后还需要执行的3个步骤

注意：如果init成功后发现参数需要调整，可以执行kubeadm reset，它的作用是尽最大努力恢复kubeadm init 或者 kubeadm join所做的更改。

To start using your cluster, you need to run the following as a regular user:

翻译：开始使用集群前，如果你是普通用户（非root），你需要执行以下的命令：

Alternatively, if you are the root user, you can run:

翻译：或者，如果你使用的是root，你可以执行以下命令：

（注意：export只是临时生效，意味着每次登录你都需要执行一次）

网络配置配的就是Pod的网络，我的网络插件选用calico

cidr就是ip地址范围，如果您使用 pod CIDR 192.168.0.0/16，请跳到下一步。

但本文中使用的pod CIDR是192.100.0.0/16，所以我需要取消对清单中的 CALICO_IPV4POOL_CIDR 变量的注释，并将其设置为与我选择的 pod CIDR 相同的值。（注意一定要注意好格式，注意对齐）

可根据需求自定义清单，一般不需要的就直接跳过这步

在所有的工作节点上执行join命令（复制之前初始化成功后返回的加入集群命令到所有的工作节点执行即可）

master上查看所有节点的状态

到这里集群已经创建完成

最后我再安装K8S的可视化界面kubernetes-dashboard，方便我们日常使用

①下载yaml文件

②修改yaml文件，新增type和nodePort，使服务能够被外部访问

③安装并查看运行情况

④新建用户

文件创建完成后保存并apply

⑤获取Token，用于界面登录

⑥登录dashboard

192.168.189.128是我的master服务器ip，另外要注意必须使用https，并且不能使用ie内核模式

复制⑤生成的token到输入框，点击登录

dashboard安装配置完成

问：如何在查看资源情况？

答：在master上执行以下命令可查看资源情况（-o wide是显示更详细的信息），

①查看所有节点

②查看所有命名空间

③查看命名空间下的pod

④查看所有命名空间的pod

⑤实时查看查看命名空间下的pod运行情况

问：kubeadm join 出现异常[ERROR Port-10250]: Port 10250 is in use，如何解决？

答：这是因为你之前join失败过了，需要先执行kubeadm reset再重新join

问：虚拟机上测试时网卡突然消失如何解决（题外问题记录）？

答：

①确认丢失的网卡信息，ens开头（可选步骤）

ifconfig -a

②执行以下命令解决

问：如何查看K8S版本？

答：kubectl version

问：join命令忘记或者过期了怎么办？

答：

生成永不过期的

生成时效24小时的

问：Pod不断重启并且无其它报错信息时怎么办？

答：这种情况通常是因为你的集群中只有master，没有worker节点，master的创建默认是有污点的，即不允许调度新的Pod，如果你需要（当然这并不推荐），就需要删除 master 上的污点。删除污点可以执行以下命令，

它应该返回以下内容。

⑻ 云和k8s哪个更有前途

k8s
k8s是一个开源的容器集群管理系统，可以实现容器集群的自动化部署、自动扩缩容、维护等功能。
原因是k8s是容器管理编排引擎，一般配合docker容器使用。容器化的优势是快速部署、轻量化、弹性扩容和可移植。docker相对于虚拟化KVM，优势是启动快、资源占用小，通过namespace和cgroup实现资源调配和隔离，缺点是隔离性不好，依赖宿主机内核。
k8s可以更快的更新新版本，打包应用，更新的时候可以做到不用中断服务，服务器故障不用停机，从开发环境到测试环境到生产环境的迁移极其方便，一个配置文件搞定，一次生成image，到处运行。