kubernetes configmap yaml（kubernetes（十一） 数据存储（挂载卷管理））

本文目录

• kubernetes（十一） 数据存储（挂载卷管理）
• kubernetes启动redis并设置密码yaml文件
• 【Flink on k8s】Flink on Kubernetes 部署模式
• ingress-nginx部署
• Kubernetes自定义资源（CRD）

kubernetes（十一） 数据存储（挂载卷管理）

在前面已经提到，容器的生命周期可能很短，会被频繁地创建和销毁。那么容器在销毁时，保存在容器中的数据也会被清除。这种结果对用户来说，在某些情况下是不乐意看到的。为了持久化保存容器的数据，kubernetes引入了Volume的概念。

Volume是Pod中能够被多个容器访问的共享目录，它被定义在Pod上，然后被一个Pod里的多个容器挂载到具体的文件目录下，kubernetes通过Volume实现同一个Pod中不同容器之间的数据共享以及数据的持久化存储。Volume的生命容器不与Pod中单个容器的生命周期相关，当容器终止或者重启时，Volume中的数据也不会丢失。

kubernetes的Volume支持多种类型，比较常见的有下面几个：

EmptyDir是最基础的Volume类型，一个EmptyDir就是Host上的一个空目录。

EmptyDir是在Pod被分配到Node时创建的，它的初始内容为空，并且无须指定宿主机上对应的目录文件，因为kubernetes会自动分配一个目录，当Pod销毁时， EmptyDir中的数据也会被永久删除。 EmptyDir用途如下：

接下来，通过一个容器之间文件共享的案例来使用一下EmptyDir。

在一个Pod中准备两个容器nginx和busybox，然后声明一个Volume分别挂在到两个容器的目录中，然后nginx容器负责向Volume中写日志，busybox中通过命令将日志内容读到控制台。

创建一个volume-emptydir.yaml

EmptyDir中数据不会被持久化，它会随着Pod的结束而销毁，如果想简单的将数据持久化到主机中，可以选择HostPath。

HostPath就是将Node主机中一个实际目录挂在到Pod中，以供容器使用，这样的设计就可以保证Pod销毁了，但是数据依据可以存在于Node主机上。

创建一个volume-hostpath.yaml：

HostPath可以解决数据持久化的问题，但是一旦Node节点故障了，Pod如果转移到了别的节点，又会出现问题了，此时需要准备单独的网络存储系统，比较常用的用NFS、CIFS。

NFS是一个网络文件存储系统，可以搭建一台NFS服务器，然后将Pod中的存储直接连接到NFS系统上，这样的话，无论Pod在节点上怎么转移，只要Node跟NFS的对接没问题，数据就可以成功访问。

1）首先要准备nfs的服务器，这里为了简单，直接是master节点做nfs服务器

2）接下来，要在的每个node节点上都安装下nfs，这样的目的是为了node节点可以驱动nfs设备

3）接下来，就可以编写pod的配置文件了，创建volume-nfs.yaml

4）最后，运行下pod，观察结果

前面已经学习了使用NFS提供存储，此时就要求用户会搭建NFS系统，并且会在yaml配置nfs。由于kubernetes支持的存储系统有很多，要求客户全都掌握，显然不现实。为了能够屏蔽底层存储实现的细节，方便用户使用， kubernetes引入PV和PVC两种资源对象。

PV（Persistent Volume）是持久化卷的意思，是对底层的共享存储的一种抽象。一般情况下PV由kubernetes管理员进行创建和配置，它与底层具体的共享存储技术有关，并通过插件完成与共享存储的对接。

PVC（Persistent Volume Claim）是持久卷声明的意思，是用户对于存储需求的一种声明。换句话说，PVC其实就是用户向kubernetes系统发出的一种资源需求申请。

使用了PV和PVC之后，工作可以得到进一步的细分：

PV是存储资源的抽象，下面是资源清单文件:

PV 的关键配置参数说明：

实验
使用NFS作为存储，来演示PV的使用，创建3个PV，对应NFS中的3个暴露的路径。
1.准备NFS环境

2.创建pv.yaml

PVC是资源的申请，用来声明对存储空间、访问模式、存储类别需求信息。下面是资源清单文件:

PVC 的关键配置参数说明：

实验
1.创建pvc.yaml，申请pv

2.创建pods.yaml, 使用pv

PVC和PV是一一对应的，PV和PVC之间的相互作用遵循以下生命周期：

ConfigMap是一种比较特殊的存储卷，它的主要作用是用来存储配置信息的。

创建configmap.yaml，内容如下：

接下来，使用此配置文件创建configmap

接下来创建一个pod-configmap.yaml，将上面创建的configmap挂载进去

