Kubernetes

我们在前面介绍svc的的时候，可以通过ping svc的而获取到svc的ClusterIP。而我们在linux进阶里面讲过从域名变成ip是dns的功能，在k8s里面实现这个dns的功能是CoreDNS

我们前面2个小节介绍了svc的几种类型，但是并没有介绍这个流量是如何从svc走到pod去的，下面我将以iptables的方式介绍流量是如何通过svc方式走到pod里面的。

我们上一小节介绍了如何创建一个svc以及svc如何通过标签绑定到工作负载上。并且也介绍了svc有几种类型，默认不做任何标识的情况下，就是ClusterIP，下面我们讲介绍其他几种服务形式。

k8s就给我们抽象一个资源叫做服务Service，简称svc，我们通过访问svc，然后来实现负载均衡访问多个后端，并且还能随着pod的增加或者减少自动调整后端rs。

在Docker里面是是可以通过cgroup来限制容器的资源占用，并且是通过docker run 然后添加限制参数来实现的，但是k8s并没有直接这样的参数，它又是通过什么方式来限制呢？

虽然我们上一小节，介绍了健康检查的几种用法，今天我们将通过一个实际的案例来讲解。这样可以更好的理解这个健康检查的机制。

在 Kubernetes 中，健康检查（Health Checks）主要通过两种机制来实现：Liveness Probes 和 Readiness Probes。

我们在上一章docker-harbor部署指南的时候，介绍了如果是使用harbor，则仓库是默认带密码的。哪kubernetes 怎么解决这个问题呢？

Service的存在确保即使后端Pods发生变化，前端客户端也无需知道这些变化，可以继续通过Service访问应用，因为svc会自动调整对后端的访问，实现自动屏蔽pod和增加扩容pod。

我们上一小节，介绍了3种方式创建cm，这里用了单独一节创建资源，实际上前面2种是所有资源都通用的方法，最后也那种只适合少量的资源。 下面我们将介绍如何来使用创建的configmap。

我们前面介绍几个工作负载(workloads)，都是以不同形式运行pod，后面几个小节，我们将讲讲其他资源，今天要讲解的资源名字是ConfigMap，简称cm。

StatefulSet 是 Kubernetes 中专门用于管理有状态应用的工作负载 API 对象。

上一小节我们讲解的Deployment，虽然是整个k8s集群最常用的资源，并且默认的情况下他只会在node节点出现，但是我们有些业务是一个类似agent的操作，需要在每个节点都需要，并且只能有一个。

我们上一小节介绍了k8s的第一个控制器ReplicaSets，也同时说明了，我们一般不会单独使用，而是使用更高级的Deployment(也可以简称deploy)。

我们前面介绍pod的时候通过yaml文件创建了pod，这个pod大概就等于使用docker run 创建的容器。如果我们想对这个容器做更高级的操作(增加pod的数量，更换镜像等)则必须要借助其他控制器

我们在上小节介绍了master上的4个核心组件，这4个核心组件都是以静态pod方式存在的。也只有这几个是以静态的pod，其他的组件则是以其他方式运行的

我们在上一小节介绍静态pod，而在k8s的第一节我们就介绍了master的哪些组件，下图就是标准k8s下的4个静态pod文件的yaml文件。

我们上一小节介绍了普通pod的时候有已经有提过管理节点也几个组件kube-apiserver/kube-controller-manager/kube-scheduler等也会默认有2个容器。

在早期的Kubernetes介绍pod会直接引用pod的英文翻译豆荚来介绍什么是Pod，还是很贴切的，整个豆荚包括豆荚壳+豆子，其中豆荚壳可以理解为pause容器，每个豆荚都必须有一个。

上一小节我们安装了docker版本的k8s版本是1.23.12，但是目前的k8s版本截止2024年12月，已经发布到 1.32.0，但是阿里云旧版本的源只更新到1.28所以我这里还是1.28。