经过搭建MySQL掌握k8s（Kubernetes）重要概念（上）：网络与持久卷

时间  2019-11-08
标签 经过 搭建 mysql 掌握 k8s kubernetes 重要 概念 网络 持久 栏目 MySQL 繁體版
原文   原文链接

上一篇"经过实例快速掌握k8s（Kubernetes）核心概念"讲解了k8s的核心概念，有了核心概念整个骨架就完整了，应付无状态程序已经够了，但还不够丰满。应用程序分红两种，无状态和有状态的。通常的前段和后端程序都是无状态的，而数据库是有状态的，他须要把数据存储起来，这样即便断电，数据也不会丢失。要建立有状态的程序，还须要引入另一些k8s概念。它们虽然不是核心，但也很重要，共有三个，持久卷，网络和参数配置。掌握了这些以后，基本概念就已经作到了全覆盖，k8s就已经入门了。咱们经过搭建MySQL来熟悉这些k8s概念。容器自己是无状态的，一旦出现问题它会被随时销毁，它存储的数据也就丢失了。MySQL须要一个能保存数据的持久层，在容器被销毁以后仍然存在，k8s叫它持久卷。html

建立和验证MySQL镜像：

在k8s上安装MySQL以前，先用Docker验证一下MySQL镜像：node

docker run --name test-mysql -p 3306:33060 -e MYSQL_ROOT_PASSWORD=root -d mysql:5.7

“root”是根（root）用户的password，这里是在建立MySQL容器时指定“root”用户的password。“test-MySQL”是容器的名字。“mysql:5.7”用的是docker库里的“MySQL”5.7版本。此次没有用最新的8.0版，由于新版跟之前的客户端不兼容，须要修改不少东西。所用的镜像是全版的Linux，于是文件比较大，有400M。mysql

容器建好了以后，键入“docker logs test-mysql”，查看日志。nginx

...
2019-10-03T06:18:50.439784Z 0 [System] [MY-010931] [Server] /usr/sbin/mysqld: ready for connections. Version: '8.0.17'  socket: '/var/run/mysqld/mysqld.sock'  port: 3306  MySQL Community Server - GPL.
2019-10-03T06:18:50.446543Z 0 [System] [MY-011323] [Server] X Plugin ready for connections. Socket: '/var/run/mysqld/mysqlx.sock' bind-address: '::' port: 33060

查看容器状态。sql

vagrant@ubuntu-xenial:~$ docker ps
CONTAINER ID        IMAGE               COMMAND                  CREATED             STATUS              PORTS                 NAMES
3b9c50420f5b        mysql:latest        "docker-entrypoint.s…"   11 minutes ago      Up 11 minutes       3306/tcp, 33060/tcp   test-mysql

为了验证MySQL，须要在虚机上安装MySQL客户端。docker

sudo apt-get -y -f install mysql-client

完成以后，键入“docker inspect test-mysql”找到容器IP地址, 下面显示"172.17.0.2"是容器IP地址。shell

vagrant@ubuntu-xenial:~$ docker inspect test-mysql
...
 "Gateway": "172.17.0.1",
                    "IPAddress": "172.17.0.2",
                    "IPPrefixLen": 16,
                    "IPv6Gateway": "",
...

键入“mysql -h 172.17.0.2 -P 3306 --protocol=tcp -u root -p”登陆到MySQL，"172.17.0.2"是MySQL的IP地址，“3306”是MySQL端口，是在建立镜像时设定的对外开放的端口，“root”是用户名，“-p”是password的参数选项。敲入命令后，系统要求输入password，输入后，显示已成功链接到MySQL。数据库

vagrant@ubuntu-xenial:~$ mysql -h 172.17.0.2 -P 3306 --protocol=tcp -u root -p
...
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 3
Server version: 5.7.27 MySQL Community Server (GPL)
...

在k8s上安装MySQL

在k8s上安装MySQL分红三个部分，建立部署文件，建立服务文件和安装测试。编程

部署(Deployment)文件

