Content #

刘易斯·芒福德就是这些伟大观察者中的一个。他不是那种为了看时间才看钟表的人，这并不是因为他对大家关心的钟表本身的分分秒秒不感兴趣，而是他对钟表怎样表现“分分秒秒”这个概念更感兴趣。他思考钟表的哲学意义和隐喻象征，而这些正是我们的教育不甚了了的地方，钟表匠们对此更是一无所知。芒福德总结说：“钟表是一种动力机械，其产品是分和秒。”在制造分秒的时候，钟表把时间从人类的活动中分离开来，并且使人们相信时间是可以以精确而可计量的单位独立存在的。分分秒秒的存在不是上帝的意图，也不是大自然的产物，而是人类运用自己创造出来的机械和自己对话的结果。

在芒福德的著作《技术与文明》中，他向我们展示了从14世纪开始，钟表是怎样使人变成遵守时间的人、节约时间的人和现在拘役于时间的人。在这个过程中，我们学会了漠视日出日落和季节更替，因为在一个由分分秒秒组成的世界里，大自然的权威已经被取代了。确实，正如芒福德所指出的，自从钟表被发明以来，人类生活中便没有了永恒。所以，钟表不懈的嘀嗒声代表的是上帝至高无上的权威的日渐削弱，虽然很少有人能意识到其中的关联。也就是说，钟表的发明引入了一种人和上帝之间进行对话的新形式，而上帝似乎是输家。也许摩西的“十诫”中还应该再加上一诫：你不可制作任何代表时间的机械。

From #

娱乐至死

Links #

Content #

Deployment 三个关键字段:

1. replicas 定义了 Pod 的“期望数量”，Kubernetes 会自动维护 Pod 数量到正常水平。
2. selector 定义了基于 labels 筛选 Pod 的规则，它必须与 template 里 Pod 的 labels 一致。
3. template 定义了要运行的 Pod 模板。

Kubernetes 采用的是“贴标签”的方式，通过在 API 对象的“metadata”元信息里加各种标签（labels），我们就可以使用类似关系数据库里查询语句的方式，筛选出具有特定标识的那些对象。通过标签这种设计，Kubernetes 就解除了 Deployment 和模板里 Pod 的强绑定，把组合关系变成了“弱引用”。

下图用虚线特别标记了 matchLabels 和 labels 之间的联系。

关键字段 selector，它的作用是“筛选”出要被 Deployment 管理的 Pod 对象，下属字段“matchLabels”定义了 Pod 对象应该携带的 label，它必须和“template”里 Pod 定义的“labels”完全相同，否则 Deployment 就会找不到要控制的 Pod 对象，apiserver 也会告诉你 YAML 格式校验错误无法创建。

为什么要这么麻烦？为什么不能像 Job 对象一样，直接用“template”里定义好的 Pod 就行了呢？

这是因为在线业务和离线业务的应用场景差异很大。离线业务中的 Pod 基本上是一次性的，只与这个业务有关，紧紧地绑定在 Job 对象里，一般不会被其他对象所使用。而在线业务就要复杂得多了，因为 Pod 永远在线，除了要在 Deployment 里部署运行，还可能会被其他的 API 对象引用来管理，比如负责负载均衡的 Service 对象。

Content #

Viewpoints #

From #

15｜实战演练：玩转Kubernetes（1）

Links #

Content #

1. CRI （Container Runtime Interface）容器运行时接口，CRI中定义了容器和镜像两个接口，实现了这两个接口的目前主流的是：CRI-O、Containerd。（目前 PCI 产品使用的即为 Containerd）。
2. OCI（Open Container Initiative）开放容器标准，OCI 中定义了两个标准：容器运行时标准和容器镜像标准，实现了这一标准的主流是：runc（也即我们日常说的 Docker）、 Kata-Container
3. CNI（Container Network Interface）容器网络接口，CNI接口只有两个：容器创建分配网络资源、容器删除释放网络资源。

Viewpoints #

From #

15｜实战演练：玩转Kubernetes（1）

Links #

Content #

