前面的课程中我们学习了 PV 和 PVC 的使用方法,但是前面的 PV 都是静态的,什么意思?就是我要使用的一个 PVC 的话就必须手动去创建一个 PV,我们也说过这种方式在很大程度上并不能满足我们的需求,比如我们有一个应用需要对存储的并发度要求比较高,而另外一个应用对读写速度又要求比较高,特别是对于 StatefulSet 类型的应用简单的来使用静态的 PV 就很不合适了,这种情况下我们就需要用到动态 PV,也就是我们今天要讲解的 StorageClass。
标签: #Kubernetes
前面我们和大家一起学习了一些基本的资源对象的使用方法,前面我们也和大家讲到了有状态的应用和对数据有持久化的应用,我们有通过 hostPath 或者 emptyDir 的方式来持久化我们的数据,但是显然我们还需要更加可靠的存储来保存应用的持久化数据,这样容器在重建后,依然可以使用之前的数据。但是显然存储资源和 CPU 资源以及内存资源有很大不同,为了屏蔽底层的技术实现细节,让用户更加方便的使用,Kubernetes 便引入了 PV 和 PVC 两个重要的资源对象来实现对存储的管理。
前面两节课我们学习了Kubernetes中的两个用于配置信息的重要资源对象:ConfigMap和Secret,其实到这里我们基本上学习的内容已经覆盖到Kubernetes中一些重要的资源对象了,来部署一个应用程序是完全没有问题的了。在我们演示一个完整的示例之前,我们还需要给大家讲解一个重要的概念:RBAC - 基于角色的访问控制。
上节课我们学习了ConfigMap的使用,我们说ConfigMap这个资源对象是Kubernetes当中非常重要的一个对象,一般情况下ConfigMap是用来存储一些非安全的配置信息,如果涉及到一些安全相关的数据的话用ConfigMap就非常不妥了,因为ConfigMap是明文存储的,我们说这个时候我们就需要用到另外一个资源对象了:Secret,Secret用来保存敏感信息,例如密码、OAuth 令牌和 ssh key等等,将这些信息放在Secret中比放在Pod的定义中或者docker镜像中来说更加安全和灵活。
我们前面的课程中学习了Pod的基本用法,我们也了解到Pod的生命是有限的,死亡过后不会复活了。我们后面学习到的RC和Deployment可以用来动态的创建和销毁Pod。尽管每个Pod都有自己的IP地址,但是如果Pod重新启动了的话那么他的IP很有可能也就变化了。这就会带来一个问题:比如我们有一些后端的Pod的集合为集群中的其他前端的Pod集合提供API服务,如果我们在前端的Pod中把所有的这些后端的Pod的地址都写死,然后去某种方式去访问其中一个Pod的服务,这样看上去是可以工作的,对吧?但是如果这个Pod挂掉了,然后重新启动起来了,是不是IP地址非常有可能就变了,这个时候前端就极大可能访问不到后端的服务了。
上节课我们学习了Pod自动伸缩的方法,我们使用到了HPA这个资源对象,我们在后面的课程中还会和大家接触到HPA的。今天我们来给大家介绍另外一类资源对象:Job,我们在日常的工作中经常都会遇到一些需要进行批量数据处理和分析的需求,当然也会有按时间来进行调度的工作,在我们的Kubernetes集群中为我们提供了Job和CronJob两种资源对象来应对我们的这种需求。
TODO
上节课我们学习了容器的健康检查的两个探针:liveness probe(存活探针)和 readiness probe(可读性探针)的使用方法,我们说在这两个探针是可以影响容器的生命周期的,包括我们之前提到的容器的两个钩子函数 PostStart 和 PreStop 。我们今天要给大家介绍的是Init Container(初始化容器)。
我们知道Pod是Kubernetes中最小的调度单元,平时我们操作Pod的时间也是最多的,那么你知道Pod是怎样被创建出来的吗?知道他的工作流程吗?
kubeadm是Kubernetes官方提供的用于快速安装 Kubernetes 集群的工具,通过将集群的各个组件进行容器化安装管理,通过kubeadm的方式安装集群比二进制的方式安装要方便不少,但是目录kubeadm还处于beta状态,还不能用于生产环境,Using kubeadm to Create a Cluster文档中已经说明kubeadm将会很快能够用于生产环境了。
所以现在来了解下kubeadm的使用方式的话还是很有必要的,对于现阶段想要用于生产环境的,建议还是参考我们前面的文章:手动搭建高可用的kubernetes 集群或者视频教程。
老规矩,本周的k8s技术圈的几个精选的问题,分享给大家。另外,也欢迎大家加入我们的【微信群】和【知识星球】共同探讨,共同进步。