概述

Kubernetes的搭建与使用少不了网络基础设施的搭建工作， 本文简述了Kubernetes所需要的网络基础环境，Docker的网络实现以及Kubernetes的网络实现。最后，简单提了一下可以实现这些网络基础的网络开源组件Flannel。希望可以通过这些简单的语言描述，让初学者能够初步了解Kubernetes的网络原理。

Kubernetes网络模型

Kubernetes网络模型设计的基础原则：每个Pod都有一个独立的IP地址，这样Pod之间可以直接进行通信，无论它们是否在同一个Node上。而且用户就不需要考虑将容器的端口映射到节点的物理端口上了。

一个Pod分配一个独立的IP，一个Pod内部的所有容器共享一个Linux网络堆栈，包括它们的IP地址、网络设备、配置等都是共享的。所以容器之间是可以通过localhost来连接对方端口的。从这个层面来看，Pod内部容器之间的隔离性相比于不同Pod的容器有所降低，但也只是它们不用相同的端口而已。Pod中的容器有点类似于VM中的进程。

Kubernetes网络模型的必要基础：
1.集群中所有的容器和容器之间可以不通过NAT进行通信
2.节点可以不通过NAT与任一容器进行通信
3.容器的地址和别人看到的地址是一样的

就是说，并不是节点安装了Kubernetes与Docker就可以工作了。还必须满足以上的网络模型才行。而原生的Docker并不能很好的支持这些要求。所以需要一些网络组件来满足这些基础网络要求。

Docker的网络基础

Docker本身的技术依赖于近年来Linux内核虚拟化技术的发展，所以Docker对Linux内核有很强的依赖性。这接下来讲述一下Docker使用到的与Linux网络有关的主要技术。

网络的命名空间

网络命名空间代表的是一个独立的协议栈，所以它们之间是相互隔离的。Docker利用了网络的命名空间特性，实现了不同容器之间网络的隔离。

Veth设备对

引入Veth设备对的目的是让两个网络命名空间进行通信。在Docker内部，Veth设备对也是联系容器到外面的重要设备，离开它是不行的。

网桥

网桥是二层交换机（数据链路层），转发的依据是MAC地址。
在Linux的内部网络栈里也实现了网桥设备，与实际的网桥设备作用相似。是Linux内部各种网络设备之间相互转发数据的二层设备。但Linux网桥与实际的交换机又有不同之处，因为它不仅可能会转发或丢弃，还可能被送到网络协议栈的上层（网络层），从而被自己（网络协议栈）所消化。

Iptables/Netfilter

iptables-save命令可以查看Iptables中的内容

我们可以看到service的IP转发到Pod的IP

路由

Linux系统包含一个完整的路由功能。当IP层进行数据的发送或转发时，会使用路由表来决定发往哪里。

Docker的网络实现

标准的Docker支持四种网络模式：host、container、none、bridge。
在Kubernetes管理模式下，通常只会使用bridge模式。如图：



使用ip route show table local type local可以查看本地设备的地址，也显示了docker0网桥的IP地址
这样，在节点内部容器之间可以相互通信，在节点外部则不行。必须将容器的端口映射到主机的端口上才行，docker在跨主机通信时会面临很多的问题。

Kubernetes的网络实现

Kubernetes网络设计主要解决以下场景：
1.容器之间的通信
2.Pod之间的通信
3.Pod到Service之间的通信
4.集群外部与内部组件之间的通信

容器之间的通信

同一个Pod下的容器共享同一个网络命名空间，共享同一个Linux协议栈。所以它们就像在同一台机器上一样。可以相互之间直接通信。可以用localhost访问彼此的端口。

如果容器2运行的是mysql容器，那么容器1通过localhost:3306就直接能够访问运行在容器2上的Mysql了。当然，既然像是在同一台机器上的不同进程，那么它们之间也就是可以通过IPC（进程间通信）进行通信（如消息队列或管道）。

Pod之间的通信

同一Node内的Pod之间的通信

