华为云用户手册

Service的类型与使用场景 Service的类型除了ClusterIP还有NodePort、LoadBalancer和Headless Service，这几种类型的Service有着不同的用途。 ClusterIP：用于在集群内部互相访问的场景，通过ClusterIP访问Service。 NodePort：用于从集群外部访问的场景，通过节点上的端口访问Service，详细介绍请参见NodePort类型的Service。 LoadBalancer：用于从集群外部访问的场景，其实是NodePort的扩展，通过一个特定的LoadBalancer访问Service，这个LoadBalancer将请求转发到节点的NodePort，而外部只需要访问LoadBalancer，详细介绍请参见LoadBalancer类型的Service。 Headless Service：用于Pod间的互相发现，该类型的Service并不会分配单独的ClusterIP， 而且集群也不会为它们进行负载均衡和路由。您可通过指定spec.clusterIP字段的值为“None”来创建Headless Service，详细介绍请参见Headless Service。

直接访问Pod的问题 Pod创建完成后，如何访问Pod呢？直接访问Pod会有如下几个问题： Pod会随时被Deployment这样的控制器删除重建，那访问Pod的结果就会变得不可预知。 Pod的IP地址是在Pod启动后才被分配，在启动前并不知道Pod的IP地址。 应用往往都是由多个运行相同镜像的一组Pod组成，逐个访问Pod也变得不现实。 举个例子，假设有这样一个应用程序，使用Deployment创建了前台和后台，前台会调用后台做一些计算处理，如图1所示。后台运行了3个Pod，这些Pod是相互独立且可被替换的，当Pod出现状况被重建时，新建的Pod的IP地址是新IP，前台的Pod无法直接感知。 图1 Pod间访问

在Volume中引用Secret 在Volume中引用Secret，就是通过文件的方式直接将Secret的每条数据填入Volume，每条数据是一个文件，键就是文件名，键值就是文件内容。 如下示例中，创建一个名为vol-secret的Volume，这个Volume引用名为“mysecret”的Secret，再将Volume挂载到容器的“/tmp”路径下。Pod创建成功后，在容器的“/tmp”路径下，就有两个文件key1和key2。 apiVersion: v1 kind: Pod metadata: name: nginx spec: containers: - image: nginx:alpine name: container-0 resources: limits: cpu: 100m memory: 200Mi requests: cpu: 100m memory: 200Mi volumeMounts: - name: vol-secret # 挂载名为vol-secret的Volume mountPath: "/tmp" imagePullSecrets: - name: default-secret volumes: - name: vol-secret secret: # 引用Secret secretName: mysecret 进入Pod容器中，可以在/tmp目录下发现key1和key2两个文件，并看到文件中的值是base64解码后的值，分别为“hello world”和“3306”。

创建Secret 如下示例中定义的Secret中包含两条Key-Value。 apiVersion: v1 kind: Secret metadata: name: mysecret data: key1: aGVsbG8gd29ybGQ= # "hello world" Base64编码后的值 key2: MzMwNg== # "3306" Base64编码后的值

在环境变量中引用Secret Secret最常见的用法是作为环境变量注入到容器中，如下示例。 apiVersion: v1 kind: Pod metadata: name: nginx spec: containers: - image: nginx:alpine name: container-0 resources: limits: cpu: 100m memory: 200Mi requests: cpu: 100m memory: 200Mi env: - name: key valueFrom: secretKeyRef: name: mysecret key: key1 imagePullSecrets: - name: default-secret

