k8s初探(2)-kubernetes Pod（2）
持续创作，加速成长！这是我参与「掘金日新计划 · 6 月更文挑战」的第3天，点击查看活动详情
我们前面已经介绍过pod的基本特性，这次继续来看pod操作。
如何计划pod容器
如之前所述，pod可以运行至少一个容器，如图所述，大概是这样的
pod中容器是否必须运行在同一宿主机上？
这点尤为重要，我们在计划pod容器的时候，应该思考这样几个点，我们知晓pod是kubernetes的最小基本单位，其启动后，定会负载在某台node上。
例如：有2个容器，A容器和B容器相互依赖，这个时候放在一个pod上就合适
pod中容器是否可以扩容或者缩容？
我们使用kubernetes，最大程度上是得益于其负载均衡/随意扩缩容，若pod中容器，不满足扩缩容，还需谨慎。
例如: 我们将pod直接加进了一个项目，有前端、后端、数据库，这种，显然就不建议加入到一个pod中，因为不方便扩容和缩容。
pod是否是不可拆分的组件
我们在使用docker的过程中，其核心理念，一个容器跑一个进程，这在kubernetes中也深入人心，我们尽量使用一个pod完成一个最小独立的任务。
例如: 我们将pod直接加进了一个项目，有前端、后端、数据库，这种，就建议拆分出来，拆分为如下组件。
kubernetes 标签
label(标签)，是kubernetes中最最最重要的核心概念之一，任何资源都可以定义标签，在pod创建标签，可以直接添加到 metadata.labels中，其explain如下
我们可以定义key:value的形式，来添加标签，例如 我们想修改一下之前定义的nginx，描述，可以定义如下
使用apply创建一下pod
使用show-labels查看一下标签
可以看到，我们之前创建的标签已经生效了
除此之外，我们好像用标签，便无永无之地了，可是，我们可以让pod在指定node上运行，试想下如下场景
我们node2 和 node3是SSD硬盘，其余的都是普通硬盘，假设我们想在kubernetes上运行类似于mysql、mongodb 之类的数据库，我们更加趋向于在有SSD的硬盘上运行， 这个时候，我们就可以给node打一个标签，使用命令(kubectl label)给符合条件的node打上一个标签，在创建pod的时候，选择spec.nodeSelector为node标签即可，这样在负载的时候，就能负载到符合条件的pod上去了。
pod探针
在kubernetes中，有三种探针
- exec探针
在容器中执行任何命令，若命令退出码为0则成功，否则失败
- tcp探针
尝试建立tcp连接，若建立成功，则成功，否则失败
- http get 探针
对容器进行http get请求，如果返回值在200-300之前，则成功，否则失败
除此之外，我们还有2种探寻方式
- 存活探针(
liveness): 在pod启动后，会按照间隔时间进行探测，若探测失败或返回的不是期望值，则pod会被重启，以此往复。 - 就绪探针(
readiness): 就绪探针，仅用于启动容器的时候进行探测使用，在pod启动完毕后，则不会进行探测了。
我们还是可以通过explain来获取帮助，例如，我们想看下http get探针
命令: kubectl explain pod.spec.containers.livenessProbe.tcpSocket
我们想做大概一个这样的事情，就是 我们启动一个nginx的pod，但是这个pod需要对某台宿主机的6379端口进行探测。
我们尝试来编写下描述文件
我们尝试启动pod，若检测失败，出现的日志大概是这样的
若检测失败，它会不断的进行重启。
总结
我们介绍了pod应当如何规划，大概可以理解为如下形式:
-
pod中的容器必须在同一宿主机运行 -
pod扩容和缩容 不影响pod内容器 -
pod容器应当保持最小化原则
接着，我们又介绍了标签和探针，标签在目前看来，似乎毫无用武之地，但是在后期介绍更多资源的时候，其底层所管理pod都是使用便签进行的，而探针则毫无质疑，是很重要的，这也印证我们第一篇看到的，若后端访问失败，则前端不受影响。