同一个Node内的不同Pod都是通过Veth连接在同一个Docker0网桥上的。所以它们之间是可以直接进行通信的。而且，非本地数据的网络数据都是默认发送到Docker0网桥然后由它进行中转的。
Docker0网桥会路由到节点上的所有Pod的，这个可以通过看Kubernetes任一节点上的路由表了解

这个就表示docker0的IP地址为10.0.82.1，而该节点上的Pod都是10.0.82网段的。

不同Node上的Pod之间的通信

不同Node上的Pod与Pod之间进行通信，肯定是要通过节点的物理网卡的。而且不同的Pod肯定是不能有相同的私有IP的。另外，我们还必须要有Node IP找到该Pod的IP才成。
对于这些要求，Flannel就可以做得到。

开源的网络组件

Kubernetes是谷歌的开源项目，它假定了所有的Pod都是在一个可以直接连通的扁平的网络空间中，因为它建立在GCE上，而GCE已经实现了这些要求。

但是对于一个私有云来说，要想用Kubernetes就必须自己来实现这个网络假设。有些开源软件可以做到这些。

Flannel

Flannel实现了两点来保证Kubernetes的底层网络：
1.保证集群中每个Pod的IP不冲突
2.建立了一个覆盖网络，保证数据可以在不同节点之间的Pod传递（通过Pod节点路由表可以找到Pod与节点的对应关系）

概述

本文试图用简单的语言描述Kubernetes主要组件的作用及其关系。这里我讲解的Kubernetes主要组件有API Server、Controller Manager、Scheduler、kubelet、kube-proxy，其中前三者运行于集群的Master节点，后两者运行于集群的Slave节点。接着描述了一下用于存储Kubernetes集群信息的Etcd，它是一个高可用、强一致性的服务发现存储仓库。最后，我抛出了一个我所遇到的一个问题。大家可以一同思考一下问题出在了哪里。

API Server

Kubernetes API Server通过kube-apiserver进程提供服务，该进程运行于Master节点上。

API Server是Kubernetes的核心组件，是各个组件通信的渠道，有如下特性：

1.集群管理的API入口

我们如果要创建一个资源对象如Deployment、Service、RC、ConfigMap等，都是要通过API Server的。

当然，我们可能是通过命令行的kubectl命令将一个yaml/json格式的文件create进行创建，还可能是通过写代码的方式使用如client-go这样的操作Kubernetes的第三方包来操作集群。总之，最终，都是通过API Server对集群进行操作的。通过API Server，我们就可以往Etcd中写入数据。Etcd中存储着集群的各种数据。

2.资源配额控制的入口

Kubernetes可以从各个层级对资源进行配额控制。如容器的CPU使用量、Pod的CPU使用量、namespace的资源数量等。这也是通过API Server进行配置的。将这些资源配额情况写入到Etcd中。

3.提供了完备的集群安全机制

Controller Manager

Replication Controller

副本控制器。用来保证Deployment或者RC中副本的数量的。

Node Controller

通过API Server监控Etcd中存储的关于节点的各类信息，这些信息是kubelet定时推给API Server的，由API Server写入到Etcd中。这些节点信息包括：节点健康状况、节点资源、节点名称、节点地址信息、操作系统版本、Docker版本、kubelet版本等。监控到节点信息若有异常情况，则会对节点进行某种操作，如节点状态变为故障状态，则删除节点与节点相关的Pod等资源的信息。

ResourceQuota Controller

将期望的资源配额信息通过API Server写入到Etcd中。然后ResourceQuota Controller会定时的统计这些信息，在系统请求资源的时候就会读取这些统计信息，如果不合法就不给分配该资源，则创建行为会报错。

Namespace Controller

用户是可以通过API Server创建新的namespace并保存在Etcd中的。Namespace Controller会定时通过API Server读取这些Namespace信息并做对应的对于Namespace的一些操作。

Endpoints Controller

负责生成和维护所有Endpoints对象的控制器。Endpoints表示了一个Service对应的所有Pod副本的访问地址。

