kubernetes介绍及相关概念
k8s在市面上的大火，导致不得不去学习它，去适应公司的需求。
Kubernetes是一个基于docker对容器进行编排的引擎，包括了安装部署、应用管理、网络、存储、监控、日志管理等多个方面。
背景
2017 年 9 月，Mesosphere 宣布 支持 Kubernetes；10 月，Docker 宣布将在新版本中加入对 Kubernetes 的原生支持。至此，容器编排引擎领域的三足鼎立时代结束，Kubernetes 赢得全面胜利。
三足分别是：docker swarm、mesos、kubernetes
其实早在 2015 年 5 月，Kubernetes 在 Google 上的的搜索热度就已经超过了 Mesos 和 Docker Swarm，从那儿之后更是一路飙升，将对手甩开了十几条街。
即使现在Docker Swarm还在有人使用，相对kubernetes来说也是很少了。
目前，AWS、Azure、Google、阿里云、腾讯云等主流公有云提供的是基于 Kubernetes 的容器服务；Rancher、CoreOS、IBM、Mirantis、Oracle、Red Hat、VMWare 等无数厂商也在大力研发和推广基于 Kubernetes 的容器 CaaS 或 PaaS 产品。可以说，Kubernetes 是当前容器行业最炙手可热的明星。
每一轮新技术的兴起，无论对公司还是个人既是机会也是挑战。如果这项新技术未来必将成为主流，那么作为 IT 从业者，正确的做法就尽快掌握，因为：
- 新技术意味着新的市场和新的需求。
初期掌握这种技术的人不会很多，而市场需求会越来越大，因而会形成供不应求的卖方市场，物以稀为贵，这对技术人员将是一个难得的价值提升机会。 - 学习新技术需要时间和精力，早起步早成材。
新技术往往意味着技术上的突破和创新，会有不少新的概念和方法。
对于 Kubernetes 这项平台级技术，覆盖的技术范围非常广，包括了计算、网络、存储、高可用、监控、日志管理等多个方面，要掌握这些新技术对 IT 老兵尚有不小难度，更别说新人了。
Kubernetes的应用场景
IT 实施和运维工程师
越来越多的应用将以容器的方式在开发、测试和生产环境中运行。掌握基于 Kubernetes 的容器平台运维能力将成为实施和运维工程师的核心竞争力。
软件开发人员
基于容器的微服务架构（Microservice Architecture）会逐渐成为开发应用系统的主流。而 Kubernetes 将是运行微服务应用的理想平台，市场将需要大量具备 Kubernetes 技能的应用程序开发人员。
Kubernetes的诞生
据说 Google 的数据中心里运行着超过 20 亿个容器，而且 Google 十年前就开始使用容器技术。
最初，Google 开发了一个叫 Borg 的系统（现在命令为 Omega）来调度如此庞大数量的容器和工作负载。在积累了这么多年的经验后，Google 决定重写这个容器管理系统，并将其贡献到开源社区，让全世界都能受益。
这个项目就是 Kubernetes。简单的讲，Kubernetes 是 Google Omega 的开源版本。
从 2014 年第一个版本发布以来，Kubernetes 迅速获得开源社区的追捧，包括 Red Hat、VMware、Canonical 在内的很多有影响力的公司加入到开发和推广的阵营。目前 Kubernetes 已经成为发展最快、市场占有率最高的容器编排引擎产品。
Kubernetes 一直在快速地开发和迭代，基本每隔几个月就会更新。目前已经到了v1.18.1版本的 Kubernetes。接下来会去对 Kubernetes 重要的概念和架构，Kubernetes 如何编排容器，包括优化资源利用、高可用、滚动更新、网络插件、服务发现、监控、数据管理、日志管理等进行深入研究。
k8s的核心功能
k8s 的核心功能：应用部署、访问、Scale Up/Down（伸缩）以及滚动更新。
k8s的重要概念
Kubernetes 的几个重要概念，它们是组成 Kubernetes 集群的基石。
Cluster
- Cluster（集群） 是计算、存储和网络资源的集合，Kubernetes 利用这些资源运行各种基于容器的应用。
- 最简单的 Cluster 可以只有一台主机（它既是 Master 也是 Node）
Master
- Master 是 Cluster 的大脑，它的主要职责是调度，即决定将应用放在哪里运行。
- Master 运行 Linux 操作系统，可以是物理机或者虚拟机。
- 为了实现高可用，可以运行多个 Master。
- 最多最优为7个，损坏率不高，7个足够，和swarm是一样的
Node
- Node 的职责是运行容器应用。
- Node 由 Master 管理，Node 负责监控并汇报容器的状态，并根据 Master 的要求管理容器的生命周期。
- Node 运行在 Linux 操作系统，可以是物理机或者是虚拟机。
- 尽量控制Node的数量在两个或者两个以上。
Pod介绍
- Pod 是 Kubernetes 的最小工作单元。
- 每个 Pod 包含一个或多个容器。Pod 中的容器会作为一个整体被 Master 调度到一个 Node 上运行。
- 相当于swarm的service
创建部署时，Kubernetes创建了一个Pod来托管应用程序实例。 Pod是一个Kubernetes抽象概念，它表示一个或多个应用程序容器的组合(如Docker或rkt)，以及这些容器的一些共享资源。 这些资源包括:
- 共享存储，如卷
- 网络，作为唯一的集群IP地址
- 关于如何运行每个容器的信息，例如容器镜像版本或要使用的特定端口
Pod为特定于应用程序的“逻辑主机”建模，可以包含相对紧密耦合的不同应用程序容器。 例如，Pod可能既包括带有Nodejs应用程序的容器， 也包括由Nodejs web服务器发布的提供数据的容器。 Pod中的容器共享一个IP地址和端口空间，它们总是位于同一个节点上，并在同一个上下文中运行。
Pods在Kubernetes 平台上是原子单位。在Kubernetes上创建部署时，该部署将创建包含容器的Pods(而不是直接创建容器)。 每个Pod被绑定到调试执行它的节点上，并一直保持到终止(根据重启策略)或删除。 在节点失败的情况下，相同的pod会在集群中的其他可用节点上被调度。
Pod 的两种使用方式
（1）运行单一容器
- one-container-per-Pod 是 Kubernetes 最常见的模型，这种情况下，只是将单个容器简单封装成 Pod。
- 即便是只有一个容器，Kubernetes 管理的也是 Pod 而不是直接管理容器。
如下图：一个FTP 会定期从外部的 Content Manager 中拉取最新的文件，将其存放在共享的 volume 中。Web Server 从 volume 读取文件，响应 Consumer 的请求。这两个容器是紧密协作的，它们一起为 Consumer 提供最新的数据；同时它们也通过 volume 共享数据。所以放到一个 Pod 是合适的。
（2）运行多个容器
- 对于那些联系非常紧密，而且需要直接共享资源的容器，应该放在一个 Pod 中。
如：Tomcat 从 MySQL 读取数据，它们之间需要协作，但还不至于需要放到一个 Pod 中一起部署，一起启动，一起停止。同时它们是之间通过 JDBC 交换数据和授权来通信，并不是直接共享存储，所以放到各自的 Pod 中更合适。
Controller控制器
基本介绍
Kubernetes 通常不会直接创建 Pod，而是通过 Controller 来管理 Pod 的。Controller 中定义了 Pod 的部署特性，比如有几个副本，在什么样的 Node 上运行等。为了满足不同的业务场景，Kubernetes 提供了多种 Controller，包括 Deployment、ReplicaSet、DaemonSet、StatefuleSet、Job 等。
各个 Controller 介绍
（1）Deployment（部署/调度）
- Deployment 是最常用的 Controller，比如我们可以通过创建 Deployment 来部署应用的。
- Deployment 可以管理 Pod 的多个副本，并确保 Pod 按照期望的状态运行。也就是当集群中一台主机故障后，不会减少副本数量，会调度其他主机来运行相应的副本数量
- 是一种无序部署，启动时没有固定顺序，有序部署是下面写到的StatefuleSet
（2）ReplicaSet（多副本）
- ReplicaSet 实现了 Pod 的多副本管理。
- 使用 Deployment 时会自动创建 ReplicaSet，也就是说 Deployment 是通过 ReplicaSet 来管理 Pod 的多个副本，我们通常不需要直接使用 ReplicaSet。
（3）DaemonSet
- DaemonSet 用于每个 Node 最多只运行一个 Pod 副本的场景。正如其名称所揭示的，DaemonSet 通常用于运行 daemon。类似swarm集群的global模式运行service。
（4）StatefuleSet
- StatefuleSet 能够保证 Pod 的每个副本在整个生命周期中名称是不变的。而其他 Controller 不提供这个功能，
- 当某个 Pod 发生故障需要删除并重新启动时，Pod 的名称会发生变化。同时 StatefuleSet 会保证副本按照固定的顺序启动、更新或者删除。
（5）Job
- Job 用于运行结束就删除的应用。而其他 Controller 中的 Pod 通常是长期持续运行。也可以抽象的理解为docker run的选项**–rm**。如：备份/还原
（6）CronJob
- CronJob是Kubernetes提供的定时任务功能，CronJob可以根据你指定的cron策略来完成任务。
Service
上面说到k8s中的Pod和swarm集群的service功能相似，这里的service当然和之前的也不是一回事
这里的service是用来被外部来访问Pod时使用。
要知道 Pod 很可能会被频繁地销毁和重启，它们的 IP 会发生变化，用 IP 来访问不太现实。
Kubernetes Service 定义了外界访问一组特定 Pod 的方式。Service 有自己的 IP 和端口，Service 为 Pod 提供了负载均衡。
Kubernetes 运行容器（Pod）与访问容器（Pod）这两项任务分别由 Controller 和 Service 执行。
Namespace
（1）Namespace 可以将一个物理的 Cluster 逻辑上划分成多个虚拟 Cluster，每个 Cluster 就是一个 Namespace。不同 Namespace 里的资源是完全隔离的。
（2）Kubernetes 默认创建了四 Namespace：
- default：创建资源时如果不指定，将被放到这个 Namespace 中。
- kube-system：Kubernetes 自己创建的系统资源将放到这个 Namespace 中。
- kube-pubulic：对外的公开的，放到这个Namespace中
- kube-node-lease：node节点的周期
执行kubectl get namespaces来查看namespace
[root@node1 ~]# kubectl get namespaces
NAME STATUS AGE
default Active 3h38m
kube-node-lease Active 3h38m
kube-public Active 3h38m
kube-system Active 3h38m博客内容遵循 署名-非商业性使用-相同方式共享 4.0 国际 (CC BY-NC-SA 4.0) 协议
