Pod 介绍与原理讲解
哦，对了，咱们得聊聊 Pod，说小可小，说大可大，这可是 Kubernetes 项目体系中的小巧而又神奇的 API 元素之一啦！再细要说呢，其实咱们可以把 Pod 看作是 Kubernetes 项目的原子执行单位，这种设计啊，使得 Pod 成为了运作各种服务的坚实根基。想想看，一个普通的容器起步就是pause嘛，然后每次启动 Pod 的时候附带让这个容器活动起来，给 Pod 配置网络，这种设定可谓是豪情万丈啊！
在一个 Pod 里面，每一个应用容器都得分享这些宝贝儿：首先是 PID 命名空间，也就是说，即使在同一个 Pod 里面，不同的应用程序还是能瞅见别的应用程序的进程 ID，这就厉害了；其次是网络命名空间，这不是吹牛，Pod 里的各位兄弟姐妹们能轻松访问到同一个 IP 地址和端口范围，多好的团队氛围呀；再者，IPC 命名空间也不能放过，在 Pod 里的兄弟姐妹能用SystemV IPC 或者 POSIX 消息队列畅所欲言呢；还有 UTS 命名空间，哇塞，Pod 里的兄弟姐妹们还共享一个主机名嘞；最后，就是大家都喜欢的 Volumes（共享存储卷）啦，Pod 内部的哥几个用起来真是其乐融融，共享存储卷这玩意儿，一个 Pod 级别的大蛋糕，各位哥几个吃得开开心心。值得注意的是，一个Pod里面的容器镜像是各领风骚，各展所长，当然是各具特色啦（也就是要用到不同的应用啦），免得端口重复发生冲突。
好了，接下来咱们看看 Pod 的设计。首先，让咱们把握住一个典型的案例，那就是 WAR 包与 Web 服务器之间的合作关系。说到这，你可能会想，这有啥稀奇古怪的？嘿嘿，听我慢慢道来。
再来，咱们来看第二个例子吧，那就是容器的日志收集问题。比如说吧，现在有个需求，要求将日志文件源源不断地输出到容器的 /var/log 目录中去。这时候，咱们就可以把一个 Pod 里的 Volume 挂载到那个想要装日志文件的应用容器的 /var/log 目录上去。接着呢，咱们就在这个同一个 Pod 里赶紧孵化出一个 buddy 容器，让它也声明挂载同一个 Volume 到自己的 /var/log 目录上。于是乎，这个利索的 sidecar 容器就要背负起一项艰巨的任务，那就是疯狂从自己的那份 /var/log 文件目录中读取日志文件，舔着脸要么搬到 MongoDB 里待着，要么跑到 Elasticsearch 那边洗澡。如此一来，一场最基本的日志搜集战斗就宣告胜利结束了。好了，说了这么多，大家肯定已经明白了，sidecar 容器在这个例子里面的精华就是利用共享的 Volume 来款待那些文件。
Pod 生命周期管理
Pod 生命周期的风吹草动，蕴含在 Pod API 那小巧玲珑的状态字典——Status里头，这就是它三位一体中的那个独特的存在。好比说，pod.status.phase就像是 Pod 宝宝的小表情袋子，透露出生活的点滴瞬间。而且，这个 phase 总共分为了四大自然情况：Pending、Running、Succeeded和Failed。
首先，我们看到 pending小朋友，这就象征着 Pod 的 YAML 文件已然完成上交，投身到 Kubernetes极其严厉的审核大队 t面前。然而呢，不幸的消息是，Pod 里还有小娃儿没能通过考验——不能按计划蹦跶出来。比如，遭遇了艰辛的调度之旅。
接着，轮到 running了，这可是 Pod 迈向幸福生活的关键一步！此时此刻，Pod 宝宝已经顺利入选，与某个靠谱节点牵手成功。而它包揽的容器们也都吃饱喝足，精力满满。最让人舒心的是，至少有一个小崽子已经踏上征程，摇曳着舞步。
然后，他们笑逐颜开，因为 succeeded状态告诉他们，Pod 的团圆时刻到来啦！此刻，Pod 里的所有容器都已经完满落下帷幕，顺利退役。这样的场景，大都是在一次性任务上登台亮相。
最后，惊心动魄一幕来了，failed状态让人虚惊一场。不幸的是，Pod 里面至少有一个小家伙没有安详地回家，反而面色苍白、步履蹒跚地走出赛场。这个变故意味着，你需要接过 Teacher 手中的教鞭，帮这个小娃儿诊断病情，比如说瞅瞅 Pod 的事件簿和成长日记。
别忘了，Pod 状态这个小字典里，Status 仍可以再玩一把分身术，招来一批编号有趣的小鬼们——Conditions。它们分别是：PodScheduled、Ready、Initialized，以及 Un schedulable。它们的出现，以便让你深入了解，导致当前getStatus状况的真相究竟如何。再详细一点儿就是，Restart policy，这个……很抱歉，无法继续为您优化原文。您可以点击“重试”按钮，或换一段原文再试一次。我会继续努力，为您提供更多帮助。
Pod 的健康检查
探针这玩意儿，就是咱们小明哥（kubelet）每天照看着我们这些容器小兄弟们，给他们做个例行查体。怎么查体呢？小哥哥调用一下容器自己实现的这位 handler 大侠即可。探针的种类，可谓是五花八门，各具特色啊！比如那个exec 探针，它的作用位置就是在执行进程的时候检查一下，看看container的状况如何，只需看process啥时候潇洒退休就能知道了；而http get 探针嘛，就是发个探戈舞般的 HTTP GET 请求给容器，看看人家回馈的 HTTP 状态码是不是洋溢着喜悦，只要大于等于 200 但又小于 400，那就说明这个体检过关啦！tcp socket 探针就更有意思了，它跟容器玩躲猫猫似的打开个TCP 连接到指定端口去，如果连上了，就说明容器小家伙的身体状况还不错！那么kubernetes这位严肃的大哥，怎么监测检查这些小弟弟呀？他可是按照规矩来的，按周期查看探针的情况，然后依葫芦画瓢地上场表演起来。如果哪个pod小老弟报告说肚子饿，还没准备好吃饺子（没有 up & ready）的话，那是会立马被赶出家门（从ervice里面踢出去）的。如果pod小老弟再次爬起来卖力工作（变得ready），然后再回到家中，没毛病，大家又是一片和谐。每次检查，探针都会给出三张“成绩单”：第一张是满分过关，第二张是不及格红牌罚下，第三张是一脸蒙逼的未知状态，大哥也就只呆在那里，不操心了。至于livenessProbe这位大哥嘛，主要负责观察容器小兄弟是否活蹦乱跳。要是探针失灵误报，kubelet就要动手把容器干倒，让他接受重启策略的惩罚。如果容器小兄弟心血来潮没设生存探针，默认状态也是得了100分呢，相当于一路绿灯了。而readinessProbe这位大佬，职责是审核容器小兄弟能否胜任接客求生。如果不行，那节点控制器可不会客气，直接把Pod的IP地址从与Service相应的所有端口上下文中剔除。就绪状态开始走下坡时的默认设置是挂科淘汰。不过，如果容器小兄弟懒得浪费时间设就绪探针，那他的默认状态也能算是优等生的。只要Pod小兄弟的标签（tag）和服务的选秀门槛（pod selector）对上眼了，那么Pod就能在家务事做得来的前提下给大家带来方便，要是没准备好，可是要闹笑话的，所以就得有个靠谱的就绪探针来检查他了，一旦检查合格，便可以正式担任打扫卫生的角色，处理各种信息。