在kubernetes中，还存在一种和ConfigMap非常类似的对象，称为Secret对象。它主要用于存储敏感信息，例如密码、秘钥、证书等等。

1.首先使用base64对数据进行编码

2.接下来编写secret.yaml，并创建Secret

3.创建pod-secret.yaml，将上面创建的secret挂载进去：

至此，已经实现了利用secret实现了信息的编码。

kubernetes启动redis并设置密码yaml文件

测试环境创建redis单机就可以满足，redis启动后默认是无密码的，为了安全我们会登录容器手动设置，但是容器重启后又出现无密码，所以希望redis 容器启动后自动设置密码：
docker启动redis并设置密码:

修改redis 密码这里有两种法式：
配置redis.conf，利用kubernetes 的配置管理configmap，然后挂载到容器的相应路径，然后指定配置文件启动：redis-server /path/redis.conf，或者基于官方镜像再打镜像，Dockerfile如下：

另一种是利用kubernetes的lifecycle.postStart设置redis密码，这种方法简单方便，下面就是用kubernetes的lifecycle.postStart设置redis密码。
kubernetes启动redis并设置密码yaml文件:

redis service yaml文件：

【Flink on k8s】Flink on Kubernetes 部署模式

Flink 选择 Kubernetes 的主要原因是结合 Flink 和 Kubernetes 的 长稳性 。
① Flink 特性 ：提供的实时服务是需要 长时间、稳定地运行 ，常应用于电信网络质量监控、实时风控、实时推荐等稳定性要求较高的场景；
② Kubernetes 优势 ： 为应用提供了部署、管理能力，同时保证其稳定运行 。Kubernetes 具有很好的生态，可以 集成各种运维工具 ，例如 prometheus、主流日志采集工具等。Kubernetes 具有很好的 扩缩容机制 ，可以大大提高资源利用率。

预先构建 Flink 集群，且该集群长期处于运行状态，但不能自动扩缩容 。用户通过 client 提交作业到运行中的 JobManager，而 JobManager 将任务分配到运行中的 TaskManager。

Flink 集群是预先启动运行的。用户提交作业的时候，作业可以立即分配到 TaskManager，即 作业启动速度快 。

① 资源利用率低 ，提前确定 TaskManager 数量，如果作业需要的资源少，则大量 TaskManager 处于闲置状态。反正 TaskManager 资源不足。
② 作业隔离性差 ，多个作业的任务存在资源竞争，相互影响。如果一个作业异常导致 TaskManager 挂了，该 TaskManager 上的全部作业都会被重启。

参考： Flink on Standalone Kubernetes Reference
① 集群配置
集群配置通过 configmap 挂载到容器中
flink-configuration-configmap.yaml

② Deployment 文件
把 Flink 镜像 上传到 私有镜像仓 。 jobmanager-service.yaml、jobmanager-deployment.yaml、taskmanager-deployment.yaml

jobmanager-deployment.yaml

taskmanager-deployment.yaml

jobmanager-service.yaml

③ 执行 yaml
通过 kubectl create -f 命令创建 Flink 集群

每个作业独占一个 Flink 集群，当作业完成后，集群也会被回收。

一个作业独占一个集群， 作业的隔离性好 。

资源利用率低 ，提前确定 TaskManager 数量，如果作业需要的资源少，则大量 TaskManager 处于闲置状态。反之 TaskManager 资源不足。同时，JobManager 不能复用。

类似 Session 模式，需要 预先构建 JobManager 。不同点是用户通过 Flink Client 向 JobManager 提交作业后， 根据作业需要的 Slot 数量，JobManager 直接向 Kubernetes 申请 TaskManager 资源 ，最后把作业提交到 TaskManager 上。

TaskManager 的资源是实时的、按需进行的创建，对 资源的利用率更高 。

作业真正运行起来的时间较长 ，因为需要等待 TaskManager 创建。

参考： Native Kubernetes - Session Mode
① 集群配置
集群配置通过 configmap 挂载到容器中，如上 2.1 所示。
新增如下配置：
flink-configuration-configmap.yaml

② 配置 jobmanager-deployment.yaml
如上 2.1 所示，需要把启动脚本修改为 ./bin/kubernetes-session.sh

jobmanager-deployment.yaml

③ 执行 yaml
通过 kubectl create -f 命令创建 Flink 集群

类似 Application 模式，每个作业独占一个 Flink 集群，当作业完成后，集群也会被回收。不同点是 Native 特性 ，即 Flink 直接与 Kubernetes 进行通信并 按需申请资源 ，无需用户指定 TaskManager 资源的数量。

① 一个作业独占一个集群，作业的隔离性好。
② 资源利用率相对较高 ，按需申请 JobManager 和 TaskManager。

