Content #
Service 与它引用的 Pod 的关系，需要重点关注的是 selector、targetPort 与 Pod 的关联：
port 指定映射端口 target-port 指定容器端口
Service与Deployment的关联
November 23, 2023
Blog
November 23, 2023
sub:Service(Kubernetes)
November 23, 2023
Content #
这里 Service 使用了 iptables 技术，每个节点上的 kube-proxy 组件自动维护 iptables 规则，客户不再关心 Pod 的具体地址，只要访问 Service 的固定 IP 地址，Service 就会根据 iptables 规则转发请求给它管理的多个 Pod，是典型的负载均衡架构。
不过 Service 并不是只能使用 iptables 来实现负载均衡，它还有另外两种实现技术：性能更差的 userspace 和性能更好的 ipvs。
Service与Deployment的关联 生成Service yaml(kubectl expose)
Service 对象的域名完全形式是“对象. 名字空间.svc.cluster.local”，但很多时候也可以省略后面的部分，直接写“对象. 名字空间”甚至“对象名”就足够了，默认会使用对象所在的名字空间（比如这里就是 default）。
Service 的默认类型是“ClusterIP”，只能在集群内部访问，如果改成“NodePort”，就会在节点上开启一个随机端口号，让外界也能够访问内部的服务。
Viewpoints #
From #
Links #
静态Pod
November 23, 2023
Content #
“静态 Pod”非常特殊，它不受 Kubernetes 系统的管控，不与 apiserver、 scheduler 发生关系，所以是“静态”的。
但既然它是 Pod，也必然会“跑”在容器运行时上，也会有 YAML 文件来描述它，而唯一能够管理它的 Kubernetes 组件也就只有在每个节点上运行的 kubelet 了。
“静态 Pod”的 YAML 文件默认都存放在节点的 /etc/kubernetes/manifests 目录下，它是 Kubernetes 的专用目录。
Kubernetes 的 4 个核心组件 apiserver、etcd、scheduler、 controller-manager 都以静态 Pod 的形式存在的，这也是为什么它们能够先于 Kubernetes 集群启动的原因。
如果你有一些 DaemonSet 无法满足的特殊的需求，可以考虑使用静态 Pod，编写一个 YAML 文件放到这个目录里，节点的 kubelet 会定期检查目录里的文件，发现变化就会调用容器运行时创建或者删除静态 Pod。
Viewpoints #
From #
Links #
让pod容忍污点(tolerations)
November 23, 2023
Content #
为 Pod 添加字段 tolerations，让它能够“容忍”某些“污点”，就可以在任意的节点上运行了。
tolerations 是一个数组，里面可以列出多个被“容忍”的“污点”，需要写清楚“污点”的名字、效果。比较特别是要用 operator 字段指定如何匹配“污点”，一般我们都使用 Exists，也就是说存在这个名字和效果的“污点”。
如果我们想让 DaemonSet 里的 Pod 能够在 Master 节点上运行，就要写出这样的一个 tolerations，容忍节点的 node-role.kubernetes.io/master:NoSchedule 这个污点：
tolerations:
- key: node-role.kubernetes.io/master
effect: NoSchedule
operator: Exists
Viewpoints #
From #
Links #
污点（taint）和容忍度（toleration）
November 23, 2023
Content #
“污点”是 Kubernetes 节点的一个属性，它的作用也是给节点“贴标签”，但为了不和已有的 labels 字段混淆，就改成了 taint。
和“污点”相对的，就是 Pod 的“容忍度”，顾名思义，就是 Pod 能否“容忍”污点。
集群里的节点各式各样，有的节点“纯洁无瑕”，没有“污点”；而有的节点因为某种原因粘上了“泥巴”，也就有了“污点”。Pod 也脾气各异，有的“洁癖”很严重，不能容忍“污点”，只能挑选“干净”的节点；而有的 Pod 则比较“大大咧咧”，要求不那么高，可以适当地容忍一些小“污点”。
“污点”和“容忍度”倒是有点像是一个“相亲”的过程。Pod 就是一个挑剔的“甲方”，而“乙方”就是集群里的各个节点，Pod 会根据自己对“污点”的“容忍程度”来选择合适的目标，比如要求“不抽烟不喝酒”，但可以“无车无房”，最终决定在哪个节点上“落户”。
Kubernetes 在创建集群的时候会自动给节点 Node 加上一些“污点”，方便 Pod 的调度和部署。你可以用 kubectl describe node 来查看 Master 和 Worker 的状态：
kubectl describe node master
Name: master
Roles: control-plane,master
...
Taints: node-role.kubernetes.io/master:NoSchedule
...
kubectl describe node worker
Name: worker
Roles: <none>
...
Taints: <none>
...
可以看到，Master 节点默认有一个 taint，名字是 node-role.kubernetes.io/master，它的效果是 NoSchedule，也就是说这个污点会拒绝 Pod 调度到本节点上运行，而 Worker 节点的 taint 字段则是空的。
...DaemonSet与Deployment的差异
November 23, 2023
Content #
DaemonSet 在 spec 里没有 replicas 字段，这是它与 Deployment 的一个关键不同点，意味着它不会在集群里创建多个 Pod 副本，而是要在每个节点上只创建出一个 Pod 实例。
DaemonSet 仅仅是在 Pod 的部署调度策略上和 Deployment 不同，其他的都是相同的，某种程度上我们也可以把 DaemonSet 看做是 Deployment 的一个特例。
可以用变通的方法来创建 DaemonSet 的 YAML 样板，只需要用 kubectl create 先创建出一个 Deployment 对象，然后把 kind 改成 DaemonSet，再删除 spec.replicas 就行了，比如：
export out="--dry-run=client -o yaml"
# change "kind" to DaemonSet
kubectl create deploy redis-ds --image=redis:5-alpine $out
Viewpoints #
From #
Links #
sub:DaemonSet
November 23, 2023
DaemonSet的由来
November 23, 2023
Content #
Deployment 并不关心 Pod 会在集群的哪些节点上运行，Pod 的运行环境与功能是无关的，只要 Pod 的数量足够，应用程序应该会正常工作。
这个假设对于大多数业务来说是没问题的，比如 Nginx、WordPress、MySQL，它们不需要知道集群、节点的细节信息，只要配置好环境变量和存储卷，在哪里“跑”都是一样的。
但是有一些业务比较特殊，它们不是完全独立于系统运行的，而是与主机存在“绑定”关系，必须要依附于节点才能产生价值，比如说：
-
网络应用（如 kube-proxy），必须每个节点都运行一个 Pod，否则节点就无法加入 Kubernetes 网络。
-
监控应用（如 Prometheus），必须每个节点都有一个 Pod 用来监控节点的状态，实时上报信息。
-
日志应用（如 Fluentd），必须在每个节点上运行一个 Pod，才能够搜集容器运行时产生的日志数据。
-
安全应用，同样的，每个节点都要有一个 Pod 来执行安全审计、入侵检查、漏洞扫描等工作。
这些业务如果用 Deployment 来部署就不太合适了，因为 Deployment 所管理的 Pod 数量是固定的，而且可能会在集群里“漂移”，但，实际的需求却是要在集群里的每个节点上都运行 Pod，也就是说 Pod 的数量与节点数量保持同步。
所以，Kubernetes 就定义了新的 API 对象 DaemonSet，它在形式上和 Deployment 类似，都是管理控制 Pod，但管理调度策略却不同。DaemonSet 的目标是在集群的每个节点上运行且仅运行一个 Pod，就好像是为节点配上一只“看门狗”，忠实地“守护”着节点，这就是 DaemonSet 名字的由来。
Viewpoints #
From #
Links #
book:园丁与木匠
November 22, 2023
Content #
引言 你是园丁，还是木匠 01 “教养”是一种糟糕的现代发明混乱是童年的主旋律年轻的大脑天生就要探索父母的爱让孩子的智力发展成为可能 02 童年，人类进化的关键策略养育孩子比狩猎技能更重要要考证，不要假设童年越漫长，智力越发达人类的学习能力在反馈循环中代代更迭多样性是面对未知的利器对孩子精雕细刻终归是徒劳 03 爱，持续进化的保障爱的三面手1：父母爱的三面手2：祖父母爱的三面手3：异亲对孩子的爱就像一个无法言喻的承诺因为照顾所以爱 04 边看边学孩子都是优秀的小演员镜像神经元的“神话”模仿是最有效的因果学习形式孩子的模仿能力高级又高效孩子拥有超越成人的创造力过度模仿，抓住“权威”的每一个细节仪式模仿，找到文化归属感和孩子一起做，而不是“照我说的做” 05 边听边学依恋模式决定孩子更相信谁你的孩子为什么不信你的话孩子知道虚构和假想不是现实永无止境的为什么，是在寻求好的解释“为什么”的最佳答案是揭示因果关系你的解释影响孩子的思维方式孩子对你的信任胜过一切方法 06 边玩边学打闹是一种社交演练聪明的动物对一切都感兴趣玩玩具就是在做科学实验假装是人类独有的玩耍方式反事实思维，想象力与创造力之源爱假装的孩子善于弄清别人怎么想玩耍教会我们如何应对意外“玩”就很好玩，不需要理由 07 边练边学学徒训练是历史主流教育方式目标导向的学校教育是一种新发明从探索式学习到掌握式学习学校就像专注力竞技场学校教育应该服务于不同类型的孩子重要的学习发生在教室之外青春期：游走在冲动与控制之间 08 科技与孩子的未来“阅读”是门新技术步入电子屏幕的世界科技之于孩子，就像阅读之于我们让时代的棘轮徐徐向前网络世界的希望与迷失给孩子一个世界，让他们重建尾声 养育孩子的意义后记 为人父母是在一系列矛盾中寻找平衡的艺术
From #
Links #
几个奖励的方法
November 22, 2023