下面是部署配置文件。在上一篇文章中已经详细讲解了文件格式，全部的k8s的配置文件格式都是相同的。“template”之上是部署配置，从“template”向下是Pod配置。从“containers”开始是Pod里面的容器配置。“env：”是环境变量，这里经过环境变量来设置数据库的用户名和口令，后面还会详细讲解。MySQL的端口是“3306”ubuntu

apiVersion: apps/v1
kind: Deployment  # 类型是部署 
metadata:
  name: mysql-deployment  # 对象的名字
spec:
  selector:
    matchLabels:
      app: mysql #用来绑定label是“mysql”的Pod
  strategy:
    type: Recreate
  template:   # 开始定义Pod 
    metadata:
      labels:
        app: mysql  #Pod的Label，用来标识Pod
    spec:
      containers: # 开始定义Pod里面的容器
        - image: mysql:5.7
          name: mysql-con
          imagePullPolicy: Never
          env:   #  定义环境变量
            - name: MYSQL_ROOT_PASSWORD  #  环境变量名
              value: root  #  环境变量值
            - name: MYSQL_USER
              value: dbuser
            - name: MYSQL_PASSWORD
              value: dbuser
          args: ["--default-authentication-plugin=mysql_native_password"]
          ports:
            - containerPort: 3306 # mysql端口 
              name: mysql

服务（Service）文件

下面是服务配置文件，这个与上一篇讲的配置基本相同，这里就不解释了。

apiVersion: v1
kind: Service
metadata:
  name: mysql-service
  labels:
    app: mysql
spec:
  type: NodePort
  selector:
      app: mysql
  ports:
  - protocol : TCP
    nodePort: 30306
    port: 3306
    targetPort: 3306

安装测试：

有了配置文件后，下面就开始建立MySQL。在建立时要按照顺序，依次进行，先从最底层的对象开始建立。

建立部署和服务：

kubectl apply -f mysql-deployment
kubectl apply -f mysql-service.yaml

查看服务：

vagrant@ubuntu-xenial:~$ kubectl get service
NAME            TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)          AGE
kubernetes      ClusterIP   10.96.0.1       <none>        443/TCP          3h42m
mysql-service   NodePort    10.102.253.32   <none>        3306:30306/TCP   3h21m

“mysql-service”的端口（PORT（S））有两个，“3306”是k8s内部端口，“30306”是外部端口。因为“NodePort”已经打开了对外端口，这时就能够在虚拟机上经过“30306”端口访问MySQL。

vagrant@ubuntu-xenial:~$  mysql -h localhost -P 30306 --protocol=tcp -u root -p
Enter password:
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 6
Server version: 5.7.27 MySQL Community Server (GPL)
...
mysql>

这时本地虚机已经与k8s联通了，下一步就能够在宿主机（ 笔记本）上用图形客户端来访问MySQL了。我是在Vagrant里设定了私有网络，设定的虚机IP地址是 "192.168.50.4”，就用这个地址和30306端口来访问MySQL。

file

网络：

这里的网络有两层含义，一层是k8s网络，就是让k8s内部服务之间能够互相访问，而且从k8s集群外部能够访问它内部的服务。另外一层是宿主机（笔记本）和虚机之间的网路，就是在宿主机上能够访问虚机。这两层都通了以后，就能够在宿主机直接访问k8s集群里面的MySQL。

k8s网络：

