k8s服务案例开发（sprintboot）

国际惯例，以helloworld工程为例，从restful工程开发，打包，docker镜像制作。Ingress+service+pod的方式发布服务的例子。

由于没有远程镜像服务器，采用本地镜像的方式加载服务。

镜像设置成本地策略：

  spec:

      containers:

        - name:

          image:

          imagePullPolicy: IfNotPresent

在开发之前，我们先了解一下k8s的命名空间，命名空间可以帮助我们管理和隔离pod等组件，增加权限租户管理等 *** 作。

以本文为例，创建一个名为dwayne的命名空间，新建一个create-namespaceyaml文件，内容如下

apiVersion: v1

kind: Namespace

metadata:

  name: dwayne

  labels:

    name: dwayne

执行kubectl apply -f create-namespaceyaml

设置成默认命名空间

kubectl config set-context $(kubectl config current-context) --namespace=dwayne

工程很简单，一个get接口/helloworld，返回json

package comexampledemo;
import orgspringframeworkwebbindannotationRequestMapping;

import orgspringframeworkwebbindannotationRequestMethod;

import orgspringframeworkwebbindannotationRestController;
@RestController

public class AController {

    @RequestMapping(value = "helloworld", method = RequestMethodGET)

    public Response hello() {

        Response res = new Response();

        ressetMsg("helloworld");

        return res;

    }

}

打包成jar包，demo-001-SNAPSHOTjar

在节点服务器（所有节点）上新建目录作为工作目录，将jar包上传到节点服务器，并在同一目录下编辑Dockerfile：

FROM java:8

VOLUME /tmp

ADD demo-001-SNAPSHOTjar /demo-001-SNAPSHOTjar

ENTRYPOINT ["java","-Djavasecurityegd=file:/dev//urandom","-jar","/demo-001-SNAPSHOTjar"]
保存Dockerfile，退出，执行docker build命令

docker build -t demo-hello-world-master  

生成demo-hello-world-master，先打个tag，方便后续使用:

docker tag demo-hello-world-master dw/demo-hello-world-master
这里部署两个helloworld服务实例（replicas: 2）。部署在dwayne命名空间,yaml文件内容如下：

apiVersion: v1

kind: Service

metadata:

  name: helloworld-master

  namespace: dwayne

spec:

  type: NodePort

  selector:

    app: helloworld

    release: master

  ports:

      - port: 7071

        targetPort: 17001

        nodePort: 30002

---

apiVersion: apps/v1

kind: Deployment

metadata:

  name: helloworld-master

  namespace: dwayne

spec:

  replicas: 2

  selector:

    matchLabels:

      app: helloworld

      release: master

  template:

    metadata:

      labels:

        app: helloworld

        release: master

    spec:

      containers:

        - name: demo-hello-world-master

          image: dw/demo-hello-world-master

          imagePullPolicy: IfNotPresent

          ports:

            - name: >

Kubernetes 是一个跨主机集群的开源的容器调度平台，它可以自动化应用容器的部署、扩展和 *** 作 , 提供以容器为中心的基础架构。谷歌旗下开源软件，江湖人称K8S。

上图是一个通过K8S搭建的集群环境，采用三台物理机搭建(三台机器是K8S搭建集群的最低要求)，我先简单介绍一下几个重点名词。

Centos 7 Master  1 (注意必须是双核以上的CPU，否则无法初始化K8S)

Centos 7 Node  2

将文件上传至该目录

网盘地址： >

提取码：aew7

执行以下命令

如果不是groupfs,执行下列语句

将最后一行注释

运行docker images可以看到以下几个关键应用

kube-proxy 容器间通讯代理、kube-apiserver API服务端、kube-scheduler 任务调度器、kube-controller-manager 集群控制器、coredns  K8S内置的 DNS 服务器、etcd 用于保存集群所有的网络配置和对象的状态信息、pause前面已经提到用于容器间的通讯以及数据卷的挂载。至此K8S安装完成

图中的第一个红框的命令是需要管理员手动复制，然后在master服务器上执行的。