为什么需要Namespace Label虽然好，但只用Label的话，那Label会非常多，有时候会有重叠，而且每次查询之类的动作都带一堆Label非常不方便。Kubernetes提供了Namespace来做资源组织和划分，使用多Namespace可以将包含很多组件的系统分成不同的组。Namespace也可以用来做多租户划分，这样多个团队可以共用一个集群，使用的资源用Namespace划分开。 不同的Namespace下的资源名称可以相同，Kubernetes中大部分资源可以用Namespace划分，不过有些资源不行，例如Node、PV等，它们属于全局资源，不属于某一个Namespace，后面会逐步接触到。 通过如下命令可以查询到当前集群下的Namespace。 $ kubectl get ns NAME STATUS AGE default Active 36m kube-node-realease Active 36m kube-public Active 36m kube-system Active 36m 到目前为止，我们都是在default Namespace下操作，当使用kubectl get而不指定Namespace时，默认为default Namespace。 看下kube-system下面有些什么东西。 $ kubectl get po --namespace=kube-system NAME READY STATUS RESTARTS AGE coredns-7689f8bdf-295rk 1/1 Running 0 9m11s coredns-7689f8bdf-h7n68 1/1 Running 0 11m everest-csi-controller-6d796fb9c5-v22df 2/2 Running 0 9m11s everest-csi-driver-snzrr 1/1 Running 0 12m everest-csi-driver-ttj28 1/1 Running 0 12m everest-csi-driver-wtrk6 1/1 Running 0 12m icagent-2kz8g 1/1 Running 0 12m icagent-hjz4h 1/1 Running 0 12m icagent-m4bbl 1/1 Running 0 12m 可以看到kube-system有很多Pod，其中coredns是用于做服务发现、everest-csi是用于对接存储服务、icagent是用于对接监控系统。 这些通用的、必须的应用放在kube-system这个命名空间中，能够做到与其他Pod之间隔离，在其他命名空间中不会看到kube-system这个命名空间中的东西，不会造成影响。

创建Namespace 使用如下方式定义Namespace。 apiVersion: v1 kind: Namespace metadata: name: custom-namespace 使用kubectl命令创建。 $ kubectl create -f custom-namespace.yaml namespace/custom-namespace created 您还可以使用kubectl create namespace命令创建。 $ kubectl create namespace custom-namespace namespace/custom-namespace created 在指定Namespace下创建资源。 $ kubectl create -f nginx.yaml -n custom-namespace pod/nginx created 这样在custom-namespace下，就创建了一个名为nginx的Pod。

为什么需要Label 当资源变得非常多的时候，如何分类管理就非常重要了，Kubernetes提供了一种机制来为资源分类，那就是Label（标签）。Label非常简单，但是却很强大，Kubernetes中几乎所有资源都可以用Label来组织。 Label的具体形式是key-value的标记对，可以在创建资源的时候设置，也可以在后期添加和修改。 以Pod为例，当Pod变得多起来后，就显得杂乱且难以管理，如下图所示。 图1 没有分类组织的Pod 如果我们为Pod打上不同标签，那情况就完全不同了，如下图所示。 图2 使用Label组织的Pod

修改Label 对于已存在的Label，如果要修改的话，需要在命令中带上--overwrite，如下所示。 $ kubectl label pod nginx env=debug --overwrite pod/nginx labeled $ kubectl get pod --show-labels NAME READY STATUS RESTARTS AGE LABELS nginx 1/1 Running 0 50s app=nginx,creation_method=manual,env=debug

添加Label Label的形式为key-value形式，使用非常简单，如下，为Pod设置了app=nginx和env=prod两个Label。 apiVersion: v1 kind: Pod metadata: name: nginx labels: # 为Pod设置两个Label app: nginx env: prod spec: containers: - image: nginx:alpine name: container-0 resources: limits: cpu: 100m memory: 200Mi requests: cpu: 100m memory: 200Mi imagePullSecrets: - name: default-secret Pod有了Label后，在查询Pod的时候带上--show-labels就可以看到Pod的Label。 $ kubectl get pod --show-labels NAME READY STATUS RESTARTS AGE LABELS nginx 1/1 Running 0 50s app=nginx,env=prod 还可以使用-L只查询某些固定的Label。 $ kubectl get pod -L app,env NAME READY STATUS RESTARTS AGE APP ENV nginx 1/1 Running 0 1m nginx prod 对已存在的Pod，可以直接使用kubectl label命令直接添加Label。 $ kubectl label pod nginx creation_method=manual pod/nginx labeled $ kubectl get pod --show-labels NAME READY STATUS RESTARTS AGE LABELS nginx 1/1 Running 0 50s app=nginx, creation_method=manual,env=prod