在 Pod 里挂载 Volume 只需要在“spec”里增加一个“volumes”字段，然后再定义卷的名字和引用的 ConfigMap/Secret 就可以了。要注意的是 Volume 属于 Pod，不属于容器，所以它和字段“containers”是同级的，都属于“spec”。

apiVersion: v1
kind: Pod
metadata:
  name: vol-pod

spec:
  volumes:
  - name: cm-vol
    configMap:
      name: info
  - name: sec-vol
    secret:
      secretName: user

  containers:
  - volumeMounts:
    - mountPath: /tmp/cm-items
      name: cm-vol
    - mountPath: /tmp/sec-items
      name: sec-vol

    image: busybox
    name: busy
    imagePullPolicy: IfNotPresent
    command: ["/bin/sleep", "300"]

创建之后，我们还是用 kubectl exec 进入 Pod，看看配置信息被加载成了什么形式：

kubectl apply -f vol-pod.yml
kubectl get pod
kubectl exec -it vol-pod -- sh

挂载 Volume 的方式和环境变量又不太相同。环境变量是直接引用了 ConfigMap/Secret，而 Volume 又多加了一个环节，需要先用 Volume 引用 ConfigMap/Secret，然后在容器里挂载 Volume，有点“兜圈子”“弯弯绕”。

Content #

可以使用另一个“valueFrom”字段，从 ConfigMap 或者 Secret 对象里获取值。由于“valueFrom”字段在 YAML 里的嵌套层次比较深，初次使用最好看一下 kubectl explain 对它的说明：

kubectl explain pod.spec.containers.env.valueFrom

比如：

apiVersion: v1
kind: Pod
metadata:
  name: env-pod

spec:
  containers:
  - env:
      - name: COUNT
        valueFrom:
          configMapKeyRef:
            name: info
            key: count
      - name: GREETING
        valueFrom:
          configMapKeyRef:
            name: info
            key: greeting
      - name: USERNAME
        valueFrom:
          secretKeyRef:
            name: user
            key: name
      - name: PASSWORD
        valueFrom:
          secretKeyRef:
            name: user
            key: pwd

    image: busybox
    name: busy
    imagePullPolicy: IfNotPresent
    command: ["/bin/sleep", "300"]

这个 Pod 会执行命令 sleep 睡眠 300 秒，我们可以在这段时间里使用命令 kubectl exec 进入 Pod 观察环境变量。

四个变量的引用关系如下图所示：

Content #

apiVersion: v1
kind: ConfigMap
metadata:
  name: info

data:
  count: '10'
  debug: 'on'
  path: '/etc/systemd'
  greeting: |
    say hello to kubernetes.

ConfigMap 存储的是配置数据，是静态的字符串，并不是容器，所以它们就不需要用“spec”字段来说明运行时的“规格”。ConfigMap 要存储数据，需要用另一个含义更明确的字段“data”。

要生成带有“data”字段的 YAML 样板，你需要在 kubectl create 后面多加一个参数 –from-literal ，表示从字面值生成一些数据：

kubectl create cm info --from-literal=k=v $out

Viewpoints #

From #

14｜ConfigMap/Secret：怎样配置、定制我的应用

Links #

Content #

CronJob 其实是又组合了 Job 而生成的新对象，它的“套娃”结构：

CronJob 使用定时规则控制 Job，Job 使用并发数量控制 Pod，Pod 再定义参数控制容器，容器再隔离控制进程，进程最终实现业务功能，层层递进的形式有点像设计模式里的 Decorator（装饰模式），链条里的每个环节都各司其职，在 Kubernetes 的统一指挥下完成任务。

Viewpoints #

From #

13｜Job/CronJob：为什么不直接用Pod来处理业务？

Links #

Content #

infra容器维护着Pod内多容器共享的主机名、网络和存储。infra容器的镜像叫“pause”，只有不到500KB。

From #

Links #

Content #

科幻电影里Pod常用来称呼飞船的分享舱，Apple的播放器受Mac管控，从属于Mac，关系有点类似，所以就命名为"Pod"。

From #

Links #