• kubernetes入门(04)kubernetes的核心概念(1)


    一、ReplicationController/ReplicaSet

    在Kubernetes集群中,ReplicationController能够确保在任意时刻,指定数量的Pod副本正在运行。如果Pod副本的数量过多,则ReplicationController会Kill掉部分使其数量与预期保持一致,如果Pod数量过少,则会自动创建新的Pod副本以与预期数量相同。下面是一个ReplicationController的配置示例,如下所示:

    ReplicaSet是ReplicationController的下一代实现,它们之间没有本质的区别,除了ReplicaSet支持在selector中通过集合的方式进行配置。在新版本的Kubernetes中支持并建议使用ReplicaSet,而且我们应该尽量使用Deployment来管理一个ReplicaSet。下面定义一个ReplicaSet,对应的配置示例如下所示:

    二、Volume

    默认情况下容器的数据都是非持久化的,在容器销毁以后数据也会丢失,所以Docker提供了Volume机制来实现数据的持久化存储。同样,Kubernetes提供了更强大的Volume机制和丰富的插件,实现了容器数据的持久化,以及在容器之间共享数据。
    Kubernetes Volume具有显式的生命周期,它与Pod的生命周期是相同的,所以只要Pod还处于运行状态,则该Pod内部的所有容器都能够访问该Volume,即使该Pod中的某个容器失败,数据也不会丢失。
    Kubernetes支持多种类型的Volume,如下所示:

    • emptyDir
    • hostPath
    • gcePersistentDisk
    • awsElasticBlockStore
    • nfs
    • iscsi
    • fc (fibre channel)
    • flocker
    • glusterfs
    • rbd
    • cephfs
    • gitRepo
    • secret
    • persistentVolumeClaim
    • downwardAPI
    • projected
    • azureFileVolume
    • azureDisk
    • vsphereVolume
    • Quobyte
    • PortworxVolume
    • ScaleIO
    • StorageOS
    • local

    上面各种类型的说明和示例,可以参考官方文档。Volume是与Pod有关的,所以这里我们给出一个Pod定义的配置示例,使用了hostPath类型的Volume,如下所示:

    上面定义中,指定了Pod中容器使用的Node节点上的data存储路径。

    三、Deployment

    Deployment提供了声明式的方法,对Pod和ReplicaSet进行更新,我们只需要在Deployment对象中设置好预期的状态,然后Deployment就能够控制将实际的状态保持与预期状态一致。使用Deployment的典型场景,有如下几个:

    • 创建ReplicaSet,进而通过ReplicaSet启动Pod,Deployment会检查启动状态是否成功
    • 滚动升级或回滚应用
    • 应用扩容或缩容
    • 暂停(比如修改Pod模板)及恢复Deployment的运行
    • 根据Deployment的运行状态,可以判断对应的应用是否hang住
    • 清除掉不再使用的ReplicaSet

    定义一个Deployment,示例如下所示:

    上述配置创建一个ReplicaSet,进而启动3个Nginx Pod。

    四、DaemonSet

    DaemonSet能够保证Kubernetes集群中某些Node,或者全部Node上都运行一个Pod副本,当集群中某个Node被移除时,该Node上的Pod副本也会被清理掉。删除一个DaemonSet,也会把对应的Pod都删除掉。
    通常,DaemonSet会被用于如下场景(在Kubernetes集群中每个Node上):

    • 运行一个存储Daemon,如glusterd、ceph等
    • 运行一个日志收集Daemon,如fluentd、logstash等
    • 运行一个监控Daemon,如collectd、gmond等

    定义一个DaemonSet,示例如下所示:

    上面例子,创建了一个基于fluentd的日志收集DaemonSet。

    五、StatefulSet

    StatefulSet是Kubernetes v1.5版本新增的,在v1.5之前的版本叫做PetSet(使用v1.4版本可以使用,具体可以查看官方文档,这里不再累述),是为了解决有状态服务的问题(对应无状态服务的Kubernetes对象:Deployment和ReplicaSet),其应用场景包括:

    • 稳定的持久化存储,即Pod重新调度后还是能访问到相同的持久化数据,基于PVC来实现
    • 稳定的网络标志,即Pod重新调度后其PodName和HostName不变,基于Headless Service(即没有Cluster IP的Service)来实现
    • 有序部署,有序扩展,即Pod是有顺序的,在部署或者扩展的时候要依据定义的顺序依次进行,基于init containers来实现
    • 有序缩容,有序删除

    为了说明StatefulSet,我们先定义一个名称为nginx的Headless Service,如下所示:

    再定义一个名称为web的StatefulSet,定义了要在3个独立的Pod中分别创建3个nginx容器,示例如下所示:

    上面示例,在Service中引用了名称为web的StatefulSet,该Service对应的存储信息是有状态的,通过StatefulSet能够保证Service中的Pod失败也不会丢失存储的数据,它通过PersistentVolume来提供稳定存储的。

    六、ConfigMap

    应用程序会从配置文件、命令行参数或环境变量中读取配置信息,如果将这些配置信息直接写在Docker镜像中,会非常不灵活,每次修改配置信息都要重新创建一个Docker镜像。ConfigMap的出现,能够使配置信息与Docker镜像解耦,更加方便和灵活。

    在定义一个Pod的时候,可以使用ConfigMap对象中的配置数据,有很多种方式,如下所示:

    • 从一个ConfigMap中读取键值对配置数据
    • 从多个ConfigMap中读取键值对配置数据
    • 从一个ConfigMap中读取全部的键值对配置数据
    • 将一个ConfigMap中的配置数据加入到一个Volume中

    下面给出其中2种使用方式:

    • 定义一个环境变量,该变量值映射到一个ConfigMap对象中的配置值

    创建一个名称为special-config的ConfigMap对象,执行如下命令:

    kubectl create configmap special-config --from-literal=special.how=very

    在上述ConfigMap对象special-config中创建了一个键special.how,它对应的值为very。
    然后,我们定义一个Pod,将ConfigMap中的键special.how对应的值,赋值给环境变量SPECIAL_LEVEL_KEY,Pod定义文件内容,如下所示:

    这时,Pod创建以后,就可以获取到对应的环境变量的值:SPECIAL_LEVEL_KEY=very。

    • 创建多个ConfigMap对象,Pod从多个ConfigMap对象中读取到对应的配置值

    首先,创建第一个ConfigMap对象special-config,该对象定义了配置数据special.how=very,如下所示:

    然后,创建第二个ConfigMap对象env-config,该对象定义了配置数据log_level=INFO,如下所示:

    最后,就可以在Pod中定义环境变量,如下所示:

    在Pod创建后,可以分别从special-config、env-config中读取环境变量的值:SPECIAL_LEVEL_KEY=very、LOG_LEVEL=INFO。

    七、Secret

    Secret对象用来保存一些敏感信息,比如密码、OAuth令牌、ssh秘钥等,虽然这些敏感信息可以放到Pod定义中,或者Docker镜像中,但是放到Secret对象中更加安全和灵活。
    使用Secret对象时,可以在Pod中引用创建的Secret对象,主要有如下两种方式:

    • 挂载到一个或多个容器的Volume中的文件里面
    • 当为一个Pod拉取镜像时,被kubectl使用

    可以通过将Secret挂载到Volume中,或者以环境变量的形式导出,来被一个Pod中的容器使用。下面是一个示例,在一个Pod中的Volume上挂载一个Secret,如下所示:

    通过导出环境变量,使用Secret,示例如下所示:

    八、Job

    一个Job会创建一个或多个Pod,并确保指定数目的Pod能够运行成功。Job会跟踪每个Pod的运行,直到其运行成功,如果该Job跟踪的多个Pod都运行成功,则该Job就变为完成状态。删除一个Job,该Job创建的Pod都会被清理掉。
    定义一个Job,示例如下所示:

     

    九、CronJob

    Crontab用来管理定时Job,主要使用场景如下:

    • 在一个给定的时间点,调度Job运行
    • 创建一个周期性运行的Job,例如数据库备份、发送邮件等等

    定义一个CronJob,示例配置内容如下所示:

    十、Ingress

    通常情况下,Service和Pod仅可在集群内部网络中通过IP地址访问。所有到达Edge router的流量或被丢弃或被转发到其它地方。一个Ingress是一组规则的集合,这些规则允许外部请求(公网访问)直接连接到Kubernetes集群内部的Service,

    如下图所示:

    我们可以配置Ingress,为它提供外部(公网)可访问给定Service的规则,如Service URL、负载均衡、SSL、基于名称的虚拟主机等。用户想要基于POST方式请求Ingress资源,需要通过访问Kubernetes API Server来操作Ingress资源。
    Ingress Controller是一个daemon进程,它是通过Kubernetes Pod来进行部署的。它负责实现Ingress,通常使用负载均衡器,还可以配置Edge router和其他前端(frontends),以高可用(HA)的方式来处理请求。为了能够使Ingress工作,Kubernetes集群中必须要有个一个Ingress Controller在运行,不同于kube-controller-manager所管理的Controller,我们必须要选择一个适合我们Kubernetes集群的Ingress Controller实现,如果没有合适的就需要开发实现一个。
    定义一个Ingress,示例如下所示:

    上面rules配置了Ingress的规则列表,目前只支持HTTP规则,该示例使用了HTTP的paths规则,所请求URL能够匹配上paths指定的testpath,都会被转发到backend指定的Service上。
    Ingress有如下5种类型:

      • 单Service Ingress
      • 简单扇出(fanout)
      • 基于名称的虚拟主机
      • TLS
      • 负载均衡

    十一、Horizontal Pod Autoscaler (弹性伸缩)

    应用运行在容器中,它所依赖的资源的使用率通常并不均衡,资源使用量有时可能达到峰值,有时使用的又很少,为了提高Kubernetes集群的整体资源利用率,我们需要Service中的Pod的个数能够根据实际资源使用量来自动调整。

    这时我们就可以使用HPA(Horizontal Pod Autoscaling),它和Pod、Deployment等都是Kubernetes API资源,能实现Kubernetes集群内Service中Pod的水平伸缩。

    HPA的工作原理,如下图所示:

    通过下面命令,可以对HPA进行各种操作(创建HPA、列出所有HPA、获取HPA详细描述信息、删除HPA):

    另外,还可以通过kubectl autoscale 命令来创建HPA,例如,执行如下命令:

    kubectl autoscale rc foo --min=2 --max=5 --cpu-percent=80

    上面示例的命令,要为名称为foo的ReplicationController创建一个HPA对象,使得目标CPU利率用为80%,并且副本的数量保持在2到5之间。

    十二、kubectl CLI

     kubectl是一个命令行接口,通过它可以执行命令与Kubernetes集群交互。kubectl命令的语法格式,如下所示:

     kubectl [command] [TYPE] [NAME] [flags]

    上面命令说明中:
    command:需要在一种或多种资源上执行的操作,比如:create、get、describe、delete等等,更详细可以参考官网文档。
    TYPE:指定资源类型,大小写敏感,当前支持如下这些类型的资源:certificatesigningrequests、clusters、clusterrolebindings、clusterroles、componentstatuses、configmaps、cronjobs、daemonsets、deployments、endpoints、events、horizontalpodautoscalers、ingresses、jobs、limitranges、namespaces、networkpolicies、nodes、persistentvolumeclaims、persistentvolumes、poddisruptionbudget、pods、podsecuritypolicies、podtemplates、replicasets、replicationcontrollers、resourcequotas、rolebindings、roles、secrets、serviceaccounts、services、statefulsets、storageclasses、thirdpartyresources。
    NAME:指定资源的名称,大小写敏感。
    flags:可选,指定选项标志,比如:-s或-server表示Kubernetes API Server的IP地址和端口。
    如果想要了解上述命令的详细用法说明,可以执行帮助命令:

    kubectl help

    另外,还可以通过官方文档,根据使用的Kubernetes的不同版本,来参考如下链接获取帮助:

    下面,举个常用的命令行操作,需要通过YAML文件定义一个Service(详见上文“基本概念”中给出的Service示例),创建一个Service,执行如下命令:

    kubectl create -f ./my-k8s-service.yaml

    定义任何Kubernetes对象,都是通过YAML文件去配置,使用类似上述命令进行创建。如果想要查看创建Kubernetes对象的结果,比如查看创建Service对象的结果,可通过如下命令查看:

    kubectl get services

    这样,就能看到当前创建的Service对象的状态。

    参考链接

  • 相关阅读:
    LDAP Authentication for openNebula3.2
    opennebula auth module ldap
    opennebula extend(expending) auth module ldap
    centos6.4 ceph安装部署之ceph object storage
    centos6.4 ceph安装部署之cephFS
    ERROR: modinfo: could not find module rbd FATAL
    centos6.4 ceph安装部署之ceph block device
    Cannot retrieve metalink for repository: epel.
    卡特兰数
    iOS开发之UIImage等比缩放
  • 原文地址:https://www.cnblogs.com/lexiaofei/p/7778393.html
Copyright © 2020-2023  润新知