Kubernetes介绍（一）

本章节主要介绍应用程序在服务器上部署方式演变以及kubernetes的概念、组件和工作原理。

应用部署方式演变

在部署应用程序的方式上，主要经历了三个时代：
传统部署：互联网早期，会直接将应用程序部署在物理机上
优点：简单，不需要其它技术的参与
缺点：不能为应用程序定义资源使用边界，很难合理地分配计算资源，而且程序之间容易产
生影响

虚拟化部署：可以在一台物理机上运行多个虚拟机，每个虚拟机都是独立的一个环境
优点：程序环境不会相互产生影响，提供了一定程度的安全性
缺点：增加了操作系统，浪费了部分资源

容器化部署：与虚拟化类似，但是共享了操作系统
优点：
可以保证每个容器拥有自己的文件系统、CPU、内存、进程空间等
运行应用程序所需要的资源都被容器包装，并和底层基础架构解耦
容器化的应用程序可以跨云服务商、跨Linux操作系统发行版进行部署

容器编排工具的出现

容器化部署方式给带来很多的便利，但是也会出现一些问题，比如说：
① 一个容器故障停机了，怎么样让另外一个容器立刻启动去替补停机的容器
② 当并发访问量变大的时候，怎么样做到横向扩展容器数量

这些容器管理的问题统称为容器编排问题，为了解决这些容器编排问题，就产生了一些容器编排的软件：
Swarm：Docker自己的容器编排工具
Mesos：Apache的一个资源统一管控的工具，需要和Marathon结合使用
Kubernetes：Google开源的的容器编排工具

Kubernetes简介

kubernetes，是一个全新的基于容器技术的分布式架构领先方案，是谷歌严格保密十几年的秘密武器----Borg系统的一个开源版本，于2014年9月发布第一个版本，2015年7月发布第一个正式版本。

kubernetes的本质是一组服务器集群，它可以在集群的每个节点上运行特定的程序，来对节点中的容器进行管理。目的是实现资源管理的自动化，主要提供了如下的主要功能：

• 自我修复：一旦某一个容器崩溃，能够在1秒中左右迅速启动新的容器
• 弹性伸缩：可以根据需要，自动对集群中正在运行的容器数量进行调整
• 服务发现：服务可以通过自动发现的形式找到它所依赖的服务
• 负载均衡：如果一个服务起动了多个容器，能够自动实现请求的负载均衡
• 版本回退：如果发现新发布的程序版本有问题，可以立即回退到原来的版本
• 存储编排：可以根据容器自身的需求自动创建存储卷

Kubernetes组件

一个kubernetes集群主要是由控制节点(master)、工作节点(node)构成，每个节点上都会安装不同的组件。

master：集群的控制平面，负责集群的决策（管理）

ApiServer : 资源操作的唯一入口，接收用户输入的命令，提供认证、授权、API注册和发现等机制
Scheduler : 负责集群资源调度，按照预定的调度策略将Pod调度到相应的node节点上
ControllerManager : 负责维护集群的状态，比如程序部署安排、故障检测、自动扩展、滚动更新等
Etcd ：负责存储集群中各种资源对象的信息

node：集群的数据平面，负责为容器提供运行环境。

Kubelet : 负责维护容器的生命周期，即通过控制docker，来创建、更新、销毁容器
KubeProxy : 负责提供集群内部的服务发现和负载均衡
Docker : 负责节点上容器的各种操作

kube-apiserver

1.apiserver是 Kubernetes 控制平面的组件， 该组件负责公开了 Kubernetes API，负责处理接受请求的工作。 API 服务器是 Kubernetes 控制平面的前端/入口。

2.监听6443端口

[root@k8smaster kubernetes]# netstat -anplut|egrep "LISTEN.*apiserver" 
tcp6       0      0 :::6443                 :::*                    LISTEN      2828/kube-apiserver 
[root@k8smaster kubernetes]# 

3.会起一个容器