存活探针 Kubernetes提供了自愈的能力，具体就是能感知到容器崩溃，然后能够重启这个容器。但是有时候例如Java程序内存泄漏了，程序无法正常工作，但是JVM进程却是一直运行的，对于这种应用本身业务出了问题的情况，Kubernetes提供了Liveness Probe机制，通过检测容器响应是否正常来决定是否重启，这是一种很好的健康检查机制。 毫无疑问，每个Pod最好都定义Liveness Probe，否则Kubernetes无法感知Pod是否正常运行。 Kubernetes支持如下三种探测机制。 HTTP GET：向容器发送HTTP GET请求，如果Probe收到2xx或3xx，说明容器是健康的。 TCP Socket：尝试与容器指定端口建立TCP连接，如果连接成功建立，说明容器是健康的。 Exec：Probe执行容器中的命令并检查命令退出的状态码，如果状态码为0则说明容器是健康的。 与存活探针对应的还有一个就绪探针（Readiness Probe），将在就绪探针（Readiness Probe）中会详细介绍。

配置有效的Liveness Probe Liveness Probe应该检查什么 一个好的Liveness Probe应该检查应用内部所有关键部分是否健康，并使用一个专有的URL访问，例如/health，当访问/health 时执行这个功能，然后返回对应结果。这里要注意不能做鉴权，不然probe就会一直失败导致陷入重启的死循环。 另外检查只能限制在应用内部，不能检查依赖外部的部分，例如当前端web server不能连接数据库时，这个就不能看成web server不健康。 Liveness Probe必须轻量 Liveness Probe不能占用过多的资源，且不能占用过长的时间，否则所有资源都在做健康检查，这就没有意义了。例如Java应用，就最好用HTTP GET方式，如果用Exec方式，JVM启动就占用了非常多的资源。

TCP Socket TCP Socket尝试与容器指定端口建立TCP连接，如果连接成功建立，说明容器是健康的，定义方法如下所示。 apiVersion: v1 kind: Pod metadata: labels: test: liveness name: liveness-tcp spec: containers: - name: liveness image: nginx:alpine livenessProbe: # liveness probe tcpSocket: port: 80 imagePullSecrets: - name: default-secret

Liveness Probe高级配置 上面liveness-http的describe命令回显中有如下行。 Liveness: http-get http://:80/ delay=0s timeout=1s period=10s #success=1 #failure=3 这一行表示Liveness Probe的具体参数配置，其含义如下： delay：延迟，delay=0s，表示在容器启动后立即开始探测，没有延迟时间 timeout：超时，timeout=1s，表示容器必须在1s内进行响应，否则这次探测记作失败 period：周期，period=10s，表示每10s探测一次容器 success：成功，#success=1，表示连续1次成功后记作成功 failure：失败，#failure=3，表示连续3次失败后会重启容器 以上存活探针表示：容器启动后立即进行探测，如果1s内容器没有给出回应则记作探测失败。每次间隔10s进行一次探测，在探测连续失败3次后重启容器。 这些是创建时默认设置的，您也可以手动配置，如下所示。 apiVersion: v1 kind: Pod metadata: name: liveness-http spec: containers: - name: liveness image: nginx:alpine livenessProbe: httpGet: path: / port: 80 initialDelaySeconds: 10 # 容器启动后多久开始探测 timeoutSeconds: 2 # 表示容器必须在2s内做出相应反馈给probe，否则视为探测失败 periodSeconds: 30 # 探测周期，每30s探测一次 successThreshold: 1 # 连续探测1次成功表示成功 failureThreshold: 3 # 连续探测3次失败表示失败 initialDelaySeconds一般要设置大于0，这是由于很多情况下容器虽然启动成功，但应用就绪也需要一定的时间，需要等就绪时间之后才能返回成功，否则就会导致probe经常失败。 另外failureThreshold可以设置多次循环探测，这样在实际应用中健康检查的程序就不需要多次循环，这一点在开发应用时需要注意。

