标签: #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两种资源对象来应对我们的这种需求。

前面我们的课程中学习了Pod的一些基本使用方法，而且前面我们都是直接来操作的Pod，假如我们现在有一个Pod正在提供线上的服务，我们来想想一下我们可能会遇到的一些场景：

• 某次运营活动非常成功，网站访问量突然暴增
• 运行当前Pod的节点发生故障了，Pod不能正常提供服务了

第一种情况，可能比较好应对，一般活动之前我们会大概计算下会有多大的访问量，提前多启动几个Pod，活动结束后再把多余的Pod杀掉，虽然有点麻烦，但是应该还是能够应对这种情况的。

第二种情况，可能某天夜里收到大量报警说服务挂了，然后起来打开电脑在另外的节点上重新启动一个新的Pod，问题也很好的解决了。

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技术圈的几个精选的问题，分享给大家。另外，也欢迎大家加入我们的【微信群】和【知识星球】共同探讨，共同进步。

在我们开发kubernetes应用的过程中，一般情况下是我们在本地开发调试测试完成以后，再通过CI/CD的方式部署到kubernetes的集群中，这个过程首先是非常繁琐的，而且效率非常低下，因为你想验证你的每次代码修改，就得提交代码重新走一遍CI/CD的流程，我们知道编译打包成镜像这些过程就是很耗时的，即使我们在自己本地搭建一套开发kubernetes集群，也同样的效率很低。在实践中，若不在本地运行那些服务，调试将变得颇具挑战。就在几天前，我遇到了Skaffold，它是一款命令行工具，旨在促进kubernetes应用的持续开发，Skaffold可以将构建、推送及向kubernetes集群部署应用程序的过程自动化，听上去是不是很舒服呀~~~