PS: adminconf是kubeadm集群管理的核心配置文件，包含整个集群各个节点的授权信息，以及本身的一些配置信息

第二个红框中的命令是在node节点上执行，里面包含了一个加入集群的token认证信息以及ca证书的hashcode。通过该token可以加入K8S集群

从图中看到master节点处于NotReady状态，说明节点中存在有问题的Pod，查看存在问题的pod，执行以下命令查看所有Pod状态

如果某个Pod的STATUS处于CrashLoopBackOff状态表示创建失败了，那么它会不断自动重新创建。上图中两个coredns处于pending状态，原因是我们没有配置K8S网络通讯协议fannel，从上传的文件中加载并创建flannel网络组件

3在node节点上执行刚刚由kubeadm生成的节点加入命令

如果出现反复无法加入节点的情况，运行 kubeadm reset 这条命令还原当前节点上 kubeadm init 或者 kubeadm join 所做的所有更改。当想加入新节点忘记token时可以使用 kubeadm token list 查看token，或者 kubeadm token create创建token,采用跳过ca安全认证的方式加入节点。

4三台机器设置kubelet开机自启,至此通过kubeadm集群配置完成

在主节点上执行以下命令，以下三个配件都是已经配置好的，装载即可。

图中dashboard服务已经被创建，配置文件中关闭了密码验证，只需要浏览器打开 >

Kubernetes（简称K8S） 是Google开源的分布式的容器管理平台，方便我们在服务器集群中管理我们容器化应用。

节点 （Master node and Worker node）
节点通常指的就是服务器，在k8s中有两种节点：管理节点（Master Node）和工作节点（Worker Node）
管理节点（Master Node）：负责管理整个k8s集群，一般由3个管理节点组成HA的架构。
工作节点（Worker Node）：主要负责运行容器。

命名空间 (Namespace)
k8s命名空间主要用于隔离集群资源、隔离容器等，为集群提供了一种虚拟隔离的策略；默认存在3个名字空间，分别是默认命名空间 default、系统命名空间 kube-system 和 kube-public。

Object
k8s 对象(Object)是一种持久化存储并且用于表示集群状态的实体。k8s 对象其实就是k8s自己的配置协议，总之我们可以通过定义一个object让k8s根据object定义执行一些部署任务、监控任务等等。

POD
Pod是 Kubernetes 部署应用或服务的最小的基本单位。一个Pod 封装多个应用容器（也可以只有一个容器）、存储资源、一个独立的网络 IP 以及管理控制容器运行方式的策略选项。

副本集 (Replica Set，RS)
是一种控制器，负责监控和维护集群中pod的副本(replicas)数，确保pod的副本数是我们期望的样子。

部署 (Deployment)
表示对k8s集群的一次更新 *** 作，是k8s集群中最常用的Object，主要用于部署应用。支持滚动升级。

服务 (service)
是对应用的抽象，也是k8s中的基本 *** 作单元，一个服务背后由多个pod支持，服务通过负载均衡策略将请求转发到容器中。

Ingress
是一种网关服务，可以将k8s服务通过>

无状态应用 & 有状态应用

无状态应用指的是应用在容器中运行时候不会在容器中持久化存储数据，应用容器可以随意创建、销毁；如果一个应用有多个容器实例，对于无状态应用，请求转发给任何一个容器实例都可以正确运行。例如：web应用

有状态应用指的是应用在容器中运行时候需要稳定的持久化存储、稳定的网络标识、固定的pod启动和停止次序。例如：mysql数据库

回顾2019年中国云计算产业的发展，趁着“产业互联网”火热的东风，云计算也一路高歌前行。阿里巴巴、腾讯、百度、华为等 科技 互联网巨头企业都在持续布局。

Salesforce与阿里巴巴达成战略合作，阿里巴巴推出政务钉钉，百度云升级为百度智能云，百度推出爱番番CRM开放平台，销售易获腾讯独家12亿美元E轮融资，腾讯云全面升级d性计算产品序列，计算性能提升30%；金山办公正式登陆科创板上市、华为新成立“华为云计算技术有限公司” ……这些“新鲜“的云计算故事，也都曾轰动一时，甚至时至今日，仍对云计算领域影响至深。

