kubernetes简介-k8s_1 #3
Comments
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
title: kubernetes简介-k8s_1
date: 2017-08-09 20:55:48
tags:
什么是Kubernetes？
Kubernetes（k8s）是自动化容器操作的开源平台，这些操作包括部署，调度和节点集群间扩展。如果你曾经用过Docker容器技术部署容器，那么可以将Docker看成Kubernetes内部使用的低级别组件。Kubernetes不仅仅支持Docker，还支持其他的容器技术，比如Rocket。
使用Kubernetes可以：
由于kubernetes较长，因此很多人都习惯简写成k8s，用8替换中间的8个字母，类似于i18n（internationalization，国际化）。后面我们的介绍都是用k8s替代kubernetes。
“Kubernetes”是古希腊词汇，其原意是“万能的神”，因为希腊是航海大国，不可预测的海上风浪经常会引起翻船事故，为保佑船只和人的安全，古希腊人引用“万能的神”这个词作为舵手。
而Docker的意思是集装箱，正好让舵手掌管装载集装箱的船的航向，很贴切。
k8s相关概念
k8s中的概念很多，如Master、Node、Pod、Container、Service、Namespace、Replication Controller、Deployment、Endpoint、Volume、Label等等。要使用好k8s，首先要了解这些概念，下面来介绍一下这些概念。
在了解这些概念之前，我们先来看一下k8s的一个典型组网。
这个图中涉及了很多相关的概念。
kubernetes集群
kubernets集群由k8s master和node组成。这个组网中就1个master和2个node，在生产环境中master一般有多个（2n+1）组成一个集群，来实现高可用性。node可以有很多个，当node不够用时，可以不断扩容。node的规模需要master来支撑，因为单个master所能管理的node节点的个数是有限的。
master
master是集群的控制节点，负责整个集群的管理和控制。master节点可以运行在物理机或虚拟机中，因为它是整个集群的“大脑”，非常重要，所以要保证它的可用性与可靠性。可以把它独占一个物理机，或者放到虚拟机中，用master集群来保证其可靠性。
k8s master由三个组件(进程)组成：
另外，集群中还有一个etcd进程，k8s里面的所有资源的数据全部保存在etcd中。这里也是一个etcd节点，生产环境中一般用集群。etcd 是一个应用在分布式环境下的 key/value 存储服务。利用 etcd 的特性，应用程序可以在集群中共享信息、配置、leader选举或作服务发现，etcd 会在集群的各个节点中复制这些数据并保证这些数据始终正确。
node
除了master，k8s集群中的其他节点是node节点。node节点可以是一台物理机或者虚拟机。node节点是k8s集群中的工作负载节点，master会把一些任务调度到node节点上进行。当某个node出现故障时，master会把这个节点上的任务转移到其他节点上。
每个node节点上会运行3个组件（进程）：
Node节点可以在运行期间动态添加到k8s集群，在默认情况下kubelet会向Master注册自己。一旦node被纳入集群管理范围，kubelet进程就会定时向Master节点汇报自身的情况，例如操作系统、Docker版本、cpu和内存、运行的pod等，这样master可以获得每个node的资源情况，可以实现高效的资源调度。
而某个Node超过指定时间不上报信息时，Master会认为此node失效了，会把此node的状态标记为不可用（Not Ready）,随后会根据一些策略将此Node上的Pod进行转移。
Pod
Pod是Kubernetes最基本的操作单元，包含一个或多个紧密相关的容器；一个Pod中的多个容器应用通常是紧密耦合的，Pod在Node上被创建、启动或者销毁；每个Pod里运行着一个特殊的被称之为“根容器”的Pause容器，还包含一个或多个业务容器，这些业务容器共享Pause容器的网络栈和Volume挂载卷，因此他们之间通信和数据交换更为高效。同一个Pod里的容器之间仅需通过localhost就能互相通信。
k8s会为每个pod都分配一个唯一的IP地址（至少在node节点上是唯一的），称之为PodIP，一个pod的里的多个容器共享PodIP。
Pod被创建后，k8s master会将其调度到某个具体的Node上，随后该Node上的kubelet进程会将Pod中的一组容器启动。在默认情况下，当pod里面的某个容器停止时，k8s会自动检测到这个又问题的Pod，并重新启动这个Pod（重启Pod里的所有容器）。如果Pod所在的Node出现故障，不可用了，则K8s会将这个Node上的Pod重新调度到其他节点上（这个调度需要Replication Controller或者Deployment的支持）。
Label
上图中Node或pod上，都有一个小的标识，那个就是Label。一个Label是一个key=value的键值对，其中key和value均可自定义。Label可以附加到各种资源对象上，例如Pod、Node/Service等，每个资源对象都可以定义任意多个Label，Label可以动态的增加或者删除。
Label的作用是：通过给指定的资源对象绑定一个或多个Label，来实现多维度的资源分组管理，以便灵活的进行资源分配、调度、配置和部署等。给某个资源加上Label后，后面就可以通过Label Selector查询和筛选有某些Label的资源对象。
当前Label Selector有两种表达式：基于等式的（Equality-based）和基于集合的（Set-based）。
where name=anan，例如：name=dbnode:匹配具有标签是name=dbnode的资源对象。name in (dbnode，biznode,plnode),匹配所有具有Label：name=dbnode或name=biznode或name=plnode的资源对象。EndPoint
每个Pod都会有一个IP，而Pod中的容器都会开放一些端口对外提供服务，这个端口被称为容器端口（ContainerPort），PodIP+ContainerPort就组成了一个新概念——EndPoint。它代表了此Pod中的一个服务进程的对外同曦地址。当然一个Pod可以存在多个EndPoint，这取决于pod中的业务容器。
Service
从上Pod的介绍中，可以知道：Pods是短暂的，可能会重启或者转移，这样IP地址可能会改变，如果这个PodIP经常变化，我们就无法正常的使用它了。
Service是定义一组Pod以及访问这些Pod的策略的一层抽象。Service通过Label找到Pod组。因为Service是抽象的，所以在图表里通常看不到它们的存在，这也就让这一概念更难以理解。
K8s的Service定义了一个服务的访问入口地址，一组应用可以通过这个入口地址访问其背后的一组Pod组成的集群实例，Service可以通过Label Selector将一组pod纳入到此Service中。
每个Pod都有一个IP，而每个Pod都有一个独立的EndPoint被客户端访问，那么多个Pod副本组成的一个集群来提供服务的话，客户端就需要负载均衡来访问它们。K8s的负载均衡是通过Node上的kube-proxy来实现的（后面会专门写一篇博客来讲它，这一块关于网络的东西很有意思，而且我在工作中接触的也比较多，所以比较熟悉，研究了很多实例，并且看了kube-proxy的源码）。可以通过下图来描述Service的使用。
每个Service会分配一个全局唯一的虚拟IP地址，这个IP被称为ClusterIP。这样，每个服务就只有一个唯一入口，客户端调用就无需关心这个服务有多少个Pod提供。ClusterIP在Service的整个生命周期内是不会变化的，所以Pod重启或者因Node失效进行了转移，也不会影响到Service。
上面的讲述中，我们已经提到了3种IP：
有一些情况下，服务是要提供给集群外的应用来使用的，当然k8s也提供了方法，后面再详细讲解。
Replication Controller 和 Replica Set
Replication Controller(后文简称RC)是kube-controller-manager组件中的一个Controller，它定义了一个期望的场景，即使得某个Pod的副本数量在任意时刻都满足某种期望值。RC的定义包含如下几个部分：
当定义了一个RC并提交到k8s集群后，master上的controller manager就会得到通知，定期检查集群中当前存活的目标Pod，并确保目标Pod的实例的数量等于RC的期望值。如果有过多的Pod在运行，就会停掉多的Pod，如果数量不够，则再根据Pod模版创建一些Pod。
下面的动图展示了一个例子：
Replication Controller是k8s中最开始版本的Pod自动管理和调度工具，它只支持基于等式的Label Selector，有一定的局限性，k8s 1.2版本中引入了Replica Set，是“下一代的RC”，它与RC的唯一区别是：Replica Set支持基于集合的Label Selector。这样Replica Set的功能更强大。
Deployment
Deployment也是k8s 1.2引入的新概念，它的目的是更好的解决Pod的编排问题。Deployment无论是作用与目的、yaml定义文件，还是使用方式，都和RC很相似，可以看作是RC的一次升级。Deployment内部使用Replica Set来实现Pod的部署与调度。
Delpoyment有如下几个典型的使用场景：
Volume
上文中讲到，Pod可能被重启或转移，那么Pod中的容器中保存的文件就会丢失，为了解决这个问题，k8s提出了Volume的概念。当然，Volume还有一个作用是解决Pod中的容器之间的文件共享。
Volume是Pod中能够被多个容器访问的共享目录。k8s的Volume概念、用途和目的与Docker的Volume很类似，但是又不完全相同。
小结
上面介绍了k8s的相关概念，对k8s有了一个大概的认识。
多说无益，实践最重要，我们就来手动安装一下k8s集群来进行实践。
参考
The text was updated successfully, but these errors were encountered: