qq_47261578的博客

使用Replication Controller、Replica Set 管理Pod前面我们学习了Pod的一些基本使用方法，而且前面我们都是直接来操作的Pod，假如现在有一个Pod正在提供线上的服务，我们来想想一下我们可能会遇到的一些场景：某次运营活动非常成功，网站访问量突然暴增运行当前Pod的节点发生故障了，Pod不能正常提供服务了第一种情况，可能比较好应对，一般活动之前我们会大概计算下会有多大的访问量，提前多启动几个Pod，活动结束后把多余的Pod杀掉，虽然有点麻烦，但是应该还是能够应对这

初始化容器容器的健康检查的两个探针：liveness probe（存活探针）和readiness probe（就绪探针）的使用方法，这两个探针是可以影响容器的生命周期的，包括我们之前提到的容器的两个钩子函数PostStart和PreStop。今天要介绍的是Init Container（初始化容器）。Init Container就是用来做初始化工作的容器，可以是一个或者多个，如果有多个的话，这些容器会按定义的顺序依次执行，只有所有的Init Container执行完后，主容器才会被启动。一个Pod里面的所

健康检查在Kubernetes集群当中，我们可以通过配置**liveness probe（存活探针）和readiness probe（就绪探针）**来影响容器的生存周期。#kubelet 通过使用 liveness probe 来确定你的应用 程序是否正在运行，通俗点将就是是否还活着。一般来说，如果你的程序一旦崩溃了，Kubernetes 就会立刻知道这个程序已经终止了，然后就会重启这个程序。而我们的liveness probe 的目的就是来捕获到当前应用程序还没有终止，还没有崩溃，如果出现了这些情况，

pod的生命周期我们知道Pod是Kubernetes集群中的最小单元，而 Pod 是由容器组成的，所以在讨论 Pod 的生命周期的时候我们可以先来讨论下容器的生命周期。实际上 Kubernetes 为我们的容器提供了生命周期钩子，就是我们说的Pod Hook，Pod Hook 是由 kubelet 发起的，当容器中的进程启动前或者容器中的进程终止之前运行，这是包含在容器的生命周期之中。我们可以同时为 Pod 中的所有容器都配置 hook。[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接

静态POD静态pod的原理静态 Pod 直接由特定节点上的kubelet进程来管理，不通过 master 节点上的apiserver。无法与我们常用的控制器Deployment或者DaemonSet进行关联，它由kubelet进程自己来监控，当pod崩溃时重启该pod，kubelete也无法对他们进行健康检查。静态 pod 始终绑定在某一个kubelet，并且始终运行在同一个节点上。 kubelet会自动为每一个静态 pod 在 Kubernetes 的 apiserver 上创建一个镜像 Pod（Mi

Kubeadm安装K8s基础环境ip/主机名配置安装软件192.168.10.101/k8s-master2G/2C三台基础docker环境192.168.10.102/k8s-node012G/1C三台基础docker环境192.168.10.103/k8s-node022G/1C三台基础docker环境一：更改控制组@1[root@centos-01 ~]# cat /etc/docker/daemon.json{ "registry-m

k8s结合Metrics-Server实现自动伸缩资源限制的介绍requests.cpu是命名空间中所有容器的最大组合CPU请求（以毫秒为单位）。 在上面的示例中，您可以拥有50个具有10m请求的容器，5个具有100m请求的容器，甚至一个具有500m请求的容器。 只要命名空间中请求的总CPU和小于500m！requests.memory是命名空间中所有容器的最大组合内存请求。 在上面的示例中，您可以拥有50个具有2MiB请求的容器，5个具有20MiB请求的容器，甚至是具有100MiB请求的单个容器。

Secret安全存储上节课我们学习了Kubernetes 当中非常重要的一个对象ConfigMap ，一般情况下ConfigMap 是用来存储一些非安全的配置信息，如果涉及到一些安全相关的数据的话用ConfigMap 就非常不妥了，因为ConfigMap 是名为存储的，我们说这个时候我们就需要用到另外一个资源对象了：Secret ， Secret 用来保存敏感信息，例如密码、Auth 令牌和 ssh key等等，将这些信息放在Secret 中比放在Pod 的定义中或者docker 镜像中来说更加安全和灵活

ConfigMap配置文件存储前面的课程中我们学习了Servie 的使用，Service是Kubernetes 系统中非常重要的一个核心概念，后面的课程中还会继续学习Service的一些使用方法的。这节课来学习另外一个非常重要的资源对象：ConfigMap ，在实际工作中许多应用经常会有从配置文件、命令行参数或者环境变量中读取一些配置信息，这些配置信息我们肯定不会直接写死到应用程序中去的，比如你一个应用连接一个redis服务，下一次想更换一个，还得重新去修改代码，重新制作一个镜像，这肯定是不可取的，而Co

Job 和 Cronjob 的使用我们来介绍另外一类资源对象：Job，在日常的工作中经常都会遇到一些需要进行批量数据处理和分析的需求，当然也会有按时间来进行调度的工作，在我们的Kubernetes 集群中为我们提供了Job 和CronJob两种资源对象来应对我们的这种需求。Job 负责处理任务，即仅执行一次的任务，它保证批处理任务的一个或多个Pod 成功结束。而CronJob则就是在Job 上加上了时间调度。中文解释文档一次性任务Job我们用Job 这个资源对象来创建一个任务，定一个Job 来执行

Service我们前面学习了Pod 的基本用法，也了解到 Pod 的生命周期管理。后面学习到的RC 和Deployment 可以用来动态的创建和销毁Pod 。尽管每个Pod 都有自己的IP 地址，但是如果 Pod 重新启动了的话那么他的IP 很有可能也就变化了。这就会带来一个问题：比如我们有一些后端的Pod 的集合为集群中的其他前端的Pod 集合提供 API 服务，如果我们在前端的Pod 中把所有的这些后端的Pod 的地址都写死，然后去某种方式去访问其中一个Pod 的服务，这样看上去是可以工作的，但是如果

Deployment的使用官方文档请点击前面我们学习了Replication Controller和Replica Set两种资源对象，RC和RS的功能基本上是差不多的，唯一的区别就是RS支持集合的selector。我们也学习到了用RC / RS来控制Pod副本的数量，也实现了滚动升级Pod的功能。现在看上去似乎一切都比较完美的运行着，但是我们上节课最后也提到了现在我们推荐使用Deployment这种控制器了，而不是我们之前的RC或者RS，这是为什么呢？我们来对比下二者之间的功能吧，首先RC是Kube