Exec Exec即执行具体命令，具体机制是Probe执行容器中的命令并检查命令退出的状态码，如果状态码为0则说明健康，定义方法如下所示。 apiVersion: v1 kind: Pod metadata: labels: test: liveness name: liveness-exec spec: containers: - name: liveness image: nginx:alpine args: - /bin/sh - -c - touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy; sleep 600 livenessProbe: # liveness probe exec: # Exec定义 command: - cat - /tmp/healthy imagePullSecrets: - name: default-secret 上面定义在容器中执行cat /tmp/healthy命令，如果成功执行并返回0，则说明容器是健康的。上面定义中，30秒后命令会删除/tmp/healthy，这会导致Liveness Probe判定Pod处于不健康状态，然后会重启容器。

Flexus L实例 有哪些实例类型？ Flexus应用服务器L实例包含两种实例类型： Flexus应用服务器L实例：包含多种实例规格，购买时支持自定义选择数据盘、主机安全或云备份，创建后默认分配一个固定的公网IP。其中，实例规格包含vCPU/内存、系统盘、流量包。 Flexus服务组合：包含基础套餐和高可用套餐，并且套餐内的资源为固定配置。 组合套餐不支持升级套餐规格，购买时不支持自定义选择主机安全、云备份、Flexus负载均衡。 基础套餐包含一台云主机（vCPU/内存、系统盘）、一个弹性公网IP、流量包、主机安全、云备份。 高可用套餐包含两台云主机（vCPU/内存、系统盘）、一个弹性公网IP、流量包、两个主机安全、云备份、Flexus负载均衡。 高可用套餐不支持使用应用镜像，不支持访问外网。 Flexus L实例规格配置详见实例类型及规格。 父主题： 产品咨询

Flexus L实例的ID和实例中云服务器ID在哪里查看？ Flexus L实例是一个包含云服务器、云硬盘、云备份、主机安全和Flexus负载均衡的组合产品，以套餐形式整体售卖、管理。因此，Flexus应用服务器L实例存在实例ID、云主机ID、云备份ID和Flexus负载均衡ID多个ID。本节为您介绍如何查看Flexus L实例的实例ID和实例中的云服务器ID即云主机ID。 登录Flexus应用服务器L实例控制台。 单击待查看的Flexus L实例资源卡片，在实例名称后可查看实例ID 。 单击“云主机 VM”，在云主机信息中可查看云主机ID。 单击ID后的复制按钮，可快速复制ID。 图1 实例套餐ID和云主机ID 父主题： 产品咨询

操作场景 在用户意外修改、删除或需要找回数据时，集群用户对ClickHouse进行重大操作（如升级、重大数据调整等）后，系统数据出现异常或未达到预期结果，模块全部故障无法使用，或者迁移数据到新集群的场景中，需要对ClickHouse进行恢复数据操作。 集群用户可以通过 FusionInsight Manager创建恢复ClickHouse任务并恢复数据。只支持创建任务手动恢复数据。 ClickHouse备份恢复功能不支持识别用户的ClickHouse表、索引、视图等对象在业务和结构上存在的关联关系。用户在执行备份恢复任务时，需要根据业务场景管理统一的恢复点，防止影响业务正常运行。 该功能仅 MRS 3.1.0及之后版本支持。 只支持进行数据备份时的系统版本与当前系统版本一致时的数据恢复。 当业务正常时需要恢复数据，建议手动备份最新管理数据后，再执行恢复数据操作。否则会丢失从备份时刻到恢复时刻之间的ClickHouse数据。 ClickHouse元数据恢复和业务数据恢复不能同时进行操作，否则会导致业务数据恢复失败。建议元数据恢复完成后再进行业务数据恢复。

前提条件 如果需要从远端HDFS恢复数据，需要准备备集群，且已完成数据备份，详细操作请参见备份ClickHouse业务数据。如果主备集群部署为安全模式，且主备集群不是由同一个FusionInsight Manager管理，则必须配置系统互信，请参见配置MRS集群间互信。如果主备集群部署为普通模式，则不需要配置互信。 主备集群上的时间必须一致，而且主备集群上的NTP服务必须使用同一个时间源。 规划好恢复数据保存表的数据库，数据表在HDFS的保存位置，以及访问恢复数据的用户清单。 检查ClickHouse备份文件保存路径。 停止ClickHouse的上层应用。 主备集群中，从远端HDFS恢复至本地时，需要确保ClickHouse的“HADOOP_RPC_PROTECTION”配置项与HDFS的“hadoop.rpc.protection”配置项的值保持一致。