一个Service可能对应了多个Endpoints，那么，在创建一个新的Service时Endpoints Controller就会生成对应的Endpoints。在Service被删除时，Endpoints Controller就会删除对应的Endpoints。等等。

Scheduler

Kubernetes的调度器。Scheduler监听API Server，当需要创建新的Pod时。Scheduler负责选择该Pod与哪个Node进行绑定。将此绑定信息通过API Server写入到Etcd中。

若此时与Node A进行了绑定，那么A上的Kubelet就会从API Server上监听到此事件，那么该Kubelet就会做相应的创建工作。

此调度涉及到三个对象，待调度的Pod，可用的Node，调度算法。简单的说，就是使用某种调度算法为待调度的Pod找到合适的运行此Pod的Node。

关于Kubernetes Scheduler的调度算法，我会再另写一篇文章。

Kubelet

每个Node节点上都会有一个Kubelet负责Master下发到该节点的具体任务，管理该节点上的Pod和容器。而且会在创建之初向API Server注册自身的信息，定时汇报节点的信息。它还通过cAdvisor监控容器和节点资源。

节点管理

Kubelet在创建之初就会向API Server做自注册，然后会定时报告节点的信息给API Server写入到Etcd中。默认为10秒。

Pod管理

Kubelet会监听API Server，如果发现对Pod有什么操作，它就会作出相应的动作。例如发现有Pod与本Node进行了绑定。那么Kubelet就会创建相应的Pod且调用Docker Client下载image并运行container。

容器健康检查

有三种方式对容器做健康检查：
1.在容器内部运行一个命令，如果该命令的退出状态码为0，则表明容器健康。
2.TCP检查。
3.HTTP检查。

cAdvisor资源监控

Kubelet通过cAdvisor对该节点的各类资源进行监控。如果集群需要这些监控到的资源信息，可以安装一个组件Heapster。

Heapster会进行集群级别的监控，它会通过Kubelet获取到所有节点的各种资源信息，然后通过带着关联标签的Pod分组这些信息。

如果再配合InfluxDB与Grafana，那么就成为一个完整的集群监控系统了。

Kube-proxy

负责接收并转发请求。Kube-proxy的核心功能是将到Service的访问请求转发到后台的某个具体的Pod。

无论是通过ClusterIP+Port的方式还是NodeIP+NodePort的方式访问Service，最终都会被节点的Iptables规则重定向到Kube-proxy监听服务代理端口，该代理端口实际上就是SocketServer在本地随机打开的一个端口，SocketServer是Kube-proxy为每一个服务都会创建的“服务代理对象”的一部分。

当Kube-proxy监听到Service的访问请求后，它会找到最适合的Endpoints，然后将请求转发过去。具体的路由选择依据Round Robin算法及Service的Session会话保持这两个特性。

Etcd

Etcd一种k-v存储仓库，可用于服务发现程序。在Kubernetes中就是用Etcd来存储各种k-v对象的。

所以我也认为Etcd是Kubernetes的一个重要组件。当我们无论是创建Deployment也好，还是创建Service也好，各种资源对象信息都是写在Etcd中了。

各个组件是通过API Server进行交流的，然而数据的来源是Etcd。所以维持Etcd的高可用是至关重要的。如果Etcd坏了，任何程序也无法正常运行了。

以下是我的环境中的Etcd集群

通过以下命令我们就可以看到该集群中yce这个namespace下的pod有哪些，此为目录，列出的都是键值

接下来，我们就可以查看某一个具体键值的value值

可以看到这个value值是一个Json格式的文件。

一个问题

我做了一个实验，如果从Etcd中直接改yce这个deployment的Json值，从replicas的值从1改到3，发现deployment的desired值发生了变化，但是current值并没有变化，也就是说，Pod的数量并没有因为Etc中的值的改变而改变。难道是因为Replicas Controller没有监控到Etcd中的此变化？




如上所示，更改了Etcd中deployment的replicas的值之后，可以用kubectl edit看到该deployment的replicas值确实发生了变化。但是deployment的current值却并无变化。

若是用kubectl edit更改deployment的replicas值就会发现deployment的current值是会发生变化的。请大家思考一下这是为什么。