k8s的网络也有两层含义，一个是集群内部的，k8s有内部DNS，能够经过服务名进行寻址。另外一个是从集群外部访问集群内部服务，一共有四种方式，详情请见“Kubernetes NodePort vs LoadBalancer vs Ingress? When should I use what?”

  • LoadBalancer：Load Balancer不是由K8s来管理的。k8s经过Load Balancer把外部请求转发给内部服务。这种方法要求有Load Balancer，通常云环境里会提供，但本身的本地环境就没有了。不过Minikube提供了一个程序能够模拟Load Balancer。你只要键入“minikube tunnel ”，它就会模拟Load Balancer，对请求进行转发。只不过当你在使用“Load Balancer”时(在Minikube环境里），每次运行服务时产生的IP和端口是随机的，不能控制，使用起来不太方便，但在正式环境里就没有这个问题。

下面是服务信息，“EXTERNAL-IP”是"pending"，说明外部网络不通。

$ kubectl get service
NAME            TYPE           CLUSTER-IP       EXTERNAL-IP   PORT(S)        AGE
kubernetes      ClusterIP      10.96.0.1        <none>        443/TCP        31d
nginx-service   LoadBalancer   10.104.228.212   <pending>     80:31999/TCP   45h

下面是在运行“minikube tunnel ”（在另外一个窗口运行）以后的服务信息，“EXTERNAL-IP”是 “10.104.228.212”。这时Minikube的LoadBalancer已经起做用了，如今就能够经过IP地址从外部访问k8s内部的服务了，“80”是k8s内部端口，“31999”是k8s对外端口。

$ kubectl get service
NAME            TYPE           CLUSTER-IP       EXTERNAL-IP      PORT(S)        AGE
kubernetes      ClusterIP      10.96.0.1        <none>           443/TCP        31d
nginx-service   LoadBalancer   10.104.228.212   10.104.228.212   80:31999/TCP   45h

这是一种比较好的方式，但不能控制它的IP地址和端口，所以我暂时没有采用它。

  • NodePort：这种方法能够在每一个Node上开放一个对外端口，每个指向这个端口的请求都被转发给一个服务。它的好处是你能够指定一个固定的端口（端口的取值范围只能是30000–32767），这样我在笔记本上访问MySQL时就不用更换端口了。 若是你不指定，系统会随机分配一个。它的缺点是每一个端口只能有一个服务，并且端口取值受限制，所以不适合生产环境。但在Windows环境，因为我用Vagrant固定了虚机的IP地址，这个问题就不存在了。所以它是最好的选择。

  • ClusterIP: 这个只能在k8s集群内部寻址。

  • Ingress: 这是推荐的方法，通常在生产环境中使用。Load balancer的问题是每个服务都要有一个Load balancer，服务多了以后会很麻烦，这时就会用Ingress，它的缺点是配置起来比较复杂。Minikube自带了一个基于Nginx的Ingress控制器，只需运行“minikube addons enable ingress”，就好了。但Ingress的设置较复杂，所以这里没有用它。

虚拟机网络：

这里讲的是宿主机（笔记本）和虚机之间的互相访问，主要是从宿主机访问虚机。我用的是Vagrant， 所以要在Vagran的配置文件（Vagrantfile）里进行配置。它有两种方法：

  • 端口转发：它能够把笔记本上特定端口的请求转发到虚机的指定端口，仍是比较方便的。只是若是事先不知道是哪一个端口，或端口是变化的，就比较麻烦。Vagrant的配置命令：“config.vm.network "forwarded_port", guest: 3306, host: 3306, auto_correct: true”
  • 私有网络：这是一种很灵活的方式。能够给宿主机和虚机各自设定一个固定的IP地址，这样能够双向互访。任何端口都没有问题，惟一的缺点就是你要事先肯定IP地址。详情请参见“Vagrant reverse port forwarding?”。Vagrant的配置命令：“config.vm.network "private_network", ip: "192.168.50.4”

当配置私有网络时，须要在笔记本的VirtualBox上配置“Host-only Adapter”，以下图所示。

file

但这会形成在Vagrant启动Minikube时产生以下错误：“VBoxManage.exe: error: Failed to create the host-only adapter”。这是VirtualBox的一个Bug，你能够下载一个软件解决，详见这里. 这个软件已是四年以前的了，开始还担忧是否与如今的VirtualBox版本兼容，结果很好用，并且它是一个单独运行的软件，不会与如今的软件冲突。只要在启动虚机以前，用管理员身份运行这个补丁就好了。另一个问题是，我原来使用的是5.x版的VirtualBox，上图中只能选“NAT”，不能选“Host-only Adapter”，升级到6.X以后才能选“Host-only Adapter”。但当虚机从新启动以后，它会自动变回“NAT”，不过私有网络仍是可用。

建立持久卷（PersistentVolume）：

k8s卷的概念包括卷和持久卷。

卷（volume）：

卷是k8s的存储概念，它依附于Pod，不能单独存在。但它不是在容器层。所以若是容器被从新启动，卷仍然在。但若是Pod从新启动，卷就丢失了。若是一个Pod里有多个容器，那么这些容器共享Pod的卷。你能够把卷当作是一个目录，里面能够存储各类文件。k8s支持各类类型的卷，例如本地文件系统和各类云存储。

持久卷（PersistentVolume）：

是对卷的一个封装，目的是为了更好地管理卷。它的生命周期不须要与Pod绑定，它能够独立于Pod存在。

持久卷申请（PersistentVolumeClaim）：

是对持久卷资源的一个申请，你能够申请特定的存储容量的大小和访问模式，例如读写模式或只读模式。k8s会根据持久卷申请分配适合的持久卷，若是没有合适的，系统会自动建立一个。持久卷申请是对持久卷的一个抽象，就像编程里的接口（Interface）,它能够有不一样的具体实现（持久卷）。例如，阿里云和华为云支持的存储系统不一样，它生成的持久卷也不相同。持久卷是与特定的存储实现绑定的。那你要把程序从阿里云移植到华为云，怎么保证配置文件的兼容性呢？你就用持久卷申请来作这个接口，它只规定存储容量大小和访问模式，而由阿里云和华为云自动生成各自云里知足这个接口需求的持久卷. 不过，它还有一个限制条件，那就是持久卷申请和持久卷的StorageClass须要匹配，这使它没有接口灵活。后面会详细讲解。

动态持久卷：

在这种状况下，你只需建立持久卷申请（不须要单首创建持久卷），而后把持久卷申请与部署绑定。系统会按照持久卷申请自动建立持久卷。下面是持久卷申请配置文件。其中“storage：1Gi”，是指申请的空间大小是1G。

持久卷申请配置文件：
shell apiVersion: v1 kind: PersistentVolumeClaim metadata: name: mysql-pv-claim labels: app: mysql spec: accessModes: - ReadWriteOnce resources: requests: storage: 1Gi #持久卷的容量是 1 GB
挂载持久卷申请的部署：

下面是挂载了持久卷申请的部署配置文件。它经过把持久卷申请当作持久卷来使用，与Pod进行绑定。请阅读文件里有关持久卷的注释。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: mysql-deployment
spec:
  selector:
    matchLabels:
      app: mysql
  strategy:
    type: Recreate
  template:
    metadata:
      labels:
        app: mysql
    spec:
      containers:
        - image: mysql:5.7
          name: mysql-con
          imagePullPolicy: Never
          env:
            - name: MYSQL_ROOT_PASSWORD
              value: root
            - name: MYSQL_USER
              value: dbuser
            - name: MYSQL_PASSWORD
              value: dbuser
          args: ["--default-authentication-plugin=mysql_native_password"]
          ports:
            - containerPort: 3306
              name: mysql
          volumeMounts: # 挂载Pod上的卷到容器
            - name: mysql-persistent-storage # Pod上卷的名字，与“volumes”名字匹配
              mountPath: /var/lib/mysql # 挂载的Pod的目录
      volumes:   # 挂载持久卷到Pod
        - name: mysql-persistent-storage # 持久卷名字， 与“volumMounts”名字匹配
          persistentVolumeClaim: 
            claimName: mysql-pv-claim  # 持久卷申请名字

这里只指定了Pod的挂载目录，并无指定虚拟机（宿主机）的目录，后面会讲到如何找到虚拟机的目录（系统自动分配挂载目录）。

运行部署：

键入“kubectl apply -f mysql-volume.yaml”建立持久卷申请，在建立它的同时，系统自动建立持久卷。

查看持久卷申请

vagrant@ubuntu-xenial:~/dockerimages/kubernetes/mysql$ kubectl get pvc
NAME             STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS   AGE
mysql-pv-claim   Bound    pvc-ac6c88d5-ef5a-4a5c-b499-59715a2d60fa   1Gi        RWO            standard       10m

查看持久卷申请详细信息

vagrant@ubuntu-xenial:/mnt$ kubectl describe pvc mysql-pv-claim
Name:          mysql-pv-claim
Namespace:     default
StorageClass:  standard
Status:        Bound
Volume:        pvc-ac6c88d5-ef5a-4a5c-b499-59715a2d60fa
Labels:        app=mysql
...

显示持久卷：

vagrant@ubuntu-xenial:/mnt$ kubectl get pv
NAME                                       CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS   CLAIM                    STORAGECLASS   REASON   AGE
pvc-ac6c88d5-ef5a-4a5c-b499-59715a2d60fa   1Gi        RWO            Delete           Bound    default/mysql-pv-claim   standard                24h

键入“kubectl describe pv pvc-ac6c88d5-ef5a-4a5c-b499-59715a2d60fa”， 显示持久卷详细信息。从这里能够看出，虚拟机上的持久卷在以下位置：“Path： /tmp/hostpath-provisioner/pvc-ac6c88d5-ef5a-4a5c-b499-59715a2d60fa”。

vagrant@ubuntu-xenial:/mnt$ kubectl describe pv pvc-ac6c88d5-ef5a-4a5c-b499-59715a2d60fa
Name:            pvc-ac6c88d5-ef5a-4a5c-b499-59715a2d60fa
Labels:          <none>
Annotations:     hostPathProvisionerIdentity: 19948fdf-e67f-11e9-8fbd-026a5b40726f
                 pv.kubernetes.io/provisioned-by: k8s.io/minikube-hostpath
Finalizers:      [kubernetes.io/pv-protection]
StorageClass:    standard
Status:          Bound
Claim:           default/mysql-pv-claim
Reclaim Policy:  Delete
Access Modes:    RWO
VolumeMode:      Filesystem
Capacity:        1Gi
Node Affinity:   <none>
Message:
Source:
    Type:          HostPath (bare host directory volume)
    Path:          /tmp/hostpath-provisioner/pvc-ac6c88d5-ef5a-4a5c-b499-59715a2d60fa
    HostPathType:
Events:            <none>

查看MySQL目录信息：

vagrant@ubuntu-xenial:/tmp/hostpath-provisioner/pvc-ac6c88d5-ef5a-4a5c-b499-59715a2d60fa$ ls -al
total 188488
drwxrwxrwx 6  999 docker     4096 Oct  4 13:23 .
drwxr-xr-x 3 root root       4096 Oct  4 12:58 ..
-rw-r----- 1  999 docker       56 Oct  4 12:58 auto.cnf
-rw------- 1  999 docker     1679 Oct  4 12:59 ca-key.pem
-rw-r--r-- 1  999 docker     1107 Oct  4 12:59 ca.pem
-rw-r--r-- 1  999 docker     1107 Oct  4 12:59 client-cert.pem
-rw------- 1  999 docker     1679 Oct  4 12:59 client-key.pem
-rw-r----- 1  999 docker      668 Oct  4 13:21 ib_buffer_pool
-rw-r----- 1  999 docker 79691776 Oct  4 13:23 ibdata1
-rw-r----- 1  999 docker 50331648 Oct  4 13:23 ib_logfile0
-rw-r----- 1  999 docker 50331648 Oct  4 12:58 ib_logfile1
-rw-r----- 1  999 docker 12582912 Oct  4 13:24 ibtmp1
drwxr-x--- 2  999 docker     4096 Oct  4 12:58 mysql
drwxr-x--- 2  999 docker     4096 Oct  4 12:58 performance_schema
-rw------- 1  999 docker     1679 Oct  4 12:59 private_key.pem
-rw-r--r-- 1  999 docker      451 Oct  4 12:59 public_key.pem
-rw-r--r-- 1  999 docker     1107 Oct  4 12:59 server-cert.pem
-rw------- 1  999 docker     1675 Oct  4 12:59 server-key.pem
drwxr-x--- 2  999 docker     4096 Oct  4 13:18 service_config
drwxr-x--- 2  999 docker    12288 Oct  4 12:58 sys

持久卷的回收模式：

当持久卷和持久卷申请被删除后，它有三种回收模式。

  • 保持（Retain）：当持久卷申请被删除后，持久卷仍在。你能够手动回收持久卷里的数据。
  • ** 删除（Delete）**：持久卷申请和持久卷都被删除，底层存储的数据也会被删除。当使用动态持久卷时，缺省的模式是Delete。固然，你能够在持久卷被建立以后修改它的回收模式。
  • ** 回收（Recycle）**：这种方式已经不推荐使用了，建议用Retain代替。

静态持久卷：

动态持久卷的一个问题是它的缺省回收模式是“删除”，这样当虚机从新启动后，持久卷会被删除。当你从新运行部署时，k8s会建立一个新的MySQL，这样原来MySQL里的新建信息就会丢失，这是咱们不肯意看到的。虽然你能够手动修改回收方式为“保持”，但仍是要手动回收原来持久卷里的数据。
一个解决办法是把持久卷建在宿主机上，这样即便虚机出了问题被从新启动，MySQL里的新建信息依然不会丢失。若是是在云上，就会有专门的的存储层，若是是本地，大体有三种方式：

  • Local：把存储从宿主机挂载到k8s集群上. 详情请参见："Volumes".
  • HostPath：也是把存储从宿主机挂载到k8s集群上，但它有许多限制，例如只支持单节点（Node），并且只支持“ReadWriteOnce”模式。详情请参见： "hostPath as volume in kubernetes".
  • NFS：网络文件系统，这种是最灵活的，但须要安装NFS服务器。详情请参见："Kubernetes Volumes Guide".

我选择了比较简单的“Local”方式。在这种方式下，必须单首创建持久卷，不能 只建立持久卷申请而让系统自动建立持久卷。

下面是使用“Local”方式的配置文件，它把持久卷和持久卷申请写在了一个文件里。当用“Local”方式时，须要设置“nodeAffinity”部分，其中“values:- minikube” 的“Minikube”是k8s集群Node的名字，“Minikube”只支持一个Node，既是“Master Node”，又是“Worker Node”。

持久卷和申请的配置文件：

apiVersion: v1
kind: PersistentVolume
metadata:
  name: mysql-pv
spec:
  capacity:
    storage: 1Gi
  volumeMode: Filesystem
  accessModes:
    - ReadWriteOnce
  storageClassName:  standard #持久卷存储类型，它须要与持久卷申请的类型相匹配
  local:
    path: /home/vagrant/database/mysql #宿主机的目录
  nodeAffinity:
    required:
      nodeSelectorTerms:
        - matchExpressions:
            - key: kubernetes.io/hostname
              operator: In
              values:
                - minikube # Node的名字
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: mysql-pv-claim
  labels:
    app: mysql
spec:
  accessModes:
    - ReadWriteOnce
  # storageClassName:  # 这里的存储类型注释掉了
  resources:
    requests:
      storage: 1Gi #1 GB

若是不知道Node名字，可用以下命令查看：

vagrant@ubuntu-xenial:/$ kubectl get node
NAME       STATUS   ROLES    AGE    VERSION
minikube   Ready    master   6d3h   v1.15.2

改用静态持久卷以后，只有持久卷配置文件发生了变化，部署和服务的配置文件没有变。从新运行持久卷和部署，成功以后，即便重启虚拟机，MySQL里面的新建内容也没有丢失。

注意这里storageClassName的用法。k8s规定持久卷和持久卷申请的storageClassName必须匹配，这时才会把持久卷分配给持久卷申请。咱们这里的持久卷申请没有指定storageClassName，这时系统会使用缺省的storageClass。

查看是否安装了缺省的storageClass

vagrant@ubuntu-xenial:/$ kubectl get sc
NAME                 PROVISIONER                AGE
standard (default)   k8s.io/minikube-hostpath   6d3h
vagrant@ubuntu-xenial:/$

查看缺省的storageClass详细信息

vagrant@ubuntu-xenial:/$ kubectl describe sc
Name:                  standard
IsDefaultClass:        Yes
Annotations:           storageclass.kubernetes.io/is-default-class=true
Provisioner:           k8s.io/minikube-hostpath
Parameters:            <none>
AllowVolumeExpansion:  <unset>
MountOptions:          <none>
ReclaimPolicy:         Delete
VolumeBindingMode:     Immediate
Events:                <none>

从这里能够看出，Minikube安装了缺省的storageClass，它的名字是“standard”。上面的持久卷申请里没有指定storageClass，所以系统使用缺省的storageClass与之匹配，而上面的持久卷的storageClassName是“standard”，正好能配上。详情请见“Dynamic Provisioning and Storage Classes in Kubernetes”

踩过的坑:

  1. 使用Hyper-V仍是VirtualBox

    Hyper-V和VirtualBox是不兼容的，只能选一个（固然你能够在这二者之间切换，但太麻烦了）。我在Windows上装了VirtualBox，运行正常。进入Vagrant以后，安装了“ubuntu”版的Linux。这时，当你启动Minikube时，能够键入“minikube start --vm-driver=virtualbox”，但系统显示“This computer doesn't have VT-X/AMD-v enabled. Enabling it in the BIOS is mandatory”。我按照网上的建议去修改BIOS的“VT-X/AMD-v”，但个人BIOS就没有这个选项。其余的方法也都试过了，没有一个成功的。但由于已经装了VirtualBox，就不能用Hyper-V了。就只能用另一个方法，使用命令“minikube start --vm-driver=none”。幸亏这个方法工做得很好。

    当用“minikube start --vm-driver=virtualbox”时，你是先建了虚拟机，再在虚拟机上运行Minikube。当用“minikube start --vm-driver=none”时，是直接在宿主机上运行Minikube。但因为个人Windows版本不能直接支持k8s，我已经在Windows上装了Linux虚机，并用Vagrant进行管理。若是用“minikube start --vm-driver=virtualbox”，就是在Linux虚机上又装了一个虚机。如今用“minikube start --vm-driver=none”，表面上看是在宿主机上运行，实际上已经运行在Windows的Linux虚机上了。

  2. 登陆k8s集群

    当用“minikube start --vm-driver=none”启动Minikube时，不能用“minikube ssh”登陆k8s集群，由于这时已经没有虚机了，是直接安装在宿主机上，所以不须要“minikube ssh”。但你能够登陆到Pod上，可用以下命令：" kubectl exec -ti mysql-deployment-56c9cf5857-fffth -- /bin/bash"。其中“mysql-deployment-56c9cf5857-fffth”是Pod名字。

  3. 建立重名PV或PVC

    当原来的PV或PVC还在，而你又建立了一个新的PV, 并与原来的重名，则会获得以下错误：The persistentvolumeclaim "mysql-pv-claim" is invalid: spec: forbidden: is immutable after creation except resources.requests for bound claims. 这时，你须要将原来的PV或PVC删掉，再从新建立新的。

请继续阅读下篇“经过搭建MySQL掌握k8s（Kubernetes）重要概念（下）：参数配置”

索引：

  1. 经过实例快速掌握k8s（Kubernetes）核心概念
  2. Kubernetes NodePort vs LoadBalancer vs Ingress? When should I use what?
  3. Vagrant reverse port forwarding?
  4. hostPath as volume in kubernetes
  5. Volumes
  6. Kubernetes Volumes Guide
  7. Dynamic Provisioning and Storage Classes in Kubernetes

本文由博客一文多发平台 OpenWrite 发布！

相关文章
相关标签/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公众号
   欢迎关注本站公众号,获取更多信息
联系我们 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程