① 一个作业独占一个集群， JobManager 不能复用 。
② 作业启动较慢 ，在作业提交后，才开始创建 JobManager 和 TaskManager。

ingress-nginx部署

在kubernetes中，POD，SVC的IP地址只能集群内部使用，集群外部是无法访问的。
为了能让外部的应用访问进来，kubernetes提供了如下几种方案：

***隐藏网址***
本次使用基于nginx的ingress
***隐藏网址***

***隐藏网址***
configmap.yaml 存储配置信息，key/value值
namespace.yaml 建命名空间
mandatory.yaml 包含部署deploy相关所有资源(configmap.yaml,namespace.yaml,rbac.yaml,with-rbac.yaml)
rbac.yaml rbac授权配置,创建Ingress需要使用的ServiceAccount,ClusterRole,Role,RoleBinding,ClusterRoleBinding
with-rbac.yaml 能使用rbac授权的deploy配置，用于构建ingress-controller

自建集群用：

***隐藏网址***

公有云上用：

亚马孙云上用：

修改mandatory.yaml或者with-rbac.yaml里面的image地址,避免原地址镜像拉取超时

查看deploy

查看pod详情
kubectl -n ingress-nginx describe pod nginx-ingress-controller-55c9df84c6-8x4kk
查看svc

访问测试

Kubernetes自定义资源（CRD）

Kubernetes系统拥有强大的高扩展功能，其中自定义资源（Custom Resource）就是一种常见的扩展方式，即可将自己定义的资源添加到Kubernetes系统中。Kubernetes系统附带了许多内置资源，但是仍有些需求需要使用自定义资源来扩展Kubernetes的功能。

在Kubernetes系统早期，是通过 ThirdPartyResource（TPR） 来实现扩展自定义资源的，但自Kubernetes 1.7版本后，ThirdPartyResource功能已被弃用，并且其已根据Beta功能的弃用政策在Kubernetes 1.8中被删除，取而代之的是 CustomResourceDefinitions（自定义资源定义，简称CRD） 。

开发者通过CRD可以实现自定义资源，它允许用户将自己定义的资源添加到Kubernetes系统中，并像使用Kubernetes内置资源一样使用这些资源，例如，在YAML/JSON文件中带有Spec的资源定义都是对Kubernetes中的资源对象的定义，所有的自定义资源都可以与Kubernetes系统中的内置资源一样使用kubectl或client-go进行操作。

当你创建新的 CustomResourceDefinition（CRD）时，Kubernetes API 服务器会为你所指定的每一个版本生成一个 RESTful 的资源路径。CRD 可以是命名空间作用域的，也可以是集群作用域的，取决于 CRD 的 scope 字段设置。和其他现有的内置对象一样，删除 一个命名空间时，该名字空间下的所有 CRD 对象也会被删除。CustomResourceDefinition 本身是不受命名空间限制的，对所有命名空间可用。

例如，如果你将下面的 CustomResourceDefinition 保存到 resourcedefinition.yaml 文件：

之后创建它：

这样一个新的受名字空间约束的 RESTful API 端点会被创建在：

此端点 URL 自此可以用来创建和管理定制对象。对象的 kind 将是来自你上面创建时 所用的 spec 中指定的 CronTab。

创建端点的操作可能需要几秒钟。你可以监测你的 CustomResourceDefinition 的 Established 状况变为 true，或者监测 API 服务器的发现信息等待你的资源出现在那里。

在创建了 CustomResourceDefinition 对象之后，你可以创建定制对象（Custom Objects）。定制对象可以包含定制字段。这些字段可以包含任意的 JSON 数据。 在下面的例子中，在类别为 CrontTab 的定制对象中，设置了 cronSpec 和 image 定制字段。类别 CronTab 来自你在上面所创建的 CRD 的规约。

如果你将下面的 YAML 保存到 my-crontab.yaml ：

并执行创建命令：

你就可以使用 kubectl 来管理你的 CronTab 对象了。例如：

应该会输出如下列表：

使用 kubectl 时，资源名称是大小写不敏感的，而且你既可以使用 CRD 中所定义的单数 形式或复数形式，也可以使用其短名称：

你可以看到输出中包含了你创建定制对象时在 YAML 文件中指定的定制字段 cronSpec 和 image：

当你删除某 CustomResourceDefinition 时，服务器会卸载其 RESTful API 端点，并删除服务器上存储的所有定制对象。

如果你在以后创建相同的 CustomResourceDefinition 时，该 CRD 会一个空的结构。

使用 CustomResourceDefinition 扩展 Kubernetes API
Kubernetes CRD 系列：CRD 介绍