总结

Kubernetes的这些组件各自分别有着重要的功能。它们之间协同工作，共同保证了Kubernetes对于容器化应用的自动管理。

其中API Server起着桥梁的作用，各个组件都要通过它进行交互。Controller Manager像是集群的大管家，管理着许多事务。Scheduler就像是一个调度亭，负责Pod的调度工作。

Kubelet则在每个节点上都有，像是一个执行者，真正创建、修改、销毁Pod的工作都是由它来具体执行。Kube-proxy像是负载均衡器，在外界需要对Pod进行访问时它作为代理进行路由工作，将具体的访问分给某一具体的Pod实例。

Etcd则是Kubernetes的数据中心，用来存储Kubernetes创建的各类资源对象信息。

这些组件缺一不可，无论少了哪一个Kubernetes都不能进行正常的工作。这里大概讲了下各组件的功能，感兴趣的可以分析Kubernetes的源码，github中就有。

背景

client-go是go语言访问Kubernetes API的一种新的框架。本文记录client-go访问Kubernetes的过程。最终实现了给服务器端发送container ID，服务器端会返回该container所在pod的pod Name与Spacename。我们Kubernetes集群中一个pod都只运行了一个container。
程序用httprouter包来作为http的访问接口。返回的值编码为Json文件，客户拿到Json之后再进行解析，最终拿到需要的信息。如图：

程序实现基本功能之后，用Dockerfile将程序打包成docker镜像。

源代码

package main

import (
    "flag"
    "fmt"
    "github.com/julienschmidt/httprouter"
    "net/http"
    "io"
    "io/ioutil"
    apiv1 "k8s.io/api/core/v1"
    metav1 "k8s.io/apimachinery/pkg/apis/meta/v1"
    "k8s.io/client-go/kubernetes"
    "k8s.io/client-go/tools/clientcmd"
    "encoding/json"
)

type Container_msg struct {
    Name string
    Namespace string
}

func main() {
    router := httprouter.New()

    kubeconfig := flag.String("kubeconfig", "", "absolute path to the kubeconfig file")
    flag.Parse()

    if *kubeconfig == "" {
        panic("-kubeconfig not specified")
    }

    config, err := clientcmd.BuildConfigFromFlags("", *kubeconfig)
    if err != nil {
        panic(err)
    }

    clientset, err := kubernetes.NewForConfig(config)

    if err != nil {
        panic(err)
    }

    router.POST("/api/v1/containerID",func(w http.ResponseWriter, r *http.Request, _ httprouter.Params){

        podsClient := clientset.Pods(apiv1.NamespaceAll)

        // List Pods
        list, err := podsClient.List(metav1.ListOptions{
        })
        if err != nil {
            panic(err)
        }

        body,_ := ioutil.ReadAll(io.LimitReader(r.Body,1122334))


        for _, d := range list.Items {
            containerID := d.Status.ContainerStatuses[0].ContainerID[9:]
            if string(body)==containerID{
                container_msg := Container_msg{
                    d.Name,
                    d.Namespace,
                }

                c,err := json.Marshal(container_msg)

                if err != nil{
                    panic(err)
                }

                fmt.Fprintf(w,"%v", c)
            }
        }
    })
        http.ListenAndServe(":8082", router)
}

具体实现

上面我已经先把程序的源代码贴出来了，接下来就进行逐步分析

1.获取第三方包client-go与httprouter

https://github.com/kubernetes/client-go
https://github.com/julienschmidt/httprouter
进入它们的github中看使用说明按步骤安装即可。
简单来说，就是分别使用go get k8s.io/client-go/…与go get github.com/julienschmidt/httprouter命令即可。
不过要记得在安装之前配置GOPATH环境变量。比如我的项目是放在naruto目录中的，所以我的GOPATH设置为naruto目录。
配置完GOPATH环境变量，安装完第三方包，我们就可以直接使用它们了。

2.使用httprouter包中的方法获取客户发来的container ID

router := httprouter.New()

建立http连接