2020年刚起步，中国云计算“第一股”——UCloud成功登陆科创板，成为众多业内人士在武汉的新型冠状病毒肺炎爆发前，最关注的"热点”之一。

展望2020年，亿欧智库坚定看好云计算领域的发展机会，并将持续输出云计算产业细分领域，如PaaS、SaaS、云安全等领域的研究报告。

值得注意的是，亿欧智库此前发布的《2019年中国云计算行业发展研究报告》所总结的六条云计算产业发展趋势依旧具备长期预判价值。以下列出概括性的内容，具体详见报告正文：

基于此，亿欧智库进一步总结云计算产业的未来发展趋势，帮助业内人士更加及时把握云计算产业最新发展机遇。本篇将重点介绍五条云计算产业有希望快速落地或爆发的主流技术：

无服务器计算（Severless Computing，以下简称Serverless）是一种包含第三方BaaS（后端即服务）服务的应用程序设计方式，与包括FaaS（函数即服务）平台上的托管临时容器中运行的自定义代码。与很多技术趋势一样，Serverless至今还没有明确且清晰的定义，对于开发人员来说，其重点代表两个截然不同但有重合的概念：

Serverless相比IaaS和SaaS，可以更好更快的在云服务商平台上部署应用，完全不用提前测算资源需求，所有功能根据事件驱动，按需加载，执行完毕，资源释放，真正实现了用多少付费多少，降低成本的同时，还提高了开发人员的生产力。

Serverless主要适合于新兴的、事件驱动性的，类似于IoT等传感设备、金融交易类型等场景。

Serverless兴起于2017年，在最近两年伴随云原生概念的推广逐渐火热。

目前 Serverless 在国内的发展和采用依然处于初期阶段，业务实践偏少，仍在不断 探索 之中。相比之下，国外整体要领先 1-2 年，国外几大云厂商前期对整个研发生态的教育和布局较多，应用较早。

现在国外也已经出现不少 Serverless 框架，比较知名包括 Serverlesscom 和 Zeitcom。

根据RightScale的2018年云状态报告，无服务器是当今增长速度很快的云服务模型，年增塑达75%，并有望于2020年超越该增速。亿欧智库也对Serverless的增长速度和市场规模持乐观态度。

Kubernetes（以下简称K8s） 是一个针对容器应用，进行自动部署，d性伸缩，和管理的开源系统。主要负责在大规模服务器环境中管理容器组（pod）的扩展、复制、 健康 ，并解决 pod 的启动、负载均衡等问题。

K8s 能在实体机或虚拟机集群上调度和运行程序容器。K8s 也能让开发者斩断联系着实体机或虚拟机的“锁链”，从以主机为中心的架构跃至以容器为中心的架构。该架构最终提供给开发者诸多内在的优势，例如可移动、可扩展、自修复等。

K8s 也能兼容各种云服务提供商，例如 Google Cloud、Amazon、Microsoft Azure，还可以工作在 CloudStack、OpenStack、OVirt、Photon、VSphere。

K8s 源于 Google 内部的 Borg 项目，经 Google 使用 Go 语言重写后，被命名为Kubernetes，并于 2014 年 6 月开源。目前已有多家大公司，例如 Microsoft、 RedHat、 IBM、Docker，都支持K8s。

从近年来国外K8s发展来看， 巨头公司为自有K8s部门增添活力或构建全新产品的有效手段之一为收购 。

随着专注于容器初创公司逐渐增加，预计2020年各大云服务商将继续收购表现优秀的容器初创公司，以进军K8s市场，完善其产品体系。

不可否认，K8s作为一项新兴技术距全球普及它还有很长的路要走。但很明显，K8s已经是，并且将继续是软件世界中的主导力量。

服务网格（Service Mesh）是用于控制和监视微服务应用程序中的内部服务到服务流量的软件基础结构层。服务网格的独特之处在于它是为适应分布式微服务环境而构建的。

