通过上节内容，学习了Kubernetes自己就是一个大型的分布式系统，Kubernetes集群的包含众多组件。集群中的服务器节点分为control-plane节点和node节点. control-plane节点上需要部署kube-apiserver、kube-controller-manager、kube-scheduler组件。 node节点上需要部署kubelet、kube-proxy组件，另外还需要在node节点上部署实现了CRI的容器运行时(如: Containerd, CRI-O)。 还需要部署一套etcd集群作为k8s集群的存储数据库，kube-apiserver使用etcd存储整个集群的状态。 最后还需要在k8s集群中部署一些扩展组件(Addons)包含: 网络和网络策略插件(如Calico)、服务发现插件(如CoreDNS)、可视化管理插件(如Kubernetes Dashboard)，才能让整个k8s集群的功能对外可用。
上节学习了k8s是什么以及k8s的核心特性。 k8s是一个用于自动部署，扩展和管理容器化应用程序的开源系统，它的核心功能包括: 自动化上线和回滚、服务发现与负载均衡、存储编排、Secret和配置管理、自动装箱、批量执行、IPv4/IPv6 双协议栈、水平扩缩容、自我修复、为扩展性设计。本节将介绍Kubernetes集群的组成及核心组件。
Kubernetes的定义 引用Kubernetes官方网站上的定义: Kubernetes是一个用于自动部署，扩展和管理容器化应用程序的开源系统。Kubernetes将多个容器组成一个逻辑单元以便于管理和服务发现。 Kubernetes源自Google内部十五年的生产环境运维经验，同时凝聚了社区的最佳创意和实践。
前面一节初步学习了istio安全管理功能中的认证策略，并使用认证策略配置了服务之间的双向TLS，使用认证策略对暴露到集群外部的http服务开启了基于JWT的终端用户认证。本节将对上节配置JWT终端用户认证时用到一些JWT相关知识做一个补充学习。
Prometheus是一个基于时序数据库的开源监控系统。 Prometheus在2016年加入了CNCF(云原生计算基金会)，成为继Kubernetes之后CNCF的第二个托管项目。 Prometheus HTTP API Prometheus的监控指标数据metrics存储在其内置的时序数据库中，即其本身也是一个时序数据库，但目前Prometheus还没有提供直接管理数据的功能，默认情况下只能通过Promtheus的HTTP API查看数据。文档https://prometheus.io/docs/prometheus/latest/querying/api/中是对Prometheus查询API的介绍。其实Prometheus的WebUI使用的就是它的HTTP API，因此在运维开发中如果需要使用Prometheus的HTTP API的话，可以先在Prometheus的WebUI中写好PromQL执行查询，然后借助浏览器的开发者工具查看具体的HTTP API的写法。
前面在第9节"Containerd是如何存储容器镜像和数据的"中介绍了，containerd的snapshotter的主要作用就是通过mount各个层为容器准备rootfs。containerd默认配置的snapshotter是overlayfs，overlayfs是联合文件系统的一种实现。 overlayfs将只读的镜像层成为lowerdir，将读写的容器层成为upperdir，最后联合挂载呈现出mergedir。
前面3~12节学习了istio的流量管理功能，包括如何配置请求路由、故障注入、流量转移、流量镜像、设置请求超时和熔断、将服务网格外部流量接入到集群内、控制服务网格的出口流量等。 从本节开始学习istio的安全管理功能，看istio是如何保护服务网格内的微服务的。本节将根据istio官方文档https://istio.io/latest/zh/docs/tasks/security/authentication/authn-policy/中的内容，学习使用istio的认证策略来设置双向TLS和基本的终端用户认证。
linux memory cgroup子系统 限制容器的内存使用需要借助memory cgroup子系统。 在使用cgroups时需要先挂载，例如在centos下memory cgroup子系统被挂载到了/sys/fs/cgroup/memory下，，在这个目录下是各个memory控制组目录，每个控制组目录下还可以有子目录，各个控制组形成了一个树状的层级关系。
上一节学习了istio服务网格内部访问外部服务的三种方法，推荐使用ServiceEntry将一个外部服务注册到服务网格中的方式，这样服务网格内部的到外部服务的访问流量都是受到istio管理的，但这种方法下访问外部服务的流量都是从内部服务实例所在节点的sidecar代理发出的，这在某些场景下会有一些限制。 例如，一个对安全有严格要求的组织，要求服务网格所有的出站流量必须经过一组专用节点。专用节点运行在专门的机器上，与集群中运行应用程序的其他节点隔离，这些专用节点将专门实施针对出站流量的策略，并且受到比其余节点更严密地监控。另外一个场景是在集群中不是所有节点都可以访问公网(或某个外部IP的)，如集群中只有一个节点可以访问公网，所以服务网格内其他节点上的服务实例也就无法访问公网上的外部服务了。在这两个场景中都是因为服务网格内的一部分节点在网络上无法访问外部服务，因此需要有一个在网络上可以访问外部服务的节点作为egress gateway节点，用来引导所有的出站流量，这样也能实现该节点以受控的方式访问外部服务。
容器的单进程模型 容器的单进程模型是指推荐在一个容器里只运行一个进程。 容器的单进程模型并不是说容器里只能运行一个进程，而是因为容器本身没有管理多个进程的能力，推荐在一个容器里只运行一个进程。 在正常的Linux操作系统里都有个1号进程init，例如CentOS的systemd，所有的其他进程都是1号进程的子进程或者是子进程的子进程。 1号进程具有进程管理能力，例如对僵尸进程的管理。而容器中的1号进程就是容器运行的应用本身，它是没有进程管理能力的，所以推荐在容器中只运行一个进程。