而Service的地址是一个虚拟IP地址◆■，没有任何网络接口配置在此地址上◆◆，它由kube-proxy借助iptable规则或ipvs规则重定向到本地端口 ，再将其调度到后端的Pod对象。Service的IP地址是集群提供服务的接口，也称为Cluster IP★◆◆■■。

　　Ingress是一种kubernetes资源类型★■，它允许kubernetes 集群中暴露HTTP和HTTPS服务★◆◆◆。通过Ingress◆◆■◆■，你可以将流量路由到不同的服务和端口点★■★◆■，而无需使用不同的负载均衡器。Ingress通常使用Ingress Contrller实现■◆◆◆◆◆，它是一个运行在kubernetes 集群中的负载均衡器，它根据Ingress规则下面是一个将所有流量都发送到同一Service的简单Ingress示例：

　　k8s是一个基于容器技术的分布式集群管理系统。既然是个分布式系统■◆■■■■，那势必有多个Node节点(物理主机或虚拟机)，它们组成一个分布式集群◆■，并且这些节点中会有一个Master节点◆◆★◆，由它来统一管理Node节点★◆■。

　　卷的核心就是一个目录，其中可能存有数据◆★◆★，Pod中的容器可以访问该目录中的数据★★◆■◆。所采用的不同卷类型将决定该目录如何形成的、使用何种介质保存数据以及目录中存放的东西。常见有confingMap◆◆■★■★、emptyDir、local、nfs、secret等。

　　在k8s中采用etcd组件作为高可用强一致性的储存仓库，该组件可以内置在k8s中，也可以外部搭建拱k8s使用。

　　Service是一个抽象层，它定义了一组Pod的逻辑集，并为这些Pod支持外部流量暴露、负载均衡和服务发现。

　　尽管每个Pod都有一个唯一的IP地址，但是如果没有Service，这些IP不会暴露在集群外部。Service允许您的应用程序接收流量。Service也可以用在ServiceSpect标记type的方式暴露，type类型如下■★◆★■：

　　Deployment负责创建和更新应用程序的实例，使Pod拥有多副本◆■■★■，自愈★◆★★◆◆，扩容等能力。创建Deployment后，kubernetes master将应用程序实列调整到集群中的各个节点上。如果托管实列的节点关闭或被删除，Deployment控制器会将该实例替换为集群中另一个节点上的实例，这提供了一种自我修复机制来解决机器故障维护问腿。

　　是kubernetes中抽象的应用程序服务■◆◆■■■，它公开了一个单一的IP地址和端口，可以用于在kubernetes集群内部的Pod之间进行流量路由。

　　Volume指的是存储卷■★■■，包含可被Pod中容器访问的数据目录■★◆■。容器中的文件在磁盘上是临时存放的★★，当容器崩溃时文件会丢失，同事无法在多个Pod享文件◆◆■，通过使用存储卷可以解决这问题■★■■■★。

　　kubernetes包含这个命名空间，以便你无需创建新的命名空间即可开始使用新集群

　　关于Pod内是如何做到网络共享的■★◆，每个Pod启动，内部都会启动一个pause容器(google的一个镜像)■★◆■◆，它是使用默认的网络模式■◆◆◆★，而其他容器的网络都设置给它，以此来完成网络的共享问题◆★◆★◆◆。

　　k8s是属于Master-Worker架构■★◆，即有Master节点负责核心的调度、管理和运维，Worker节点规则执行用户的程序。但是在看k8s中，主节点一般称为Master Node，而从节点则被称为Worker Node或者Node。

　　外部用户可以通过REST接口,或者kubectl命令行进行集群管理，其内在都是与apiserver进行通信。

　　Ingress和Service都是kubernetes中用于将流量路由到应用的机制■★，但他们是在路由层面上有所不同：

　　在k8s中，Pod是基本的操作单元，它与docker的容器略微有不同，因为Pod可能包含一个或多个容器(可以是docker容器)，这些内部的容器是共享网络资源的■★◆，即可通过locahost进行互相访问■■◆■★。

　　该命名空间包含用于各个节点关联的**Lease(租约)**对象★◆。节点租约允许kubelet发送心跳，由此控制能够检测到节点故障■■◆。

　　EmptyDir◆★：是一个空目录■◆★■◆★，可以在Pod用来存储临时数据，当Pod删除时★◆■，该目录也会删除◆★★。

　　Pod是可以运行在kubernetes中创建和管理的、最小的可部署的计算单元。Pod是一组(一个或多个)容器★■；这些容器共享存储★★★◆★◆、网络、以及怎样运行这些 容器的生命★★。

　　既然知道了服务是由Pod组成的，那么服务的扩容也就意味着Pod的扩容。通俗点讲■■★◆★■，就是在需要时将Pod复制多份◆■，在不需要后■■■◆，将Pod缩减指定的份数。k8s中通过Replication Controller来进行管理★★◆■，为每个Pod设置一个期望的副本数◆■◆，当实际副本数与期望不符时，就动态的进行数量调整，以达到期望数值。期望数值可以由我们手动更新，或自动扩容代理来完成。

　　ConfingMap：可以将配置文件以键值对的形式保存到ConfigMap中◆■，并且可以在Pod中以文件或环境变量的形式使用。ConfigMap可以用来存储不敏感的配置信息，如应用程序的配置文件。

　　从上面的Pod调度角度看，我们的有一个存储中心■◆★■◆，用来储存各节点资源使用情况■◆、健康状态◆■、以及各Pod的基本信息等★■■，这样Pod的调度来能正常进行★◆■★■◆。

