xiong

调度器在k8s集群中，能运行pod资源的只有工作节点，master 主要是做为控制平面组件 (api-server, contarner-manage, 调度器)， 也依赖于etcd(最好能有冗余能力)节点创建流程当用户发起请求向Api Server 要求创建一个新的Pod资源对象时， Api Server先检查权限、授权、准入控制皆无问题，然后将请求交给scheduler(调度器), 然后从集群中的work节点中匹配一个此Pod资源的运行节点， 调度器的选择结果并不会直接产生对应的Pod资源，而

Network Policy官方文档， 理论来源        当我们部署Pod时，不同名称空间下的Pod可以同名，比如名称空间A下的xiong-nginx与名称空间B下的xiong-nginx，它们受k8s集群上同一个Pod plugin管理，它们只是名称空间隔离名称，而不隔离通信，这就意味着这种跨组织的通信安全或通信隔离将无从保障，而为了实现通信隔离，k8s引入了一个标准资源来允许用户获取一个名称空间之后，在自己所在名称

容器网络通信理论来源docker网络说明bridge： 桥接网络， 自由使用网络名称空间，其宿主机接口也就是docker0桥，每一个容器也会有自己的虚拟网卡，来实现容器内部的虚拟网络通信joined： 联盟式网络， 共享使用另外容器的IPCopened： 开放式网络，容器直接共享使用虚拟机的IPCnone：　无网络， 不使用任何网络名称空间如果跨节点之间的容器通信时，必须要使用NAT，任何容器在出去之前都是私有的地址，离开本地时必须要做SIP转换，取到物理机地址出去，每个容器要