[root@k8smaster kubernetes]# docker ps|grep api
2c5d2509da7c   ca9843d3b545                                        "kube-apiserver --ad…"   About an hour ago   Up About an hour             k8s_kube-apiserver_kube-apiserver-k8smaster_kube-system_be11e4a1557f0b5c0b67f4205eccba74_1
210308d752d9   registry.aliyuncs.com/google_containers/pause:3.2   "/pause"                  About an hour ago   Up About an hour             k8s_POD_kube-apiserver-k8smaster_kube-system_be11e4a1557f0b5c0b67f4205eccba74_1
[root@k8smaster kubernetes]# 

etcd

1.一致且高可用的键值存储，用作 Kubernetes 所有集群数据的后台数据库。

2.起的容器

[root@k8smaster kubernetes]# docker ps|grep etcd
97acc159fe79   0369cf4303ff                                        "etcd --advertise-cl…"   About an hour ago   Up About an hour             k8s_etcd_etcd-k8smaster_kube-system_2ab7e116655c35c493249ee469b3f715_1
225e24d965cd   registry.aliyuncs.com/google_containers/pause:3.2   "/pause"                  About an hour ago   Up About an hour             k8s_POD_etcd-k8smaster_kube-system_2ab7e116655c35c493249ee469b3f715_1
[root@k8smaster kubernetes]#  

3.监听2624端口

[root@k8smaster kubernetes]# netstat -anplut|grep etcd
tcp        0      0 192.168.2.221:2379      0.0.0.0:*               LISTEN      2624/etcd           
tcp        0      0 127.0.0.1:2379          0.0.0.0:*               LISTEN      2624/etcd           
tcp        0      0 192.168.2.221:2380      0.0.0.0:*               LISTEN      2624/etcd           
tcp        0      0 127.0.0.1:2381          0.0.0.0:*               LISTEN      2624/etcd  

kube-scheduler

1.负责监视新创建的、未指定运行节点（node）的 Pods， 并选择节点来让 Pod 在上面运行。(调度器)

计划决策（调度策略）考虑的因素包括： 个人和集体资源要求、硬件/软件/策略 约束、亲和力和反亲和性规范、数据局部性、 工作负载间干扰和截止日期。

2.监听3090端口

[root@k8smaster kubernetes]# netstat -anplut|grep scheduler
tcp        0      0 127.0.0.1:10259         0.0.0.0:*               LISTEN      3090/kube-scheduler 
tcp        0      0 192.168.2.221:52492     192.168.2.221:6443      ESTABLISHED 3090/kube-scheduler 
tcp        0      0 192.168.2.221:52494     192.168.2.221:6443      ESTABLISHED 3090/kube-scheduler 
[root@k8smaster kubernetes]# 

3.起的容器

[root@k8smaster kubernetes]# docker ps|grep scheduler
cbbcc1ba0077   3138b6e3d471                                        "kube-scheduler --au…"   About an hour ago   Up About an hour             k8s_kube-scheduler_kube-scheduler-k8smaster_kube-system_0378cf280f805e38b5448a1eceeedfc4_1
f271c78c0627   registry.aliyuncs.com/google_containers/pause:3.2   "/pause"                  About an hour ago   Up About an hour             k8s_POD_kube-scheduler-k8smaster_kube-system_0378cf280f805e38b5448a1eceeedfc4_1
[root@k8smaster kubernetes]# 

kube-controller-manager

1.控制器-管理器 负责运行控制器进程。

2.

cloud-controller-manager

1.嵌入了特定于云平台的控制逻辑

2.与公有云进行对接的控制器

kubelet

1.单独的程序，在宿主机里运行（不使用容器）,保证容器都在pod中运行,指挥docker去工作，调用docker去启动需要的容器。

[root@k8smaster kubernetes]# ps aux|grep kubelet

root 1020 6.7 2.2 1951916 87964 ? Ssl 09:58 7:01 /usr/bin/kubelet

kube-proxy

1.单独的程序，在宿主机（节点）里运行。是一个网络代理， 实现 Kubernetes 的一部分服务概念。