操作场景 为了确保IoTDB元数据安全，防止因IoTDB的文件损坏等导致IoTDB服务不可用时，需要对IoTDB元数据进行备份，从而保证系统在出现异常或未达到预期结果时可以及时进行数据恢复，将对业务的影响降到最低。 系统管理员可以通过FusionInsight Manager创建恢复IoTDB任务。只支持创建任务手动恢复数据。 只支持进行数据备份时的系统版本与当前系统版本一致时的数据恢复。 当业务正常时需要恢复数据，建议手动备份最新管理数据后，再执行恢复数据操作。否则会丢失从备份时刻到恢复时刻之间的IoTDB数据。 建议一个恢复任务只恢复一个组件的元数据，避免因停止某个服务或实例影响其他组件的数据恢复。同时恢复多个组件数据，可能导致数据恢复失败。

前提条件 如果需要从远端HDFS恢复数据，需要准备备集群，且已完成数据备份，详细操作请参见备份HDFS NameNode元数据。如果主集群部署为安全模式，且主备集群不是由同一个FusionInsight Manager管理，则必须配置系统互信，请参见配置MRS集群间互信。如果主集群部署为普通模式，则不需要配置互信。 主备集群必须已配置跨集群拷贝，请参见启用MRS集群间拷贝功能。 主备集群上的时间必须一致，而且主备集群上的NTP服务必须使用同一个时间源。 在FusionInsight Manager停止所有待恢复数据的NameNode角色实例，其他的HDFS角色实例必须保持正常运行，恢复数据后重启NameNode。NameNode角色实例重启前无法访问。 检查NameNode备份文件保存路径是否保存在主管理节点“数据存放路径/LocalBackup/”。

操作场景 在用户意外修改、删除或需要找回数据时，系统管理员对NameNode进行重大操作（如升级、重大数据调整等）后，系统数据出现异常或未达到预期结果，模块全部故障无法使用，或者迁移数据到新集群的场景中，需要对NameNode进行恢复数据操作。 系统管理员可以通过FusionInsight Manager创建恢复NameNode任务并恢复数据。只支持创建任务手动恢复数据。 只支持进行数据备份时的系统版本与当前系统版本一致时的数据恢复。 当业务正常时需要恢复数据，建议手动备份最新管理数据后，再执行恢复数据操作。否则会丢失从备份时刻到恢复时刻之间的NameNode数据。 建议一个恢复任务只恢复一个组件的元数据，避免因停止某个服务或实例影响其他组件的数据恢复。同时恢复多个组件数据，可能导致数据恢复失败。 HBase元数据不能与NameNode元数据同时恢复，会导致数据恢复失败。

操作场景 该章节指导用户开启Guardian组件存算分离操作。开启后Guardian可以在存算分离场景下为HDFS、Hive、Spark、Loader、HetuEngine等服务提供访问OBS的临时认证凭据。 配置Guardian服务对接OBS主要操作如下： 创建OBS并行文件系统 创建普通账号委托 创建云服务委托并绑定集群 为Guardian组件配置访问OBS权限 开启Hive表的级联授权功能 配置回收站清理策略

集群互信概念介绍 域 每个系统用户安全使用的范围定义为“域”，不同的Manager系统需要定义唯一的 域名 。跨Manager访问实际上就是用户跨域使用。 用户加密 配置跨Manager互信，当前Kerberos服务端仅支持并使用“aes256-cts-hmac-sha1-96:normal”和“aes128-cts-hmac-sha1-96:normal”加密类型加密跨域使用的用户，不支持修改。 用户认证 配置跨Manager集群互信后，两个系统中只要存在同名用户，且对端系统的同名用户拥有访问自身系统中某个资源的对应权限，则可以使用当前系统用户访问远程资源。 直接互信 系统在配置互信的两个集群分别保存对端系统的互信票据，通过互信票据访问对端系统。

