目录
放在文章首位：
该文章为学习时发现的宝藏集合，为了避免失联仅以留存形式在此。建议去原文阅读：https://blog.csdn.net/qq_42987484/category_9539473.html。
个人认为内容以理解为主，不求记忆，涉及时反复温习即可，相信每次会有新的收获。
一、kubernetes架构
K8s 集群属于主从分布式架构，主要由分布式存储（etcd）、服务节点（Worker Node）和控制节点（Master Node）构成的，以及包括以下主要核心组件：
-
etcd保存了整个集群的状态；
-
apiserver提供了资源操作的唯一入口，并提供认证、授权、访问控制、API注册和发现等机制；
-
controller manager负责维护集群的状态，比如故障检测、自动扩展、滚动更新等；
-
scheduler负责资源的调度，按照预定的调度策略将Pod调度到相应的机器上；
-
kubelet负责维护容器的生命周期，同时也负责Volume（CVI）和网络（CNI）的管理；
-
Container runtime负责镜像管理以及Pod和容器的真正运行（CRI）；
-
kube-proxy负责为Service提供cluster内部的服务发现和负载均衡；
除了核心组件，还有一些推荐的Add-ons：
-
kube-dns：负责为整个集群提供DNS服务；
-
Ingress Controller：为服务提供外网入口；
-
Heapster：提供资源监控；
-
Dashboard：提供GUI；
-
Federation：提供跨可用区的集群；
-
Fluentd-elasticsearch：提供集群日志采集、存储与查询；
注释：
Master Node：作为控制节点，对集群进行调度管理；Master Node由API Server、Scheduler、Cluster State Store和Controller-Manger Server所组成；
Worker Node：作为真正的工作节点，运行业务应用的容器；Worker Node包含kubelet、kube proxy和Container Runtime等；
Kubernetes设计理念和功能其实就是一个类似Linux的分层架构，如下图：
-
核心层：Kubernetes最核心的功能，对外提供API构建高层的应用，对内提供插件式应用执行环境；
-
应用层：部署（无状态应用、有状态应用、批处理任务、集群应用等）和路由（服务发现、DNS解析等）；
-
管理层：系统度量（如基础设施、容器和网络的度量），自动化（如自动扩展、动态Provision等）以及策略管理（RBAC、Quota、PSP、NetworkPolicy等）；
-
接口层：kubectl命令行工具、客户端SDK以及集群联邦；
-
生态系统：在接口层之上的庞大容器集群管理调度的生态系统，可以划分为两个范畴：
Kubernetes外部：日志、监控、配置管理、CI、CD、Workflow、FaaS、OTS应用、ChatOps等；
Kubernetes内部：CRI、CNI、CVI、镜像仓库、Cloud Provider、集群自身的配置和管理等；
API Server主要用来处理REST的操作，确保它们生效，并执行相关业务逻辑，以及更新etcd（或者其他存储）中的相关对象。API Server是所有REST命令的入口，它的相关结果状态将被保存在etcd（或其他存储）中。API Server的基本功能包括：
-
REST语义，监控，持久化和一致性保证，API 版本控制，放弃和生效；
-
内置准入控制语义，同步准入控制钩子，以及异步资源初始化；
-
API注册和发现；
另外，API Server也作为集群的网关。默认情况，客户端通过API Server对集群进行访问，客户端需要通过认证，并使用API Server作为访问Node和Pod（以及service）的堡垒和代理/通道
1-2.Cluster state store（集群状态存储）
Kubernetes默认使用etcd作为集群整体存储，当然也可以使用其它的技术。etcd是一个简单的、分布式的、一致的key-value存储，主要被用来共享配置和服务发现。etcd提供了一个CRUD操作的REST API，以及提供了作为注册的接口，以监控指定的Node。集群的所有状态都存储在etcd实例中，并具有监控的能力，因此当etcd中的信息发生变化时，就能够快速的通知集群中相关的组件
1-3.Controller-Manager Server（控制管理服务器）
Controller-Manager Serve用于执行大部分的集群层次的功能，它既执行生命周期功能(例如：命名空间创建和生命周期、事件垃圾收集、已终止垃圾收集、级联删除垃圾收集、node垃圾收集)，也执行API业务逻辑（例如：pod的弹性扩容）。控制管理提供自愈能力、扩容、应用生命周期管理、服务发现、路由、服务绑定和提供。Kubernetes默认提供Replication Controller、Node Controller、Namespace Controller、Service Controller、Endpoints Controller、Persistent Controller、DaemonSet Controller等控制器。
scheduler组件为容器自动选择运行的主机。依据请求资源的可用性，服务请求的质量等约束条件，scheduler监控未绑定的pod，并将其绑定至特定的node节点。Kubernetes也支持用户自己提供的调度器，Scheduler负责根据调度策略自动将Pod部署到合适Node中，调度策略分为预选策略和优选策略，Pod的整个调度过程分为两步：
1）预选Node：遍历集群中所有的Node，按照具体的预选策略筛选出符合要求的Node列表。如没有Node符合预选策略规则，该Pod就会被挂起，直到集群中出现符合要求的Node。
2）优选Node：预选Node列表的基础上，按照优选策略为待选的Node进行打分和排序，从中获取最优Node。
Kubelet是Kubernetes中最主要的控制器，它是Pod和Node API的主要实现者，Kubelet负责驱动容器执行层。在Kubernetes中，应用容器彼此是隔离的，并且与运行其的主机也是隔离的，这是对应用进行独立解耦管理的关键点。
在Kubernets中，Pod作为基本的执行单元，它可以拥有多个容器和存储数据卷，能够方便在每个容器中打包一个单一的应用，从而解耦了应用构建时和部署时的所关心的事项，已经能够方便在物理机/虚拟机之间进行迁移。API准入控制可以拒绝或者Pod，或者为Pod添加额外的调度约束，但是Kubelet才是Pod是否能够运行在特定Node上的最终裁决者，而不是scheduler或者DaemonSet。kubelet默认情况使用cAdvisor进行资源监控。负责管理Pod、容器、镜像、数据卷等，实现集群对节点的管理，并将容器的运行状态汇报给Kubernetes API Server。
每一个Node都会运行一个Container Runtime，其负责下载镜像和运行容器。Kubernetes本身并不停容器运行时环境，但提供了接口，可以插入所选择的容器运行时环境。kubelet使用Unix socket之上的gRPC框架与容器运行时进行通信，kubelet作为客户端，而CRI shim作为服务器。
protocol buffers API提供两个gRPC服务，ImageService和RuntimeService。ImageService提供拉取、查看、和移除镜像的RPC。RuntimeSerivce则提供管理Pods和容器生命周期管理的RPC，以及与容器进行交互(exec/attach/port-forward)。容器运行时能够同时管理镜像和容器（例如：Docker和Rkt），并且可以通过同一个套接字提供这两种服务。在Kubelet中，这个套接字通过–container-runtime-endpoint和–image-service-endpoint字段进行设置。Kubernetes CRI支持的容器运行时包括docker、rkt、cri-o、frankti、kata-containers和clear-containers等。
基于一种公共访问策略（例如：负载均衡），服务提供了一种访问一群pod的途径。此方式通过创建一个虚拟的IP来实现，客户端能够访问此IP，并能够将服务透明的代理至Pod。每一个Node都会运行一个kube-proxy，kube proxy通过iptables规则引导访问至服务IP，并将重定向至正确的后端应用，通过这种方式kube-proxy提供了一个高可用的负载均衡解决方案。服务发现主要通过DNS实现。
在Kubernetes中，kube proxy负责为Pod创建代理服务；引到访问至服务；并实现服务到Pod的路由和转发，以及通过应用的负载均衡。
kubectl是Kubernetes集群的命令行接口。运行kubectl命令的语法如下所示：
$ kubectl [command] [TYPE] [NAME] [flags]
这里的command，TYPE、NAME和flags为：
comand：指定要对资源执行的操作，例如create、get、describe和delete
TYPE：指定资源类型，资源类型是大小学敏感的，开发者能够以单数、复数和缩略的形式。例如：
$ kubectl get pod pod1
$ kubectl get pods pod1
$ kubectl get po pod1
NAME：指定资源的名称，名称也大小写敏感的。如果省略名称，则会显示所有的资源，例如:
$kubectl get pods
flags：指定可选的参数。例如，可以使用-s或者–server参数指定Kubernetes API server的地址和端口。
另外，可以通过运行kubectl help命令获取更多的信息。
在Kunbernetes中可以以附加项的方式扩展Kubernetes的功能，目前主要有网络、服务发现和可视化这三大类的附加项，下面是可用的一些附加项：
-
ACI 通过与Cisco ACI集成的容器网络和网络安全。
-
Calico 是一个安全的3层网络和网络策略提供者。
-
Canal 联合Fannel和Calico，通过网络和网络侧。
-
Cilium 是一个3层网络和网络侧插件，它能够透明的加强HTTP/API/L7 策略。其即支持路由，也支持overlay/encapsultion模式。
-
Flannel 是一个overlay的网络提供者。
-
CoreDNS 是一个灵活的，可扩展的DNS服务器，它能够作为Pod集群内的DNS进行安装。
-
Ingress 提供基于Http协议的路由转发机制。
-
Dashboard 是Kubernetes的web用户界面。
分析和理解 K8s 的设计理念对设计和实现分布式系统有两方面的益处。一方面，可以使我们更深入地了解 K8s 系统，更好地利用它管理分布式部署的云原生应用；另一方面，K8s 集群管理平台本身也是个分布式系统，分析和理解它可以让我们借鉴其在分布式系统设计方面的经验
-
所有API应该是声明式的。正如前文所说，声明式的操作，相对于命令式操作，对于重复操作的效果是稳定的，这对于容易出现数据丢失或重复的分布式环境来说是很重要的。另外，声明式操作更容易被用户使用，可以使系统向用户隐藏实现的细节，隐藏实现的细节的同时，也就保留了系统未来持续优化的可能性。此外，声明式的API，同时隐含了所有的API对象都是名词性质的，例如Service、Volume这些API都是名词，这些名词描述了用户所期望得到的一个目标分布式对象。
-
API对象是彼此互补而且可组合的。这里面实际是鼓励API对象尽量实现面向对象设计时的要求，即“高内聚，松耦合”，对业务相关的概念有一个合适的分解，提高分解出来的对象的可重用性。事实上，K8s这种分布式系统管理平台，也是一种业务系统，只不过它的业务就是调度和管理容器服务。
-
高层API以操作意图为基础设计。如何能够设计好API，跟如何能用面向对象的方法设计好应用系统有相通的地方，高层设计一定是从业务出发，而不是过早的从技术实现出发。因此，针对K8s的高层API设计，一定是以K8s的业务为基础出发，也就是以系统调度管理容器的操作意图为基础设计。
-
低层API根据高层API的控制需要设计。设计实现低层API的目的，是为了被高层API使用，考虑减少冗余、提高重用性的目的，低层API的设计也要以需求为基础，要尽量抵抗受技术实现影响的诱惑。
-
尽量避免简单封装，不要有在外部API无法显式知道的内部隐藏的机制。简单的封装，实际没有提供新的功能，反而增加了对所封装API的依赖性。内部隐藏的机制也是非常不利于系统维护的设计方式，例如PetSet和ReplicaSet，本来就是两种Pod集合，那么K8s就用不同API对象来定义它们，而不会说只用同一个ReplicaSet，内部通过特殊的算法再来区分这个ReplicaSet是有状态的还是无状态。
-
API操作复杂度与对象数量成正比。这一条主要是从系统性能角度考虑，要保证整个系统随着系统规模的扩大，性能不会迅速变慢到无法使用，那么最低的限定就是API的操作复杂度不能超过O(N)，N是对象的数量，否则系统就不具备水平伸缩性了。
-
API对象状态不能依赖于网络连接状态。由于众所周知，在分布式环境下，网络连接断开是经常发生的事情，因此要保证API对象状态能应对网络的不稳定，API对象的状态就不能依赖于网络连接状态。
-
尽量避免让操作机制依赖于全局状态。因为在分布式系统中要保证全局状态的同步是非常困难的。
-
控制逻辑应该只依赖于当前状态。这是为了保证分布式系统的稳定可靠，对于经常出现局部错误的分布式系统，如果控制逻辑只依赖当前状态，那么就非常容易将一个暂时出现故障的系统恢复到正常状态，因为你只要将该系统重置到某个稳定状态，就可以自信的知道系统的所有控制逻辑会开始按照正常方式运行。
-
假设任何错误的可能，并做容错处理。在一个分布式系统中出现局部和临时错误是大概率事件。错误可能来自于物理系统故障，外部系统故障也可能来自于系统自身的代码错误，依靠自己实现的代码不会出错来保证系统稳定其实也是难以实现的，因此要设计对任何可能错误的容错处理。
尽量避免复杂状态机，控制逻辑不要依赖无法监控的内部状态。因为分布式系统各个子系统都是不能严格通过程序内部保持同步的，所以如果两个子系统的控制逻辑如果互相有影响，那么子系统就一定要能互相访问到影响控制逻辑的状态，否则，就等同于系统里存在不确定的控制逻辑。 -
假设任何操作都可能被任何操作对象拒绝，甚至被错误解析。由于分布式系统的复杂性以及各子系统的相对独立性，不同子系统经常来自不同的开发团队，所以不能奢望任何操作被另一个子系统以正确的方式处理，要保证出现错误的时候，操作级别的错误不会影响到系统稳定性。
每个模块都可以在出错后自动恢复。由于分布式系统中无法保证系统各个模块是始终连接的，因此每个模块要有自我修复的能力，保证不会因为连接不到其他模块而自我崩溃。 -
每个模块都可以在必要时优雅地降级服务。所谓优雅地降级服务，是对系统鲁棒性的要求，即要求在设计实现模块时划分清楚基本功能和高级功能，保证基本功能不会依赖高级功能，这样同时就保证了不会因为高级功能出现故障而导致整个模块崩溃。根据这种理念实现的系统，也更容易快速地增加新的高级功能，以为不必担心引入高级功能影响原有的基本功能。
K8s 在实现上述架构时要基于以下架构理念：
-
只有 API Server 与存储通信，其他模块通过 API Server 访问集群状态。这样第一，是为了保证集群状态访问的安全。第二，是为了隔离集群状态访问的方式和后端存储实现的方式：API Server 是状态访问的方式，不会因为后端存储技术 etcd 的改变而改变。加入以后将 etcd 更换成其他的存储方式，并不会影响依赖依赖 API Server 的其他 K8s 系统模块。
-
一个工作节点被攻破不能导致整个 K8s 集群被攻破。这是所有分布式系统架构设计中都应该考虑的问题。
-
考虑网络随时可能断开的情况，没有新配置声明时各模块按照之前的配置声明继续工作。在 K8s 集群中，所有的配置管理操作都声明式而非命令式的，因为声明式操作对于网络故障等分布式系统常见的故障情况更加稳定。
-
各个模块在内存中缓存自己的相关状态以提高系统性能。
-
需要监控某个系统状态来做下一步动作的时候，优先考虑观察通知模式，其次再考虑轮询模式，这也是为了提高系统的响应速度。
从 K8s 的系统架构、技术概念和设计理念，我们可以看到 K8s 系统最核心的两个设计理念：一个是容错性，一个是易扩展性。容错性实际是保证 K8s 系统稳定性和安全性的基础，易扩展性是保证 K8s 对变更友好，可以快速迭代增加新功能的基础。
本文仅是个人学习时的整理收藏，以便回顾所用，内容均来源其它处。
[参考文档]http://docs.kubernetes.org.cn/249.html#i-2.
二、kubernetes核心技术概念
Container（容器）是一种便携式、轻量级的操作系统级虚拟化技术。它使用 namespace 隔离不同的软件运行环境，并通过镜像自包含软件的运行环境，从而使得容器可以很方便的在任何地方运行。
API对象是K8s集群中的管理操作单元。K8s集群系统每支持一项新功能，引入一项新技术，一定会新引入对应的API对象，支持对该功能的管理操作。例如副本集Replica Set对应的API对象是RS。
集群是指由Kubernetes使用一系列的物理机、虚拟机和其他基础资源来运行你的应用程序的集合。
master是cluster的大脑，他的主要职责是调度，即决定将应用放在那里运行。master运行linux操作系统，可以是物理机或者虚拟机。为了实现高可用，可以运行多个master。
node的职责是运行容器应用。node由master管理，node负责监控并汇报容器的状态，同时根据master的要求管理容器的生命周期。
K8s集群中的计算能力由Node提供，最初Node称为服务节点Minion，后来改名为Node。K8s集群中的Node也就等同于Mesos集群中的Slave节点，是所有Pod运行所在的工作主机，可以是物理机也可以是虚拟机。不论是物理机还是虚拟机，工作主机的统一特征是上面要运行kubelet管理节点上运行的容器。
Pod是在K8s集群中运行部署应用或服务的最小单元，它是可以支持多容器的。一个pod对应一个由相关容器和卷组成的容器组。
Pod是K8s集群中所有业务类型的基础，可以看作运行在K8s集群中的小机器人，不同类型的业务就需要不同类型的小机器人去执行。目前K8s中的业务主要可以分为长期伺服型（long-running）、批处理型（batch）、节点后台支撑型（node-daemon）和有状态应用型（stateful application）；分别对应的小机器人控制器为Deployment、Job、DaemonSet和PetSet。
7.复制控制器（Replication Controller，RC）
RC是为了保证一定数量被指定的Pod的复制品在任何时间都能正常工作，它不仅允许复制的系统易于扩展，还会处理当pod在机器在重启或发生故障的时候再次创建一个。
RC是K8s集群中最早的保证Pod高可用的API对象。通过监控运行中的Pod来保证集群中运行指定数目的Pod副本。指定的数目可以是多个也可以是1个；少于指定数目，RC就会启动运行新的Pod副本；多于指定数目，RC就会杀死多余的Pod副本。即使在指定数目为1的情况下，通过RC运行Pod也比直接运行Pod更明智，因为RC也可以发挥它高可用的能力，保证永远有1个Pod在运行。RC是K8s较早期的技术概念，只适用于长期伺服型的业务类型，比如控制小机器人提供高可用的Web服务。
ReplicaSet（RS）是Replication Controller（RC）的升级版本。ReplicaSet 和 Replication Controller之间的唯一区别是对选择器的支持。ReplicaSet支持labels user guide中描述的set-based选择器要求， 而Replication Controller仅支持equality-based的选择器要求。
**
deployment可以管理pod的多个副本，并确保pod按照期望的状态运行。
部署表示用户对K8s集群的一次更新操作。部署是一个比RS应用模式更广的API对象，可以是创建一个新的服务，更新一个新的服务，也可以是滚动升级一个服务。滚动升级一个服务，实际是创建一个新的RS，然后逐渐将新RS中副本数增加到理想状态，将旧RS中的副本数减小到0的复合操作；这样一个复合操作用一个RS是不太好描述的，所以用一个更通用的Deployment来描述。以K8s的发展方向，未来对所有长期伺服型的的业务的管理，都会通过Deployment来管理。
一个service定义了访问pod的方式，就像单个固定的IP地址和与其相对应的DNS名之间的关系。
RC、RS和Deployment只是保证了支撑服务的微服务Pod的数量，但是没有解决如何访问这些服务的问题。一个Pod只是一个运行服务的实例，随时可能在一个节点上停止，在另一个节点以一个新的IP启动一个新的Pod，因此不能以确定的IP和端口号提供服务。要稳定地提供服务需要服务发现和负载均衡能力。服务发现完成的工作，是针对客户端访问的服务，找到对应的的后端服务实例。在K8s集群中，客户端需要访问的服务就是Service对象。每个Service会对应一个集群内部有效的虚拟IP，集群内部通过虚拟IP访问一个服务。在K8s集群中微服务的负载均衡是由Kube-proxy实现的。Kube-proxy是K8s集群内部的负载均衡器。它是一个分布式代理服务器，在K8s的每个节点上都有一个；这一设计体现了它的伸缩性优势，需要访问服务的节点越多，提供负载均衡能力的Kube-proxy就越多，高可用节点也随之增多。与之相比，我们平时在服务器端做个反向代理做负载均衡，还要进一步解决反向代理的负载均衡和高可用问题。
Job 负责批量处理短暂的一次性任务，用于运行结束就删除的应用，而其他controller中的pod通常是长期持续运行的。
Job是K8s用来控制批处理型任务的API对象。批处理业务与长期伺服业务的主要区别是批处理业务的运行有头有尾，而长期伺服业务在用户不停止的情况下永远运行。Job管理的Pod根据用户的设置把任务成功完成就自动退出了。成功完成的标志根据不同的spec.completions策略而不同：单Pod型任务有一个Pod成功就标志完成；定数成功型任务保证有N个任务全部成功；工作队列型任务根据应用确认的全局成功而标志成功。
CronJob即定时任务，在指定的时间周期运行指定的任务，就类似于Linux系统的crontab。
一个DaemonSet对象能确保其创建的Pod在集群中的每一台（或指定）Node上都运行一个副本。
长期伺服型和批处理型服务的核心在业务应用，可能有些节点运行多个同类业务的Pod，有些节点上又没有这类Pod运行；而后台支撑型服务的核心关注点在K8s集群中的节点（物理机或虚拟机），要保证每个节点上都有一个此类Pod运行。节点可能是所有集群节点也可能是通过nodeSelector选定的一些特定节点。典型的后台支撑型服务包括，存储，日志和监控等在每个节点上支持K8s集群运行的服务。
StatefulSet 用于支持部署有状态服务，能够保证pod的每个副本在整个生命周期中PodName 和HostName 是不变的，同时保证副本按照固定的顺序启动、更新或者删除。
Volume是Pod中能够被多个容器共享的磁盘目录。
容器中的磁盘的生命周期是短暂的，这就带来了一系列的问题，第一，当一个容器损坏之后，kubelet 会重启这个容器，但是文件会丢失-这个容器会是一个全新的状态，第二，当很多容器在同一Pod中运行的时候，很多时候需要数据文件的共享。Kubernete Volume解决了这个问题。
K8s集群中的存储卷跟Docker的存储卷有些类似，只不过Docker的存储卷作用范围为一个容器，而K8s的存储卷的生命周期和作用范围是一个Pod。每个Pod中声明的存储卷由Pod中的所有容器共享。K8s支持非常多的存储卷类型，特别的，支持多种公有云平台的存储，包括AWS，Google和Azure云；支持多种分布式存储包括GlusterFS和Ceph；也支持较容易使用的主机本地目录hostPath和NFS。K8s还支持使用Persistent Volume Claim即PVC这种逻辑存储，使用这种存储，使得存储的使用者可以忽略后台的实际存储技术（例如AWS，Google或GlusterFS和Ceph），而将有关存储实际技术的配置交给存储管理员通过Persistent Volume来配置。
Kubernete 支持如下类型的volume：emptyDir、hostPath、gcePersistentDisk、awsElasticBlockStore、nfs、iscsi、glusterfs、rbd、gitRepo、secret、persistentVolumeClaim；
16.持久存储卷（PersistentVolume，PV）、持久存储卷声明（PersistentVolumeClaim，PVC）和存储类（StorageClass）
PersistentVolume (PV) 是外部存储系统中的一块存储空间，由管理员创建和维护。与 Volume 一样，PV 具有持久性，生命周期独立于 Pod。
PersistentVolumeClaim (PVC)是对 PV 的申请 。PVC 通常由普通用户创建和维护。需要为 Pod 分配存储资源时，用户可以创建一个 PVC，指明存储资源的容量大小和访问模式（比如只读）等信息，Kubernetes 会查找并提供满足条件的 PV。
StorageClass为管理员提供了一种描述他们提供的存储的“类”的方法。 不同的类可能映射到服务质量级别，或备份策略，或者由群集管理员确定的任意策略。 这个概念有时在其他存储系统中称为“配置文件”
PV和PVC使得K8s集群具备了存储的逻辑抽象能力，使得在配置Pod的逻辑里可以忽略对实际后台存储技术的配置，而把这项配置的工作交给PV的配置者，即集群的管理者。存储的PV和PVC的这种关系，跟计算的Node和Pod的关系是非常类似的；PV和Node是资源的提供者，根据集群的基础设施变化而变化，由K8s集群管理员配置；而PVC和Pod是资源的使用者，根据业务服务的需求变化而变化，有K8s集群的使用者即服务的管理员来配置。
Namespace是对一组资源和对象的抽象集合，不同的namespace里的资源是完全隔离的。常用来对系统内部的对象划分为不同的项目组或用户组来达到资源隔离的目的，比如Kubernetes自带的服务一般运行在命名空间kube-system中。也可以将一个物理的cluster逻辑上划分成多个虚拟cluster，每个cluster就是一个namespace。
Namespace 好比一个资源名字的前缀。它帮助不同的项目、团队或是客户可以共享cluster,例如防止相互独立的团队间出现命名冲突。
名字空间为K8s集群提供虚拟的隔离作用，K8s集群初始有两个名字空间，分别是默认名字空间default和系统名字空间kube-system，除此以外，管理员可以可以创建新的名字空间满足需要。
Secret是用来保存和传递密码、密钥、认证凭证这些敏感信息的对象。使用Secret的好处是可以避免把敏感信息明文写在配置文件里。在K8s集群中配置和使用服务不可避免的要用到各种敏感信息实现登录、认证等功能，例如访问AWS存储的用户名密码。为了避免将类似的敏感信息明文写在所有需要使用的配置文件中，可以将这些信息存入一个Secret对象，而在配置文件中通过Secret对象引用这些敏感信息。这种方式的好处包括：意图明确，避免重复，减少暴漏机会。
ConfigMap用于保存配置数据的键值对，可以用来保存单个属性，也可以用来保存配置文件。ConfigMap跟secret很类似，但它可以更方便地处理不包含敏感信息的字符串。
Ingress就是为给外部进入集群的请求提供路由规则的集合。通常情况下，Service 和 Pod 仅支持在集群内部进行服务访问。而 Ingress 可以提供外部服务可访问的 URL / 负载均衡器等。
Ingress 对象只是配置了一些规则，若要实现集群外部的访问，还需要部署一个 Ingress Controller，它会从 kube-apiserver 监听 Ingress 和 Service 的变更，并根据 Ingress 的规则配置负载均衡来提供访问入口。
21.自动伸缩（Horizontal Pod Autoscaling）
Horizontal Pod Autoscaling可以根据CPU使用率或应用自定义metrics自动扩展Pod数量（支持replication controller、deployment和replica set）。
PodPreset用来给指定标签的Pod注入额外的信息，如环境变量、存储卷等。这样，Pod模板就不需要为每个Pod都显式设置重复的信息。
资源配额（Resource Quotas）是用来限制用户资源用量的一种机制，可以用来定义某个命名空间下所有资源的使用限额，包括计算资源的配额、存储资源的配额、对象数量的配额。
Network Policy提供了基于策略的网络控制，用于隔离应用并减少攻击面。它使用标签选择器模拟传统的分段网络，并通过策略控制它们之间的流量以及来自外部的流量。
Kubernetes要求集群中所有pod，无论是节点内还是跨节点，都可以直接通信，或者说所有pod工作在同一跨节点网络，此网络一般是二层虚拟网络，称为pod网络。在安装引导kubernetes时，由选择并安装的network plugin实现。默认情况下，集群中所有pod之间、pod与节点之间可以互通。
网络主要解决两个问题，一个是连通性，实体之间能够通过网络互通。另一个是隔离性，出于安全、限制网络流量的目的，又要控制实体之间的连通性。Network Policy用来实现隔离性，只有匹配规则的流量才能进入pod，同理只有匹配规则的流量才可以离开pod。
但请注意，kubernetes支持的用以实现pod网络的network plugin有很多种，并不是全部都支持Network Policy，为kubernetes选择network plugin时需要考虑到这点，是否需要隔离？可用network plugin及是否支持Network Policy请参考https://kubernetes.io/docs/concepts/cluster-administration/addons/#networking-and-network-policy
Security Context的目的是限制不可信容器的行为，保护系统和其他容器不受其影响。
Pod Security Policies（PSP）是集群级的Pod安全策略，自动为集群内的Pod和Volume设置Security Context。使用PSP需要API Server开启extensions/v1beta1/podsecuritypolicy，并且配置PodSecurityPolicyadmission控制器。
ThirdPartyResources是一种无需改变代码就可以扩展Kubernetes API的机制，可以用来管理自定义对象。(注意：ThirdPartyResources将在v1.7弃用，并在未来版本中删除。建议从v1.7开始，迁移到CustomResourceDefinition)
endpoint是k8s集群中的一个资源对象，存储在etcd中，用来记录一个service对应的所有pod的访问地址。service配置selector，endpoint controller才会自动创建对应的endpoint对象。否则，不会生成endpoint对象。
记录k8s集群运行所遇到的各种大事件。
29.用户帐户（User Account）和服务帐户（Service Account）
顾名思义，用户帐户为人提供账户标识，而服务账户为计算机进程和K8s集群中运行的Pod提供账户标识。用户帐户和服务帐户的一个区别是作用范围；用户帐户对应的是人的身份，人的身份与服务的namespace无关，所以用户账户是跨namespace的；而服务帐户对应的是一个运行中程序的身份，与特定namespace是相关的。
K8s在1.3版本中发布了alpha版的基于角色的访问控制（Role-based Access Control，RBAC）的授权模式。相对于基于属性的访问控制（Attribute-based Access Control，ABAC），RBAC主要是引入了角色（Role）和角色绑定（RoleBinding）的抽象概念。在ABAC中，K8s集群中的访问策略只能跟用户直接关联；而在RBAC中，访问策略可以跟某个角色关联，具体的用户在跟一个或多个角色相关联。显然，RBAC像其他新功能一样，每次引入新功能，都会引入新的API对象，从而引入新的概念抽象，而这一新的概念抽象一定会使集群服务管理和使用更容易扩展和重用。
K8s在1.3版本里发布了beta版的Federation功能。在云计算环境中，服务的作用距离范围从近到远一般可以有：同主机（Host，Node）、跨主机同可用区（Available Zone）、跨可用区同地区（Region）、跨地区同服务商（Cloud Service Provider）、跨云平台。K8s的设计定位是单一集群在同一个地域内，因为同一个地区的网络性能才能满足K8s的调度和计算存储连接要求。而联合集群服务就是为提供跨Region跨服务商K8s集群服务而设计的。
每个K8s Federation有自己的分布式存储、API Server和Controller Manager。用户可以通过Federation的API Server注册该Federation的成员K8s Cluster。当用户通过Federation的API Server创建、更改API对象时，Federation API Server会在自己所有注册的子K8s Cluster都创建一份对应的API对象。在提供业务请求服务时，K8s Federation会先在自己的各个子Cluster之间做负载均衡，而对于发送到某个具体K8s Cluster的业务请求，会依照这个K8s Cluster独立提供服务时一样的调度模式去做K8s Cluster内部的负载均衡。而Cluster之间的负载均衡是通过域名服务的负载均衡来实现的。
所有的设计都尽量不影响K8s Cluster现有的工作机制，这样对于每个子K8s集群来说，并不需要更外层的有一个K8s Federation，也就是意味着所有现有的K8s代码和机制不需要因为Federation功能有任何变化。
本文仅是个人学习时的整理收藏，以便回顾所用，内容均来源其它处。
[参考文档]http://docs.kubernetes.org.cn/227.html.
三、kubernetes核心组件
Master组件提供集群的管理控制中心。Master组件可以在集群中任何节点上运行。但是为了简单起见，通常在一台VM/机器上启动所有Master组件，并且不会在此VM/机器上运行用户容器。
kube-apiserver用于暴露Kubernetes API。任何的资源请求/调用操作都是通过kube-apiserver提供的接口进行。
etcd是Kubernetes提供默认的存储系统，保存所有集群数据，使用时需要为etcd数据提供备份计划。
kube-controller-manager运行管理控制器，它们是集群中处理常规任务的后台线程。逻辑上，每个控制器是一个单独的进程，但为了降低复杂性，它们都被编译成单个二进制文件，并在单个进程中运行。这些控制器包括：
-
节点（Node）控制器。
-
副本（Replication）控制器：负责维护系统中每个副本中的pod。
-
端点（Endpoints）控制器：填充Endpoints对象（即连接Services＆Pods）。
-
Service Account和Token控制器：为新的Namespace 创建默认帐户访问API Token。
kube-scheduler 监视新创建没有分配到Node的Pod，为Pod选择一个Node。
云控制器管理器负责与底层云提供商的平台交互。云控制器管理器是Kubernetes版本1.6中引入的，目前还是Alpha的功能。
云控制器管理器仅运行云提供商特定的（controller loops）控制器循环。可以通过将–cloud-provider flag设置为external启动kube-controller-manager ，来禁用控制器循环。
cloud-controller-manager 具体功能：
-
节点（Node）控制器
-
路由（Route）控制器
-
Service控制器
-
卷（Volume）控制器
节点组件运行在Node，提供Kubernetes运行时环境，以及维护Pod。
kubelet是主要的节点代理，它会监视已分配给节点的pod，具体功能：
-
安装Pod所需的volume。
-
下载Pod的Secrets。
-
Pod中运行的 docker（或experimentally，rkt）容器。
-
定期执行容器健康检查。
-
Reports the status of the pod back to the rest of the system, by creating a mirror pod if necessary.
-
Reports the status of the node back to the rest of the system.
提供网络代理以及负载均衡，实现与Service通讯。
每个Node都需要提供一个容器运行时（Container Runtime）环境，它负责下载镜像并运行容器。目前K8S支持的容器运行环境至少包括Docker、RKT、cri-o、Fraki等。
插件（addon）是实现集群pod和Services功能的 。Pod由Deployments，ReplicationController等进行管理。Namespace 插件对象是在kube-system Namespace中创建。
群集 DNS是一个DNS服务器，能够为 Kubernetes services提供 DNS记录。由Kubernetes启动的容器自动将这个DNS服务器包含在他们的DNS searches中。
在K8S集群中调度并运行提供DNS服务的Pod，同一集群内的其他Pod可以使用该DNS服务来解决主机名。K8S自1.11版本开始默认使用CoreDNS项目来为集群提供服务注册和服务发现的动态名称解析服务。
K8S集群的全部功能都可以基于Web的UI，来管理集群中的应用和集群自身。
容器和节点的性能监控与分析系统，它收集并解析多种指标数据，如资源利用率、生命周期时间，在最新的版本当中，其主要功能逐渐由Prometheus结合其他的组件进行代替。
Cluster-level logging，负责保存容器日志，搜索/查看日志。
K8s本身没有网络方案,它允许别人给他提供。主要的网络有flannel、calico、canel、Kube-router，flannel其默认情况下是用的vxlan的方式来作为后端网络传输机制的。
Service是一种工作于4层的负载均衡器，而Ingress是在应用层实现的HTTP(S)的负载均衡。不过，Ingress资源自身并不能进行流量的穿透，，它仅仅是一组路由规则的集合，这些规则需要通过Ingress控制器（Ingress Controller）发挥作用。目前该功能项目大概有：Nginx-ingress、Traefik、Envoy和HAproxy等
本文仅是个人学习时的整理收藏，以便回顾所用，内容均来源其它处。
[参考文档]http://docs.kubernetes.org.cn/230.html
四、kubernetes核心组件之etcd详解
etcd组件
etcd是一个高可用的键值存储系统，主要用于共享配置和服务发现。etcd是由CoreOS开发并维护的，灵感来自于 ZooKeeper 和 Doozer，它使用Go语言编写，并通过Raft一致性算法处理日志复制以保证强一致性。Raft是一个来自Stanford的新的一致性算法，适用于分布式系统的日志复制，Raft通过选举的方式来实现一致性，在Raft中，任何一个节点都可能成为Leader。Google的容器集群管理系统Kubernetes、开源PaaS平台Cloud Foundry和CoreOS的Fleet都广泛使用了etcd。etcd的特性如下：
-
简单: curl可访问的用户的API（HTTP+JSON）
-
安全: 可选的SSL客户端证书认证
-
快速: 单实例每秒 1000 次写操作
-
可靠: 使用Raft保证一致性
ETCD概念词汇表：
| 概念 |
解释 |
|---|---|
| Raft |
etcd所采用的保证分布式系统强一致性的算法。 |
| Node |
一个Raft状态机实例。 |
| Member |
一个etcd实例。它管理着一个Node，并且可以为客户端请求提供服务。 |
| Cluster |
由多个Member构成可以协同工作的etcd集群。 |
| Peer |
对同一个etcd集群中另外一个Member的称呼。 |
| Client |
向etcd集群发送HTTP请求的客户端。 |
| WAL |
预写式日志，etcd用于持久化存储的日志格式。 |
| snapshot |
etcd防止WAL文件过多而设置的快照，存储etcd数据状态。 |
| Proxy |
etcd的一种模式，为etcd集群提供反向代理服务。 |
| Leader |
Raft算法中通过竞选而产生的处理所有数据提交的节点。 |
| Follower |
竞选失败的节点作为Raft中的从属节点，为算法提供强一致性保证。 |
| Candidate |
当Follower超过一定时间接收不到Leader的心跳时转变为Candidate开始Leader竞选。 |
| Term |
某个节点成为Leader到下一次竞选开始的时间周期，称为一个Term。 |
| Index |
数据项编号。Raft中通过Term和Index来定位数据。 |
etcd主要分为四个部分：
-
HTTP Server： 用于处理用户发送的API请求以及其他etcd节点的同步与心跳信息请求
-
Store: 用于处理 etcd 支持的各类功能的事务，包括数据索引、节点状态变更、监控与反馈、事件处理与执行等等，是 etcd 对用户提供的大多数 API 功能的具体实现。
-
Raft： Raft 强一致性算法的具体实现，是 etcd 的核心。
-
WAL：Write Ahead Log（预写式日志/日志先行），是 etcd 的数据存储方式，也是一种实现事务日志的标准方法。etcd通过 WAL 进行持久化存储，所有的数据提交前都会事先记录日志。Snapshot 是为了防止数据过多而进行的状态快照；Entry 表示存储的具体日志内容。
-
流程分析：通常，一个用户的请求发送过来，会经由HTTP Server转发给Store进行具体的事务处理，如果涉及到节点的修改，则交给Raft模块进行状态的变更、日志的记录，然后再同步给别的etcd节点以确认数据提交，最后进行数据的提交，再次同步。
etcd使用Raft协议来维护集群内各个节点状态的一致性。简单说，ETCD集群是一个分布式系统，由多个节点相互通信构成整体对外服务，每个节点都存储了完整的数据，并且通过Raft协议保证每个节点维护的数据是一致的。
-
Raft算法
Raft 是一种为了管理复制日志的一致性算法。它提供了和 Paxos 算法相同的功能和性能，但是它的算法结构和 Paxos 不同，使得 Raft 算法更加容易理解并且更容易构建实际的系统。一致性算法允许一组机器像一个整体一样工作，即使其中一些机器出现故障也能够继续工作下去。正因为如此，一致性算法在构建可信赖的大规模软件系统中扮演着重要的角色。Raft算法分为三部分，分别是Leader选举、日志复制和安全性。
-
Leader选举：包括
Raft 状态机和Raft算法中的Term（任期）两部分。
A) Raft 状态机
Raft集群中的每个节点都处于一种基于角色的状态机中。具体来说，Raft定义了节点的三种角色： Follower、Candidate和Leader。
1、Leader(领导者): Leader节点在集群中有且仅能有一个，它负责向所有的Follower节点同步日志数据。
2、Follower(跟随者): Follower节点从Leader节点获取日志，提供数据查询功能，并将所有修改请求转发给Leader节点。（注意：由于proxy模式的本职就是启一个HTTP代理服务器，所以Etcd的代理节点（proxy）即作为Proxy角色的节点不会参与Leader的选举，只是将所有接收到的用户查询和修改请求转发到任意一个Follower或者Leader节点上。）
3、Candidate(候选者): 当集群中的Leader节点不存在或者失联之后，其他Follower节点转换为Candidate，然后开始新的Leader节点选举。
这三种角色状态之间的转换，如下图：
B)Raft算法中的Term（任期）
Raft会把时间分割成任意长度的任期，并且任期用连续的整数来标记。每一段任期都是从一次选举开始，一个或者多个候选人尝试成为领导者。如果一个候选人赢得选举，然后他就会在接下来的任期中充当Leader的职责。在某些情况下，一次选举会造成选票瓜分，这样，这一个任期将没有Leader。如果没有Leader，那么新的一轮选举就马上开始，也就是新的任期就会开始。Raft保证了在一个Term任期内，有且只有一个Leader。
-
日志复制：是指主节点将每次操作形成日志条目，并持久化到本地磁盘，然后通过网络IO发送给其他节点。
一旦一个领导人被选举出来，他就开始为客户端提供服务。客户端的每一个请求都包含一条被复制状态机执行的指令。领导人把这条指令作为一条新的日志条目附加到日志中去，然后并行的发起附加条目 RPCs 给其他的服务器，让他们复制这条日志条目。
Raft 算法保证所有已提交的日志条目都是持久化的并且最终会被所有可用的状态机执行。当主节点收到包括自己在内超过半数节点成功返回，那么认为该日志是可提交的(committed），并将日志输入到状态机，将结果返回给客户端。
在正常的操作中，领导人和跟随者的日志保持一致性，所以附加日志 RPC 的一致性检查从来不会失败。然而，领导人崩溃的情况会使得日志处于不一致的状态（老的领导人可能还没有完全复制所有的日志条目）。这种不一致问题会在一系列的领导人和跟随者崩溃的情况下加剧。跟随者的日志可能和新的领导人不同的方式。跟随者可能会丢失一些在新的领导人中有的日志条目，他也可能拥有一些领导人没有的日志条目，或者两者都发生。丢失或者多出日志条目可能会持续多个任期。这就引出了另一个部分，就是安全性。 -
安全性：选主以及日志复制并不能保证节点间数据一致。试想，当一个某个节点挂掉了，一段时间后再次重启，并当选为主节点。而在其挂掉这段时间内，集群若有超过半数节点存活，集群会正常工作，那么会有日志提交。这些提交的日志无法传递给挂掉的节点。当挂掉的节点再次当选主节点，它将缺失部分已提交的日志。在这样场景下，按Raft协议，它将自己日志复制给其他节点，会将集群已经提交的日志给覆盖掉。这显然是错误的。
其他协议解决这个问题的办法是，新当选的主节点会询问其他节点，和自己数据对比，确定出集群已提交数据，然后将缺失的数据同步过来。这个方案有明显缺陷，增加了集群恢复服务的时间（集群在选举阶段不可服务），并且增加了协议的复杂度。Raft解决的办法是，在选主逻辑中，对能够成为主的节点加以限制，确保选出的节点已定包含了集群已经提交的所有日志。如果新选出的主节点已经包含了集群所有提交的日志，那就不需要从和其他节点比对数据了。简化了流程，缩短了集群恢复服务的时间。
etcd应用场景很多，主要的有以下六种：服务发现、消息发布与订阅（配置中心）、负载均衡（集群管理）、分布式锁、分布式队列、集群监控与LEADER竞选。
服务发现（Service Discovery）要解决的是分布式系统中最常见的问题之一，即在同一个分布式集群中的进程或服务如何才能找到对方并建立连接。
从本质上说，服务发现就是想要了解集群中是否有进程在监听udp或tcp端口，并且通过名字就可以进行查找和连接。要解决服务发现的问题，需要有下面三大支柱，缺一不可。
-
一个强一致性、高可用的服务存储目录。基于Raft算法的etcd天生就是这样一个强一致性高可用的服务存储目录。
-
一种注册服务和监控服务健康状态的机制。用户可以在etcd中注册服务，并且对注册的服务设置key TTL，定时保持服务的心跳以达到监控健康状态的效果。
-
一种查找和连接服务的机制。通过在etcd指定的主题下注册的服务也能在对应的主题下查找到。为了确保连接，我们可以在每个服务机器上都部署一个proxy模式的etcd，这样就可以确保能访问etcd集群的服务都能互相连接。
在分布式系统中，最为适用的组件间通信方式是消息发布与订阅机制。
具体而言，即构建一个配置共享中心，数据提供者在这个配置中心发布消息，而消息使用者则订阅他们关心的主题，一旦相关主题有消息发布，就会实时通知订阅者。
通过这种方式可以实现分布式系统配置的集中式管理与实时动态更新。
利用etcd维护一个负载均衡节点表。etcd可以监控一个集群中多个节点的状态，当有一个请求发过来后，可以轮询式地把请求转发给存活着的多个节点。
类似KafkaMQ，通过Zookeeper来维护生产者和消费者的负载均衡。同样也可以用etcd来做Zookeeper的工作。
因为etcd使用Raft算法保持了数据的强一致性，某次操作存储到集群中的值必然是全局一致的，所以很容易实现分布式锁。
锁服务有以下两种使用方式：
-
保持独占，即所有试图获取锁的用户最终只有一个可以得到。etcd为此提供了一套实现分布式锁原子操作CAS（CompareAndSwap）的API。通过设置prevExist值，可以保证在多个节点同时创建某个目录时，只有一个成功，而该用户即可认为是获得了锁。
-
控制时序，即所有试图获取锁的用户都会进入等待队列，获得锁的顺序是全局唯一的，同时决定了队列执行顺序。etcd为此也提供了一套API（自动创建有序键），对一个目录建值时指定为POST动作，这样etcd会自动在目录下生成一个当前最大的值为键，存储这个新的值（客户端编号）。同时还可以使用API按顺序列出所有当前目录下的键值。此时这些键的值就是客户端的时序，而这些键中存储的值可以是代表客户端的编号。
在保证队列达到某个条件时再统一按顺序执行。这种方法的实现可以在/queue这个目录中另外建立一个/queue/condition节点。
-
condition可以表示队列大小。比如一个大的任务需要很多小任务就绪的情况下才能执行，每次有一个小任务就绪，就给这个condition数字加1，直到达到大任务规定的数字，再开始执行队列里的一系列小任务，最终执行大任务。
-
condition可以表示某个任务在不在队列。这个任务可以是所有排序任务的首个执行程序，也可以是拓扑结构中没有依赖的点。通常，必须执行这些任务后才能执行队列中的其他任务。
-
condition还可以表示其它的一类开始执行任务的通知。可以由控制程序指定，当condition出现变化时，开始执行队列任务。
通过etcd来进行监控实现起来非常简单并且实时性强，用到了以下两点特性。
-
Watcher机制，当某个节点消失或有变动时，Watcher会第一时间发现并告知用户。
-
节点可以设置TTL key，比如每隔30s向etcd发送一次心跳使代表该节点仍然存活，否则说明节点消失。
这样就可以第一时间检测到各节点的健康状态，以完成集群的监控要求。
-
2379和2380为etcd在IANA 的注册端口，以前为私有端口4001和7001。
| 参数 |
使用说明 |
|---|---|
| --name 'default’ |
本member的名字 |
| --data-dir '${name}.etcd’ |
指定节点的数据存储目录，这些数据包括节点ID，集群ID，集群初始化配置，Snapshot文件，若未指定-wal-dir，还会存储WAL文件；如果不指定会用缺省目录。 |
| --listen-peer-urls http://0.0.0.0:2380 |
本member侧使用，用于监听其他member发送信息的地址。ip为全0代表监听本member侧所有接口 |
| --listen-client-urls http://0.0.0.0:2379 |
本member侧使用，用于监听etcd客户发送信息的地址。ip为全0代表监听本member侧所有接口 |
| --wal-dir ‘path’ |
到专用wal目录的路径 |
| --snapshot-count ‘100000’ |
number of committed transactions to trigger a snapshot to disk |
| --heartbeat-interval ‘100’ |
检测间隔的时间(毫秒) |
| --election-timeout ‘1000’ |
超时时间(毫秒) |
| --initial-election-tick-advance ‘true’ |
是否提前初始化选举时钟启动，以便更快的选举 |
| --max-snapshots ‘5’ |
要保留的最大快照文件数(0是无限的) |
| --max-wals ‘5’ |
要保留的最大wal文件数(0是无限的) |
| --cors ‘’ |
comma-separated whitelist of origins for CORS (cross-origin resource sharing) |
| --quota-backend-bytes ‘0’ |
当后端大小超过给定限额时发出警报(0默认为低空间限额) |
| --max-txn-ops ‘128’ |
事务中允许的最大操作数 |
| --max-request-bytes ‘1572864’ |
服务器将接受的最大客户端请求大小(以字节为单位) |
| --grpc-keepalive-min-time ‘5s’ |
客户端在ping服务器之前应该等待的最小持续时间间隔 |
| --grpc-keepalive-interval ‘2h’ |
检查连接是否激活的服务器到客户机ping的频率持续时间(0表示禁用) |
| --grpc-keepalive-timeout ‘20s’ |
关闭无响应连接之前的额外等待时间(0表示禁用) |
| 参数 |
使用说明 |
|---|---|
| --initial-advertise-peer-urls 'http://localhost:2380’ |
其他member使用，其他member通过该地址与本member交互信息。一定要保证从其他member能可访问该地址。静态配置方式下，该参数的value一定要同时在–initial-cluster参数中存在。 |
| --initial-cluster 'etcd01=http://localhost01:2380, |
本member侧使用。描述集群中所有节点的信息，本member根据此信息去联系其他member。 |
| --initial-cluster-state 'new’ |
用于指示本次是否为新建集群。有两个取值new和existing。如果填为existing，则该member启动时会尝试与其他member交互。集群初次建立时，要填为new，经尝试最后一个节点填existing也正常，其他节点不能填为existing。集群运行过程中，一个member故障后恢复时填为existing，经尝试填为new也正常。 |
| --initial-cluster-token 'etcd-cluster’ |
引导期间etcd集群的初始集群令牌。 |
| --advertise-client-urls 'http://localhost:2379’ |
etcd客户使用，客户通过该地址与本member交互信息。一定要保证从客户侧能可访问该地址 |
| --discovery ’ ’ |
用于引导集群的发现URL，指定第三方etcd上key地址，要建立的集群各member都会向其注册自己的地址 |
| --enable-v2 ‘true’ |
接受etcd V2客户端请求 |
| --discovery-fallback ‘proxy’ |
当发现服务失败时的预期行为(“exit”或“proxy”)。“proxy”只支持v2 API |
| --discovery-proxy ’ ’ |
用于传输到发现服务的HTTP代理 |
| --discovery-srv ’ ’ |
用于引导集群的dns srv域 |
| --strict-reconfig-check ‘true’ |
拒绝可能导致仲裁丢失的重新配置请求 |
| --auto-compaction-retention ‘0’ |
auto compaction retention length. 0 means disable auto compaction |
| --auto-compaction-mode ‘periodic’ |
interpret ‘auto-compaction-retention’ one of: periodic丨revision. ‘periodic’ for duration based retention, defaulting to hours if no time unit is provided (e.g. ‘5m’). ‘revision’ for revision number based retention. |
-
注意：“proxy” supports v2 API only.
| 参数 |
使用说明 |
|---|---|
| --proxy ‘off’ |
proxy mode setting (‘off’, ‘readonly’ or ‘on’). |
| --proxy-failure-wait 5000 |
time (in milliseconds) an endpoint will be held in a failed state |
| --proxy-refresh-interval 30000 |
time (in milliseconds) of the endpoints refresh interval |
| --proxy-dial-timeout 1000 |
time (in milliseconds) for a dial to timeout |
| --proxy-write-timeout 5000 |
time (in milliseconds) for a write to timeout. |
| --proxy-read-timeout 0 |
time (in milliseconds) for a read to timeout. |
| 参数 |
使用说明 |
|---|---|
| --ca-file ’ ’ [DEPRECATED] |
客户端服务器TLS CA文件的路径。“-ca-file ca.crt”可以替换为“-trusted-ca-file ca.crt -client-cert-auth”，etcd将执行相同的操作。 |
| --cert-file ’ ’ |
客户端服务器TLS证书文件的路径 |
| --key-file ‘’ |
客户端服务器TLS密钥文件的路径 |
| --client-cert-auth ‘false’ |
启用客户证书认证 |
| --client-crl-file ’ ’ |
客户端证书撤销列表文件的路径 |
| --trusted-ca-file ’ ’ |
客户端服务器TLS信任CA证书文件的路径 |
| --auto-tls ‘false’ |
客户端TLS使用生成的证书 |
| --peer-ca-file ’ ’ [DEPRECATED] |
path to the peer server TLS CA file. ‘-peer-ca-file ca.crt’ could be replaced by ‘-peer-trusted-ca-file ca.crt -peer-client-cert-auth’ and etcd will perform the same. |
| --peer-cert-file ’ ’ |
path to the peer server TLS cert file. |
| --peer-key-file ’ ’ |
path to the peer server TLS key file. |
| --peer-client-cert-auth ‘false’ |
enable peer client cert authentication. |
| --peer-trusted-ca-file ’ ’ |
path to the peer server TLS trusted CA file. |
| --peer-auto-tls ‘false’ |
peer TLS using self-generated certificates if --peer-key-file and --peer-cert-file are not provided. |
| --peer-crl-file ’ ’ |
path to the peer certificate revocation list file. |
| 参数 |
使用说明 |
|---|---|
| --debug ‘false’ |
enable debug-level logging for etcd. |
| --log-package-levels ’ ’ |
为每个etcd包指定一个特定的日志级别(例如:‘etcdmain=CRITICAL,etcdserver=DEBUG’)。 |
| --log-output ‘default’ |
指定“stdout”或“stderr”以跳过日志记录，即使在systemd下运行时也是如此。 |
-
在使用不安全标志时请小心，因为它会破坏保证根据协商一致协议。
| 参数 |
使用说明 |
|---|---|
| --force-new-cluster ‘false’ |
强制创建一个新的单成员集群。 |
| 参数 |
使用说明 |
|---|---|
| --auth-token ‘simple’ |
指定v3认证令牌类型及其选项(‘simple’或’jwt’). |
| 参数 |
使用说明 |
|---|---|
| --enable-pprof ‘false’ |
Enable runtime profiling data via HTTP server. Address is at client URL + “/debug/pprof/” |
| --metrics ‘basic’ |
Set level of detail for exported metrics, specify ‘extensive’ to include histogram metrics. |
| --listen-metrics-urls ’ ’ |
List of URLs to listen on for metrics. |
| 参数 |
使用说明 |
|---|---|
| --experimental-initial-corrupt-check ‘false’ |
enable to check data corruption before serving any client/peer traffic. |
| --experimental-corrupt-check-time ‘0s’ |
duration of time between cluster corruption check passes. |
| --experimental-enable-v2v3 ’ ’ |
serve v2 requests through the v3 backend under a given prefix. |
etcd最新的API版本是v3，与v2相比，v3更高效更清晰。k8s默认使用的etcd V3版本API，ectdctl默认使用V2版本API。要使用v3，设置环境变量export ETCDCTL_API=3临时更改为V3或者vim /etc/profile后在里面添加export ETCDCTL_API=3，然后执行source /etc/profile则永久更改为V3。
-
使用v3或v2命令也可在命令前带上ETCDCTL_API=3或 ETCDCTL_API=2
-
加密的方式：ETCDCTL_API=3 etcdctl \
--endpoints=https://172.xxx.xx.xx:2379 \
--cacert=/etc/kubernetes/cert/ca.pem \
--cert=/etc/etcd/cert/etcd.pem \
--key=/etc/etcd/cert/etcd-key.pem
version
| 命令 |
用法 |
说明 |
可选参数 |
|---|---|---|---|
|
|
USAGE： |
获取一个或一个范围内的键<key>和键值<value> |
OPTIONS: |
|
|
USAGE： |
设置键<key>和键值<value> |
OPTIONS: |
|
|
USAGE： |
删除键[key]和键值[value] |
OPTIONS: |
| txn |
USAGE：etcdctl txn [options] |
Txn处理一个事务中的所有请求 |
OPTIONS: |
| compaction |
USAGE： |
压缩etcd中的事件历史记录 |
OPTIONS: |
| alarm disarm |
USAGE：etcdctl alarm disarm |
解除所有警报 |
- |
| alarm list |
USAGE：etcdctl alarm list |
列出所有警报 |
- |
| defrag |
USAGE：etcdctl defrag |
使用给定端点对etcd成员的存储进行碎片整理 |
OPTIONS: |
|
|
USAGE：etcdctl endpoint health |
检查 |
- |
|
|
USAGE：etcdctl endpoint status |
打印出 |
- |
|
|
USAGE：etcdctl endpoint hashkv |
在–endpoints中为每个端点打印KV历史记录 |
OPTIONS: |
|
|
USAGE： |
将领导转移到另一个etcd集群成员 |
- |
|
|
USAGE： |
在键或前缀上观察事件流,当监视到时可以执行相应命令 |
OPTIONS: |
|
|
USAGE：etcdctl version |
输出版本号 |
- |
| lease grant |
USAGE：etcdctl lease grant <ttl> |
创造租约,可以为key设置超时时间后自动删除key |
- |
| lease revoke |
USAGE：etcdctl lease revoke <leaseID> |
撤销租约 ，并删除所有关联的key |
- |
| lease timetolive |
USAGE： |
获取租赁信息 |
OPTIONS: |
| lease list |
USAGE：etcdctl lease list |
列出所有有效租约 |
- |
| lease keep-alive |
USAGE： |
让租约保持活力（续订） |
OPTIONS: |
|
|
USAGE： |
添加一个成员到集群 |
OPTIONS: |
|
|
USAGE： |
从集群中删除一个成员 |
- |
|
|
USAGE： |
在集群中更新一个成员 |
OPTIONS: |
|
|
USAGE：etcdctl member list |
显示集群内所有成员 |
- |
| snapshot save |
USAGE： |
将etcd节点后端快照存储到给定文件 |
- |
| snapshot restore |
USAGE： |
将etcd成员快照还原到etcd目录 |
OPTIONS: |
| snapshot status |
USAGE： |
获取给定文件的后端快照状态 |
- |
| make-mirror |
USAGE： |
在目标etcd集群中创建镜像 |
OPTIONS: |
| migrate |
USAGE：etcdctl migrate |
将v2存储中的密钥迁移到mvcc存储 |
OPTIONS: |
| lock |
USAGE： |
获取一个命名锁 |
OPTIONS: |
| elect |
USAGE： |
观察并参与领导人选举 |
OPTIONS: |
|
|
USAGE：etcdctl auth enable |
启用身份认证 |
- |
|
|
USAGE：etcdctl auth disable |
禁用身份认证 |
- |
|
|
USAGE： |
添加一个新用户 |
OPTIONS: |
|
|
USAGE： |
删除一个用户 |
- |
|
|
USAGE： |
获取用户的详细信息 |
OPTIONS: |
|
|
USAGE：etcdctl user list |
显示所有用户 |
- |
|
|
USAGE： |
更改用户密码 |
OPTIONS: |
|
|
USAGE： |
授予用户角色 |
- |
|
|
USAGE： |
撤消用户的角色 |
- |
|
|
USAGE：etcdctl role add <role name> |
添加新角色 |
- |
|
|
USAGE：etcdctl role delete <role name> |
删除一个角色 |
- |
|
|
USAGE：etcdctl role get <role name> |
获取角色的详细信息 |
- |
|
|
USAGE：etcdctl role list |
显示所有角色 |
- |
| role grant-permission |
USAGE： |
授予钥密给角色 |
OPTIONS: |
| role revoke-permission |
USAGE： |
从角色中撤消密钥 |
OPTIONS: |
| check perf |
USAGE：etcdctl check perf [options] |
检查etcd集群的性能 |
OPTIONS: |
| help |
USAGE：etcdctl help [command] |
帮助信息 |
- |
| 全局参数 |
说明 |
|---|---|
| --cacert="" |
使用CA包验证启用了tls的安全服务器的证书 |
| --cert="" |
使用此TLS证书文件识别安全客户端 |
| --command-timeout=5s |
短时间运行命令超时(不包括拨号超时) |
| --debug[=false] |
启用客户端调试日志记录 |
| --dial-timeout=2s |
客户端连接的拨号超时 |
| -d, --discovery-srv="" |
要查询描述集群端点的SRV记录的域名 |
| --endpoints=[127.0.0.1:2379] |
gRPC端点 |
| --hex[=false] |
将字节字符串打印为十六进制编码的字符串 |
| --insecure-discovery[=true] |
接受描述集群端点的不安全SRV记录 |
| --insecure-skip-tls-verify[=false] |
跳过服务器证书验证 |
| --insecure-transport[=true] |
为客户端连接禁用传输安全性 |
| --keepalive-time=2s |
保持客户端连接的存活时间 |
| --keepalive-timeout=6s |
保持客户端连接的超时 |
| --key="" |
使用此TLS密钥文件识别安全客户端 |
| --user="" |
用于身份验证的用户名[:password](如果没有提供密码，则提示) |
| -w, --write-out=“simple” |
设置输出格式 (fields, json, protobuf, simple, table) |
本次搭建的基础环境：操作系统centos7（已安装docker）
首先在服务器上先下载最新的etcd镜像，可在docker Hub官网上搜索etcd，寻找最新的etcd镜像下载。
本次使用的镜像是quay.io/coreos/etcd；
可在操作系统上执行docker pull quay.io/coreos/etcd来下载镜像，如下图所示：
-
接下来我采用了如下两种方式来创建集群：
-
将三个服务器挨个添加进集群
-
将三个服务器统一添加进集群
-
1.在服务器A(172.27.0.42)上运行一个ETCD实例，取名为etcd01，注意其状态为new，“-initial-cluster”中只有自己的IP：
docker run -d -p 2379:2379 -p 2380:2380 --name etcd01 quay.io/coreos/etcd:latest etcd --name etcd01 --advertise-client-urls http://172.27.0.42:2379 --listen-client-urls http://0.0.0.0:2379 --initial-advertise-peer-urls http://172.27.0.42:2380 --listen-peer-urls http://0.0.0.0:2380 --initial-cluster-token etcd-cluster --initial-cluster etcd01=http://172.27.0.42:2380 --initial-cluster-state new
2.在服务器A的ETCD服务上，通过调用API添加一个新的节点B（172.27.0.16）：
curl http://127.0.0.1:2379/v2/members -XPOST -H “Content-Type: application/json” -d ‘{“peerURLs”: [“http://172.27.0.16:2380”]}’
3.在服务器B（172.27.0.16）上运行一个ETCD实例，取名为etcd02，注意其状态为existing，“-initial-cluster”中有前一个IP及自己的IP：
docker run -d -p 2379:2379 -p 2380:2380 --name etcd02 quay.io/coreos/etcd:latest etcd --name etcd02 --advertise-client-urls http://172.27.0.16:2379 --listen-client-urls http://0.0.0.0:2379 --initial-advertise-peer-urls http://172.27.0.16:2380 --listen-peer-urls http://0.0.0.0:2380 --initial-cluster-token etcd-cluster --initial-cluster etcd01=http://172.27.0.42:2380,etcd02=http://172.27.0.16:2380 --initial-cluster-state existing
4.在服务器A的ETCD服务上，通过调用API添加一个新的节点C（172.27.0.39）：
curl http://127.0.0.1:2379/v2/members -XPOST -H “Content-Type: application/json” -d ‘{“peerURLs”: [“http://172.27.0.39:2380”]}’
5.在服务器C（172.27.0.39）上运行一个ETCD实例，取名为etcd03，注意其状态为existing，“-initial-cluster”中有前一个IP及自己的IP：
docker run -d -p 2379:2379 -p 2380:2380 --name etcd03 quay.io/coreos/etcd:latest etcd --name etcd03 --advertise-client-urls http://172.27.0.39:2379 --listen-client-urls http://0.0.0.0:2379 --initial-advertise-peer-urls http://172.27.0.39:2380 --listen-peer-urls http://0.0.0.0:2380 --initial-cluster-token etcd-cluster --initial-cluster etcd01=http://172.27.0.42:2380,etcd02=http://172.27.0.16:2380,etcd03=http://172.27.0.39:2380 --initial-cluster-state existing
-
注意：“-initial-cluster”中包含所有节点的IP，状态均为new；
A(172.27.0.42)上执行：
docker run -d -p 2379:2379 -p 2380:2380 --name etcd01 quay.io/coreos/etcd:latest etcd --name etcd01 --advertise-client-urls http://172.27.0.42:2379 --listen-client-urls http://0.0.0.0:2379 --initial-advertise-peer-urls http://172.27.0.42:2380 --listen-peer-urls http://0.0.0.0:2380 --initial-cluster-token etcd-cluster --initial-cluster etcd01=http://172.27.0.42:2380,etcd02=http://172.27.0.16:2380,etcd03=http://172.27.0.39:2380 --initial-cluster-state new
B（172.27.0.16）上执行：
docker run -d -p 2379:2379 -p 2380:2380 --name etcd02 quay.io/coreos/etcd:latest etcd --name etcd02 --advertise-client-urls http://172.27.0.16:2379 --listen-client-urls http://0.0.0.0:2379 --initial-advertise-peer-urls http://172.27.0.16:2380 --listen-peer-urls http://0.0.0.0:2380 --initial-cluster-token etcd-cluster --initial-cluster etcd01=http://172.27.0.42:2380,etcd02=http://172.27.0.16:2380,etcd03=http://172.27.0.39:2380 --initial-cluster-state new
C（172.27.0.39）上执行：
docker run -d -p 2379:2379 -p 2380:2380 --name etcd03 quay.io/coreos/etcd:latest etcd --name etcd03 --advertise-client-urls http://172.27.0.39:2379 --listen-client-urls http://0.0.0.0:2379 --initial-advertise-peer-urls http://172.27.0.39:2380 --listen-peer-urls http://0.0.0.0:2380 --initial-cluster-token etcd-cluster --initial-cluster etcd01=http://172.27.0.42:2380,etcd02=http://172.27.0.16:2380,etcd03=http://172.27.0.39:2380 --initial-cluster-state new
两种方法部署的etcd可通过以下方式进行验证是否成功：
1.验证集群members，在集群中的每台机器上查看members，得出的结果应该是相同的；
curl -L http://127.0.0.1:2379/v2/members
2.可在任一服务器上进入etcd容器执行命令etcdctl member list或etcdctl cluster-health验证；
3.某台机器上添加数据，其他机器上查看数据，得出的结果应该是相同的，例如：
A上执行：curl -L http://127.0.0.1:2379/v2/keys/message -XPUT -d value=“Hello World”
B、C上执行：curl -L http://127.0.0.1:2379/v2/keys/message
环境：
| 服务器名称 |
服务器ip |
|---|---|
| etcd01 |
172.27.18.9 |
| etcd02 |
172.27.17.220 |
| etcd03 |
172.27.16.105 |
安装方式：
-
通过下载etcd安装包安装，可执行wget https://github.com/etcd-io/etcd/releases/download/v3.3.13/etcd-v3.3.13-linux-amd64.tar.gz
-
linux系统一般都有自带etcd安装包，可直接使用yum安装，如yum install etcd -y
目前我这里采用的是直接通过yum install etcd -y 安装， yum安装的etcd默认的配置文件为/etc/etcd/etcd.conf，文件如下：
<span style="color:#000000"><code>[root@VM_18_9_centos /]# cat /etc/etcd/etcd.conf
#[Member]
#ETCD_CORS=""
ETCD_DATA_DIR="/var/lib/etcd/default.etcd"
#ETCD_WAL_DIR=""
#ETCD_LISTEN_PEER_URLS="http://localhost:2380"
ETCD_LISTEN_CLIENT_URLS="http://localhost:2379"
#ETCD_MAX_SNAPSHOTS="5"
#ETCD_MAX_WALS="5"
ETCD_NAME="default"
#ETCD_SNAPSHOT_COUNT="100000"
#ETCD_HEARTBEAT_INTERVAL="100"
#ETCD_ELECTION_TIMEOUT="1000"
#ETCD_QUOTA_BACKEND_BYTES="0"
#ETCD_MAX_REQUEST_BYTES="1572864"
#ETCD_GRPC_KEEPALIVE_MIN_TIME="5s"
#ETCD_GRPC_KEEPALIVE_INTERVAL="2h0m0s"
#ETCD_GRPC_KEEPALIVE_TIMEOUT="20s"
#
#[Clustering]
#ETCD_INITIAL_ADVERTISE_PEER_URLS="http://localhost:2380"
ETCD_ADVERTISE_CLIENT_URLS="http://localhost:2379"
#ETCD_DISCOVERY=""
#ETCD_DISCOVERY_FALLBACK="proxy"
#ETCD_DISCOVERY_PROXY=""
#ETCD_DISCOVERY_SRV=""
#ETCD_INITIAL_CLUSTER="default=http://localhost:2380"
#ETCD_INITIAL_CLUSTER_TOKEN="etcd-cluster"
#ETCD_INITIAL_CLUSTER_STATE="new"
#ETCD_STRICT_RECONFIG_CHECK="true"
#ETCD_ENABLE_V2="true"
#
#[Proxy]
#ETCD_PROXY="off"
#ETCD_PROXY_FAILURE_WAIT="5000"
#ETCD_PROXY_REFRESH_INTERVAL="30000"
#ETCD_PROXY_DIAL_TIMEOUT="1000"
#ETCD_PROXY_WRITE_TIMEOUT="5000"
#ETCD_PROXY_READ_TIMEOUT="0"
#
#[Security]
#ETCD_CERT_FILE=""
#ETCD_KEY_FILE=""
#ETCD_CLIENT_CERT_AUTH="false"
#ETCD_TRUSTED_CA_FILE=""
#ETCD_AUTO_TLS="false"
#ETCD_PEER_CERT_FILE=""
#ETCD_PEER_KEY_FILE=""
#ETCD_PEER_CLIENT_CERT_AUTH="false"
#ETCD_PEER_TRUSTED_CA_FILE=""
#ETCD_PEER_AUTO_TLS="false"
#
#[Logging]
#ETCD_DEBUG="false"
#ETCD_LOG_PACKAGE_LEVELS=""
#ETCD_LOG_OUTPUT="default"
#
#[Unsafe]
#ETCD_FORCE_NEW_CLUSTER="false"
#
#[Version]
#ETCD_VERSION="false"
#ETCD_AUTO_COMPACTION_RETENTION="0"
#
#[Profiling]
#ETCD_ENABLE_PPROF="false"
#ETCD_METRICS="basic"
#
#[Auth]
#ETCD_AUTH_TOKEN="simple"
[root@VM_18_9_centos /]#
</code></span>在etcd01（172.27.18.9）修改etcd.conf启动参数，执行vim /etc/etcd/etcd.conf来修改，修改内容如下：
<span style="color:#000000"><code>ETCD_DATA_DIR="/data/etcd.etcd" # 存放etcd数据的路径，注意使用新目录时需要先创建该目录
ETCD_LISTEN_CLIENT_URLS="http://0.0.0.0:2379" # 监听的用于客户端通信的url,同样可以监听多个。
ETCD_NAME="etcd01" # etcd集群中的节点名，这里可以随意，可区分且不重复就行
ETCD_LISTEN_PEER_URLS="http://0.0.0.0:2380" # 监听的用于节点之间通信的url，可监听多个，集群内部将通过这些url进行数据交互(如选举，数据同步等)
ETCD_INITIAL_ADVERTISE_PEER_URLS="http://172.27.18.9:2380" # 建议用于节点之间通信的url，节点间将以该值进行通信。
ETCD_ADVERTISE_CLIENT_URLS="http://172.27.18.9:2379" # 建议使用的客户端通信url,该值用于etcd代理或etcd成员与etcd节点通信。
ETCD_INITIAL_CLUSTER="etcd01=http://172.27.18.9:2380,etcd02=http://172.27.17.220:2380,etcd03=http://172.27.16.105:2380" # 也就是集群中所有的initial-advertise-peer-urls 的合集
ETCD_INITIAL_CLUSTER_TOKEN="etcd-cluster" # 节点的token值，设置该值后集群将生成唯一id,并为每个节点也生成唯一id,当使用相同配置文件再启动一个集群时，只要该token值不一样，etcd集群就不会相互影响。
ETCD_INITIAL_CLUSTER_STATE="new" # 新建集群的标志，初始化状态使用 new，建立之后改此值为 existing
</code></span>修改完etcd.conf文件后还需要修改/usr/lib/systemd/system/etcd.service服务文件的ExecStart部分，与etcd.conf修改的相对应，修改内容如下所示：
<span style="color:#000000"><code>[Unit]
Description=Etcd Server
After=network.target
After=network-online.target
Wants=network-online.target
[Service]
Type=notify
WorkingDirectory=/var/lib/etcd/
EnvironmentFile=-/etc/etcd/etcd.conf
ExecStart=/bin/bash -c "GOMAXPROCS=$(nproc) /usr/bin/etcd \
--name=${ETCD_NAME} \
--listen-client-urls=${ETCD_LISTEN_CLIENT_URLS} \
--listen-peer-urls=${ETCD_LISTEN_PEER_URLS} \
--advertise-client-urls=${ETCD_ADVERTISE_CLIENT_URLS} \
--initial-advertise-peer-urls=${ETCD_INITIAL_ADVERTISE_PEER_URLS} \
--initial-cluster=${ETCD_INITIAL_CLUSTER} \
--initial-cluster-token=${ETCD_INITIAL_CLUSTER_TOKEN} \
--initial-cluster-state=new"
User=etcd
Restart=on-failure
LimitNOFILE=65536
[Install]
WantedBy=multi-user.target
</code></span> 然后执行systemctl start etcd.service启动服务，然后执行etcdctl member listf返回类似如下信息则配置成功；
etcd02、etcd03服务器部署同etcd01一致，只需要把ETCD_NAME、ETCD_ADVERTISE_CLIENT_URLS和ETCD_INITIAL_ADVERTISE_PEER_URLS换成etcd02或etcd03的配置即可；
-
注意：如执行etcdctl member listf报错如下，则是因为ETCD_LISTEN_CLIENT_URLS没有配置http://127.0.0.1:2379与本机自己进行通信导致的，配上后重启etcd服务即可。
本文仅是个人学习时的整理收藏，以便回顾所用，内容均来源其它处。
[参考文档]https://www.cnblogs.com/datacoding/p/7473953.html
[参考文档]https://blog.csdn.net/yasonan/article/details/54945066
[参考文档]https://www.kubernetes.org.cn/tags/etcd
五、kubernetes命令行工具kubectl详解
kubectl是Kubernetes集群的命令行工具，通过kubectl能够对集群本身进行管理，并能够在集群上进行容器化应用的安装部署。运行kubectl命令的语法如下所示：
kubectl [command] [TYPE] [NAME] [flags]
注意：在一个命令行中也可以同时对多个资源对象进行操作，以多个TYPE和NAME的组合表示。
示例如下：
1.获取多个Pod的信息：kubectl get pods pod1 pod2
2.获取多种对象的信息：kubectl get pod/pod1 rc/rc1
3.同时应用多个yaml文件，以多个-f file参数表示：kubectl create -f pod1.yaml -f rc1.yaml -f service1.yaml
-
comand：指定要对资源执行的操作。例如create、get、describe、delete、log、exec等等；
-
TYPE：指定资源类型，资源类型是大小学敏感的，开发者能够以单数、复数和缩略的形式。如node、pod、deployment、namespaces等等；
-
NAME：资源对象的名称，区分大小写。如果不指定名称，则系统将返回属于TYPE的全部对象的列表，例如$ kubectl get pods将返回所有Pod的列表。
-
flags：kubectl子命令的可选参数，例如使用“-s”指定apiserver的URL地址而不用默认值。
在kubernetes中，提供了很多的资源对象，开发和运维人员可以通过这些对象对容器进行编排。在下表中，是kubectl所支持的资源对象类型，以及它们的缩略别名：
| 资源对象类型 |
缩略别名 |
|---|---|
| apiservices |
- |
| certificatesigningrequests |
csr |
| clusterrolebindings |
- |
| clusters |
- |
|
|
cs |
|
|
cm |
| controllerrevisions |
- |
|
|
- |
| customresourcedefinition |
crd |
|
|
ds |
|
|
deploy |
|
|
ep |
|
|
ev |
|
|
hpa |
|
|
ing |
|
|
- |
| limitranges |
limits |
|
|
ns |
| networkpolicies |
netpol |
|
|
no |
|
|
pvc |
|
|
pv |
| poddisruptionbudget |
pdb |
| podpreset |
- |
|
|
po |
| podsecuritypolicies |
psp |
| podtemplates |
- |
|
|
rs |
|
|
rc |
|
|
quota |
| rolebindings |
- |
| roles |
- |
|
|
- |
| serviceaccounts |
sa |
|
|
svc |
|
|
- |
|
|
- |
kubectl作为kubernetes的命令行工具，主要的职责就是对集群中的资源的对象进行操作，这些操作包括对资源对象的创建、删除和查看等。下表中显示了kubectl支持的所有操作，以及这些操作的语法和描述信息：
注意：每个命令的具体使用可以使用kubectl [command] -h进行查看。设置kubectl命令自动补充source <(kubectl completion bash)。
-
基础命令
| 命令 |
语法 |
描述 |
|---|---|---|
|
|
kubectl create -f FILENAME [options] |
从文件或stdin中创建一个或多个资源对象 |
|
|
kubectl expose (-f FILENAME | TYPE NAME) [ --port=port] [ --protocol=TCP |UDP|SCTP] [ --target-port=number-or-name][ --name=name] [ --external-ip=external-ip-of-service] [ --type=type] [options] |
将rc,svc,deploy,pod暴露为一个新的svc |
|
|
kubectl run NAME --image=image [ --env=“key=value”] [ --port=port] [ --replicas=replicas] [ --dry-run=bool] [ --overrides=inline-json] [ --command] --[COMMAND] [args…] [options] |
在集群上运行一个指定的镜像 |
| set |
kubectl set SUBCOMMAND [options] |
更改现有的应用程序资源，SUBCOMMAND包括 |
|
|
kubectl explain RESOURCE [options] |
查询资源的文档 |
|
|
kubectl get [(-o| --output=)json|yaml|wide|custom-columns=…|custom-columns-file=…|go-template=…|go-template-file=…|jsonpath=…|jsonpath-file=…](TYPE[.VERSION][.GROUP] [NAME | -l label] | TYPE[.VERSION][.GROUP]/NAME …) [flags] [options] |
查询一个或者多个资源 |
|
|
kubectl edit (RESOURCE/NAME | -f FILENAME) [options] |
通过默认编辑器编辑和更新服务器上的一个或多个资源对象 |
|
|
kubectl delete ([-f FILENAME] | [-k DIRECTORY] | TYPE [(NAME | -l label | --all)]) [options] |
删除资源对象 |
-
部署命令
| 命令 |
语法 |
描述 |
|---|---|---|
|
|
kubectl rollout SUBCOMMAND [options] |
管理资源的部署, |
|
|
kubectl rolling-update OLD_CONTROLLER_NAME([NEW_CONTROLLER_NAME] --image=NEW_CONTAINER_IMAGE | -f NEW_CONTROLLER_SPEC) [options] |
通过逐步替换指定的副本控制器和Pod来执行滚动更新 |
|
|
kubectl scale [ --resource-version=version] [ --current-replicas=count] --replicas=COUNT (-f FILENAME | TYPE NAME)[options] |
扩宿容副本集的数量 |
|
|
kubectl autoscale (-f FILENAME | TYPE NAME | TYPE/NAME) [ --min=MINPODS] --max=MAXPODS [ --cpu-percent=CPU] [options] |
自动扩宿容由副本控制器管理的Pod |
-
集群管理命令
| 命令 |
语法 |
描述 |
|---|---|---|
| certificate |
kubectl certificate SUBCOMMAND [options] |
修改证书资源， |
|
|
kubectl cluster-info [flags] [options] |
显示群集中的主节点和服务的的端点信息 |
|
|
kubectl top [flags] [options] |
显示node或pod资源(CPU/内存/存储)使用情况 |
|
|
kubectl cordon NODE [options] |
将node标记为不可调度 |
|
|
kubectl uncordon NODE [options] |
将node标记为可调度 |
|
|
kubectl drain NODE [options] |
驱逐节点，准备维护 |
|
|
kubectl taint NODE NAME KEY_1=VAL_1:TAINT_EFFECT_1 … KEY_N=VAL_N:TAINT_EFFECT_N [options] |
更新一个或多个节点上的污点 |
-
故障排除和调试命令
| 命令 |
语法 |
描述 |
|---|---|---|
|
|
kubectl describe (-f FILENAME | TYPE [NAME_PREFIX | -l label] | TYPE/NAME) [options] |
显示一个或者多个资源对象的详细信息 |
|
|
kubectl logs [-f] [-p] (POD | TYPE/NAME) [-c CONTAINER] [options] |
显示Pod中一个容器的日志 |
|
|
kubectl attach (POD | TYPE/NAME) -c CONTAINER [options] |
连接到正在运行的容器上，以查看输出流或与容器交互（stdin）。 |
|
|
kubectl exec (POD | TYPE/NAME) [-c CONTAINER] [flags] --COMMAND [args…] [options] |
在Pod的容器中执行一个命令 |
| port-forward |
kubectl port-forward TYPE/NAME [options] [LOCAL_PORT:]REMOTE_PORT […[LOCAL_PORT_N:]REMOTE_PORT_N] |
将一个或多个本地端口转发到Pod |
| proxy |
kubectl proxy [ --port=PORT] [ --www=static-dir] [ --www-prefix=prefix] [ --api-prefix=prefix] [options] |
为kubernetes API服务器运行一个代理 |
| cp |
kubectl cp <file-spec-src> <file-spec-dest> [options] |
从容器中复制文件和目录 |
| auth |
kubectl auth [flags] [options] |
检查授权 |
-
高级命令
| 命令 |
语法 |
描述 |
|---|---|---|
| diff |
kubectl diff -f FILENAME [options] |
Diff live version against would-be applied version |
|
|
kubectl apply (-f FILENAME | -k DIRECTORY) [options] |
将来自于文件或stdin的配置变更应用到主要对象中 |
|
|
kubectl patch (-f FILENAME | TYPE NAME) -p PATCH [options] |
使用策略合并补丁过程更新资源对象中的一个或多个字段 |
|
|
kubectl replace -f FILENAME [options] |
从文件或stdin中替换资源对象 |
|
|
kubectl wait ([-f FILENAME] | resource.group/resource.name | resource.group [(-l label | --all)]) [ --for=delete| --for condition=available] [options] |
等待一个或多个资源上的特定条件 |
| convert |
kubectl convert -f FILENAME [options] |
将配置文件转换为不同的API Version |
| kustomize |
kubectl kustomize <dir> [flags] [options] |
从目录或远程url构建kustomization目标 |
-
设置命令
| 命令 |
语法 |
描述 |
|---|---|---|
|
|
kubectl label [ --overwrite] (-f FILENAME | TYPE NAME) KEY_1=VAL_1 … KEY_N=VAL_N [ --resource-version=version][options] |
添加或更新一个或者多个资源对象的标签 |
|
|
kubectl annotate [ --overwrite] (-f FILENAME | TYPE NAME) KEY_1=VAL_1 … KEY_N=VAL_N [ --resource-version=version][options] |
添加或更新一个或多个资源的注释 |
| completion |
kubectl completion SHELL [options] |
输出指定shell的代码完成命令 (bash or zsh) |
-
其它命令
| 命令 |
语法 |
描述 |
|---|---|---|
|
|
kubectl api-resources [flags] [options] |
在服务器上打印支持的API资源 |
|
|
kubectl api-versions [flags] [options] |
在服务器上以“group/version”的形式打印支持的API版本 |
|
|
kubectl config SUBCOMMAND [options] |
修改kubeconfig文件, |
| plugin |
kubectl plugin [flags] [options] |
提供与插件交互的实用程序 |
|
|
kubectl version [flags] [options] |
输出client和server的版本信息 |
-
global options
以下选项可以传递给任何命令:
| 全局参数 |
描述 |
|---|---|
| --add-dir-header=false |
如果为真，则将文件目录添加到标头 |
| --alsologtostderr=false |
日志到标准错误以及文件 |
| --as=’’ |
模拟操作的用户名 |
| --as-group=[] |
集团的模拟操作,这个标志可以重复指定多个组。 |
| --cache-dir=’/root/.kube/http-cache’ |
默认HTTP cache目录 |
| --certificate-authority=’’ |
指向证书颁发机构的证书文件的路径 |
| --client-certificate=’’ |
TLS客户端证书文件的路径 |
| --client-key=’’ |
TLS的客户端密钥文件的路径 |
| --cluster=’’ |
要使用的kubeconfig集群的名称 |
| --context=’’ |
The name of the kubeconfig context to use |
| --insecure-skip-tls-verify=false |
如果为真，将不检查服务器的证书的有效性。这将使您的HTTPS连接不安全 |
| --kubeconfig=’’ |
用于CLI请求的kubeconfig文件的路径。 |
| --log-backtrace-at=:0 |
当日志记录命中行文件N时，发出堆栈跟踪 |
| --log-dir=’’ |
如果非空，则在此目录中写入日志文件 |
| --log-file=’’ |
如果非空，则使用此日志文件 |
| --log-file-max-size=1800 |
定义日志文件可以增长到的最大大小。单位是字节。如果该值为0，则最大文件大小不受限制。 |
| --log-flush-frequency=5s |
日志刷新之间的最大秒数 |
| --logtostderr=true |
日志到标准错误而不是文件 |
| --match-server-version=false |
要求服务器版本与客户端版本匹配 |
| -n, --namespace=’’ |
如果存在，此CLI请求的名称空间范围 |
| --password=’’ |
API服务器的基本身份验证密码 |
| --profile=‘none’ |
要捕获的配置文件的名称,可设置(none|cpu|heap|goroutine|threadcreate|block|mutex) |
| --profile-output=‘profile.pprof’ |
要写入概要文件的文件名称 |
| --request-timeout=‘0’ |
在放弃单个服务器请求之前等待的时间长度。非零值应包含相应的时间单位(如1s、2m、3h)。值为0表示不超时请求。 |
| -s, --server=’’ |
Kubernetes API服务器的地址和端口 |
| --skip-headers=false |
如果为真，则在日志消息中避免头前缀 |
| --skip-log-headers=false |
如果为真，在打开日志文件时要避免头文件 |
| --stderrthreshold=2 |
在此阈值或以上的日志将转到stderr |
| --token=’’ |
用于向API服务器进行身份验证的承载令牌 |
| --user=’’ |
要使用的kubeconfig用户的名称 |
| --username=’’ |
API服务器的基本身份验证的用户名 |
| -v, --v=0 |
日志级别冗长性的编号 |
| --vmodule=‘’ |
逗号分隔的模式列表=N个文件过滤日志记录设置 |
-
下载kubectl
执行以下命令，获取 Kubectl 工具：
-
Mac OS X 系统
curl -LO https://storage.googleapis.com/kubernetes-release/release/v1.8.13/bin/darwin/amd64/kubectl -
Linux 系统
curl -LO https://storage.googleapis.com/kubernetes-release/release/v1.8.13/bin/linux/amd64/kubectl-
Windows 系统
-
-
curl -LO https://storage.googleapis.com/kubernetes-release/release/v1.8.13/bin/windows/amd64/kubectl.exe
以linux为例，若要下载最新的kubectl,可以执行以下命令：
curl -LO https://storage.googleapis.com/kubernetes-release/release/`curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt`/bin/linux/amd64/kubectl
要下载特定版本，请用特定版本替换：
$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)
例如，要在Linux上下载版本v1.17.0，请输入：
curl -LO https://storage.googleapis.com/kubernetes-release/release/v1.17.0/bin/linux/amd64/kubectl
-
安装 Kubectl 工具
已下载kubectl工具，安装步骤以 Linux 系统为例
-
执行以下命令，添加执行权限
chmod +x ./kubectl sudo mv ./kubectl /usr/local/bin/kubectl-
执行以下命令，测试安装结果
-
-
kubectl version如若输出类似以下版本信息，即表示安装成功。
Client Version: version.Info{Major:"1", Minor:"5", GitVersion:"v1.5.2", GitCommit:"08e099554f3c31f6e6f07b448ab3ed78d0520507", GitTreeState:"clean", BuildDate:"2017-01-12T04:57:25Z", GoVersion:"go1.7.4", Compiler:"gc", Platform:"linux/amd64"}
通过证书信息使用 Kubectl 操作集群
-
单次连接集群
Kubectl 命令格式如下所示：-s "域名信息" --username=用户名 --password=密码 --certificate-authority=证书路径示例：
kubectl get node -s "https://cls-66668888.ccs.tencent-cloud.com" --username=admin --password=6666o9oIB2gHD88882quIfLMy6666 --certificate-authority=/etc/kubernetes/cluster-ca.crt -
修改 Kubectl 配置文件，长期连接集群
-
参考以下命令，修改 Kubectl 配置文件中的密码、证书信息
kubectl config set-credentials default-admin --username=admin --password=6666o9oIB2gHD88882quIfLMy6666 kubectl config set-cluster default-cluster --server=https://cls-66668888.ccs.tencent-cloud.com --certificate-authority=/etc/kubernetes/cluster-ca.crt kubectl config set-context default-system --cluster=default-cluster --user=default-admin kubectl config use-context default-system -
配置完成后，执行以下命令，获取 node 节点信息
kubectl get nodes返回类似以下信息，即表示修改成功
NAME STATUS AGE 10.0.0.61 Ready 10h
本文仅是个人学习时的整理收藏，以便回顾所用，内容均来源其它处。
[参考文档]https://www.kubernetes.org.cn/4060.html.
[参考文档]https://kubernetes.io/docs/tasks/tools/install-kubectl/#tabset-2.