## Kubernetes概述 Kubernetes一个核心的特点就是能够自主的管理容器来保证云平台中的容器按照用户的期望状态运行着（比如用户想让apache一直运行，用户不需要关心怎么去做，Kubernetes会自动去监控，然后去重启，新建，总之，让apache一直提供服务），管理员可以加载一个微型服务，让规划器来找到合适的位置，同时，Kubernetes也系统提升工具以及人性化方面，让用户能够方便的部署自己的应用（就像canary deployments）。 ## Kubernetes分层架构 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、集群自身的配置和管理等 ## Kubernetes组件 #### etcd 所有master的持续状态都存在etcd的一个实例中。这可以很好地存储配置数据。因为有watch(观察者)的支持，各部件协调中的改变可以很快被察觉。 #### kubelet kubelet负责管理pods和它们上面的容器，images镜像、volumes、etc。 #### kube-proxy 每一个节点也运行一个简单的网络代理和负载均衡（详见services FAQ )（PS:官方 英文）。 正如Kubernetes API里面定义的这些服务（详见the services doc）（PS:官方 英文）也可以在各种终端中以轮询的方式做一些简单的TCP和UDP传输。 服务端点目前是通过DNS或者环境变量( Docker-links-compatible 和 Kubernetes{FOO}_SERVICE_HOST 及 {FOO}_SERVICE_PORT 变量都支持)。这些变量由服务代理所管理的端口来解析。 #### Kubernetes API Server API服务提供Kubernetes API （PS:官方 英文）的服务。这个服务试图通过把所有或者大部分的业务逻辑放到不两只的部件中从而使其具有CRUD特性。它主要处理REST操作，在etcd中验证更新这些对象（并最终存储）。 #### Scheduler 调度器把未调度的pod通过binding api绑定到节点上。调度器是可插拔的，并且我们期待支持多集群的调度，未来甚至希望可以支持用户自定义的调度器。 #### 概念解释 ##### Pods  一个Pod（就像一群鲸鱼，或者一个豌豆夹）相当于一个共享context的配置组，在同一个context下，应用可能还会有独立的cgroup隔离机制，一个Pod是一个容器环境下的“逻辑主机”，它可能包含一个或者多个紧密相连的应用，这些应用可能是在同一个物理主机或虚拟机上 Pod 的context可以理解成多个linux命名空间的联合 * PID 命名空间（同一个Pod中应用可以看到其它进程） * 网络 命名空间（同一个Pod的中的应用对相同的IP地址和端口有权限） * IPC 命名空间（同一个Pod中的应用可以通过VPC或者POSIX进行通信） * UTS 命名空间（同一个Pod中的应用共享一个主机名称） 同一个Pod中的应用可以共享磁盘，磁盘是Pod级的，应用可以通过文件系统调用，额外的，一个Pod可能会定义顶级的cgroup隔离，这样的话绑定到任何一个应用（好吧，这句是在没怎么看懂，就是说Pod，应用，隔离） 由于docker的架构，一个Pod是由多个相关的并且共享磁盘的容器组成，Pid的命名空间共享还没有应用到Docker中 和相互独立的容器一样，Pod是一种相对短暂的存在，而不是持久存在的，正如我们在Pod的生命周期中提到的，Pod被安排到结点上，并且保持在这个节点上直到被终止（根据重启的设定）或者被删除，当一个节点死掉之后，上面的所有Pod均会被删除。特殊的Pod永远不会被转移到的其他的节点，作为替代，他们必须被replace ##### Pod的使用 Pod可以作为垂直应用整合的载体，但是它的主要特点是支持同地协作，同地管理程序，例如： * 内容管理系统，文件和数据加载，本地缓存等等 * 日志和检查点备份，压缩，循环，快照等等 * 数据交换监控，日志追踪，日志记录和监控适配器，以及事件发布等等 * 代理，网桥，适配器 * 控制，管理，配置，更新 总体来说，独立的Pod不会去加载多个相同的应用实例 Job负责批量处理短暂的一次性任务 (short lived one-off tasks)，即仅执行一次的任务，它保证批处理任务的一个或多个Pod成功结束。 #### Node Node是Pod真正运行的主机，可以物理机，也可以是虚拟机。为了管理Pod，每个Node节点上至少要运行container runtime（比如docker或者rkt）、kubelet和kube-proxy服务。  #### Job Kubernetes支持以下几种Job： > * 非并行Job：通常创建一个Pod直至其成功结束 > * 固定结束次数的Job：设置.spec.completions，创建多个Pod，直到.spec.completions个Pod成功结束 > *带有工作队列的并行Job：设置.spec.Parallelism但不设置.spec.completions，当所有Pod结束并且至少一个成功时，Job就认为是成功 根据.spec.completions和.spec.Parallelism的设置，可以将Job划分为以下几种pattern：  #### K8s操作命令 * 常用命令 ``` 查看所有命名空间的 pods kubectl get pods -A -n namespace 查看所有命名空间的 node kubectl get nodes -n namespace 获取Pods详细信息 kubectl describe 类型/具体名 -n namespace 查看所有命名空间的 pods分布的ip kubectl get pod -o wide -A -n namespace 获取Pods详细信息 kubectl describe pods 查看对外暴露的端口 kubectl get svc 查看命名空间 kubectl get ns ``` * kubectl命令集 ``` kubectl annotate – 更新资源的注解。 kubectl api-versions – 以“组/版本”的格式输出服务端支持的API版本。 kubectl apply – 通过文件名或控制台输入，对资源进行配置。 kubectl attach – 连接到一个正在运行的容器。 kubectl autoscale – 对replication controller进行自动伸缩。 kubectl cluster-info – 输出集群信息。 kubectl config – 修改kubeconfig配置文件。 kubectl create – 通过文件名或控制台输入，创建资源。 kubectl delete – 通过文件名、控制台输入、资源名或者label selector删除资源。 kubectl describe – 输出指定的一个/多个资源的详细信息。 kubectl edit – 编辑服务端的资源。 kubectl exec – 在容器内部执行命令。 kubectl expose – 输入replication controller，service或者pod，并将其暴露为新的kubernetes service。 kubectl get – 输出一个/多个资源。 kubectl label – 更新资源的label。 kubectl logs – 输出pod中一个容器的日志。 kubectl namespace -（已停用）设置或查看当前使用的namespace。 kubectl patch – 通过控制台输入更新资源中的字段。 kubectl port-forward – 将本地端口转发到Pod。 kubectl proxy – 为Kubernetes API server启动代理服务器。 kubectl replace – 通过文件名或控制台输入替换资源。 kubectl rolling-update – 对指定的replication controller执行滚动升级。 kubectl run – 在集群中使用指定镜像启动容器。 kubectl scale – 为replication controller设置新的副本数。 kubectl stop – （已停用）通过资源名或控制台输入安全删除资源。 kubectl version – 输出服务端和客户端的版本信息。 ``` ### k8s安装 后续会出对应的文章 [k8s中文文档](http://docs.kubernetes.org.cn/)