[root@k8smaster kubernetes]# ps aux|grep kube-proxy
root       3548  0.2  0.8 744320 32848 ?        Ssl  09:59   0:13 /usr/local/bin/kube-proxy --config=/var/lib/kube-proxy/config.conf --hostname-override=k8smaster
root     100881  0.0  0.0 112828   992 pts/0    S+   11:42   0:00 grep --color=auto kube-proxy
[root@k8smaster kubernetes]# 

2.是集群中每个节点（node）上所运行的网络代理，它负责：

网络的数据的进出

负载均衡

kube-proxy 维护节点上的一些网络规则， 这些网络规则会允许从集群内部或外部的网络会话与 Pod 进行网络通信。

如果操作系统提供了可用的数据包过滤层，则 kube-proxy 会通过它来实现网络规则。 否则，kube-proxy 仅做流量转发。

Kubernetes概念（对象）

• Master：集群控制节点，每个集群需要至少一个master节点负责集群的管控。
• Node：工作负载节点，由master分配容器到这些node工作节点上，然后node节点上的docker负责容器的运行。
• Pod：kubernetes的最小控制单元，容器都是运行在pod中的，一个pod中可以有1个或者多个容器。
• Controller：控制器，通过它来实现对pod的管理，比如启动pod、停止pod、伸缩pod的数量等等。(deployment-部署控制器、replicaSet-副本控制器、daemonSet-守护进程控制器、job-批处理控制器、cronjob-计划任务控制器)
• Service：pod对外服务的统一入口，下面可以维护者同一类的多个pod。
• Label：标签，用于对pod进行分类，同一类pod会拥有相同的标签。
• NameSpace：命名空间，用来隔离pod的运行环境。
• ......

我将它们简单的分类为以下几种资源对象：

类别	名称
资源对象	Pod、ReplicaSet、ReplicationController、Deployment、StatefulSet、DaemonSet、Job、CronJob、HorizontalPodAutoscaling、Node、Namespace、Service、Ingress、Label、CustomResourceDefinition
存储对象	Volume、PersistentVolume、Secret、ConfigMap
策略对象	SecurityContext、ResourceQuota、LimitRange
身份对象	ServiceAccount、Role、ClusterRole

在 Kubernetes 中创建对象时，必须提供描述其对象规范的对象规范 所需状态，以及有关对象的一些基本信息（例如名称）。当您使用 Kubernetes API 来创建对象（直接或通过 ），该 API 请求必须 将该信息作为 JSON 包含在请求正文中。 大多数情况下，您将信息提供给称为清单的文件。 按照惯例，清单是 YAML格式（也可以使用 JSON 格式）。 

下面是一个示例清单，显示了 Kubernetes 的必填字段和对象规范 部署，具体YAML文件格式请看下一篇文章。

[root@master pod]# cat simple-pod.yaml 
apiVersion: v1      #api接口的版本
kind: Pod           #资源类型
metadata:            #元数据，对资源进行描述的数据
  name: nginx          #pod的元数据指定pod的名字
spec:                  #具体的某个资源对象的详细信息  --》具体的数据的说明
  containers:         #容器
  - name: nginx        #容器的名字
    image: nginx:1.14.2 #镜像的名字和版本
    ports:              #容器监听的端口
    - containerPort: 80   #具体的端口
[root@master pod]#
Restful 接口规范

[root@master pod]# cat nginx-deployment.yaml 
apiVersion: apps/v1 
kind: Deployment
metadata:
  name: nginx-deployment
  labels:          #打标签
    app: nginx       #具体的标签，一般采用key对应得value ，key可以自己定义
spec: 
  replicas: 3   #指定pod副本的数量  pod的数量
  selector:       #选择器，我们的副本控制器去匹配需要启动的容器的配置
    matchLabels:  #具体匹配的标签
      app: nginx    #根据app的值去找nginx的标签
  template:  #模板： 是启动pod的模板
    metadata:  #模板的启动pod的元数据
      labels:  #给启动的pod打的标签
        app: nginx  #具体的标签
    spec: 
      containers:
      - name: nginx
        image: nginx:1.14.2
        ports:
        - containerPort: 80

[root@master pod]#