服务网格的兴起主要是为了解决Docker和Kubernetes无法解决的运行问题。因为诸如Docker和Kubernetes这样的工具主要解决的是部署的问题。但部署不是生产的最后一步，部署完之后，应用程序还必须运行，服务网格因解决运行问题应运而生。

2016年服务网格提出之后，以Linkerd和Envoy为代表的框架开始崭露头角。目前市面上没有现成的商业产品，大多数服务网格都是开源项目，需要一些技巧才能实现。最著名的有：

关于服务网格技术的并购目前也逐渐升温，著名的并购案有VMware在2019年7月以42亿美元收购了Avi Networks以及F5 Networks在2019年5月斥资25亿美元收购了NGINX。

2019年是被确定是适合解决服务网格问题的一年，2020年将会是核心服务网格用例出现的一年。

开源软件（Open Source Software，以下简称OSS）被定义为描述其源码可以被公众使用的软件，并且此软件的使用，修改和分发也不受许可证的限制。

1998年2月，“开源”一词首先被运用于软件。最初的开源软件项目并不是真正的企业，而是一些顶级程序员针对Microsoft、Oracle、SAP等老牌闭源公司对软件收费较高的一场革命。顶级开发人员通常以异步方式协同编写一些出色的软件。每个人不仅可以查看公开的软件，而且通过一种松散的治理模型，他们可以添加，改进和增强它。这是第一代的开源软件项目。

而经过10多年的发展，Linux、MySQL的成功为第二代开源软件公司奠定基础，比如Cloudera和Hortonworks。但第二代开源软件公司中，没有一家公司对软件拥有绝对的控制权，对手经常通过免费提供软件来进行竞争。

之后出现了像Elastic、Mongo和Confluent等第三代开源软件公司提供的Elastic Cloud，Confluent Cloud和MongoDB Atlas这样的服务，这种进化代表着开源软件公司这种模式有机会成为软件基础设施的主要商业模式。

经过22年的发展，如今OSS已经无处不在。OSS领域也发声了一些“大事件”：IBM以320亿美元的价格收购了Redhat（是2014年市值的3倍）；Mulesoft在上市后以65亿美金的价格被Salesforce收购；MongoDB现在市值超过40亿美元；Elastic则为60亿美元；并且，通过Cloudera和Hortonworks的合并，将出现一个市值超过40亿美元的新公司……

当然还有很多OSS的公司在路上，例如Confluent、HashiCorp、DataBricks、Kong、Cockroach Labs等。

展望2020年，OSS的理念将与云计算SaaS（软件即服务）的理念更加契合，将大大推动软件产业的创新，并有机会迎来新一轮的发展高潮。

高性能计算（High Performance Computing，以下简称HPC）指能够执行一般个人电脑无法处理的大资料量与高速运算的电脑，其基本组成组件与个人电脑的概念无太大差异，但规格与性能则强大许多。

HPC能够在非常短的时间内执行大量计算，正从过去主要传统科研领域计算密集型为主，逐渐向新兴的大数据、人工智能以及深度学习等方向进行融合和演进。

从应用领域来看，HPC是不同行业中非常专业的领域，可以用于预报天气，也可以是分析风险，还可以分析农场数据，以根据不断变化的天气条件找到最佳的农作物种植地点。

在中国市场当中，主要有联想、浪潮和曙光三家公司处于领先的地位，占据了超过90%的市场份额。这三家公司作为中国HPC市场的状元、榜眼和探花，共同将中国HPC推上了世界第一的位置。

其中，联想连续五年蝉联“HPC China TOP100榜单”第一名，并于2019年11月8日发布“深腾X9000”高性能融合计算平台，该平台在兼顾算的更快、更准、更全面的同时，也使联想成为HPC绿色数据中心的积极倡导者，继续领跑HPC水冷解决方案。

除此之外，联想还在全球160多个国家开展众多领域的突破性研究，这些领域包括癌症、大脑研究、天体物理学、人工智能、气候科学、化学、生物学、 汽车 和航空等。

公开调研资料显示，2018年企业中使用了HPC的比例是36%。随着云计算领域的基础设施完备、资源和数据的增加，HPC的需求也将在2020年有所增加，云服务商有望对HPC进行投资。

众所周知，技术的进步对产业发展和创新具有积极推动作用。

正如近年来区块链、5G、机器学习等技术的发展对传统产业的转型促进一样，Serverless、Service Mesh、K8s、OSS、HPC这些云技术也必将提升IaaS、PaaS、SaaS等传统云计算模式的d性、灵活性、计算能力等，并与传统模式融合互补，协同助推各产业转型升级。

推荐阅读：

千淘万漉，吹尽黄沙，中国智能制造哨声洪亮 | 预见2020

2020银行业展望：对外开放加快，理财转型提速， 科技 深度赋能……

2020物流业新态势：巨头效应显著、 科技 赋能、智慧物流建设加快……

拨云见日，始得真金，产业互联网迎来高光时刻丨预见2020

预见2020：日新月异的中国保险业

容器编排就是有关管理容器生命周期的全部工作，特别是在大型动态环境中。 软件团队使用容器编排来控制和自动化许多任务：

•运行中的Kubernetes集群包含节点代理（kubelet）和集群控制平面（AKA主节点），集群状态由分布式存储系统（etcd）支持

除了核心组件，还有一些推荐的插件，其中有的已经成为CNCF中的托管项目：

Controller Manager 用于实现 Kubernetes 集群故障检测和恢复的自动化工作。Controller Manager 主要负责执行以下各种控制器：

Kubelet 「节点上的 Pod 管家」

Proxy「负载均衡、路由转发」

Kubectl 「集群管理命令行工具集」

客户端访问 ——> service1 ——> Pod1 ——> service2 ——>Pod2

所有的Pod之前的访问都是由其service来代理的，当Pod间知道相应的Pod的IP后，就会直接进行通信，可以理解为DNS的作用。

• Pod - 一组容器

• 标签 - 用于识别Pods的标签

• Kubelet - 容器代理

• kube-proxy - Pod的负载平衡器

• etcd - 元数据服务

• cAdvisor - 容器顾问提供者资源使用/性能统计

• Replication Controller - 管理Pod的复制

• Scheduler- 调度工作节点中的Pod

• API Server - Kubernetes API服务器

管理Pod | 复制集

处理复制和推出 | 部署

提供自我修复功能 | 守护程序集

使用个Pod模板制作真实的Pods | 工作

grep -E '(vmx|svm)' /proc/cpuinfo

yum install qemu virt kvm -y

Question：

Solution：已安装的跳过

yum install qemu virt kvm -y --skip-broken

systemctl start libvirtd

systemctl enable libvirtd

virsh list

yum install -y bridge-utils

#配置桥接模式

cd /etc/sysconfig/network-scripts

cp ifcfg-em2 ifcfg-br0

[root@localhost network-scripts]# vim ifcfg-em2

TYPE=Ethernet

BRIDGE=br0

NAME=em2

UUID=74c8085f-4c0d-4743-b0a0-70e51e3eb877

DEVICE=em2

ONBOOT=yes

#注意IPADDR 要改为自己的

[root@localhost network-scripts]# vim ifcfg-br0

TYPE=Bridge

PROXY_METHOD=none

BROWSER_ONLY=no

BOOTPROTO=none

DEFROUTE=yes

IPV4_FAILURE_FATAL=no

IPV6INIT=yes

IPV6_AUTOCONF=yes

IPV6_DEFROUTE=yes

IPV6_FAILURE_FATAL=no

IPV6_ADDR_GEN_MODE=stable-privacy

NAME=br0

DEVICE=br0

ONBOOT=yes

IPADDR=17216103

PREFIX=24

GATEWAY=1721610254

DNS1=114114114114

systemctl restart network

#验证

brctl show

cd /home/kvm

#创建master虚拟机的存储盘 104

qemu-img create -f qcow2 -o cluster_size=2M k8s-master01qcow2 200G

virt-install --virt-type kvm --os-type=linux --os-variant rhel7 --name k8s-master01qcow2 --memory 8192 --vcpus 4 --disk /home/kvm/k8s-master01qcow2,format=qcow2 --cdrom /home/kvm/CentOS-7-x86_64-DVD-2009iso --network bridge=br0 --graphics vnc,listen=0000 --noautoconsole

#创建worker虚拟机的存储盘 105

qemu-img create -f qcow2 -o cluster_size=2M k8s-worker01qcow2 200G

virt-install --virt-type kvm --os-type=linux --os-variant rhel7 --name k8s-worker01qcow2 --memory 8192 --vcpus 4 --disk /home/kvm/k8s-worker01qcow2,format=qcow2 --cdrom /home/kvm/CentOS-7-x86_64-DVD-2009iso --network bridge=br0 --graphics vnc,listen=0000 --noautoconsole

#创建worker虚拟机的存储盘 103

qemu-img create -f qcow2 -o cluster_size=2M k8s-worker02qcow2 200G

virt-install --virt-type kvm --os-type=linux --os-variant rhel7 --name k8s-worker02qcow2 --memory 32768 --vcpus 32 --disk /home/kvm/k8s-worker02qcow2,format=qcow2 --cdrom /home/kvm/CentOS-7-x86_64-DVD-2009iso --network bridge=br0 --graphics vnc,listen=0000 --noautoconsole

netstat -ntlp | grep 5900

virsh list --all

virsh shutdown k8s-master01qcow2

virsh start k8s-master01qcow2

ssh 172161050 root@starQuest2022

Question：系统启动卡住

Solution：

virsh destroy k8s-master01qcow2

virsh undefine k8s-master01qcow2

Question：更改桥接模式失败引发的问题

Solution：

vi /etc/sysconfig/network-scripts/ifcfg-eth0

TYPE=Ethernet

PROXY_METHOD=none

BROWSER_ONLY=no

BOOTPROTO=static

DEFROUTE=yes

IPV4_FAILURE_FATAL=no

IPV6INIT=yes

IPV6_AUTOCONF=yes

IPV6_DEFROUTE=yes

IPV6_FAILURE_FATAL=no

IPV6_ADDR_GEN_MODE=stable-privacy

NAME=eth0

UUID=c510f2f9-9820-45e8-9c70-65674bd35258

DEVICE=eth0

ONBOOT=yes

IPADDR=172161050

PREFIX=24

GATEWAY=1721610254

DNS1=114114114114

systemctl restart network

Question：

Solution：

vi /root/ssh/known_hosts 删除有问题IP对应行

#设置hostname

hostnamectl set-hostname k8s-master01

hostnamectl set-hostname k8s-worker01

hostnamectl set-hostname k8s-worker02

yum update

yum install wget

yum install vim

rpm --import >

通过kubeadmin安装K8S集群可以做到快速部署，但是如果需要调整K8S各个组件及服务的安全配置，高可用模式，最好通过二进制模式进行K8S的安装
生产环境K8S Master节点最好在3个节点以上，且配置不低于4核16g
生产环境：确保Master高可用，启用安全访问机制

PS：

服务器节点只是起名字，与是否为k8s-master或k8s-node无关，可根据需要增加或删减测试用例的数量，如多台master主机只部署k8s-master组件。多台node主机只部署k8s-node组件
master1 192168100100
node1 192168100101
node2 192168100102

注：本节中创建的证书为部署流程全过程证书，测试用例为openssl生成证书，cfssl生成证书需要参考cfssl生成k8s证书，并在对应配置文件的相关证书位置替换对应证书

在配置文件中需要在[alt_names]设置Master服务的全部域名和IP地址，包括：

参数解析

配置文件详解：

分发配置文件

配置文件详解：

配置详解

分发配置文件

分发配置文件

在三个kube-apiserver的前段部署HAProxy和keepalived，使用VIP（虚拟IP地址）192168100200作为Master的唯一入口地址，供客户端访问
将HAProxy和keepalived均部署为至少有两个实例的高可用架构，以避免单点故障。
接下来在主机master（192168100100）和主机node1（192168100101）中部署
HAProxy负责将客户端请求转发到后端的3个kube-apiserver实例上，keepalived负责维护VIP的高可用