　　NFS◆■◆：将网络上的一个或多个NFS共享目录挂载到Pod中的Volume中，可以用来在多个Pod之间共享数据。

　　Local：将本地文件系统的目录或文件映射到Pod中的一个Volume中，可以用来在Pod享文件或数据。

　　**节点网络：**各主机(Master★★◆◆、Node◆■■■、ETCD等)自身所属的网络，地址配置在主机的网络接口，用于各主机之间的通信★◆★★◆◆，又称为节点网络。

　　k8s为Pod和Service资源对象分别使用了各自的专有网络，Pod网络由K8s的网络插件配置实现，而Service网络则由K8s集群进行指定★■。如下图★★：

　　Pod网络和IK8s的网络插件负责和管理，具体使用的网络地址可以再管理网络插件时进行指定■★■，如192.168■◆■.0.0/16网络。而Cluster网络和IP是由负责配置和管理，如192◆◆■★.96■◆★.0.0/12网络。

　　集群上的所有配置信息都储存在了etcd,为了考虑各个组件的相对独立，以及整体的维护性，对于这些存储数据的增、删、改★■★★■、查◆■◆■■，统一由kube-apiserver来进行调度■■★◆，apiserver也提供了RESET的支持，不仅对各个内部组件提供服务外，还对集群外部用户暴露服务◆★■■■。

　　Secret■★◆◆★◆：将敏感信息以密文的形式保存到Secret中，并且可以在Pod中以文件或环境变量的形式使用◆■◆★■◆。Secret可以用来存储敏感信息，如用户的密码■◆★◆■★、证书等。

　　这里■◆★，k8s引入了Service的概念，将多个相同的Pod包装成一个完整的service对外提供服务◆■★★◆，至于获取到这些相同的Pod■■★■，每个Pod启动时都会设置labels属性，在Service中我们通过选择器Selector◆★◆★,选择具有相同Controller来完成。同时，每个节点上会启动一个kube-porxy进程，由它来负责服务地址到Pod地址的代理以及负载均衡等工作。

　　所有的客户端(包括未经身份验证的客户端)都可以读取该命名空间。该命名空间主要预留未集群使用◆★◆◆，以便某些资源需要在整个集群中可见可读。该命名空间的公属性是一种约定而非要求◆★★★◆◆。

　　在Node节点上，使用k8s中的kubelet组件，在每个Node节点上都会运行一个kubelet进程◆★■■，它负责向Master汇报自身节点的运行情况，如Node节点的注册、终止◆◆、定时上报健康状况等◆★■◆，以及接收Master发出的命令■◆★◆，创建相应Pod。

　　k8s使用的网路插件需要为每个Pod配置至少一个特定的地址■◆◆，即Pod IP◆◆■。Pod IP地址实际存在于某个网卡(可以是虚拟机设备)上。

　　提供一种机制同一集群中的资源划分为相互隔离的组◆★◆■■★，同一命名空间内的资源名称要唯一，命名空间是用来隔离资源的，不隔离网路★◆★★◆。

　　使用卷时◆■■，在**.spec.volumes字段中设置为Pod提供的卷，并在

　　该工作由kube-scheduler来完成的■■◆★◆★，整个调度过程通过执行一些列复杂的算法最终为每个Pod计算出一个最佳的目标Pod调度到一个指定的Node上，我们可以通过节点的标签(Label)和Pod的nodeSelcetor属性的相互匹配，来达到指定的效果。

　　是一个kubernetes资源对象，它提供了对集群外部路由的规则。Ingress通过一个公共IP地址和端口将流量路由到一个或多个Service。

　　首先■■，Master节点启动时，会运行一个kube-apiserver进程，它提供了集群管理的API接口，是集群内各个功能模块之间数据交互和通信的中心枢纽，并且它也提供了完备的集群安全机制。

　　kubernetes 支持很多类型的卷。Pod可以同时使用任意数目的卷类型。临时卷类型的生命周期与Pod相同，但持久卷可以比Pod的存活期长。当Pod不再存在时★◆◆，kubernetes 也会销毁临时卷；不过kubernetes 不会销毁永久卷。对于给定的Pod中任何类型的卷★◆■，在容器重启期间数据都不会丢失◆◆。

　　那么，k8s的外部访问是否也是实现的？答案是否定的，k8s中情况要复杂些。因为docker是单机模式下的■■，而且一个容器对外就暴露一个服务。分布式集群下。一个服务往往由多个Application提供■◆■■★◆，用来分担访问压力◆■★，而且这些Application可能分布在多个节点上★■★■，这样又涉及了跨主机的通信★■◆◆。

　　前面讲了外部用户如何管理k8s，而我们更关心的是内部运行的Pod如何对外访问◆◆。使用过Docker的人都应当了解，如果使用bridge模式，在容器创建时◆◆■■，都会分配一个虚拟IP,该IP外部是没法访问到的★■，就可以访问到内部容器端口了。

　　**Pod网络 ：**专用于Pod资源对象的网络，它是一个虚拟网络，用于为各个Pod对象设定IP地址等网络参数，其地址配置在Pod种容器的接口上■■◆◆■。Pod网络需要借助kubenet插件或CNI插件实现。

　　相关链接：【【K8S极简教程】4小时快速学会Kubernetes(k8s)■◆◆，史上用时最短■◆◆★★■，效率最高◆★★！】…

　　：专用于Service资源对象的网络，它也是一个虚拟网络◆■◆★■，用于k8s集群之中的Service配置IP地址，但是该地址不会配置在任何主机或容器的网络接口上★★■★■，而是通过Node上的kube-proxy配置为iptable或ipvs规则，从而将发往该地址的所有流量调度到后端的各Pod对象之上。