http.ListenAndServe(":8082", router)
在8082端口进行监听

router.POST
获取客户端POST的数据

3.用client-go获取Kubernetes集群中pod信息

clientset, err := kubernetes.NewForConfig(config)
使用config建立client-go与Kubernetes集群的关系
config文件是Kubernetes集群的配置文件，存放在集群Master节点的～/.kube/config中
建立好连接之后， 我们就可以使用clientset的对应方法来获取pod或deployment等对象资源的信息。

4.比较获取到的container ID与集群中各pod的container ID

因为我们集群中一个pod仅运行着一个container，所以，我们只需要将pod中container的ID得到之后与获取到的客户发来了container ID做比较即可。假如相等，就可以把此pod的信息返回给客户端。

body,_ := ioutil.ReadAll(io.LimitReader(r.Body,1122334))

for _, d := range list.Items {
    containerID := d.Status.ContainerStatuses[0].ContainerID[9:]
    if string(body)==containerID{
     container_msg := Container_msg{
               d.Name,
               d.Namespace,
           }

     c,err := json.Marshal(container_msg)

      if err != nil{
             panic(err)
           }

     fmt.Fprintf(w,"%v", c)

打包成docker镜像

通过编写Dockerfile文件来建立一个新的镜像。

FROM img.reg.3g:15000/go:1.8     //以这个镜像为基础镜像
COPY naruto /pf      //将naruto目录下的文件复制到容器中文件系统／目录下的pf目录中
ENV GOPATH /pf            //配置环境变量
RUN go build /pf/main_v1.go   //编译写好的程序
CMD /main_v1 -kubeconfig=/pf/config   //以运行该程序的进程为容器的主进程

我们需要将main.go、config、第三方包、Dockerfile都放在同一目录下。通过docker build命令建立镜像。

背景

相信大家应该都在自己的电脑中部署过tomcat与mysql集群，我们可以通过访问tomcat来访问后台数据库。kubernetes是一个可自动部署、扩缩、管理容器化应用的工具。本篇博客主要讲解如何在kubernetes中部署tomcat与mysql集群。当然，这涉及到kubernetes的自动化部署功能。至于扩缩、管理功能，我这里就不详述了，以后有机会再讲解。

基础

在kubernetes中部署tomcat与mysql集群之前必须要有以下这些基础：

1. 已安装、配置kubernetes
2. 集群中有tomcat与mysql容器镜像
3. 有docker基础

具体步骤

部署tomcat

创建tomcat RC对象

我们想要在kubernetes集群中配置tomcat服务器，首先要保证集群中的节点上有tomcat镜像，镜像可以从docker Hub中拉取，也可以放在自己的私有仓库中。这在我之前的博客中讲过，这里就不详述了。

要部署tomcat服务，我们需要做两件事，一是创建RC（Replication Controller），二是创建Service。RC是kubernetes中的副本控制器，也就是说，RC负责自动部署容器化应用。Service是我们访问tomcat服务的入口地址，我们是通过Service来对该服务就行访问的。

创建RC与Service对象，我这里用的是创建yaml文件的方式。yaml文件中的内容是声明式的。这些声明让kubernetes做你想要它做的事情。声明与命令有所不同，声明是告诉它你的需要是什么，而不涉及具体的实现的步骤，而命令，如linux中的ls，你是告诉它去做什么。声明与命令是不同的，请自己体会。话不多说了，上代码：

  1 apiVersion: v1
  2 kind: ReplicationController
  3 metadata:
  4   name: myweb
  5 spec:
  6   replicas: 5
  7   selector:
  8     app: myweb
  9   template:
 10     metadata:
 11       labels:
 12         app: myweb
 13     spec:
 14       containers:
 15       - image: kubeguide/tomcat-app:v1
 16         name: myweb
 17         resources:
 18           limits:
 19             cpu: "2"
 20             memory: 4Gi
 21         ports:
 22         - containerPort: 8080
 23         env:
 24         - name: MYSQL_SERVICE_HOST
 25           value: 'mysql'
 26         - name: MYSQL_SERVICE_PORT
 27           value: '3306'

如上所示就是我写的yaml文件，此文件名为myweb-rc1.yaml
这里我简单的说明一下此yaml文件声明了什么：

  1 apiVersion: v1      //描述RC对象的版本是v1
  2 kind: ReplicationController    //我现在在声明RC对象
  3 metadata:     //metadata中的是对此RC对象描述信息
  4   name: myweb      //此RC对象在default命名空间中名为myweb，同一个命名空间中的命名一定是不同的
  5 spec:     //spec中是对RC对象的具体描述
  6   replicas: 5    //我要创建5个副本，单位当然是pod
  7   selector:      //选择器，用来选择对象的
  8     app: myweb    //我选择了标签为app: myweb的pod
  9   template:     //模版，以下用来描述创建的pod的模版
 10     metadata:   //对pod模版描述的元数据
 11       labels:      //给以下的东西打上标签，以让selector来选择
 12         app: myweb   //给pod模版打上app: myweb这样的标签
 13     spec:             //对pod模版的具体描述
 14       containers:         //以下就是要放入pod模版中的容器了
 15       - image: kubeguide/tomcat-app:v1    //选择镜像
 16         name: myweb         //容器名
 17         resources:           //给该容器分配的资源大小
 18           limits:
 19             cpu: "2"
 20             memory: 4Gi
 21         ports:         //容器端口号
 22         - containerPort: 8080         
 23         env:          //给该容器设置环境变量，这里就可以将mysql与我们的tomcat连接
 24         - name: MYSQL_SERVICE_HOST
 25           value: 'mysql'
 26         - name: MYSQL_SERVICE_PORT
 27           value: '3306'

大家可能看完比较蒙，仔细研究就发现其实yaml文件的规范还是比较严谨的。它是通过缩进与对齐的方式来表达了具体的信息的。比如一个metadata，在我这个yaml文件中就有两个。实际上通过缩进与对齐，我们就可以了解到，第一个metadata是对这个RC对象进行描述的元数据，而第二个metadata因为缩进了，实际上它是对pod模版进行描述的元数据。当然是不一样的。spec也有两个，同样的道理，大家可以自行分析。

创建tomcat RC对象的结果

如下，我截了个屏：

可以看到，我在创建完了tomcat的RC对象之后，它就立马自动部署了5个pod，这5个pod已经健康的跑起来了。为什么是创建5个pod？因为我在yaml文件中声明了我需要5个副本。是不是很方便？

创建tomcat Service对象

单单创建了RC对象还不行，虽然RC对象为我们自动部署了5个pod，但是我们还需要一个Service对象来作为入口地址来对创建好的tomcat进行访问，所以，接下来我们的任务就是创建Service对象。
此文件名为myweb-svc1.yaml。还是直接上代码：

  1 apiVersion: v1
  2 kind: Service
  3 metadata:
  4   name: myweb
  5 spec:
  6   ports:
  7   - name: myweb-svc
  8     port: 8080
  9     targetPort: 8080
 10     nodePort: 31111
 11   selector:
 12     app: myweb
 13   type: NodePort

关于yaml文件声明的含义我已经解释过了。这里不再重复解释。只挑不同的地方强调一下：

  1 apiVersion: v1
  2 kind: Service   //对象是Service了哦
  3 metadata:
  4   name: myweb
  5 spec:  
  6   ports:
  7   - name: myweb-svc         //端口名称，Service是必须指定端口名称的
  8     port: 8080          //Service的端口号
  9     targetPort: 8080        //容器暴露的端口号
 10     nodePort: 31111       //node的真实端口号
 11   selector:
 12     app: myweb     //Service选择了标签为app: myweb的pod
 13   type: NodePort

重点在于三个端口的区别，容器有端口，Service有端口，node也有真实的端口号，这里我们将这三者关联起来，在一会访问的时候会看出门道。所以，我们就拿结果说话吧。

创建tomcat Service对象的结果

大家可以看到，我已经创建好了名为myweb的Service。而且这个Service也已经通过selector选择了刚才创建好的5个pod。所以我可以通过Service来访问tomcat的服务了。我这里使用命令行来演示。

访问服务的方式

我们可以通过两种方式来访问已经创建好的服务。

1. 集群内部访问服务

我们可以通过Service IP + Service端口号的方式来从集群内部访问已经创建好的服务，所以，我们来看看tomcat Service的IP与端口号。

好了，现在可以进行访问了。

可以看到该服务已经通了，已经可以访问了，具体访问的是哪个pod中的tomcat，这是要根据具体情况进行负载均衡的。

2. 集群外部访问服务

从集群的外部我们可以通过node IP + node端口号的方式来对服务进行访问。pod实际上已经分在了不同的node中了，我们只用找到其中一个pod所在的node就行了。

可以看到我这个pod所在的IP地址。刚才已经看到了，在yaml文件中我将物理端口设为31111。好的，接下来就可以从外部对服务进行访问了。

可以看到，此时也可以访问服务。

部署mysql

如果你能将tomcat部署成功了，那么部署mysql就没有什么好讲的了。照前面做就行了。

创建mysql RC对象

我将此RC对象命名为mysql-rc1.yaml
直接上代码：

  1 apiVersion: v1
  2 kind: ReplicationController
  3 metadata:
  4   name: mysql
  5 spec:
  6   replicas: 1
  7   selector:
  8     app: mysql
  9   template:
 10     metadata:
 11       labels:
 12         app: mysql
 13     spec:
 14         containers:
 15         - image: img.reg.3g:15000/mysql:5.7.13
 16           name: mysql
 17           resources:
 18             limits:
 19               cpu: "2"
 20               memory: 4Gi
 21           ports:
 22           - containerPort: 3306
 23           env:
 24           - name: MYSQL_ROOT_PASSWORD
 25             value: "123456"

不同之处在于创建mysql的RC对象yaml文件时，注入了一个name为MYSQL_ROOT_PASSWORD的环境变量，这个是给mysql数据库设置密码，这个环境变量的注入是必须的，如果没有此环境变量，虽然RC可以被创建成功，但是系统是无法启动mysql容器的。不信可以试试。算了，还是给你演示一下吧。

创建mysql RC对象的结果

我把环境变量删了之后运行的结果如下：

可以看到，删掉环境变量的mysql RC虽然可以创建成功，但是容器启动失败了。
增加环境变量之后的结果

增加环境变量之后就可以启动起来容器了

创建mysql Service对象

同样道理，mysql也需要一个访问入口地址。创建的Service yaml文件名为mysql-svc1.yaml
还是直接上代码

  1 apiVersion: v1
  2 kind: Service
  3 metadata:
  4   name: mysql
  5 spec:
  6   ports:
  7   - name: mysql-svc
  8     port: 3306
  9     targetPort: 3306
 10     nodePort: 31101
 11   selector:
 12     app: mysql
 13   type: NodePort

没什么好解释的。

创建mysql Service对象的结果

可以看到，mysql Service对象也已经启动成功了。

由于前面已经详细介绍过如何访问服务了，这里我就不再赘述了。大家可以自己访问mysql的服务看看。

需要注意的细节

我认为，在kubernetes中部署应用集群的时候有两点特别需要注意的，当然，是我会犯错的地方，与大家分享：

1. yaml文件的格式问题
   我初次编写yaml文件可是花了不少时间，就是因为格式的问题，总是创建不了RC或者Servcice。尤其是需要注意，缩进要用空格缩进而不能用TAB键缩进。否则是成功不了的。
2. 理解pod、Service、node IP以及端口的关系
   这里的概念可能会比较难以理解，但一定要搞清楚，这是访问时的重点

总结

在kubernetes中部署容器，不仅可以用yaml，也可以用Json。还有，现在有许多容器化应用都是通过deployment部署的。当然，如果用RC部署也是可以的。我是第一次在kubernetes中部署容器化应用集群，所以就从简单的入手。希望本篇博客能够帮助到有些也刚刚接触kubernetes的同学。