准备 HAProxy 的配置文件 haproxycfg

参数说明：

分发配置文件

在master（192168100100）和node1（192168100101）上使用docker部署HAProxy，并将配置文件挂载到容器的/usr/local/etc/haproxy下

访问192168100100:8888/stats，192168100101:8888/stats

keepalived用于维护VIP地址的高可用，同样在master和node1中部署

主节点配置文件

子节点配置文件

参数解析

主节点和子节点配置异同

健康检查脚本
keeplived需要持续监控HAProxy的运行状态，在某个节点运行不正常时转移到另外的节点上去
监控运行状态需要创建健康检查脚本，定期运行监控
脚本内容如下：

分发脚本

在master（192168100100）和node1（192168100101）上使用docker部署keeplived，并将配置文件挂载到容器的/container/service/keepalived/assets下，将脚本挂载到容器的/usr/bin下

检查ens33网卡是否存在keeplived VIP地址

检测keeplived是否进行转发

注：master集群已经配置完毕，后续需要在node中需要部署docker，kubelet，kube-proxy，且在加入k8s集群后，还需要部署CNI网络插件、DNS插件等
之前已经在master，node1，node2中部署了docker，接下来需要部署其他服务组件，本节部署kubelet组件

参数说明

参数说明

参数说明

当前显示所有node为NOT READY，需要部署完网络插件才可使用
为方便使用kubectl

k8s的存储常用的就是上面几种模式，分为临时存储，半持久化存储，与持久化存储这三类，本章我们着重讲解emptydir与hostpath与pvc跟pv等

当pod的存储方案设定为emptydir的时候，pod启动时，就会在pod所在节点的磁盘空间开辟出一块空卷，最开始里面是什么都没有的，pod启动后容器产生的数据会存放到那个空卷中。空卷变成了一个临时卷

供pod内的容器读取和写入数据，一旦pod容器消失，节点上开辟出的这个临时卷就会随着pod的销毁而销毁

一般来说emptydir的用途都是用来充当临时存储空间，例如一些不需要数据持久化的微服务，我们都可以用emptydir来当做微服务pod的存储方案

k8s存储emptdir实战例子：以之前的myapp应用为例

创建应用

观察是否生产data目录，并在/data目录创建文件testtxt

手动删除容器模拟容器销毁，用于是pod是被控制器管理的，删除后会被重建新的pod

这时候在看我们之前创建的datatxt已经不见了

hostPath类型则是映射node文件系统中的文件或者目录到pod里。在使用hostPath类型的存储卷时，也可以设置type字段，支持的类型有文件、目录、File、Socket、CharDevice和BlockDevice（我只映射过文件与目录）。

其实这个功能就相当于docker中的-v 目录映射，只不过在k8s中的时候，pod会漂移，当pod漂移到其他node节点的时候，pod不会跨节点的去读取目录。所以说hostpath只能算一种半持久化的存储方式

实战例子

创建应用

在node节点可以看到生成了/data/volume目录，在里面创建测试文件

检验pod里面的/data是否存在这个映射目录的文件

可以看到刚才创建的文件已经映射到我们的目录里边了

为了验证是否映射到容器里面的目录也会随着pod生命周期的消失而消失，我们手动删除pod模拟容器终止

可以看到容器被删除后，新建的pod也可以看到我们映射的目录，而且里面数据testtxt还在。

这有个缺点就是不能够跨容器去读取数据，如果删除后的pod被调度到其他节点的话，原来的数据也就没有了，如果能不受节点的影响，并且挂载的数据不会随生命周期的结束而结束，我们应该怎么解决呢？就是我们后面讲到的持久化存储了

上面介绍了俩种临时存储于半持久化存储的方案。在k8s实际生产环境中，一般会选用私有云持久化存储方案还有公有云持久化存储方案，私有云存储方案包括nfs，ceph，glusterfs等方案。公有云存储会用到AWS等方案

存储方案各有各的优缺点，可参考 >