操作场景 在用户意外修改、删除或需要找回数据时，系统管理员对FusionInsight Manager系统进行重大数据调整等操作后，系统数据出现异常或未达到预期结果，模块全部故障无法使用，需要对Manager进行恢复数据操作。 管理员可以通过FusionInsight Manager创建恢复Manager任务。只支持创建任务手动恢复数据。 只支持进行数据备份时的系统版本与当前系统版本一致时的数据恢复。 当业务正常时需要恢复数据，建议手动备份最新管理数据后，再执行恢复数据操作。否则会丢失从备份时刻到恢复时刻之间的Manager数据。

对系统的影响 恢复过程中需要重启Controller，重启时FusionInsight Manager无法登录和操作。 恢复过程中需要重启所有集群，集群重启时无法访问。 Manager数据恢复后，会丢失从备份时刻到恢复时刻之间的数据，例如系统设置、用户信息、告警信息或审计信息。可能导致无法查询到数据，或者某个用户无法访问集群。 Manager数据恢复后，系统将强制各集群的LdapServer从OLadp同步一次数据。

前提条件 如果需要从远端HDFS恢复数据，需满足以下条件： 需准备一个用于恢复数据的备集群，且该集群已完成数据备份，详细操作请参见备份Manager数据（MRS 3.x及之后版本）。如果主集群部署为安全模式，且主备集群不是由同一个FusionInsight Manager管理，则必须配置系统互信，请参见配置MRS集群间互信。如果主集群部署为普通模式，则不需要配置互信。 主备集群必须已配置跨集群拷贝，请参见启用MRS集群间拷贝功能。 主备集群上的时间必须一致，而且主备集群上的NTP服务必须使用同一个时间源。 检查 OMS 资源状态是否正常，检查各集群的LdapServer实例状态是否正常。如果不正常，不能执行恢复操作。 检查集群主机和服务的状态是否正常。如果不正常，不能执行恢复操作。 检查恢复数据时集群主机拓扑结构与备份数据时是否相同。如果不相同，不能执行恢复操作，必须重新备份。 检查恢复数据时集群中已添加的服务与备份数据时是否相同。如果不相同，不能执行恢复操作，必须重新备份。 停止依赖集群运行的上层业务应用。

前提条件 如果需要从远端HDFS恢复数据，需要准备备集群，且已完成数据备份，详细操作请参见备份Kafka元数据。如果主集群部署为安全模式，且主备集群不是由同一个FusionInsight Manager管理，则必须配置系统互信，请参见配置MRS集群间互信。如果主集群部署为普通模式，则不需要配置互信。 主备集群必须已配置跨集群拷贝，请参见启用MRS集群间拷贝功能。 主备集群上的时间必须一致，而且主备集群上的NTP服务必须使用同一个时间源。 先停止Kafka服务，待恢复完成后，再启动Kafka服务。

操作场景 在用户意外修改、删除或需要找回数据时，系统管理员对ZooKeeper进行重大操作（如升级、重大数据调整等）后，系统数据出现异常或未达到预期结果，导致Kafka组件全部故障无法使用，或者迁移数据到新集群的场景中，需要对Kafka元数据进行恢复数据操作。 系统管理员可以通过FusionInsight Manager创建恢复Kafka任务。只支持创建任务手动恢复数据。 只支持进行数据备份时的系统版本与当前系统版本一致时的数据恢复。 当业务正常时需要恢复Kafka元数据，建议手动备份最新Kafka元数据后，再执行恢复操作。否则会丢失从备份时刻到恢复时刻之间的Kafka元数据信息。

前提条件 如果需要从远端HDFS恢复数据，需要准备备集群，且已完成数据备份，详细操作请参见备份IoTDB业务数据。如果主集群部署为安全模式，且主备集群不是由同一个FusionInsight Manager管理，则必须配置系统互信，请参见配置MRS集群间互信。如果主集群部署为普通模式，则不需要配置互信。 主备集群上的时间必须一致，而且主备集群上的NTP服务必须使用同一个时间源。 检查IoTDB备份文件保存路径。 停止IoTDB的上层应用。