网络策略（Network Policy），用于限制 Pod 出入流量，提供 Pod 级别和 Namespace 级别网络访问控制。

已知 flannel 目前并不支持网络策略，即使创建了也并不会应用，其它组件在使用网络策略时还请自行了解以下是否支持。

应用场景

• 应用程序（Pod）间的访问控制。例如微服务 A ，允许访问微服务 B ，微服务 C 不能访问微服务 A
• 开发环境命名空间不能访问测试环境命名空间 Pod
• 当 Pod 暴露到外部时，需要做 Pod 白名单
• 多租户网络环境隔离（使用项目较多）

RBAC（Role-Based Access Control，基于角色的访问控制），允许通过 Kubernetes API 动态配置策略。 概念理解角色（权限的集合） Role：授权特定命名空间的访问权限 ClusterRole：授权所有命名空间的访问权限（集群角色） 角色绑定 RoleBinding：将角色（Role）绑定到主体（即subject） ClusterRoleBindin...

相信大家在使用 kubeadm init 时，会发现在 /etc/kubernetes/pki 目录下生成一大堆证书文件；还有一些 k8s 插件在部署时，会创建 RBAC，这些都是为了 kubernetes 的安全而产生的。

• K8S 安全控制框架主要有 3 个阶段进行控制，每一个阶段都支持插件方式，通过 API Server 配置来启用插件。

1. Authentication(鉴权)：鉴定访问集群的身份
2. Authorization(授权)：在确认身份的基础上，给定符合身份的权限
3. Admission Control(准入控制)：安检

在前面的学习中，发现做的例子都是 Deployment ，且大部分使用 web 应用去做示例，为什么不用 mysql 类似数据库来做示例呢。

在 LNMP 架构中，应该了解过动静分离，也就是动态数据和静态数据，是以是否需要去访问数据库去进行读写数据来区分的。

Kubernetes 同样也区分了有状态应用和无状态应用，之前常用的 Deployment 就是为无状态应用而使用的。本文中提到的 StatefulSet 就是为有状态应用使用的。

创建 nfs 的 storageClass 请跳到 Kubernetes–StorageClass(二)，因为 本文中的 NFS 仓库中的项目有点 bug ，对于新版 k8s 无法解决。不信邪你可以试试

在之前的文章 Kubernetes的数据管理 一文中，介绍了一些 volume 以及 PV 、 PVC 的使用方法，也被称为 静态 PV 供给，因为 PVC 是建立在 PV 的前提下，必须手动创建 PV ，再去创建 PVC 去匹配 PV 获取存储资源。

以上说到的方法中，对于大量 pod 的场景来说，维护成本相当大，对于运维人员也是不友好的。所以 k8s 支持了 PV 的动态供给 — StroageClass。也就是使用了 StorageClass 之后，不需要单独创建 PV，只需要创建 PVC ，就会根据 PVC 的申请自动创建一个 PV，也被称为 动态 PV 供给

据我当下所学，对于 Kubernetes 如何对外暴露服务，一个字—**service**，只要是集群内部要访问 pod，通过创建 service，可以做到使用ip访问，那如果想要对互联网提供服务，应该怎么去做，也不能一直使用 IP 访问，而且对于集群来说也是不安全的。本文提到的 Ingress 就是为了弥补 NodePort 存在的不足而生。

我们都知道 k8s 集群中 master 节点默认是存在不可调度的污点的，也就是普通的 pod 默认是不会被调度到 master 节点的，这也是 Taint(污点) 的作用。

在实际应用中，也可能会给 worker 节点也去添加污点，是为了达到避免 Pod 调度到特定的节点中。

本文将会介绍关于节点 Taint 的设置以及如何调度要具有 Taint 的节点

在之前的文章 labels控制pod运行位置 提到可以通过 nodeSelector来控制将pod运行到哪台集群节点。

本文中要使用的 nodeAffinity (节点亲和性)，其功能与 nodeSelector是类似的，也是根据节点标签来对 pod 进行调度启动

相比 nodeSelector ，nodeAffinity 更加的灵活，功能多，支持硬策略和软策略

之前的文章 Kubernetes 的 Health Check 一文中提到的健康检查的方式有三种，仅仅只用了 exec 一种方式来演示。

本文将使用一个 yaml 文件，展示 httpGet 和 tcpSocket 两种方式怎么使用，两者区别就是修改健康检查部分就可以

直接上示例

在之前的文章 Depolyment中提到的伸缩 ，是通过 Deployment 管理的 ReplicaSet 来手动控制 pod 的伸缩，而在刚接触 Kubernetes 时，就一直听到或者看到各种视频文章教程，都说K8S可以通过对资源利用率的判断，进行 pod 的自动伸缩。本文中，它来了。

当Kubernetes 1.20开始准备弃用Docker，相信很多人在k8s 1.20版本出现的时候，都听说了即将弃用docker，不过还没有完全弃用，但这也是未来的趋势了。k8s的底层还是容器。

具体使用docker和弃用docker的前因后果我就不多说了，本文只是为了使用docker以外的CRI（Container Runtime Interface）来部署Kubernetes。这里就进行单机部署了。

建议使用CentOS 7.5版本以上，这里以7.6为例，配置好网络，可以访问外网

当弃用docker后，可以直接使用containerd来做CRI

在初学Kubernetes的yaml文件时，很苦恼，到底怎么就找到哪个kind对应哪个apiVersion，曾在本站写过一篇Kubernetes的yaml文件使用语法及简单操作，然而仅仅打算靠着自己慢慢积累将apiVersion对应的kind一一记录下来，甚至也问过很多大佬，怎么才能知道，大佬告诉我用的多了就知道了。这样的回答也是很无奈。可能大佬也还没想过这种问题。

郑重其事：时区一定要调整，服务器或者虚拟机时区与浏览器时区不一致，会导致最后监控没有数据

当Kubernetes集群的master节点init完成后，会输出join命令，以便用户用来将其他节点加入，如下

kubeadm join 192.168.1.11:6443 --token abcdef.0123456789abcdef \
    --discovery-token-ca-cert-hash sha256:063cf8ade66033addf58f5d1a453aab0b1ec5ff023327bc10156935875baa7ad 

kubernetes官网

安装环境

ip	Docker Version	Kubernetes Version	硬件要求
192.168.1.11（master1）	19.03.8	v1.18.1	内存4G，双核CPU
192.168.1.12（master2）	19.03.8	v1.18.1	内存4G，双核CPU
192.168.1.13（master3）	19.03.8	v1.18.1	内存4G，双核CPU
192.168.1.100（VIP）