Ingress 编写一个简单的 Ingress 编排文件 apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: my-ingress annotations: kubernetes.io/ingress.clas

DNS 通常集群内部访问的是 Service 的域名serviceName.default.svc.cluster.local，域名访问的作用时解决 Pod IP 不固定的问题，Kubernetes 提供 CoreDNS 解决这个问题。 查看 CoreDNS 服务 [root@kube01 dns]

Service Service 资源 # service.yaml apiVersion: v1 kind: Service metadata: name: nginx-test-01 spec: selector: apps: test-nginx ports: - pro

前面我们已经学习一些常用的资源对象的使用，我们知道对于资源对象的操作都是通过 APIServer 进行的，那么集群是怎样知道我们的请求就是合法的请求呢？这个就需要了解 Kubernetes 中另外一个非常重要的知识点了：RBAC（基于角色的权限控制）。 API 对象 在学习 RBAC 之前，我们还需

Secret 前文我们学习 ConfigMap 的时候，我们说 ConfigMap 这个资源对象是 Kubernetes 当中非常重要的一个资源对象，一般情况下 ConfigMap 是用来存储一些非安全的配置信息，如果涉及到一些安全相关的数据的话用 ConfigMap 就非常不妥了，因为 Confi

ConfigMap ConfigMap 就是配置管理，应用经常会有从配置文件、命令行参数或者环境变量中读取一些配置信息的需求，这些配置信息我们肯定不会直接写死到应用程序中去的。ConfigMap 就给我们提供了向容器中注入配置信息的能力，不仅可以用来保存单个属性，还可以用来保存整个配置文件，比如我们

HPA （动态扩缩容） kubectl 有一个 scale 命令 kubectl scale deployment/nginx --replicas=4 它可以帮助 Pod 进行扩缩容，这个过程完全手动的，但是实际使用过程中，要应对线上的各种复杂情况，我们需要能够做到自动化去感知业务，来自动进行扩缩

Job 控制器 # job-demo.yaml apiVersion: batch/v1 kind: Job metadata: name: job-demo spec: template: spec: restartPolicy: Never # 只支持 Never

DaemonSet 用于在每个节点部署一个 Pod，随着集群节点新增而自动新增 Pod，随着集群节点删除而删除 Pod，通常情况下 Master 节点没有，因为 Master 节点通常存在污点，在没有特殊设置的情况下不会运行 那么在哪种情况下我们会需要用到这种业务场景呢？其实这种场景还是比较普通的，

在实际使用的过程中，Deployment并不能编排所有类型的应用，它适用于编排无状态服务的 Pod，StatefulSet适用于编排有状态服务的 Pod。 无状态服务（Stateless Service）：该服务运行的实例不会在本地存储需要持久化的数据，并且多个实例对于同一个请求响应的结果是完全一致