location = 完整路径 > location ^~ > location ~,~* > location /test/location /总结：rewrite和location都可以跳转，似乎有点像，但是区别在于rewrite是在同一域名之内更改获取资源的路径。在http模块有server，在server模块才有location，location匹配的是uri。精确匹配优先级最高-----

restartPolicy指的是pod内的容器启动失败或者有问题的重启策略：Always Never Onfalie（只有异常退出才会重启，状态非0，如果状态是0，不重启）,restartPolicy指的是容>器的重启策略，资源类型定义为deployment，容器的重启策略只能是Always。#这里的spec是声明容器的相关参数，虽然我制定了容器的暴露端口是80，nginx默认的镜像就是80，即使

ETCD：k8s的存储服务，etcd分布式键值存储系统（key:value），k8s的关键配置和用户配置，先通过APIserver调用etcd当中的存储信息，然后再实施（整个集群当中，能对etcd进行读写权限的，只有API-server）因为传统的部署方式：一般意义上的二进制部署，从安装----运行----运行维护，需要专业的人员，如果出了故障还需要人工重新拉起来。对docker的容器技术从应用的

selfLink：API的资源对象之一，表示资源对象在集群当中自身的一个连接，self-link是一个唯一标识符号，可以用于标识k8s集群当中每个资源的对象。storageclass的名称，nfs服务器的地址，以及nfs的目录。nfs的provisioner的客户端以pod的方式运行在集群当中，监听k8s集群当中pv的请求，动态的创建与NFS服务器相关的pv。hostPath：持久化存储数据，可以

就绪探针的特点：pod的状态是running，ready状态是notready，容器不可以提供正常的业务访问，就绪探针不会重启容器。onFailure：当pod内的容器退出时，整个pod都不会重启，只有一个或者N个容器非正常退出，状态码非0，整个pod才会重启。6、就绪探针，如果不影响容器运行，status:running，这个时候不会重启，但是，容器退出的话，就绪探针也会重启。5、在pod的生命

组件：kube-apiserverkube-controller-managerkube-scheduleretcd。上传 master.zip 和 k8s-cert.sh 到 /opt/k8s 目录中，解压 master.zip 压缩包。组件：kube-apiserverkube-controller-managerkube-scheduler。etcd是一个高可用----分布式的键值存储数据库

list-watch-----会在每一步监听的消息（APIserver:6443）------controllermanagerscheduleretcd都会监听apiserver:6443端口。podfitshost：pod适应主机，如果pod指定了node的name，nginx1 pod---->node01，检测主机名是否存在，存在要和pod指定的名称匹配，这样才能调度过去。硬策略（选择po

特殊情况：NoExecute依然可以部署pod，但是有生命周期，时间一到，pod会被销毁，生命周期结束之后，会被驱逐一部分pod到其他节点，有的节点还是会保留在污点节点上。拓扑域：k8s集群节点当中的一个组织结构，可以根据节点的物理关系或者逻辑关系进行划分，可以用来表示节点之间的空间关系，网络关系或者其他类型的关系。指定key的值，指标节点的标签值，但是不指定污点的类型，那么所有节点上只要包含了这

发布的过程中，暂时停止，只有一部分的pod先升级，其他的pod还是处于老的版本。确定无问题之后，再把剩下的老版本，升级成新的版本，把暂停取消，继续发布。如果是基于deployment方式创建的pod,或者是daemonset方式创建的pod，是由控制器创建的pod,使用delete删除pod是不删不掉的，相当于重启pod.l。ClusterlP:创建service的默认类型，提供一个集群内部的虚拟

proxy：安装完harbor之后，他会自动生成一个nginx的容器自动对外映射，80端口，nginx前端代理，在Harbor当中，registry，UI，TOKEN，都在nginx的反向代理后面，通过nginx的代理，可以把请求转发到后端的不同应用。Registry：负责存储镜像，docker pull/push的命令都由其负责，用户进行访问控制，不同的用户对docker的镜像有不同的读写权限。