Pods
在上一篇也说明了，pods是kubernetes的最小部署单元，并且所有在pods中的container共享namespaces
那么为什么需要pods这样的概念？
因为在实际中，我们有一种需求，某些进程需要部署在一台机器上，通过IPC或者本地文件来通信，比如因为他们之间数据传输比较大
那么现在我们用容器技术，我们的container就表示一个虚拟的机器，如果我们把多个进程都放在一个container里面可以吗？
肯定可以，但是问题在于，你使用容器的目的就是要平台来帮你管理和监控容器，那么容器就应该是最小的failover单元，如果你在容器里面加上很多process，那么这些process的管理和监控谁来做，又回到了原来的问题，所以一个container比较好的用法是只有一个process
这里如果每个容器一个process，那么容器的namespaces是隔离的，通信会比较麻烦，而且按容器调度也无法保证local
所以自然需要pods这样的higher-level概念，来便于容器的编排，把多个容器变成一个single unit
Pods内部因为共享namesapces，就和一台机器上一样，用IPC就可以简单的通信；那么Pods之间如何通信，Pods之间也可以通过ip直接通信，无论这些Pods被部署在什么地方，但他们都像一个local area network (LAN)一样，可以随意访问对方。
那么我们应该怎么使用pods？怎么把container分配到不同的pods中？
我的理解，没有充分的理由，那就应该一个pod对应于一个container；只有有充分的理由要把多个container绑定在一起的时候，才把他们放到一个pod中
创建Pod
首先创建yaml文件，里面包含这个pod的metadata和spec信息，其中的containerPort只是说明性的
docker和kubernetes中所有组件的配置都是类似这种yaml格式，
如果不清楚具体的格式，可以用explain来查看各个字段的解释
kubectl explain pods
kubectl explain pod.spec
根据Yaml创建Pods，
kubectl create -f kubia-manual.yaml
查看运行Pods的完整定义，
kubectl get po kubia-manual -o yaml
kubectl get po kubia-manual -o json
查看所有Pods，
kubectl get pods
当Pods和Container跑起来后，怎么查看他们的log？
对于docker容器，日志会被输出到标准输出，然后docker runtime会把这些日志重定向到文件，你需要登录到Pod所在的机器，用命令查看
docker logs <container id>
这样很麻烦，Kubernetes提供更简单的方法，
kubectl logs kubia-manual
看某个container
kubectl logs kubia-manual -c kubia
之前看到，可以创建service去把Pods的服务提供出去，但在之前想debug或测试，有没有其他更简单的访问方式
kubectl port-forward kubia-manual 8888:8080
Kubernetes allows you to configure port forwarding to the pod.
This is done through the kubectl port-forward command. The command will forward your machine’s local port 8888 to port 8080 of your kubiamanualpod
Pods标签
labels，干啥用的？
当Pods很多的时候，我们需要去组织和管理pods，组织和管理的标准方法，是分类
lables类似tags，被打上标签的Pods，就被分到各种类别中
如下图，我们可以按照app，rel两个维度的lables来组织各种服务
相关的命令如下，
label可以在创建pods的时候带上，
你可以查看所有pods的label，
或某些特定的label，
当然你可以动态的改label，新增或覆盖修改
kubectl label po kubia-manual creation_method=manual
kubectl label po kubia-manual-v2 env=debug --overwrite
当然有了label，你可以通过label来筛选所有的Pods，
有label的不光是Pods，其实我们也可以给work node加上labels，这样就可以做到按label来schedule Pods，
比如有些Pods需要GPU，那么就需要把他调度到有GPU的work node上，
具体做法，
先给worknode加上label，
kubectl label node gke-kubia-85f6-node-0rrx gpu=true
然后在创建Pod的Yaml指定nodeselector，
Pods Annotation
大段的注释，不具备功能性，说明性文字，最大到256kb
$ kubectl annotate pod kubia-manual mycompany.com/someannotation="foo bar"
pod "kubia-manual" annotated
$ kubectl describe pod kubia-manual
...
Annotations: mycompany.com/someannotation=foo bar
Namespaces
这个和label容易混淆，Namespaces是用户把集群划分的，是non-overlapping的分类；而label是可以overlapping的
比如把系统分成几个部分，以给多个用户使用，或是把系统分成产品，开发，QA环境
可见命名空间是一种管理和组织的方式，把一个整体的资源，划分成多块，用于不同的用途或用户，但并不会去真正隔离
Although namespaces allow you to isolate objects into distinct groups,
which allows you to operate only on those belonging to the specified namespace, they don’t provide any kind of isolation of running objects
可以列存所有Namespaces，正常情况下，都是默认在default命名空间
你可以看某个ns下的pods，
创建ns
$ kubectl create namespace custom-namespace
namespace "custom-namespace" created
在ns下创建资源
$ kubectl create -f kubia-manual.yaml -n custom-namespace
pod "kubia-manual" created
删除Pods
$ kubectl delete po kubia-gpu
pod "kubia-gpu" deleted
$ kubectl delete po -l creation_method=manual
pod "kubia-manual" deleted
pod "kubia-manual-v2" deleted