Pod资源需求及资源限制如：CPU资源属于可压缩资源，一个Pod获取资源不到时会长期等待CPU资源，而Pod获取不到内存时，会报错因为内存属于非可压缩资源requests: Pod资源需求，最低保障，作用： 确保调度时对应节点应该满足于这个Pod运行时的基本需求limits： Pod限制，最高或最低区域，硬限制，作用： 限制运行的Pod运行时资源的天花板一般来讲 requests 一般小于 limits，资源需求与资源限定需要同时使用指标说明CPU：在资源中是指一颗逻辑(虚

资源请求属性        Kubernetes是基于http或https协议工作的(restful风格)，因此其对应的操作请求，无非就是增删改查（get、put、delete），因此在每一个Kubernetes的相关请求当中，通常这个请求会包含类似以下的信息； 理论来源user： 用户名称；group： 用户所属的组；extra： 额外属性；Resource： 指定使用哪个Kind资源；Subresource：

回顾​ 有状态有存储的就需要使用到sts控制器，比如一些常见的扩缩容问题，在K8s之上如果想要定义StatefulSet不建议直接使用StatefulSet，需要使用CordOS提供的第三方解决方案进行配置，配置方式：底层存储-->pv --> 无头service ，只有基于这个无头服务才能给每个pod分配一个唯一的持久的固定标识符 sts -- pod volumeClaimTemplates 让sts自动创建

理论来源:https://blog.doorta.com/?p=57回顾       在k8s集群中运行最基础的单元是Pod，其它资源都是围绕着Pod应用而实现，如Service用于给Pod提供一个固定端点，并且为动态Pod变动提供一个服务发现机构功能，运行在k8s之上服务指的就是Service，服务注册、服务发现都是借助于Service在k8s中运行的DNS服务来实现；     &

配置管理两种特殊类型存储卷，其多数情况下目的不是给pod提供存储空间来用的，而是给管理员或用户提供了从 集群外部向 pod内部的应用注入配置信息的方式， 理论来源配置容器应用方法自定义命令行两种参数： command, args:['xx','xx']事先将配置文件直接写死镜像环境变量: 应用程序应当支持环境变量，entrypoint(预处理脚本) 方式提供如果程序镜像是云原生，或是entrypoint脚本通过传递环境变量接受参数完成配置，这是一种轻量化的配置方式，在容器启动时传递N

pvc|pv正常创建pv时的逻辑，需要定义如下，用户\开发使用pvc，集群管理员创建pv，存储人员负责维护存储​ 在pod中直接定义一个存储卷， 定义的时候只需要说明用多大的存储卷， 这个存储卷叫PVC类型的存储卷， 而该这个PVC类型的存储卷必须与当前名称空间中PVC建立直接绑定关系，而PVC又必须与PV建立绑定关系，PV应该是某个真正存储设备上的存储空间；​ PVC与PC只是k8s之上的一种抽象资源，这两种资源与创建ingress或server并没有本质区别，底层存储给它切成

存储卷理论docker存储卷​ 在以往的docker应用中，容器如果跨多节点运行，容器本身也拥有一个文件系统，通常而言，将容器从A节点迁至B节点，容器就需要关闭或删除已有镜像，并且会在被迁移的节点上重新建立一个容器，而此次容器的所有数据都会被遗留在原有节点上；​ 因为docker容器运行的方式依赖于其底层的镜像构建方式，而底层的镜像都是只读的，写操作只能发生在镜像栈最上面所添加的可写层，这个可写层保存在我们对应容器所运行的节点上， 如果删除容器，底层的只读部分镜像不会改变，但最上层的可写层被删除，

ingress​ 通常情况下，service 和 pod 的 IP 仅可在集群内部访问。集群外部的请求需要通过负载均衡转发到 service 在 Node 暴露的 NodePort 上，然后再由 kube-proxy 通过边缘路由器 (edge router) 将其转发给相关的 Pod 或者丢弃 : inter --> ingress --> services​ Ingress公开了从群集外部到群集内 services 的HTTP和HTTPS路由，但Ingress 不会公开任意端口或

Service​ 在k8s平台之上，pod是有生命周期的，所以为了能够给对应的客户端提供固定的访问端点， 因此我们在客户端与服务pod之间添加了一个固定的中间层(service)， 而service名称解析强依赖于k8s的DNS服务(CoreDns, 1.10之前为kube-dns)， 部署完k8s之后必须要部署一个DNS服务用于解析名称。k8s 在每个节点之上有一个工作组件(kube-proxy)kube-proxy始终监视着api server有关server资源的变动信息，其随时会连到api

pod控制器controller​ 对于k8s系统的来说API Server是整个集群入口的gateway，并且它还是一个Restfull系统, 做为一个Restfull风格的系统, 其所管理的内容通通会被抽象成resources， pod控制器就是一个resources, 并且我们创建出的每一个pod都是一个具体的Object；​ API Server为整个Kubernetes的数据管理提供了一种数据范式，所有存取于API Server的数据，都必须遵循于Resources这样的一个规范，比如我们需

kubectl接口风格kubectl是一种RESTful风格的api，它把各种操作对象都一率当成资源来管理，并且可通过标准的http请求方法来处理，如： GET, PUT, DELETE, POST资源：对象资源实例化之后就是一个对象，类型于py的 类， 如k8s资源： service, pod, deploymentworkload: 运行应用程序对外提供的服务，如Pod,​ 工作负载型资源： ReplicaSet, Deployment, StatefulSet, Daemon

部署1、手动安装​ 安装： 都需要编译或二进制安装， 证书\网络也需要手动安装​ master： API Serveer, Scheduler, Controller-manage， etcd 都需要当守护进程启动，​ node: kubelet, docker(或者说容器引擎), kube-proxy2、kuberadm​ k8s官方提供的一个集群部署工具， 每个节点都需要安装 docker-ce, kubelet 下载地址， 部署mdmaster： API Serveer,

devops概念应用程序交付在运维人员之前，一般来讲需要一个开发团队，做架构设计、做开发、开发完成之后还要做构建然后测试，回滚，测试，验收，上线等等流程，在交付给运维之前开发完成之后这个过程，如果它能够自动实现，我们就把它称为持续集成的过程，整个环境的需要人工的环节只有一个就是开发代码。集成完成之后就该交付给运维进行部署了，那么交付给运维是这样的，测试通过后自动打包到一个可以被运维拿到的一个共享的文件服务上，或者是一个仓库当中，让我们运维人员能够得到打包好的构建好的最终产品，把这一步也能自动实现，那这