K8S整体是一个集群，分为Master Node 和 Worker Node。 每一个的节点（node）可以跑多个的Pod。 一个Pod里面可以有多个的Container。 但是正常情况下我们一个Pod只会跑一个Container (Istio Sidecar 一个pod就会跑两个container)
在Kubernetes中，最小的管理元素不是一个个独立的容器，而是Pod,Pod是最小的，管理，创建，计划的最小单元.
我们通过创建各种各样的Pod Controller来管理Pod
最常用是 Deployment，它会先创建 ReplicaSet 再创建 Pod.
是用来管理有状态的应用，比如说数据库 集群。 Olreans的 Silo Host. (它会保存网络名称的唯一性)， Silo Host 我们可以建立非常多个。 如果用普通的Deployment的话。（当它的一个Pod挂掉，并且又重新启动起来的话它的网络名称就会变了。这样就会造成 Olreans管理的异常。） （一个普通的应用通常不会用到这个。） PVC 也会自动管理好 （每一个实例都会自己的 PV。）
每一个节点都有一个应用。 日志收集守护程序，如fluentd或logstash，在每个节点上运行以收集容器的日志; 集群存储守护程序，如glusterd、ceph要部署在每个节点上以提供持久性存储； 节点监视守护进程，如Prometheus监控集群，可以在每个节点上运行一个node-exporter进程来收集监控节点的信息。
用来定期执行某类应用的。 比如说我们的报表生成，定期同步数据。
是用来抽象Pod提供服务的。所有访问Serivce的流量会自动负载均衡到Pod中。也负责将把我们的服务暴露给集群外。
用来区分各种资源的东西 pod、services、configmap, replication controllers、等 都在namespace下面。 比如我们的线上环境 也可以分成两个 Namespace Staging 和 Live。（要是把测试环境也放在一起的）
Asp.net core 通常来说它的配置方案用的是IConfirguration的方案。 支持从 appsettings.json 和 环境变量当中读取配置值。 Kubernetes当中我们通常也是用环境变量。 但是我们可能有多个的应用共享这些配置。 这个时候我们可以创建一个Configmap. 有的程序是从配置文件当中来读取。 我们也可以把文件存在这边。然后通过挂载的方式扔进去。
我们也通过 Ingress Controller 来实现 Ingress里面的配置。 最常用的有 Nginx ingress traefik (K3s 默认的)。 为什么有了Service还需要这个。 （一个是为了分层，这样我们可以比较方便得管理证书。还有流量重写，做其它的事情。）另一个是就是省点IP资源。 它的流量还是先进到 ingress service 然后到 ingress controller 接下来到我们的 sevice 到 pod
pod 水平自动伸缩。当Pod占用的Cpu百分比达到一定程度的时候自动去调整的pod的数量。 （如果用的是云平台的 比如Azure的话。 当pod数量增加而 node节点不过的时候 node节点也会自动增加， Pod节点降下来后， Node节点也会动变少）
用来监控这个Pod是可以提供服务， 是否还是健康状态。 starupProbe 启动慢 可以用这个来判断是否启动成功 liveness 是用来控测这个pod是不是还是健康状态。 如果不健康并且达到一定的阀值的话，则会被K8s自动杀掉。 readiness 是否就绪。就绪的话 service就会把流量扔过来了
我们知道当Pod被删除，哪么里面的文件也会自动没掉。不象docker可以挂载在宿主机。 K8s环境下，Node节点也是会变的。 一个Pod可能会运行在Node1 过一阵子可能会运行在Node2。
在云平台，我们通常只要配置 PVC就行了。 它会自动去创建 PV 一般是云硬盘，或者 NFS （各个平台包装后会叫其它的名字 比如 azure file） 云硬盘只能挂载在一个Node上面。 这样如果一个Pod运行在两个Node上。（就有问题了启动不了。只能选择 NFS 类型）