基于k8s搭建的一套CI/CD系统，其目的是方便k8s和服务端相关技术的实践，在搭建过程中会涉及docker、dockerhub、k8s、github、jenkins、kubesphere
一台Mac物理机+3台Centos虚拟机
Docker是这个教程的基石，对Docker一点都不了解的同学，建议去B站看一下我发布的 Docker小白快速入门+实战 ，课程比较简洁，主要帮助不了解Docker的同学快速掌握并应用
安装命令如下
k8s是一个容器编排工具，可以轻松实现应用的扩/缩容、集群等，具体安装方式参考文档我的 k8s集群安装
这是k8s的一个web管理界面，用于简化k8s的 *** 作。
在k8s继续的所有节点上都需要安装nfs-utils、rpcbind，搭建步骤参考我的 Centos7搭建NFS服务端
kubesphere明确说明基于k8s安装需要配置DefaultStorageclass，创建步骤参考我的 k8s基于NFS创建Storageclass
安装时间会有一点长，安装步骤参考我的 k8s集群安装Kubersphere
jenkins在这里是作为一个纽带的作用，因为jenkins在构建项目时可以执行shell脚本，因此通过shell脚本轻松的将github、docker注册服务器、k8s集群三者关联起来，从而简化jenkins的使用（就是一个偏运维的工具而已）
这里之所以使用Docker安装Jenkins，是因为我不想在物理机上安装jenkins（毕竟只是一个工具），而虚拟机已经启动了三台，再创建就会影响我的物理机性能，所以这里直接使用物理机的Docker跑Jenkins，用完就删了。
安装步骤参考我的 基于Docker安装Jenkins
免密访问k8s集群的master服务器
参考我的 Linux配置免密登录 ，这里需要进入jenkins容器内部进行 *** 作
配置github的ssh key访问
在jenkins创建一个自由风格的软件->填写仓库地址->编写如下脚本
一个简单的CI/CD系统就搭建完成了，后面可以把更多的重心放在k8s资源文件的编写上，理解yaml中各节点的含义也是一项不小的工作量，搞清楚k8s的各个模块，对服务端的架构设计是有益的。
爱飞狗后台的数据爬虫以及数据服务器资源都部署在k8s上，使用rancher搭建。在不影响太多性能的情况下尽量选择最低配置的机器。对于内存不足的情况适当的使用交换文件代替（swap）。整个集群大致结构如下：一个月的开销大概在60美元左右。分析上面的集群可以发现，rancher和etcd两个节点是浪费了钱，每个月有20美元的开销。DigitalOcean提供了k8s的托管集群，可以将这部分开销节省。但托管集群的droplet无法定制化，无法使用交换分区和bbr，造成性能瓶颈。另外托管的droplet的最低要求也是2G的内存，造成不必要的开支。
k8s有一个非常不好的地方就是最低的机器要求比较高，1G内存的worker node已经完全低于推荐配置，如果在上面部署worker node直接的内存占用就要300M左右，剩余的内存空间并不多，必须要使用交换分区。etcd节点之前也用过1G的内存，但经常会由于大量使用交换分区导致性能问题，最后集群崩溃，所以无论如何也需要使用2G的内存才行。
最近rancher公司推出了k3s，其主打就是简易的部署和极地的机器消耗。这点对于节约成本来讲非常的重要。我试了下k3s的server大概只占用200M左右的内存，agent只占用几十兆内存，非常的节约。k3s也可以完全使用kubectl来进行管理，配置文件和k8s保持一致，非常方便。
我将etcd节点和rancher主机删除，替换成了1G 1CPU的机器(5美元)，节约了15美元，然后将aiflygo的服务器进行降配置到2G 2CPU (15美元)，总共节约20美元。得益于更多的可用内存，目前爬虫的性能比以前更好，整体集群的性能也非常的高。
至于HA，既然都穷到了用k3s来减少开销，对于我这样的小型的集群和不是关键系统来讲都不是需要考虑的了。
1如果自己购买实体机架的话，那么代价是很大的。从机房建设、通风等，再到水电、设备购买、安装这些都耗费人力物力的。
2如果自己从阿里云、腾讯云等第三方云服务提供商购买云服务器，那么自己的云服务器，所要做的就是应用部署、应用管理，服务器的维护、监控、动态扩容，这些都需要自己去关心啦。只需要关心应用业务逻辑即可。
3决定好模式后，就可以决定购买服务器。服务器购买好后，就是服务器应用管理，创建角色、分配资源、集群建立，基础应用软件安装。
4目前常用的是，购买服务器后，采用k8s、docker进行服务器资源管理，动态扩容。
Kubernetes是如今IT领域最火热的关键字，本文回顾Kubernetes的历史，介绍Kubernetes的基础概念，并和大家更为熟悉的虚拟化技术作类比加深对Kubernetes的理解，同时分析Kubernetes的优势劣势，最后展望未来。
有人认为自动化，云计算和人工智能是第四次工业革命。如果你开始感受到IT领域自动化率的飙升，特别是在应用程序部署和管理领域（我觉得还不是无缝的自插拔式），那么不用太过惊讶。几年前，Google就正式启动了名为Kubernetes的项目，也就是现在广为人知的k8s。Kubernetes是开源的容器集群管理器，意图成为能够在容器领域自治化部署以及扩展应用程序的平台。
Kubernetes是一个可移植的，可扩展的开源平台，用于管理容器化的工作负载和服务，可促进声明式配置和自动化。它拥有一个庞大且快速增长的生态系统。Kubernetes的服务，支持和工具广泛可用。
Kubernetes这个名字起源于希腊语，意思是舵手或飞行员。Google在2014年开源了Kubernetes项目。Kubernetes将 超过15年的Google 在大规模生产工作负载方面 的经验 与社区中最好的想法和实践相结合。
让我们回顾一下为什么Kubernetes如此有用。
传统部署时代： 早期，组织在物理服务器上运行应用程序。无法为物理服务器中的应用程序定义资源边界，这会导致资源分配问题。例如，如果在物理服务器上运行多个应用程序，则可能会出现一个应用程序占用大部分资源的情况，结果，其他应用程序的性能将下降。解决方案是在不同的物理服务器上运行每个应用程序。但这并没有随着资源利用不足而扩展，并且组织维护许多物理服务器的成本很高。
虚拟化部署时代： 作为解决方案，引入了虚拟化。它允许您在单个物理服务器的CPU上运行多个虚拟机（VM）。虚拟化允许在VM之间隔离应用程序，并提供安全级别，因为一个应用程序的信息不能被另一应用程序自由访问。
虚拟化可以更好地利用物理服务器中的资源，并可以实现更好的可伸缩性，因为可以轻松地添加或更新应用程序，降低硬件成本等等。借助虚拟化，您可以将一组物理资源呈现为一组一次性虚拟机。
每个VM都是一台完整的计算机，在虚拟化硬件之上运行所有组件，包括其自己的 *** 作系统。
容器部署时代： 容器类似于VM，但是它们具有轻松的隔离属性，可以在应用程序之间共享 *** 作系统（OS）。因此，容器被认为是轻质的。与VM相似，容器具有自己的文件系统，CPU，内存，进程空间等。由于它们与基础架构分离，因此可以跨云和OS分发进行移植。
容器之所以受欢迎，是因为它们提供了额外的好处，例如：
容器是捆绑和运行应用程序的好方法。在生产环境中，您需要管理运行应用程序的容器，并确保没有停机时间。例如，如果一个容器发生故障，则需要启动另一个容器。如果此行为由系统处理，会不会更容易？
这就是Kubernetes的救援方法！Kubernetes为您提供了一个可d性运行分布式系统的框架。它负责应用程序的扩展和故障转移，提供部署模式等。例如，Kubernetes可以轻松管理系统的Canary部署。
Kubernetes为您提供：
Kubernetes不是一个传统的，包罗万象的PaaS（平台即服务）系统。由于Kubernetes在容器级别而非硬件级别运行，因此它提供了PaaS产品共有的一些普遍适用的功能，例如部署，扩展，负载平衡，并允许用户集成其日志记录，监视和警报解决方案。但是，Kubernetes并不是单片的，这些默认解决方案是可选的和可插入的。Kubernetes提供了构建开发人员平台的基础，但是在重要的地方保留了用户的选择和灵活性。
Kubernetes：
在深入研究Kubernetes之前，要认识到如果没有容器的出现，Kubernetes也不会存在。从高层看，容器看上去像虚拟机，但是最大的区别是容器和其他容器共享主机系统的内核。这是最主要的差异要素，因为容器共享物理主机的OS，所以它们很容易移动。用户也可以在同一台主机上启动比VM数量多得多的容器，因为它们共享内核，库和二进制文件。比如，一个VM的大小大概是20GB，而运行着相同应用程序的容器大概只有200MB。
容器（无论是Docker还是CoreOS的rkt）允许开发人员无缝地关注于应用程序的运行时。基础架构的问题会影响到脆弱的应用程序开发的日子一去不复返了。使用容器，开发人员仅仅需要考虑如何恰当地扩展，部署以及管理他们新开发的应用程序，但是现有的容器方案并不能在跨多节点的环境里自己管理，调度以及部署容器。
在容器化的世界里，Kubernetes是环境的管理和部署引擎。使用Kubernetes的最基本功能，用户就可以轻松地在物理硬件或者虚拟机上调度并且运行应用程序。Kubernetes的更多高级用法让开发人员可以彻底摆脱主机为中心的世界，而进入容器为中心的环境里。
使用Kubernetes很容易。可以使用REST API来 *** 作Kubernetes所包含的主要组件 。Kubernetes的定位是平台，但是它包含多个组件，每个都有各自的角色。Master是Kubernetes集群里的控制服务（也称为control plane），Master很重要，因为它会API调用和其交互的其他组件。集群单元管理发生在Master里，调度服务也在这里。
Kubernetes架构介绍，Imesh Gunaratne 。
Master之下就是Kubernetes工作单元，这里定义特定工作的实体。既然最终目标是要交付一个应用程序，那么这些单元还有更多其他的特定功能。
Pod ：最基础的单元是Pod，当指派容器时，容器实际上并不会指派到物理硬件上，相反，容器会被分配到一个Pod里。Pod通常负责托管服务于单个应用程序的容器。这意味着Pod内的所有容器都能够共享卷和IP空间，允许它们扩展为单个应用程序。
Service（服务） ：如果想要构建更为稳健的容器化策略，那么“服务”的概念就更加重要。服务的功能是资源均衡器，将工作负载在容器间导流。这使得后台容器可以通过单一稳定的接入点和前端应用程序通信。这个特性让使用者更易于使用并且可扩展。
Replication Controller（副本控制器） ：这些单元的目的是确保在某个时间点，有所需数量的特定容器在运行。比如说突然某个内核出错了，导致某个容器（多个容器组内的）崩溃了，那么RC的责任是新启动一个副本Pod，直至之前的Pod在重启后恢复为止。一旦之前的Pod启动并且再次运行了，RC就会杀死副本Pod。
Label（标签） ：虽然标签并不是一种工作单元，但是它起着至关重要的组织作用。标签的功能是组命名，这样用户可以针对一组单元做 *** 作。这是用户组织容器环境的方式。
在最基础的级别上，这些是组成Kubernetes平台的实体。
想一想我们现在都很熟悉的技术，通过虚拟化类比一下Kubernetes。
Kubernetes的Master和VMware的vCenter类似。Master知道集群里的所有节点，以及所有节点的容量。而且，Master对Pod的调度及放置，类似于vCenter如何在vSphere的主机上部署VM。Pod的功能和vApp很类似，因为它们都在一个网络里托管多个容器。容器类似VM，因为它们之前都是互相隔离的，除非它们被指定特定的网络路径。最后，Replication Controller类似于HA，因为RC持续监控环境，确保正确数量的Pod在运行，如果数量少于预期，就会调度一个新的实例。
虽然Kubernetes并不是市场里唯一的容器管理平台（还有Docker Swarm和Mesos），但是它更受欢迎。为什么呢？从高层看，Kubernetes正获得关注，因为它提供了这样一个平台，容器化的应用程序可以只编写一次，就能够在所有类型的云供应商以及私有云上运行，无论底层使用的是哪种基础架构。而且，Kubernetes还在发展，让开发人员能够在Kubernetes上运行任意适合的应用程序。Sam Ghods，Box的联合创始人认为只要是能运行的二进制文件，就可以运行在Kubernetes上。
使用Kubernetes，开发人员可以快速部署应用程序，而无需担心传统平台上的诸多风险（想想跨多OS环境的垂直扩展），可以随时扩展应用程序，并且更好地分配资源。
硬件使用量的下降是使用Kubernetes带来的另一个好处。一些公司报告由于容器的轻量天性，以及能够快速杀死不需要的实体（和传统架构相比），硬件使用量减少了40-50%。eBay是Kubernetes的支持者和用户，声称自从他们切换了平台之后，看到了服务器上[overhead的急剧降低]
最后，Kubernetes最大的不同之处并非和技术相关，而是促成各种方案的社区。Google将其发布为开源项目，吸引了1000+的社区贡献者，34000次commit。它的社区比Mesos的社区（次大的竞争者社区）大5倍，比所有竞争者的社区加起来都要大。
Kubernetes受到了广泛的称赞，但是它也有一些缺点。当第一次使用它做部署（大规模）时，它很复杂，并且很难搭建。它要求具有特定技能的工程师，在现在的行业里可能很难找到。
第二，Kubernetes作为容器的第三方管理系统。容器技术本身的缺陷和成长之痛会影响到Kubernetes所能够提供的服务。
Kubernetes欠缺的领域是调度器。默认的Kubernetes调度器依赖于应用程序所有者提供的分配资源的需求，而不管实时使用量。这个方案会加重每个节点上的资源分片情况。
最后，能够在容器里运行的工作负载范围将影响Kubernetes的广泛使用，但是这并非Kubernetes可以直接解决的问题。比如，很多工程师还不想把“核心”工作负载放到容器里，因为它可能会崩溃，而容器从设计上就不是为了存储数据的。常见的实践是只在容器里运行那些崩溃后也不会导致下线时间的应用程序。
即使有这些不足，也并没有阻止Goldman Sachs，Box，SAP以及The New York Times这样的公司引入Kubernetes平台作为其下一代数据中心计划的一部分。
应用程序是如今大多数业务的生命线。公司需要快速的部署和高质量的应用程序。这些需求正是开发人员转向容器的原因。随着容器的发展，如果还认为Kubernetes的定位有问题那就难免有些愚蠢了。Kubernetes平台有很多的可能性，但是规模大了的话它也很难管理。最初的搭建和在生产环境上大规模运行Kubernetes之间的空白是很大的。近几年里，可能会有来自于第三方的强劲挑战，来管理这些部署和工作负载。对于Kubernetes来说，不囿于已经取得的成就至关重要。如果社区能够恰当地扩展平台，那么Kubernetes的前途甚为光明。
Kubernetes借鉴了Borg的设计理念，比如Pod、Service、Labels和单Pod单IP等。Kubernetes的整体架构跟Borg非常像，如下图所示：
Kubernetes主要由以下几个核心组件组成：
除了核心组件，还有一些推荐的Add-ons：
Kubernetes Architecture
Kubernetes Master
Kubernetes Node
API对象是K8s集群中的管理 *** 作单元。K8s集群系统每支持一项新功能，引入一项新技术，一定会新引入对应的API对象，支持对该功能的管理 *** 作。例如副本集Replica Set对应的API对象是RS。
每个API对象都有3大类属性：元数据metadata、规范spec和状态status。元数据是用来标识API对象的，每个对象都至少有3个元数据：namespace，name和uid；除此以外还有各种各样的标签labels用来标识和匹配不同的对象，例如用户可以用标签env来标识区分不同的服务部署环境，分别用env=dev、env=testing、env=production来标识开发、测试、生产的不同服务。规范描述了用户期望K8s集群中的分布式系统达到的理想状态（Desired State），例如用户可以通过复制控制器Replication Controller设置期望的Pod副本数为3；status描述了系统实际当前达到的状态（Status），例如系统当前实际的Pod副本数为2；那么复制控制器当前的程序逻辑就是自动启动新的Pod，争取达到副本数为3。
K8s中所有的配置都是通过API对象的spec去设置的，也就是用户通过配置系统的理想状态来改变系统，这是k8s重要设计理念之一，即所有的 *** 作都是声明式（Declarative）的而不是命令式（Imperative）的。声明式 *** 作在分布式系统中的好处是稳定，不怕丢 *** 作或运行多次，例如设置副本数为3的 *** 作运行多次也还是一个结果，而给副本数加1的 *** 作就不是声明式的，运行多次结果就错了。
Cluster 是计算、存储和网络资源的集合，Kubernetes 利用这些资源运行各种基于容器的应用。
Master 是 Cluster 的大脑，它的主要职责是调度，即决定将应用放在哪里运行。Master 运行 Linux *** 作系统，可以是物理机或者虚拟机。为了实现高可用，可以运行多个 Master。
Node 的职责是运行容器应用。Node 由 Master 管理，Node 负责监控并汇报容器的状态，并根据 Master 的要求管理容器的生命周期。Node 运行在 Linux *** 作系统，可以是物理机或者是虚拟机。
Pod 是 Kubernetes 的最小工作单元。每个 Pod 包含一个或多个容器。Pod 中的容器会作为一个整体被 Master 调度到一个 Node 上运行。
Kubernetes 引入 Pod 主要基于下面两个目的：
Kubernetes 通常不会直接创建 Pod，而是通过 Controller 来管理 Pod 的。Controller 中定义了 Pod 的部署特性，比如有几个副本，在什么样的 Node 上运行等。为了满足不同的业务场景，Kubernetes 提供了多种 Controller，包括 Deployment、ReplicaSet、DaemonSet、StatefuleSet、Job 等，我们逐一讨论。
Deployment 是最常用的 Controller，比如前面在线教程中就是通过创建 Deployment 来部署应用的。Deployment 可以管理 Pod 的多个副本，并确保 Pod 按照期望的状态运行。
ReplicaSet 实现了 Pod 的多副本管理。使用 Deployment 时会自动创建 ReplicaSet，也就是说 Deployment 是通过 ReplicaSet 来管理 Pod 的多个副本，我们通常不需要直接使用 ReplicaSet。
DaemonSet 用于每个 Node 最多只运行一个 Pod 副本的场景。正如其名称所揭示的，DaemonSet 通常用于运行 daemon。
StatefuleSet 能够保证 Pod 的每个副本在整个生命周期中名称是不变的。而其他 Controller 不提供这个功能，当某个 Pod 发生故障需要删除并重新启动时，Pod 的名称会发生变化。同时 StatefuleSet 会保证副本按照固定的顺序启动、更新或者删除。
Job 用于运行结束就删除的应用。而其他 Controller 中的 Pod 通常是长期持续运行。
RC、RS和Deployment只是保证了支撑服务的微服务Pod的数量，但是没有解决如何访问这些服务的问题。一个Pod只是一个运行服务的实例，随时可能在一个节点上停止，在另一个节点以一个新的IP启动一个新的Pod，因此不能以确定的IP和端口号提供服务。要稳定地提供服务需要服务发现和负载均衡能力。服务发现完成的工作，是针对客户端访问的服务，找到对应的的后端服务实例。在K8s集群中，客户端需要访问的服务就是Service对象。每个Service会对应一个集群内部有效的虚拟IP，集群内部通过虚拟IP访问一个服务。在K8s集群中微服务的负载均衡是由Kube-proxy实现的。Kube-proxy是K8s集群内部的负载均衡器。它是一个分布式代理服务器，在K8s的每个节点上都有一个；这一设计体现了它的伸缩性优势，需要访问服务的节点越多，提供负载均衡能力的Kube-proxy就越多，高可用节点也随之增多。与之相比，我们平时在服务器端做个反向代理做负载均衡，还要进一步解决反向代理的负载均衡和高可用问题。
Kubernetes 运行容器（Pod）与访问容器（Pod）这两项任务分别由 Controller 和 Service 执行。
名字空间为K8s集群提供虚拟的隔离作用，K8s集群初始有两个名字空间，分别是默认名字空间default和系统名字空间kube-system，除此以外，管理员可以可以创建新的名字空间满足需要。
有关linux：
1、卸载某一个特定的挂在点。
umount /dev/datavg01 /data01
2、移掉lvm。
vgremove /dev/datavg01
3、拷贝数据。
scp -r /home/gaogetxt root@192168101:/opt 或rsync -av /root/rpmpkgs /tmp/backups/
4、显示系统盘符并以树状格式展开。
lsblk。
5、扫描新增设备。
echo "---" >/sys/class/scsi-host/hosto/scan
6、强行杀死mysql
kill -9 $(ps -ef | grep mysql)
7、将文件内容以每一行5个的形式展示出来。
cat test2txt | xargs -n 5
8、用cut去实现awk切割列的效果
cat/etc/passwd | cut -d : -f 2
9、sed、grsp、awk。之前已经说过了、具体看 从linux三剑客说起 这篇。
10、增加一个oracle用户让其属于oinstall组同时也隶属于dba组。useradd oracle -g oinstall -G dba
11、新建立一个组groupnew并将组id修改为255。
groupadd -g 255 groupnew
12、将本地/dev/hdb整盘中的数据备份到/dev/hdd上。
dd if=/dev/hdb of=/dev/hdd
13、查看服务器cpu个数。
cat /proc/cpuinfo | grep "physical id" | wc -l
14、查看服务器io状况并以每间隔1秒的速度输出5次。
iostat 1 5
15、查看服务器内存使用情况并以每间隔2秒的速度输出10次。
vmstat 2 10
16、将gaogetxt中的第一列db2找到并将db两个字符用ab替换。
cat gaogetxt |grep db2 | awk -F 2 '{print $1}' | tr db ab
17、将包名解压到指定目录。
tar -cxvf 包名 -C 指定的目录
18、linux中前后台任务切换。
ctrl+z 切换到后台、jobs显示id、fg + id 切换至前台。
19、杀掉top下stopped的进程。
ps -A -ostat,ppid,pid,cmd |grep -e '^[T]'
然后在进行kill
20、监控cpu状态。
mpstat
21、查看虚拟内存使用了多少。
swapon
22、每月1到10号4:45重启nginx。
crontab -u root -l 显示root当前的计划任务。
crontab -u root -e 后输入以下内容并保存退出。
45 4 1,10 systemctl start nginx
23、awk打印df -h 的第一列、第三列、最后一列。
df -h | awk '{print $1 " " $3 " " $NF}'
24、批量拉、打标签、推docker镜像的shell脚本。
#！/bin/bash
for image in 'docker images | grep 10171101：10000 | awk ' { print $1 ":" $2 }
do
version = 'echo $image | awk -F / ' { print $2 } '
docker tag $image 192168101/$version
docker push 192168101/$version
done
25、正则表达式匹配电话号码。
(0d{2}[) -]d{8}
26、编译安装三步骤。
/configure --prefix=安装目录
make
make install
有关kubernetes：
将kubernetes中pod的数据拷贝到物理宿主机上。
kubectl cp gyl-run/gyl-mysql-01020304: /opt/dockersh /opt
将kubernetes中物理宿主机上的数据拷贝到pod中。
kubectl cp /opt/dockersh gyl-run/gyl-mysql-01020304: /opt
检查当前用户有没有权限在k8s中创建资源权限。
kubectl auth can-i '' ''
检查当前用户有没有权限在k8s集群中创建namespace权限。
kubectl auth can-i create pods --all-namespaces
查看集群是否 健康 。
kubectl get cs
有关数据库：
查看 mysql 二进制日志格式。
show variables like ‘%binlog_format%’
查看所有二进制日志文件
show master logs
查看正在写入的二进制日志
show master status
格式化二进制显示为sql格式
mysqlbinlog --base64 --output=decode-rows -v --start-date="2019-01-25 00:00:00" --stop-date=“2019-01-26 17:30” master-bin000006
利用bin-log去还原数据
/usr/bin/mysqlbinlog --no-default /var/lib/mysql/mysql-bin00001 | usr/bin/mysql -u root -p pwd test
连接 postgresql
psql -U 用户名 -d 数据
数据库名 -h 主机地址 -p端口（默认端口为5432）
l 显示数据库列表
d 显示所有表
d 表名称 显示表结构
du 显示所有数据库用户
c 数据库名 连接数据库
q 退出pg窗口
pg备份：
pg_dump -U kong -d kong -f /opt/2019-01-26-pgsql
pg还原：
psql -d kong -U kong -f /opt/2019-01-26-pgsql
mongo 批量更新数据：把age大于20的class name修改为，设置multi为true
可以的，k8s主要是通过config-api进行通信的，然后通过这个api进行资源调度和部署。具体如下，1 namespace
增（创建）POST请求：
创建namespace： /api/v1/namespaces
删（删除） DELETE请求：
删除namespace： /api/v1/namespaces/{namP}
改（修改）PUT请求：
替换指定的命名空间： /api/v1/namespaces/{name}
替换指定名称空间的状态： /api/v1/namespaces/{name}/status
如果部分更新可以用 PATCH
查（查询） GET请求：
查询全部： /api/v1/namespaces
查询指定namespace： /api/v1/namespaces/{name}
2 Pod
增（创建）POST请求：
创建pod： /api/v1/namespaces/{namespace}/pods
删（删除） DELETE请求：
删除pod： /api/v1/namespaces/{namespace}/pods/{name}
改（修改）PUT请求：
替换指定的pod： /api/v1/namespaces/{namespace}/pods/{name}
如果部分更新可以用 PATCH
查（查询） GET请求：
查询全部： /api/v1/namespaces/{namespace}/pods
查询指定pod： /api/v1/namespaces/{namespace}/pods/{name}
3 Node
增（创建）POST请求：
创建node： /api/v1/nodes
删（删除） DELETE请求：
删除node： /api/v1/nodes/{name}
改（修改）PUT请求：
替换指定的node： /api/v1/nodes/{name}
替换指定node的状态： /api/v1/nodes/{name}/status
如果部分更新可以用 PATCH
查（查询） GET请求：
查询全部： /api/v1/nodes
查询指定node： /api/v1/nodes/{name}
查询指定节点内所有Pod的信息： /api/v1/nodes/{name}/pods/
查询指定节点内物理资源的统计信息: /api/v1/nodes/{name}/stats/
查询指定节点的概要信息： /api/v1/nodes/{name}/spec/
4 Service
增（创建）POST请求：
创建service： /api/v1/namespaces/{namespace}/services
删（删除） DELETE请求：
删除service： /api/v1/namespaces/{namespace}/services/{name}
改（修改）PUT请求：
替换指定的service： /api/v1/namespaces/{namespace}/services/{name}
如果部分更新可以用 PATCH
查（查询） GET请求：
查询全部： /api/v1/namespaces/{namespace}/services
查询指定service： /api/v1/namespce
在前面已经提到，容器的生命周期可能很短，会被频繁地创建和销毁。那么容器在销毁时，保存在容器中的数据也会被清除。这种结果对用户来说，在某些情况下是不乐意看到的。为了持久化保存容器的数据，kubernetes引入了Volume的概念。
Volume是Pod中能够被多个容器访问的共享目录，它被定义在Pod上，然后被一个Pod里的多个容器挂载到具体的文件目录下，kubernetes通过Volume实现同一个Pod中不同容器之间的数据共享以及数据的持久化存储。Volume的生命容器不与Pod中单个容器的生命周期相关，当容器终止或者重启时，Volume中的数据也不会丢失。
kubernetes的Volume支持多种类型，比较常见的有下面几个：
EmptyDir是最基础的Volume类型，一个EmptyDir就是Host上的一个空目录。
EmptyDir是在Pod被分配到Node时创建的，它的初始内容为空，并且无须指定宿主机上对应的目录文件，因为kubernetes会自动分配一个目录，当Pod销毁时， EmptyDir中的数据也会被永久删除。 EmptyDir用途如下：
接下来，通过一个容器之间文件共享的案例来使用一下EmptyDir。
在一个Pod中准备两个容器nginx和busybox，然后声明一个Volume分别挂在到两个容器的目录中，然后nginx容器负责向Volume中写日志，busybox中通过命令将日志内容读到控制台。
创建一个volume-emptydiryaml
EmptyDir中数据不会被持久化，它会随着Pod的结束而销毁，如果想简单的将数据持久化到主机中，可以选择HostPath。
HostPath就是将Node主机中一个实际目录挂在到Pod中，以供容器使用，这样的设计就可以保证Pod销毁了，但是数据依据可以存在于Node主机上。
创建一个volume-hostpathyaml：
HostPath可以解决数据持久化的问题，但是一旦Node节点故障了，Pod如果转移到了别的节点，又会出现问题了，此时需要准备单独的网络存储系统，比较常用的用NFS、CIFS。
NFS是一个网络文件存储系统，可以搭建一台NFS服务器，然后将Pod中的存储直接连接到NFS系统上，这样的话，无论Pod在节点上怎么转移，只要Node跟NFS的对接没问题，数据就可以成功访问。
1）首先要准备nfs的服务器，这里为了简单，直接是master节点做nfs服务器
2）接下来，要在的每个node节点上都安装下nfs，这样的目的是为了node节点可以驱动nfs设备
3）接下来，就可以编写pod的配置文件了，创建volume-nfsyaml
4）最后，运行下pod，观察结果
前面已经学习了使用NFS提供存储，此时就要求用户会搭建NFS系统，并且会在yaml配置nfs。由于kubernetes支持的存储系统有很多，要求客户全都掌握，显然不现实。为了能够屏蔽底层存储实现的细节，方便用户使用， kubernetes引入PV和PVC两种资源对象。
PV（Persistent Volume）是持久化卷的意思，是对底层的共享存储的一种抽象。一般情况下PV由kubernetes管理员进行创建和配置，它与底层具体的共享存储技术有关，并通过插件完成与共享存储的对接。
PVC（Persistent Volume Claim）是持久卷声明的意思，是用户对于存储需求的一种声明。换句话说，PVC其实就是用户向kubernetes系统发出的一种资源需求申请。
使用了PV和PVC之后，工作可以得到进一步的细分：
PV是存储资源的抽象，下面是资源清单文件:
PV 的关键配置参数说明：
实验
使用NFS作为存储，来演示PV的使用，创建3个PV，对应NFS中的3个暴露的路径。
1准备NFS环境
2创建pvyaml
PVC是资源的申请，用来声明对存储空间、访问模式、存储类别需求信息。下面是资源清单文件:
PVC 的关键配置参数说明：
实验
1创建pvcyaml，申请pv
2创建podsyaml, 使用pv
PVC和PV是一一对应的，PV和PVC之间的相互作用遵循以下生命周期：
ConfigMap是一种比较特殊的存储卷，它的主要作用是用来存储配置信息的。
创建configmapyaml，内容如下：
接下来，使用此配置文件创建configmap
接下来创建一个pod-configmapyaml，将上面创建的configmap挂载进去
在kubernetes中，还存在一种和ConfigMap非常类似的对象，称为Secret对象。它主要用于存储敏感信息，例如密码、秘钥、证书等等。
1首先使用base64对数据进行编码
2接下来编写secretyaml，并创建Secret
3创建pod-secretyaml，将上面创建的secret挂载进去：
至此，已经实现了利用secret实现了信息的编码。
1 Label含义11 Label其实就一对 key/value ，被关联到对象上，比如Pod,标签的使用我们倾向于能够标示对象的特殊特点，Labels的值对系统本身并没有什么含义，只是对用户才有意义。同一个资源对象的labels属性的key必须唯一，label可以附加到各种资源对象上，如Node,Pod,Service,RC等。一个资源拥有多个标签，可以实现不同维度的管理。标签(Label)的组成: key=value。Label可以在创建对象时就附加到对象上，也可以在对象创建后通过API进行额外添加或修改。
12 Label命名规范
label 必须以字母或数字开头，可以使用字母、数字、连字符、点和下划线，最长63个字符。
2 使用Label原因
21 当相同类型的资源越来越多，对资源划分管理是很有必要，此时就可以使用Label为资源对象 命名，以便于配置，部署等管理工作，提升资源的管理效率。label 作用类似Java包能对不同文件分开管理，让整体更加有条理，有利于维护。
22 通过Label来对对象进行引用。
3Label创建脚本
31 命令创建
label [--overwrite] (-f FILENAME | TYPE NAME) KEY_1=VAL_1 KEY_N=VAL_N [--resource-version=version]
311 kubectl get pods 命令默认不会列出任何标签,使用 --show-labels 选项来查看 ：
kubectl get po --show-labels
312 指定标签查看
kubectl get po -L creation_method,env
查看匹配标签条件的node
kubectl get nodes -l 标签key=标签values
kubectl get nodes -l app=tomcat
查看匹配 标签key的pod
kubectl get po -L app
313 给名为tomcat 的Pod添加label app=tomcat。
kubectl label pods tomcat app=tomcat
314 把名为tomcat 的Pod修改label 为 app=tomcat1，且覆盖现有的value
kubectl label --overwrite pods tomcat app=tomcat1
315 把 namespace 中的所有 pod 添加 label
kubectl label pods --all test=test
316 删除名为“app”的label 。（使用“ - ”减号相连）
kubectl label pods tomcat app-
32 yaml脚本创建
vim label-pod-testyaml
apiVersion: v1
kind: Pod
metadata:
name: tomcat
labels:
app: tomcat
release: stable
spec:
containers:
- name: tomcat
image: tomcat
ports:
- containerPort: 80
为tomcat的Pod添加了两个Label，分别为app: tomcat和release: tomcat
4Label使用场景
常用的，多维度标签分类：
版本标签（release）： stable（稳定版），canary（金丝雀版本），beta（测试版）
环境类（environment）： dev（开发），qa（测试），production（生产），op（运维）
应用类（applaction）： ui（设计），as（应用软件），pc（电脑端），sc（网络方面）
架构层（tier）： frontend（前端），backend（后端），cache（缓存）
分区标签（partition）： customerA（客户），customerB
品控级别（track）： daily（每天），weekly（每周）
vim label-pod-testyaml
apiVersion: v1
kind: Pod
metadata:
name: label-pod-test
labels: #使用labels字段来定义标签，可以一次定义多个标签，这里定义3个标签
release: stable #版本：稳定版
env: qa #环境：测试
tier: frontend #架构类：前端
spec:
containers:
- name: testTomcatLabel
image: tomcat #部署的是tomcat服务
最后祝各位小伙伴新年快乐，万事如意！！有好的建议和意见，欢迎下方留言。力求每次分享能为大家带来更多的收获。
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）