为了方便归类和管理，在kubernetes中标签管理也至为重要 labels标签管理 一个资源可以拥有多个标签，同一个标签可以被添加到多个对象，标签可以在创建资源时指定，并且可以在之后进行添加和删除，以及修改 labels: www: linuxea-com 如上所示，类型key=value，其中键和值的长度最多使用63个字符 key 其中key只能使用字母，数字，下划线(_)，减号(-)，点(.

对于一个Pod而言，从开始到结束,要经过很多点初始化则在其中，而初始化也需要一定的时间，如：Dockerfile中的ENTRYPOINT脚本，此脚本也需要运行时间，所谓的秒级启动，可能不包含这些，简述pod什么周期，如下图其中，在容器内通常运行一个进程，而在pod中通常运行一个容器。在pod中的主容器运行之前是需要做一些环境设定，比如init-containers,在主容器启动之前，会运行一个环境

在之前的pod生命周期介绍中,容器启动并不是单纯的up起来就能完成工作，这期间需要做一系列的配置预热才可以更好的被使用。 存活状态liveness probe 探针类型有三种,ExecAction,TCPSocketAction,HTTPGetAction ExecAction: 容器探测failureThreshold：探测几次，默认3次探测失败，则失败periodSeconds：间隔时间，10

pod被"正式的使用"之前需要做一些简单的检测pod的服务可用性，就此，readiness probe就派上用场 readiness probe 当使用kubectl get pods，在READY中的1/1,右边的1是POD内容器数量，而左边的1是就绪的个数。倘若不定义，那么在启动时候，就会立刻就绪 [root@linuxea linuxea]# kubectl get pods NAME RE

在之前，使用kubectl run的pod中，当pod被删除后会自动创建。而在kubectl create使用-f指定yaml文件时候，在删除则不会被创建。在kubectl run的pod是被控制器管理的，pod控制会严格管控pod资源符合用户期望的目标状态，如：定义了3个pod资源，一旦缺少必然会重建补全，多余也会杀死终止，一旦故障尝试重启或者编排。倘若希望减少是可以用命令定义缩减。然而使用cr

在前面一篇中提到过ReplicaSet，而ReplicaSet很多时候是无法满足现状，ReplicaSet确保在任何给定时间运行指定数量的pod副本。但是，Deployment是一个更高级别的概念replicaset本身仅仅并不是直接被控制，在replicaset之上是由Deployment来控制，Deployment通过控制replicaset来控制pod。Deployment支持扩缩容，滚动更

集群节点中的每一个节点，或者选择器节点，运行“某个”指定的POD副本，通常用来实现系统级的管理功能，或者后台任务，可以将节点上的某个目录作为存储卷关联至POD中，让pod实现某些管理功能。并且在新加入的node节点自动添加此类的pod副本，其中也需要标签选择器的使用。并且daemonSet也支持滚动更新！这类服务通常无状态，以守护进程运行 参数 updateStrategy: 更新策略(默认滚动更

pod是有生命周期的，为了给对应的客户端提供一个固定的访问端点。在客户端与服务pod之间提供一个中间层Service，service严重依赖kubernetes(1.11.2)之上的附件CoreDNS(kube-dns) kubernetes的名称解析，强依赖于CoreDNS，在kubernetes中的名称解析中必须存在CoreDNS kubernetes提供的网络功能，需要依赖于第三方网络方案，

在之前的一些章节中，有hostNetwork和hostport,以及Nodeport三种服务暴露方式，nodeport跳过了service的cluster IP直接暴露出去，范围从30000-32767，不设置则动态分配，参考service第一章和hostNetwork 创建pod资源 在创建nodeport之前，先创建一个现有pod作为测试。pod的yaml文件如下： [root@linuxea

在之前的Nodeport和hostNetwork中，大致了解了暴露的用法，此后有Ingress Controller的用法。之前不管那种方式，对于调用前端而言是不清楚后端pod的ip地址的。但是，有一些有状态的应用程序就需要清楚的联系到每个容器的ip地址，直接与容器通信。那就是Service的No ClusterIP无头服务。 None 无头服务(No ClusterIP)：此前，每一个servi

无论service还是ipvs都是四层调度，四层调度工作在七层模型的第四层，如果用户访问https,那么四层是无法解析https回话，如果要使用https便只能在后端pod配置https来使用https，这样一来，那便意味着客户端与后端服务器之间直接建立ssl会话(图1)，此刻，如果下一个请求被调度到第二个pod，那么这个会话需要重新建立(2)倘若后端到调度器之间的网络上安全的，https会话可以

在之前的Ingress Controller介绍中，我们已经知道了Ingress用途。我们开始准备ingress使用和配置，资源清单包括之前所述的apiVersion,kind,metadata,spec等，在spec中较为特别：其中rules调度的是host或者http,如果是https则是tls。在http中是paths路径调度，或者之前的host调度backend指明后端pod数量。FIEL

在之前的一篇中简单的安装配置了Ingress Controller和Ingress Controller概述，唯独缺少后端的配置和https七层的配置，这里涉及到secret，secret存储卷在后面将会提到，先看下如何配置一个ingress backend规则那么现在，按照之前的配置Ingress Controller nginx提供两个端口，分别是30088和30443作为七层代理，分别代理h

大多数有状态的应用都是需要持续存储数据的。容器本身有生命周期，容器终结后，或者编排到其他节点运行，那就意味着数据不能存放在容器内，否则在删除或者容器损坏时数据会丢失 引言 在k8s中，pod一直运行在机器上，除非机器宕机pod才会被调度到其他机器，顶多重启。一旦这个pod被删除(故障)，或者机器宕机(被编排到其他节点)，这个pod就会重构。如果数据存放在pod的名称空间中，数据随着pod的终结而消

此前，在的存储卷类型介绍中，emptyDir只在节点本地使用。创建一个pod，一个存储卷，pod被删除，存储卷也会被删除.empryDir数据随着pod的创建而创建，随着删除而删除empryDir可以当临时目录，或者缓存使用(关联宿主机的目录可以是宿主机的内存，将内存放到pod存储卷)。没有持久化。本次将详细实验一下emptyDir的用法 emptyDir存储卷 1，pod上定义volume,vo

此前在存储卷类型中提到，hostPath位于主机路径，在宿主机创建目录挂载。一定意义的持久性。pod所在宿主机之上的，脱离pod容器名称空间之外的，宿主机的文件系统某一个目录与pod建立关系。当pod被删除，存储卷不会被删除。只要同一个pod调度到同一个节点，数据依然可被正常使用。 volumes： hostPath: path: type type字段支持为了测试效果，在三台node上都创建这个

共享存储特性是不管node是否挂掉，pod中容器是否在同一个节点，数据都不丢失，数据不存放在某一个单独的node之上。这和之前的主机存储卷hostPath，empryDir在持久化存储上效果更好。在yml配置文件中定义，且被volumeMounts挂载即可，如下： - name: linuxea-image nfs: path: PATH server: Server 以nfs为例做共享存储测试

此前在存储卷类型中介绍过pvc，以及其他的存储卷类型，本节笔记介绍pvc和nfs的使用 PVC 在pod中只需要定义存储卷，定义时只需要说明需要用到的大小，这个类型就是pvcl类型存储卷而pvc存储卷必须与当前名称空间中的pvc，建立直接绑定关系，而pvc必须与pv建立绑定关系，而pv则是某个真正存储设备的存储空间，如下：pv与pvs是kubernetes上抽象的，且标准的资源，与创建其他的pod

在之前的描述中，我们知道pv和pvc在使用中存在一种问题。pvc申请的的大小并不意味着就有符合pvc申请条件的pv。之前有意设定了符合pvc条件的pv，并成功的被pod绑定所使用。 StorageClass k8s也考虑到这种情况，于是有意的设计了一种工作逻辑，能够让pvc在申请pv时候，借助存储类--->中间层(StorageClass)完成资源分配 首先，将众多存储归类，将相同的存储分为

在之前ConfigMap介绍中，我们知道ConfigMap存在的目的并不是为pod提供存储空间来用的，而是给用户提供从集群外部向pod内部应用注入配置信息，本篇笔记简单介绍如何注入一些配置信息，发分别是环境变量和文件的方式。在configMap中，会用到configMapKeyRef和secretKeyRef.configMap也属于名称空间资源。在创建时，没有spec，而有data，结构相对简单