发表于 |

背景

我一直在维护一个公司内部的 OS 发行版，是基于 CentOS 的，最近接到了一个需求，是需要更新 Kernel 及一些软件包，但是遇到了无法安装 OS 的问题，记录一下解决方式。

定制 OS

关于定制 OS，在之前的博客中已经提到过几次了，CentOS 是比较容易改动的一个发行版，因为有着 RHEL 红（爸）帽（爸），有着完善的文档可以参考。

主要需要注意的是两点：

  1. 分区方式
  2. 软件包选择

今天遇到的问题是第二点。

先说下前提，由于是 2B 产品，所以对于每次的 BaseOS 版本升级都非常谨慎，每次 BaseOS 版本都会进行各种测试。但是如果仅仅是升级部分所需要的软件包，就不用这么麻烦了，我们可以定制自己所需要的软件组（group），来进行安装/升级。

问题

这次接到的需要是升级 Kernel、libiscsi、qemu 三个软件，后两个是虚拟化相关的，相关依赖较少；kernel 是跟 BaseOS 版本关联性很大的。

比如 CentOS 7.6 中，kernel 版本为：kernel-3.10.0-957.el7.x86_64.rpm，这个版本对 selinux 等相关软件是有依赖要求的，我在这里翻车了。

解决

像往常一样，将对应的 rpm 放置到了对应的 yum 源中，更新 yum 源，制作 ISO，在安装过程中报错：

报错显示是软件源出了问题，但是没有更多的信息了，这时候我们可以通过 console 连接到其他的 pty 中，查看对应的日志，比如 CentOS 默认的日志在： /tmp/packaging.log 中：

我们可以看到日志中提示 kernel 与当前软件源中的 selinux-policy-targeted 冲突，因为安装 OS 所用的软件源就是 ISO ，所以这里肯定是我们打包 ISO 时遗漏了依赖关系导致的，我们将对应的 Kernel 所需依赖更新，重新构建 ISO 就可以了。

发表于 |

背景

在对现有服务进行容器话改造的过程中，随着对 K8S 使用程度越来越深，也渐渐的遇到了一些坑，所以开一篇博客，记录自己所遇到的坑，应该会长期更新。

更新记录

  • 2019.07.13 02:00 来自加班中的 yiran
  • 2019.07.19 06:52 早起不想去公司的 yiran

coredns 无法解析域名

在 Kubernetes 环境中，使用 kubeadm 工具部署的集群，会自动部署 coredns 作为集群的域名服务，每当我们创建了自己的 service，都可以通过域名直接访问，不用再考虑自己多个 Pod 的 IP 不同如何连接的问题。

最近遇到多个环境出现无法解析域名的问题，具体现象如下：

  1. 集群部署完成后，部署 daemonset 资源，每个节点均运行一个 busybox；
  2. 在 busybox 中对 kubernetes 默认域名进行解析，查看解析结果。

正常情况应该是所有的 busybox 都可以正常解析才对，但是最近几个环境中均出现了 3 个node 中1个node 上的 pod 无法解析的问题，示例代码如下：

daemonset.yaml

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
apiVersion: "extensions/v1beta1"
kind: "DaemonSet"
metadata:
  name: "ds"
  namespace: "default"
spec:
  template:
    metadata:
      labels:
        app: ds
    spec:
      tolerations:
      - key: node-role.kubernetes.io/master
        effect: NoSchedule
      containers:
      - name: "apply-sysctl"
        image: "busybox:1.28.4"
        imagePullPolicy: IfNotPresent
        command:
        - "/bin/sh"
        - "-c"
        - |
          set -o errexit
          set -o xtrace
          while true
          do
            sleep 2s
            date
            echo "diu~"
          done

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
[root@node11 21:28:40 ~]$for i in `kubectl get pod  -o wide  |grep ds | awk '{print $1}'`;do kubectl exec $i nslookup kubernetes;echo ;done
Server:    10.96.0.10
Address 1: 10.96.0.10

nslookup: can't resolve 'kubernetes'
command terminated with exit code 1

Server:    10.96.0.10
Address 1: 10.96.0.10 kube-dns.kube-system.svc.cluster.local

Name:      kubernetes
Address 1: 10.96.0.1 kubernetes.default.svc.cluster.local

Server:    10.96.0.10
Address 1: 10.96.0.10 kube-dns.kube-system.svc.cluster.local

Name:      kubernetes
Address 1: 10.96.0.1 kubernetes.default.svc.cluster.local

在第一个节点的 Pod 解析时失效，最后命令执行 1min 超时退出。

经过查看发现节点的 NetFilter 相关系统配置未生效，导致 iptables 相关功能失效，具体可以参考 issue。

解决方式：

1
echo '1' > /proc/sys/net/bridge/bridge-nf-call-iptables

Flannel OOM

在配置好集群业务后，发现业务时不时的出现中断情况，最开始排查业务自身问题，未发现 Pod 出现重启或异常的日志，开始排查 k8s 状态，发现在节点 /var/log/messages 日志中，Flannel 一直处于 OOM 状态，惨不忍睹。

之前还略微惊奇，Flannel 默认的计算资源中，内存只要 50MiB，且上限也是 50MiB，没有给自己留一丝余地，看到 issue 中的描述，感觉这个不是一个偶发事件，最终我将 Flannel 的内存调整为 250MiB 后，未出现 OOM 情况。

issue 中提到的 kubectl patch 命令未自动生效，我通过更新 ds 配置，然后依次手动删除节点上的 Flannel Pod 使其生效。

Nginx Ingress

Nginx Ingress 有多个版本，在编写 Ingress 规则的时候一定要看清自己集群中的 Nginx Ingress 版本，我最开始就是因为这个看错了文档。。

主要的版本有： kubernetes/ingress-nginx , nginxinc/kubernetes-ingress with NGINX 和 nginxinc/kubernetes-ingress with NGINX PLUS ，具体的对比规则可以在 Github 中了解。

在 kubernetes/ingress-nginx 中，默认 ssl-redirect 参数是 true ，如果自己的服务不支持 https，那么需要显示的声明该参数为 false 才可以，这里需要注意一下。

在配置 nginx 参数的时候，要注意语法，正确的书写方式如下：

1
2
3
4
5
6
7
8
9
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  annotations:
    kubectl.kubernetes.io/last-applied-configuration: |
      {"apiVersion":"networking.k8s.io/v1beta1","kind":"Ingress","metadata":{"annotations":{"kubernetes.io/ingress.class":"nginx","nginx.ingress.kubernetes.io/proxy-read-timeout":"3600","nginx.ingress.kubernetes.io/proxy-send-timeout":"3600","nginx.ingress.kubernetes.io/ssl-redirect":"true","nginx.ingress.kubernetes.io/use-regex":"true","nginx.org/websocket-services":"websockify"},"name":"websockify","namespace":"default"},"spec":{"rules":[{"http":{"paths":[{"backend":{"serviceName":"websockify","servicePort":8000},"path":"/websockify"}]}}]}}
    kubernetes.io/ingress.class: nginx
    nginx.ingress.kubernetes.io/proxy-read-timeout: "3600"
    nginx.ingress.kubernetes.io/proxy-send-timeout: "3600"

相关 issue 链接： https://github.com/kubernetes/ingress-nginx/issues/2007

Docker 稳定性

在修改 Docker 配置后，需要重启 Docker.service 使配置生效，在一次重启操作中，直接导致物理节点宕机，自动重启了。。。

重启后观察物理节点日志，未发现异常日志，目前待复现调查，很坑很诡异。

Helm values 为空更新错误

今天在给应用编写 Helm Charts 的时候，在 Values 中通过 resources.requests.cpu 方式指定了 cpu 和内存，在测试的时候忘记填写具体数值了，像这面这样：

values:

1
2
3
4
5
6
7
8
9
10
11
# Default values for test.
# This is a YAML-formatted file.
# Declare variables to be passed into your templates.

resources:
  limits:
   cpu:
   memory:
  requests:
   cpu:
   memory:

在 helm templates 中定义 daemonset，指定使用 resources 字段。

直接执行 helm 命令安装成功了：

1
2
3
4
5
6
7
8
9
10
11
[root@node11 20:44:09 test]$helm install . --name-template test
NAME: test
LAST DEPLOYED: 2019-07-15 20:44:18.151073881 +0800 CST m=+0.092592446
NAMESPACE: default
STATUS: deployed

NOTES:
1. Get the application URL by running these commands:
  export POD_NAME=$(kubectl get pods -l "app=test,release=test" -o jsonpath="{.items[0].metadata.name}")
  echo "Visit http://127.0.0.1:8080 to use your application"
  kubectl port-forward $POD_NAME 8080:80

我们查看创建出来的 daemonset 资源状态：

daemonset/test

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

Name:           test
Selector:       app=test
Node-Selector:  <none>
Pods Status:  3 Running / 0 Waiting / 0 Succeeded / 0 Failed
Pod Template:
  Labels:  app=test
  Containers:
   test:
    Image:      harbor.zdyxry.com/test/test:0.1.2
    Port:       10402/TCP
    Host Port:  10402/TCP
    Command:
      /bin/sh
      -c
    Args:
      gunicorn -b :10402 -k gevent test.main:flask_app -w 2 --timeout 40 --pid /var/run/test.pid
    Limits:
      cpu:     0
      memory:  0
    Requests:
      cpu:        0
      memory:     0
    Environment:  <none>

这时候我在检查资源的时候发现自己忘记设置资源了，我计划通过更新 values 数值来更新 daemonset：

1
2
3
4
5
6
7
8
9
10
11
# Default values for test.
# This is a YAML-formatted file.
# Declare variables to be passed into your templates.

resources:
  limits:
   cpu: 100m
   memory: 100Mi
  requests:
   cpu: 100m
   memory: 100Mi

执行 helm upgrade 时候报错：

1
2
[root@node11 20:49:36 test]$helm upgrade test .
Error: UPGRADE FAILED: error validating "": error validating data: [unknown object type "nil" in DaemonSet.spec.template.spec.containers[0].resources.limits.cpu, unknown object type "nil" in DaemonSet.spec.template.spec.containers[0].resources.limits.memory, unknown object type "nil" in DaemonSet.spec.template.spec.containers[0].resources.requests.cpu, unknown object type "nil" in DaemonSet.spec.template.spec.containers[0].resources.requests.memory]

根据报错信息可以看到这个字段之前是 nil ，现在我们要更新为有效类型更新失败，只能通过 helm uninstall 卸载后再次安装修复该问题。

这个问题只在 daemonset 类型下会出现。

Flannel 网卡丢失

在通常情况下，我们的 k8s 节点都只有单一的网络环境，也就是有一块网卡，在部署 Flannel 插件的时候，默认会找默认路由所在的网卡，并将其绑定在上面。

由于内部测试环境较为特殊，我将其绑定在一个 ovs port 上，这个具体配置在 flannel yaml 中：

1
2
3
4
5
6
7
8
9
containers:
- name: kube-flannel
  image: quay.io/coreos/flannel:v0.11.0-amd64
  command:
  - /opt/bin/flanneld
  args:
  - --ip-masq
  - --kube-subnet-mgr
  - --iface=port-storage  # 在这里我强制指定了 iface

正常运行时时没有问题的，但是对 ovs port 进行了 ifdown 操作后，在 OS 层面就无法找到这个 ovs port 了，flannel 默认的 flannel.1 这个 link 也丢失了，当我尝试 ifup ovs port，这个 port 正常恢复工作了，但是 flannel.1 无法自动恢复，目前找到的办法是手动重建 flannel pod。

猜测这个动作在 flannel 的init 相关步骤执行的，在之后 container 正常运行时没有考虑 flannel.1 不存在的情况。

总结

使用经验通常是踩了一个又一个坑过来的~

发表于 |

背景

先介绍下 Kubespray，Kubespray 是 K8S SIG 下的项目，目标是帮助用户创建 生产环境级别 的 k8s 集群。

是通过 Ansible Playbook 实现的，是的，这又是一个 Ansible 项目，其中 YAML 文件就有 15k 行，名副其实的大项目。

花费了几天时间陆陆续续看完了整个项目，大概了解了其中的工作流程，具体内容不提，感觉 Ansible 90% 的使用例子都可以在这个项目中找到，是一个值得阅读的项目。

之前写过一篇当时理解的最佳实践，今天趁此机会再总结下最近使用 Ansible 的一些经验。

Tag

使用 tag 对 ansible task 进行划分，比如在重启某些服务的时候，我们只希望在初次安装的时候重启，在后续升级的时候不进行重启，那么我们就可以对这个重启服务的 task 进行tag 区分。

tag 使用示例如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
[root@node111 16:35:56 ansible]$tree . 
.
├── ansible.cfg
├── inventory
├── templates
│   └── src.j2
└── test.yaml

1 directory, 4 files
[root@node111 16:35:58 ansible]$cat test.yaml 
- hosts: cluster
  gather_facts: no
  become: yes
  become_user: root
  become_method: sudo
  tasks:
  - yum:
      name: "{{ item }}"
      state: present
    loop:
    - httpd
    - memcached
    tags:
    - packages
  
  - template:
      src: templates/src.j2
      dest: /etc/foo.conf
    tags:
    - configuration
[root@node111 16:36:01 ansible]$ansible-playbook -i inventory  test.yaml --tags configuration -v
Using /root/ansible/ansible.cfg as config file

PLAY [cluster] ******************************************************************************************************************************************************************************************************************************************************

TASK [template] *****************************************************************************************************************************************************************************************************************************************************
ok: [172.16.30.111] => {"changed": false, "checksum": "7b4cbb07f7e174316e4d892321682317e43a206c", "dest": "/etc/foo.conf", "gid": 0, "group": "root", "mode": "0644", "owner": "root", "path": "/etc/foo.conf", "size": 14, "state": "file", "uid": 0}
ok: [172.16.30.112] => {"changed": false, "checksum": "7b4cbb07f7e174316e4d892321682317e43a206c", "dest": "/etc/foo.conf", "gid": 0, "group": "root", "mode": "0644", "owner": "root", "path": "/etc/foo.conf", "size": 14, "state": "file", "uid": 0}
ok: [172.16.30.113] => {"changed": false, "checksum": "7b4cbb07f7e174316e4d892321682317e43a206c", "dest": "/etc/foo.conf", "gid": 0, "group": "root", "mode": "0644", "owner": "root", "path": "/etc/foo.conf", "size": 14, "state": "file", "uid": 0}

PLAY RECAP **********************************************************************************************************************************************************************************************************************************************************
172.16.30.111              : ok=1    changed=0    unreachable=0    failed=0   
172.16.30.112              : ok=1    changed=0    unreachable=0    failed=0   
172.16.30.113              : ok=1    changed=0    unreachable=0    failed=0

roles/meta 管理依赖

在 playbook 中存在多个 roles，且其中有相互依赖关系时，合理使用 meta 配置，填写其所依赖的 roles。注意，被依赖的 roles 会优先执行，示例如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
[root@node111 16:49:12 ansible]$tree . 
.
├── ansible.cfg
├── inventory
├── roles
│   ├── a
│   │   ├── defaults
│   │   ├── files
│   │   ├── handlers
│   │   ├── meta
│   │   │   └── main.yaml
│   │   ├── tasks
│   │   │   └── main.yaml
│   │   ├── templates
│   │   └── vars
│   └── b
│       ├── defaults
│       ├── files
│       ├── handlers
│       ├── meta
│       ├── tasks
│       │   └── main.yaml
│       ├── templates
│       └── vars
├── templates
│   └── src.j2
└── test.yaml

18 directories, 7 files
[root@node111 16:49:18 ansible]$cat roles/a/tasks/main.yaml 
---
- name: a
  debug:
    msg: "a"
[root@node111 16:49:25 ansible]$cat roles/a/meta/main.yaml 
---
dependencies:
  - { role: b }
[root@node111 16:49:33 ansible]$cat roles/b/tasks/main.yaml 
---
- name: b
  debug:
    msg: "b"
[root@node111 16:49:40 ansible]$ansible-playbook -i inventory  test.yaml -v
Using /root/ansible/ansible.cfg as config file

PLAY [cluster] ******************************************************************************************************************************************************************************************************************************************************

TASK [b : b] ********************************************************************************************************************************************************************************************************************************************************
ok: [172.16.30.111] => {
    "msg": "b"
}
ok: [172.16.30.112] => {
    "msg": "b"
}
ok: [172.16.30.113] => {
    "msg": "b"
}

TASK [a : a] ********************************************************************************************************************************************************************************************************************************************************
ok: [172.16.30.111] => {
    "msg": "a"
}
ok: [172.16.30.112] => {
    "msg": "a"
}
ok: [172.16.30.113] => {
    "msg": "a"
}

PLAY RECAP **********************************************************************************************************************************************************************************************************************************************************
172.16.30.111              : ok=2    changed=0    unreachable=0    failed=0   
172.16.30.112              : ok=2    changed=0    unreachable=0    failed=0   
172.16.30.113              : ok=2    changed=0    unreachable=0    failed=0   

You have new mail in /var/spool/mail/root
[root@node111 16:50:05 ansible]$

参数声明

在一个大型项目中，我们无论是服务的数量还是各个服务对应的参数数量都是极其惊人的，那么我们就要合理的管理相应参数，这里 kubespray 项目给出了一个很好的示例，先来看下 kubespray 的组织结构（简化版）：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
inventory/
├── local
│   └── group_vars -> ../sample/group_vars
└── sample
    └── group_vars
        ├── all
        └── k8s-cluster
roles
├── container-engine
│   ├── containerd
│   │   ├── defaults
│   │   ├── handlers
│   │   ├── tasks
│   │   └── templates
│   ├── docker
│   │   ├── defaults
│   │   ├── files
│   │   ├── handlers
│   │   ├── meta
│   │   ├── tasks
│   │   ├── templates
│   │   └── vars
│   └── meta
├── kubespray-defaults
│   ├── defaults
│   ├── meta
│   └── tasks

在 kubespray 中，参数定义有三个位置：

  1. inventory/sample/group_vars
  2. roles/kubespray-defaults/defaults
  3. roles//defaults
  4. 使用 set_fact 关键字声明

上述三个位置是按照参数粒度划分，参数粒度越细，越靠后。

举个例子：

  • bin_dir 这个参数，是一个全局参数，管理下载的二进制文件路径，它在 inventory/samle/group_vars 中定义；
  • etcd_kubeadm_enabled 参数，决定是否通过 kubeadm 来创建 etcd 集群，是集群粒度的，在 roles/kubesray-defaults/defaults 中定义；
  • docker_fedora_repo_base_url 是 docker 在下载镜像时指定的 repo，是一个容器运行时粒度的参数，那么它就在 roles/container-ngine/docker/defaults 中定义
  • 执行某些命令后，我们希望对命令结果进行过滤或判断，那么我们通常会使用 regster，但是 register 的声明周期仅限于该 playbook，而且他们的优先级也是不同的，具体可以看下官方文档

可能跟大多数项目不同，kubespray 中涉及的参数数量很多，不知道是否是这个原因，专门使用了 roles/kubespray-defaults 这个 role 来声明参数。不过它的这种参数划分方式是我们值得学习的。

Handler 触发

当我们更新了配置文件之后，我们想要重启相应服务，这时候可以使用 notify 配合 handlers 来完成相应操作，而且 handler
的方式也可以保证我们代码最大程度的重用。

loop_control

当我们在 playbook 中定义了某个变量为 list 类型，我们想要遍历变量，并且针对每个变量的操作都进行错误处理，我们可以采用 loop_control 关键字配合 include 来实现，比如：

1
2
3
4
- include_tasks: docker_plugin.yml
  loop: "{{ docker_plugins }}"
  loop_control:
    loop_var: docker_plugin

循环 device_plugins ，每个变量为 docker_plugin ，将 docker_plugin 传递到 docker_plugin.yml 。

不建议的操作

在 ansible 中使用复杂的语法规则

在 kubespray 中，随处可见一些很复杂的语法夹杂在 playbook 中，看到一个比较头疼的：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
279	
280	dashboard_image_repo: "gcr.io/google_containers/kubernetes-dashboard-{{ image_arch }}"
281	dashboard_image_tag: "v1.10.1"
282	
283	image_pull_command: "{{ docker_bin_dir }}/docker pull"
284	image_info_command: "{{ docker_bin_dir }}/docker images -q | xargs {{ docker_bin_dir }}/docker inspect -f \"{{ '{{' }} if .RepoTags {{ '}}' }}{{ '{{' }} (index .RepoTags 0) {{ '}}' }}{{ '{{' }} end {{ '}}' }}{{ '{{' }} if .RepoDigests {{ '}}' }},{{ '{{' }} (index .RepoDigests 0) {{ '}}' }}{{ '{{' }} end {{ '}}' }}\" | tr '\n' ','"
285	
286	downloads:
287	  netcheck_server:
288	    enabled: "{{ deploy_netchecker }}"
289	    container: true
290	    repo: "{{ netcheck_server_image_repo }}"
291	    tag: "{{ netcheck_server_image_tag }}"
292	    sha256: "{{ netcheck_server_digest_checksum|default(None) }}"

284 行获取 image_info_command ，这里真的是一点可维护性都没有，初步看很难看出这里到底是 ansible 语法，还是 shell 语法，还是 go template 语法，如果我们要通过这么复杂的方式来获取一个参数，为什么不干脆写一个脚本来完成这个事情呢？ 搞不懂。

总结

看完 kubespray 了解了 k8s 集群部署的步骤之外，Ansible 的一些高级用法或者说经验是之后需要改善的，收获多多。

发表于 |

背景

Kubernetes 作为一个容器编排系统，负责 Pod 生命周期管理，那么肯定会保证 Pod 的可用性，今天来说下 k8s Pod 可用性相关知识。

K8S 可用性相关参数

k8s 核心组件有 kubelet,kube-apiserver,kube-scheduler,kube-controller-manager，通过阅读官方文档中相关参数说明，我摘取了认为跟可用性相关的参数，具体列表如下：

kubelet

–housekeeping-interval duration

Default: 10s

Interval between container housekeepings.

kubelet 主动检测容器资源是否达到阈值的周期。

–node-status-update-frequency duration

Default: 10s

Specifies how often kubelet posts node status to master. Note: be cautious when changing the constant, it must work with nodeMonitorGracePeriod in nodecontroller.

kubelet 上报到 kube-apiserver 频率。

kube-controller-manager

–node-eviction-rate float32

Default: 0.1

Number of nodes per second on which pods are deleted in case of node failure when a zone is healthy (see –unhealthy-zone-threshold for definition of healthy/unhealthy). Zone refers to entire cluster in non-multizone clusters.

当 kube-controller-manager 判定节点故障，开始迁移（重建）pod 的速度，默认是 0.1，也就是 1Pod/10s 。

–node-monitor-grace-period duration

Default: 40s

Amount of time which we allow running Node to be unresponsive before marking it unhealthy. Must be N times more than kubelet’s nodeStatusUpdateFrequency, where N means number of retries allowed for kubelet to post node status.

kube-controller-manager 标记 kubelet(node) 为不健康的周期。

–node-monitor-period duration

Default: 5s

The period for syncing NodeStatus in NodeController.

kube-controller-manager 定期检查 kubelet(node) 状态周期。

–node-startup-grace-period duration

Default: 1m0s

Amount of time which we allow starting Node to be unresponsive before marking it unhealthy.

kube-controller-manager 在标记节点为不健康之前允许无响应时间。

–pod-eviction-timeout duration

Default: 5m0s

The grace period for deleting pods on failed nodes.

kube-controller-manager 判定节点故障，重建 Pod 的超时时间。

具体流程

看完了相关参数，我们来看下 kubelet 和 kube-controller-manager 是如何相互关联工作来保证 Pod 可用性的。

  1. kubelet 启动，若启动时间超过 node-startup-grace-period，则 kube-controller-manager 将其置为 unhealthy

  2. kubelet 按照 –node-status-update-frequency 周期，定时与 kube-apiserver 通信将其状态记录到 etcd

  3. 若 kubelet 无法连接到 kube-apiserver，那么 kubelet 会尝试 nodeStatusUpdateRetry 次更新状态信息

  4. kube-controller-manager 按照 –node-monitor-period 周期，定时从 etcd 中获取 kubelet 状态

  5. 若 kubelet 在 –node-monitor-grace-period 周期内均为非健康状态（这里如果 kubelet 未更新状态，等同），则该节点更新为 NotReady，将需要迁移（重建）的资源放置到队列中

  6. 当 kubelet NotReady 的 –pod-eviction-timeout 时间后， kube-controller-manager 开始进行 Pod 驱逐动作

  7. 驱逐速度为 –node-eviction-rate ，即每10s 迁移（重建）1个 Pod

需要注意的是，上述 kubelet 和 kube-controller-manager 的操作是异步的，中间任何一个更新步骤都有可能出现延迟的情况，所以真实情况会比上述流程复杂（诡异）的多。比如 lijieao 的最新博客中碰到的因为磁盘 IO 压力导致 kubelet NotReady 的情况，都是有可能出现的。

按照上面的流程，可以看到，当我们节点故障后，要花费 5min 的时间才会重建我们的业务，这种情况下大部分对稳定性要求较高的业务都无法忍受的，所以有同学可能会考虑修改默认配置，来减少业务宕机时间。

上述提到的参数的默认值，肯定是 k8s 社区经过多年的架构设计（或者经验？）的。之前看过社区中关于这部分的一篇文章提到，不建议修改默认的配置，担心修改了默认配置可能因为其他一些比较微小的故障导致 Pod 频繁的迁移，这是我们不想看到的。

上面提到的情况都是说：当节点发生故障后，我们希望我们的 Pod 能够第一时间迁移到正常运行的节点，那么有没有反过来的，不想迁移的呢？

其实是有的，比如有状态服务配合 kubelet 服务故障场景。我们的节点正常运行的情况下，容器运行时也都正常工作，唯独 kubelet 故障了，那么我们想想此时发生了什么？

kube-controller-manager 在一段时间后标记节点故障，开始迁移（重建） Pod 操作，但是要注意，此时因为是有状态服务，而节点上的容器又在正常运行，kubelet 由于故障了，k8s 无法直接操作节点上的容器，只能在其他节点进行重建。这时候问题就出现了，集群中存在2个 Pod 同时读写一个 PV，这种错误是致命的。

在这种场景下，我们想要追求的是哪怕节点故障了，我们也要尽量的不迁移 Pod，来保证我们数据的读写正常。

那么上述情况我们应该怎么解决呢？

总结

Operator 是一种方式。在 Operator 出现之前，有状态服务的运维工作都是靠着探针或者其他的基础运维工具来完成的，很多工作即使做到了自动化也不完美，现在有了 Operator 结合 CRD，我们完全可以自己在应用层面监控服务状态，从而主动的触发 Pod 的迁移（重建），保证我们业务的稳定。

另一种解决方式是 Taint based Evictions，在 1.13 版本中增加了该配置，我们可以在创建资源的时候，指定规则配置Pod 容忍节点异常的时间，加快触发 Pod 重建，这大大减缓了对集群配置的要求。

测试 YAML

在测试 Pod 可用性的时候，我们必须创建 Deployment、RS 类型资源，单纯的 Pod 资源是不被保证可用性的。同时我们也想观察 DaemonSet Pod 在节点故障场景下的表现，所以一同创建了。可以使用以下 YAML 用来创建测试环境。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
[root@m1 ha]# cat ha.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: busybox
  namespace: default
spec:
  replicas: 6
  selector:
    matchLabels:
      app: busybox
  template:
    metadata:
      labels:
        app: busybox
    spec:
      tolerations:
      - key: node-role.kubernetes.io/master
        effect: NoSchedule
      - key: "node.kubernetes.io/unreachable"
        operator: "Exists"
        effect: "NoExecute"
        tolerationSeconds: 2
      - key: "node.kubernetes.io/not-ready"
        operator: "Exists"
        effect: "NoExecute"
        tolerationSeconds: 2
      containers:
      - image: busybox
        command:
        - sleep
        - "3600"
        imagePullPolicy: IfNotPresent
        name: busybox
      restartPolicy: Always
---

apiVersion: "apps/v1beta1"
kind: Deployment
metadata:
  name: "dp"
  namespace: "default"
spec:
  replicas: 6
  template:
    metadata:
      labels:
        app: dp
    spec:
      tolerations:
      - key: node-role.kubernetes.io/master
        effect: NoSchedule
      containers:
      - name: "dp"
        image: "busybox:latest"
        command:
        - "/bin/sh"
        - "-c"
        - |
          set -o errexit
          set -o xtrace
          while true
          do
            sleep 2s
            date
          done

---
apiVersion: "extensions/v1beta1"
kind: "DaemonSet"
metadata:
  name: "ds"
  namespace: "default"
spec:
  template:
    metadata:
      labels:
        app: ds
    spec:
      tolerations:
      - key: node-role.kubernetes.io/master
        effect: NoSchedule
      containers:
      - name: "apply-sysctl"
        image: "busybox:latest"
        command:
        - "/bin/sh"
        - "-c"
        - |
          set -o errexit
          set -o xtrace
          while true
          do
            sleep 2s
            date
            echo "diu~"
          done

参考链接

https://github.com/Kevin-fqh/learning-k8s-source-code/blob/master/kubelet/(05)kubelet%E8%B5%84%E6%BA%90%E4%B8%8A%E6%8A%A5%26Evition%E6%9C%BA%E5%88%B6.md

https://github.com/kubernetes-sigs/kubespray/blob/master/docs/kubernetes-reliability.md

https://www.lijiaocn.com/%E9%97%AE%E9%A2%98/2019/05/27/kubernetes-node-frequently-not-ready.html#%E8%A7%82%E5%AF%9F-kubelet-%E8%BF%9B%E7%A8%8B%E7%8A%B6%E6%80%81

发表于 |

简介

Helm 就是k8s 的包管理器 。常见的包管理器有：yum,apt,pip…

包管理器基础功能有：

  • 安装
    • 依赖安装
  • 升级
  • 回滚
  • 卸载
  • 源管理
  • 搜索
  • …

基本概念

  • Helm: Kubernetes的包管理工具，命令行同名

  • Tiller: Helmv2 的服务端，用于接收并处理 Helm 发送的请求，默认以 Deployment 形式部署在 k8s 集群中

  • Chart: Helm 包管理的基础单元，等同于 RPM

  • Repoistory: Helm的软件源仓库，是一个 Web 服务器，路径下除了响应的软件 Chart 包之外，维护了一个 index.yaml 用于索引

  • Release: Helm 安装在 Kubernetes 集群中的 Chart 实例

现状

helm 截至06月20日最新稳定版本为 v2.14.1。

在05月16日发布了 v3.0 alpha 版本，根据相关文档描述，v2 无法平滑升级到 v3 版本。

注：存在部分小版本无法平滑升级情况。

helm v3 版本改进：

  1. 在 v2 版本设计中，需要单独创建属于 Tiller 的 ServiceAccount，授权 clusteradmin 权限，以为着只要你有 helm 权限，那么你有操作 k8s全集群所有权限。在 v3 版本中删除 Tiller，直接与 k8s api 进行通信，权限管理更清晰
  2. helm 提供 libary
  3. 模板引擎切换为 Lua
  4. 目前通过 Hook 方式创建的资源，helm 后续不会管理，在 v3 会增加管理 Hook 资源功能
  5. 目前所有配置保存在 cm 中，后续考虑保存到 secret
  6. v2 需要单独维护仓库，v3 中可以将 Chart 推送到 Docker 镜像仓库中，提供 helm push/login 功能
  7. …

Helm2 基本使用

安装

在 Helm Github Release 下载最新版本二进制文件，并在本地解压。

在 k8s master 节点，执行 helm init --server-account tiller 将 Tiller 部署在 k8s 集群中，指定 Service Account 为 Tiller。

在 k8s 1.6 版本之后，需要创建对应的 ServiceAccount 资源给 Tiller ，便于 Tiller 后续创建资源，参考官方文档：

rbac-config.yaml

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
apiVersion: v1
kind: ServiceAccount
metadata:
  name: tiller
  namespace: kube-system
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: tiller
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: cluster-admin
subjects:
  - kind: ServiceAccount
    name: tiller
    namespace: kube-system

1
2
3
$ kubectl create -f rbac-config.yaml
serviceaccount "tiller" created
clusterrolebinding "tiller" created

通过 helm version 验证是否部署成功，成功会显示 client 和 server 对应版本。

1
2
3
[root@node1 helm]# helm version
Client: &version.Version{SemVer:"v2.14.1", GitCommit:"5270352a09c7e8b6e8c9593002a73535276507c0", GitTreeState:"clean"}
Server: &version.Version{SemVer:"v2.14.1", GitCommit:"5270352a09c7e8b6e8c9593002a73535276507c0", GitTreeState:"clean"}

基本使用

Chart构建

本地创建一个测试软件包：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
[root@node1 helm]# helm create yiran-test
Creating yiran-test
[root@node1 helm]# tree yiran-test/
yiran-test/
├── charts                            # yiran-test 所依赖的 Chart，此处为空
├── Chart.yaml                        # yiran-test 的基本信息，包含：名称，apiversion, appversion, version
├── templates
│   ├── deployment.yaml               # 配置模板路径
│   ├── _helpers.tpl                  # 用于修改kubernetes objcet配置的模板
│   ├── ingress.yaml                  # 
│   ├── NOTES.txt                     # 类似于 Chart README
│   ├── service.yaml                  # 
│   └── tests
│       └── test-connection.yaml      # 测试模板
└── values.yaml                       # 用于渲染模板的具体值

3 directories, 8 files

有了基础示例，我们可以先通过 dry-run 方式跑一下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
[root@node1 yiran-test]# helm install --dry-run --debug ./
[debug] Created tunnel using local port: '39257'

[debug] SERVER: "127.0.0.1:39257"

[debug] Original chart version: ""
[debug] CHART PATH: /root/helm/yiran-test

NAME:   torrid-rodent
REVISION: 1
RELEASED: Thu Jun 20 19:10:08 2019
CHART: yiran-test-0.1.0
USER-SUPPLIED VALUES:
{}

COMPUTED VALUES:
affinity: {}
fullnameOverride: ""
image:
  pullPolicy: IfNotPresent
  repository: nginx
  tag: stable
imagePullSecrets: []
ingress:
  annotations: {}
  enabled: false
  hosts:
  - host: chart-example.local
    paths: []
  tls: []
nameOverride: ""
nodeSelector: {}
replicaCount: 1
resources: {}
service:
  port: 80
  type: ClusterIP
tolerations: []

HOOKS:
---
# torrid-rodent-yiran-test-test-connection
apiVersion: v1
kind: Pod
metadata:
  name: "torrid-rodent-yiran-test-test-connection"
  labels:
    app.kubernetes.io/name: yiran-test
    helm.sh/chart: yiran-test-0.1.0
    app.kubernetes.io/instance: torrid-rodent
    app.kubernetes.io/version: "1.0"
    app.kubernetes.io/managed-by: Tiller
  annotations:
    "helm.sh/hook": test-success
spec:
  containers:
    - name: wget
      image: busybox
      command: ['wget']
      args:  ['torrid-rodent-yiran-test:80']
  restartPolicy: Never
MANIFEST:

安装

可以看到生成的 YAML 文件就是拿 values.yaml 值渲染模板生成的，那么我们来安装一下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
[root@node1 yiran-test]# helm install ./
NAME:   precise-bear
LAST DEPLOYED: Thu Jun 20 19:12:01 2019
NAMESPACE: default
STATUS: DEPLOYED

RESOURCES:
==> v1/Deployment
NAME                     READY  UP-TO-DATE  AVAILABLE  AGE
precise-bear-yiran-test  0/1    0           0          1s

==> v1/Pod(related)
NAME                                      READY  STATUS             RESTARTS  AGE
precise-bear-yiran-test-785f967587-9rll6  0/1    ContainerCreating  0         1s

==> v1/Service
NAME                     TYPE       CLUSTER-IP     EXTERNAL-IP  PORT(S)  AGE
precise-bear-yiran-test  ClusterIP  10.68.142.106  <none>       80/TCP   1s


NOTES:
1. Get the application URL by running these commands:
  export POD_NAME=$(kubectl get pods --namespace default -l "app.kubernetes.io/name=yiran-test,app.kubernetes.io/instance=precise-bear" -o jsonpath="{.items[0].metadata.name}")
  echo "Visit http://127.0.0.1:8080 to use your application"
  kubectl port-forward $POD_NAME 8080:80

[root@node1 yiran-test]# helm list 
NAME            REVISION    UPDATED                     STATUS      CHART               APP VERSION NAMESPACE
precise-bear    1           Thu Jun 20 19:12:01 2019    DEPLOYED    yiran-test-0.1.0    1.0         default  
[root@node1 yiran-test]# kubectl get pod 
NAME                                       READY   STATUS    RESTARTS   AGE
precise-bear-yiran-test-785f967587-9rll6   0/1     Running   0          7s

注意，此时我们已经创建好了对应的资源，可以通过 kubectl 来查看状态。

升级

我们来修改一下 yiran-test/Chart.yaml ，调整下版本，进行升级：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
[root@node1 yiran-test]# cat Chart.yaml
apiVersion: v2
appVersion: "2.0"
description: A Helm chart for Kubernetes
name: yiran-test
version: 0.2.0
[root@node1 yiran-test]# helm list 
heNAME          REVISION    UPDATED                     STATUS      CHART               APP VERSION NAMESPACE
precise-bear    1           Thu Jun 20 19:12:01 2019    DEPLOYED    yiran-test-0.1.0    1.0         default  
[root@node1 yiran-test]# helm upgrade precise-bear ./
Release "precise-bear" has been upgraded.
LAST DEPLOYED: Thu Jun 20 19:18:30 2019
NAMESPACE: default
STATUS: DEPLOYED

RESOURCES:
==> v1/Deployment
NAME                     READY  UP-TO-DATE  AVAILABLE  AGE
precise-bear-yiran-test  1/1    1           1          6m30s

==> v1/Pod(related)
NAME                                      READY  STATUS   RESTARTS  AGE
precise-bear-yiran-test-785f967587-9rll6  1/1    Running  0         6m30s

==> v1/Service
NAME                     TYPE       CLUSTER-IP     EXTERNAL-IP  PORT(S)  AGE
precise-bear-yiran-test  ClusterIP  10.68.142.106  <none>       80/TCP   6m30s


NOTES:
1. Get the application URL by running these commands:
  export POD_NAME=$(kubectl get pods --namespace default -l "app.kubernetes.io/name=yiran-test,app.kubernetes.io/instance=precise-bear" -o jsonpath="{.items[0].metadata.name}")
  echo "Visit http://127.0.0.1:8080 to use your application"
  kubectl port-forward $POD_NAME 8080:80

[root@node1 yiran-test]# helm list 
NAME            REVISION    UPDATED                     STATUS      CHART               APP VERSION NAMESPACE
precise-bear    2           Thu Jun 20 19:18:30 2019    DEPLOYED    yiran-test-0.2.0    2.0         default

回滚

通过上述步骤，我们已经把我们的应用 yiran-test 从 0.1.0 版本升级到了 0.2.0 版本，那么我们现在来尝试下回滚。

helm 回滚操作需要指定 Release 名称和目标版本：

1
2
3
4
5
6
7
8
[root@node1 yiran-test]# helm list 
NAME            REVISION    UPDATED                     STATUS      CHART               APP VERSION NAMESPACE
precise-bear    2           Thu Jun 20 19:18:30 2019    DEPLOYED    yiran-test-0.2.0    2.0         default  
[root@node1 yiran-test]# helm rollback precise-bear 1
Rollback was a success.
[root@node1 yiran-test]# helm list 
NAME            REVISION    UPDATED                     STATUS      CHART               APP VERSION NAMESPACE
precise-bear    3           Thu Jun 20 19:23:04 2019    DEPLOYED    yiran-test-0.1.0    1.0         default

嗯，可以看到，我们指定了回滚的目标 REVISION，回滚成功了，yiran-test 回到了 0.1.0 版本，但是，最恶心的来了，Release 的当前版本变成了 3 ，而不是设想中的 1 。

卸载

如果我们想要从 k8s 上卸载对应的软件，也就是我们的 yiran-test ，我们可以直接执行 delete 命令，会直接把相关资源全部删除掉。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
[root@node1 ~]# helm list
NAME            REVISION        UPDATED                         STATUS          CHART                   APP VERSION     NAMESPACE
precise-bear    3               Thu Jun 20 19:23:04 2019        DEPLOYED        yiran-test-0.1.0        1.0             default
[root@node1 ~]# kubectl get pod
kuNAME                                       READY   STATUS    RESTARTS   AGE
precise-bear-yiran-test-785f967587-9rll6   1/1     Running   0          139m
[root@node1 ~]# kubectl get svc
NAME                      TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)   AGE
kubernetes                ClusterIP   10.68.0.1       <none>        443/TCP   36d
precise-bear-yiran-test   ClusterIP   10.68.142.106   <none>        80/TCP    139m
[root@node1 ~]# helm delete precise-bear
release "precise-bear" deleted
[root@node1 ~]# helm list
[root@node1 ~]# kubectl get pod
NAME                                       READY   STATUS        RESTARTS   AGE
precise-bear-yiran-test-785f967587-9rll6   0/1     Terminating   0          139m
[root@node1 ~]# kubectl get svc
NAME         TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)   AGE
kubernetes   ClusterIP   10.68.0.1    <none>        443/TCP   36d

软件源管理

上面我们所有的操作都是针对本地包（路径），那么我们怎么才能通过网络下载别人已经构建好的软件包呢？

helm 使用 repo 命令来管理软件源，使用上也很简单，简单列举下相应命令实用说明：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
[root@node1 ~]# helm repo list
NAME    URL
stable          https://kubernetes-charts.storage.googleapis.com
local   http://127.0.0.1:8879/charts
[root@node1 ~]# helm repo add stable-mirror https://burdenbear.github.io/kube-charts-mirror/
"stable-mirror" has been added to your repositories
[root@node1 ~]# helm repo add stable https://kubernetes-charts.storage.googleapis.com
helm repo list
"stable" has been added to your repositories
[root@node1 ~]# helm repo list
NAME            URL
stable          https://kubernetes-charts.storage.googleapis.com
local           http://127.0.0.1:8879/charts
stable-mirror   https://burdenbear.github.io/kube-charts-mirror/
[root@node1 ~]# helm repo remove local
"local" has been removed from your repositories
[root@node1 ~]# helm repo list
NAME            URL
stable          https://kubernetes-charts.storage.googleapis.com
stable-mirror   https://burdenbear.github.io/kube-charts-mirror/

软件搜索

1
2
3
4
5
[root@node1 ~]# helm search mongo
NAME                                            CHART VERSION   APP VERSION     DESCRIPTION
stable-mirror/mongodb                           5.20.0          4.0.10          NoSQL document-oriented database that stores JSON-like do...
stable-mirror/mongodb-replicaset                3.9.6           3.6             
...

打包与本地软件源构建

Helm v2 命令支持本地创建软件源，命令关键字是 helm serve ，下面来演示下相关操作：

启动本地源，并指定 IP 地址和 repo 路径：

1
2
3
4
5
6
7
[root@node1 helm]# pwd
/root/helm
[root@node1 helm]# ls 
rbac-config.yaml  yiran-test
[root@node1 helm]# helm serve --address 192.168.27.231:8879 --repo-path /root/helm/ 
Regenerating index. This may take a moment.
Now serving you on 192.168.27.231:8879

新开终端，通过修改 yiran-test 的 Chart.yaml 文件打包两个版本的 Chart：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
[root@node1 helm]# cat yiran-test/Chart.yaml 
apiVersion: v1
appVersion: "1.0"
description: A Helm chart for Kubernetes
name: yiran-test
version: 0.1.0
[root@node1 helm]# helm package yiran-test
Successfully packaged chart and saved it to: /root/helm/yiran-test-0.1.0.tgz
[root@node1 helm]# vi yiran-test/Chart.yaml 
[root@node1 helm]# cat yiran-test/Chart.yaml
apiVersion: v2
appVersion: "2.0"
description: A Helm chart for Kubernetes
name: yiran-test
version: 0.2.0
[root@node1 helm]# helm package yiran-test
Successfully packaged chart and saved it to: /root/helm/yiran-test-0.2.0.tgz
[root@node1 helm]# ls 
index.yaml  rbac-config.yaml  yiran-test  yiran-test-0.1.0.tgz  yiran-test-0.2.0.tgz

此时访问浏览器，应该只能看到空的列表，我们更新一下软件源索引：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
[root@node1 helm]# helm repo index --url=http://192.168.27.231:8879 .
[root@node1 helm]# pwd
/root/helm
[root@node1 helm]# cat index.yaml 
apiVersion: v1
entries:
  yiran-test:
  - apiVersion: v2
    appVersion: "2.0"
    created: "2019-06-21T13:43:41.220764856+08:00"
    description: A Helm chart for Kubernetes
    digest: af54cfdc5f8e6463a91311496bab8fafd7364c3588b85b5e676fb930cd4e2754
    name: yiran-test
    urls:
    - http://192.168.27.231:8879/yiran-test-0.2.0.tgz
    version: 0.2.0
  - apiVersion: v1
    appVersion: "1.0"
    created: "2019-06-21T13:43:41.220059406+08:00"
    description: A Helm chart for Kubernetes
    digest: 64b94c30827aab8e52f57cd3950645bb14ae2deb44e3100d48ecd64f1e706ea5
    name: yiran-test
    urls:
    - http://192.168.27.231:8879/yiran-test-0.1.0.tgz
    version: 0.1.0
generated: "2019-06-21T13:43:41.218753007+08:00"

可以看到在 repo 路径下生成了一个 index.yaml 文件，这个文件就是 repo 的索引文件，我们可以直接通过浏览器访问 http://192.168.27.231:8879 来浏览或下载所需软件包。

也可以将本地 repo 添加到 helm 中，使用 helm 命令将软件包部署到 k8s 中：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
[root@node1 helm]# helm repo list 
NAME         	URL                                             
stable       	https://kubernetes-charts.storage.googleapis.com
stable-mirror	https://burdenbear.github.io/kube-charts-mirror/
[root@node1 helm]# helm repo add local http://192.168.27.231:8879
"local" has been added to your repositories
[root@node1 helm]# helm repo list 
NAME         	URL                                             
stable       	https://kubernetes-charts.storage.googleapis.com
stable-mirror	https://burdenbear.github.io/kube-charts-mirror/
local        	http://192.168.27.231:8879                      
[root@node1 helm]# helm search yiran
NAME            	CHART VERSION	APP VERSION	DESCRIPTION                
local/yiran-test	0.2.0        	2.0        	A Helm chart for Kubernetes

尝试从本地源安装应用：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
[root@node1 helm]# helm list 
[root@node1 helm]# helm search yiran
NAME            	CHART VERSION	APP VERSION	DESCRIPTION                
local/yiran-test	0.2.0        	2.0        	A Helm chart for Kubernetes
[root@node1 helm]# helm install local/yiran-test
NAME:   orange-chicken
LAST DEPLOYED: Fri Jun 21 13:49:45 2019
NAMESPACE: default
STATUS: DEPLOYED

RESOURCES:
==> v1/Deployment
NAME                       READY  UP-TO-DATE  AVAILABLE  AGE
orange-chicken-yiran-test  0/1    0           0          1s

==> v1/Pod(related)
NAME                                        READY  STATUS             RESTARTS  AGE
orange-chicken-yiran-test-7f494c67b5-q9kwp  0/1    ContainerCreating  0         1s

==> v1/Service
NAME                       TYPE       CLUSTER-IP    EXTERNAL-IP  PORT(S)  AGE
orange-chicken-yiran-test  ClusterIP  10.68.85.197  <none>       80/TCP   1s


NOTES:
1. Get the application URL by running these commands:
  export POD_NAME=$(kubectl get pods --namespace default -l "app.kubernetes.io/name=yiran-test,app.kubernetes.io/instance=orange-chicken" -o jsonpath="{.items[0].metadata.name}")
  echo "Visit http://127.0.0.1:8080 to use your application"
  kubectl port-forward $POD_NAME 8080:80

[root@node1 helm]# helm list 
NAME          	REVISION	UPDATED                 	STATUS  	CHART           	APP VERSION	NAMESPACE
orange-chicken	1       	Fri Jun 21 13:49:45 2019	DEPLOYED	yiran-test-0.2.0	2.0        	default 
[root@node1 helm]# kubectl get pod 
NAME                                         READY   STATUS    RESTARTS   AGE
orange-chicken-yiran-test-7f494c67b5-q9kwp   1/1     Running   0          62s

Chart 依赖管理

包管理器一个比较钟要的功能就是依赖管理，当我安装 A，A 依赖于 B，那么 B 应该会自动安装完成。

我们在 yiran-test 中添加两个依赖，并构建：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
[root@node1 helm]# cat yiran-test/requirements.yaml   # 添加 apache 和 mysql 依赖
dependencies:
  - name: apache
    version: 4.3.2
    repository: https://charts.bitnami.com
  - name: mysql
    version: 1.2.0
    repository: https://burdenbear.github.io/kube-charts-mirror/
[root@node1 helm]# tree yiran-test/ # 当前目录结构
yiran-test/
├── charts
├── Chart.yaml
├── requirements.yaml
├── templates
│   ├── deployment.yaml
│   ├── _helpers.tpl
│   ├── ingress.yaml
│   ├── NOTES.txt
│   ├── service.yaml
│   └── tests
│       └── test-connection.yaml
└── values.yaml

3 directories, 9 files
[root@node1 helm]# helm dep up yiran-test/ # 下载依赖到本地
Hang tight while we grab the latest from your chart repositories...
...Successfully got an update from the "local" chart repository
...Successfully got an update from the "stable" chart repository
...Successfully got an update from the "bitnami" chart repository
...Successfully got an update from the "stable-mirror" chart repository
Update Complete.
Saving 2 charts
Downloading apache from repo https://charts.bitnami.com
Downloading mysql from repo https://burdenbear.github.io/kube-charts-mirror/
Deleting outdated charts
[root@node1 helm]# tree yiran-test/ # 完整目录结构
yiran-test/
├── charts
│   ├── apache-4.3.2.tgz
│   └── mysql-1.2.0.tgz
├── Chart.yaml
├── requirements.lock
├── requirements.yaml
├── templates
│   ├── deployment.yaml
│   ├── _helpers.tpl
│   ├── ingress.yaml
│   ├── NOTES.txt
│   ├── service.yaml
│   └── tests
│       └── test-connection.yaml
└── values.yaml

3 directories, 12 files
[root@node1 helm]# helm package yiran-test
Successfully packaged chart and saved it to: /root/helm/yiran-test-0.2.0.tgz

可以看到 helm 对依赖的管理方式是将自己所依赖的所有 Chart，均下载到 yiran-test/charts/ 路径下，我们打包的时候其实已经包含了所有依赖了。

再创建一个 Chart，依赖于 yiran-test ：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
[root@node1 helm]# tree nested/
nested/
├── charts
│   └── yiran-test-0.2.0.tgz
├── Chart.yaml
├── requirements.lock
├── requirements.yaml
├── templates
│   ├── deployment.yaml
│   ├── _helpers.tpl
│   ├── ingress.yaml
│   ├── NOTES.txt
│   ├── service.yaml
│   └── tests
│       └── test-connection.yaml
└── values.yaml

3 directories, 11 files
[root@node1 helm]# cat nested/requirements.yaml 
dependencies:
  - name: yiran-test
    version: 0.2.0
    repository: http://192.168.27.231:8879

实际安装 nested ，来看下安装结果：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
[root@node1 helm]# helm install nested/
NAME:   alliterating-gopher
LAST DEPLOYED: Fri Jun 21 18:22:52 2019
NAMESPACE: default
STATUS: DEPLOYED

RESOURCES:
==> v1/ConfigMap
NAME                            DATA  AGE
alliterating-gopher-mysql-test  1     1s

==> v1/Deployment
NAME                            READY  UP-TO-DATE  AVAILABLE  AGE
alliterating-gopher-nested      0/1    1           0          1s
alliterating-gopher-yiran-test  0/1    1           0          1s

==> v1/PersistentVolumeClaim
NAME                       STATUS   VOLUME  CAPACITY  ACCESS MODES  STORAGECLASS  AGE
alliterating-gopher-mysql  Pending  1s

==> v1/Pod(related)
NAME                                             READY  STATUS             RESTARTS  AGE
alliterating-gopher-apac-7bf7cc75d5-mhdsg        0/1    ContainerCreating  0         1s
alliterating-gopher-mysql-5db64c59d9-987vm       0/1    Pending            0         1s
alliterating-gopher-nested-6c74d785df-jdqgq      0/1    ContainerCreating  0         1s
alliterating-gopher-yiran-test-67b5cb5599-nfspm  0/1    ContainerCreating  0         1s

==> v1/Secret
NAME                       TYPE    DATA  AGE
alliterating-gopher-mysql  Opaque  2     1s

==> v1/Service
NAME                            TYPE          CLUSTER-IP     EXTERNAL-IP  PORT(S)                     AGE
alliterating-gopher-apac        LoadBalancer  10.68.35.233   <pending>    80:21195/TCP,443:26200/TCP  1s
alliterating-gopher-mysql       ClusterIP     10.68.70.173   <none>       3306/TCP                    1s
alliterating-gopher-nested      ClusterIP     10.68.190.252  <none>       80/TCP                      1s
alliterating-gopher-yiran-test  ClusterIP     10.68.217.171  <none>       80/TCP                      1s

==> v1beta1/Deployment
NAME                       READY  UP-TO-DATE  AVAILABLE  AGE
alliterating-gopher-apac   0/1    1           0          1s
alliterating-gopher-mysql  0/1    1           0          1s


NOTES:
1. Get the application URL by running these commands:
  export POD_NAME=$(kubectl get pods --namespace default -l "app.kubernetes.io/name=nested,app.kubernetes.io/instance=alliterating-gopher" -o jsonpath="{.items[0].metadata.name}")
  echo "Visit http://127.0.0.1:8080 to use your application"
  kubectl port-forward $POD_NAME 8080:80

[root@node1 helm]# helm list 
NAME               	REVISION	UPDATED                 	STATUS  	CHART       	APP VERSION	NAMESPACE
alliterating-gopher	1       	Fri Jun 21 18:22:52 2019	DEPLOYED	nested-0.1.0	1.0        	default  
[root@node1 helm]# kubectl get pod 
NAME                                              READY   STATUS    RESTARTS   AGE
alliterating-gopher-apac-7bf7cc75d5-mhdsg         0/1     Running   0          5s
alliterating-gopher-mysql-5db64c59d9-987vm        0/1     Pending   0          5s
alliterating-gopher-nested-6c74d785df-jdqgq       0/1     Running   0          5s
alliterating-gopher-yiran-test-67b5cb5599-nfspm   1/1     Running   0          5s

我们可以看到 nested 已经安装完成了，同时 nested 依赖得 yiran-test 及 yiran-test 依赖得 mysql & apache 也已经安装了。

具体得依赖关系直接引用官方文档示例：

假设名为 “A” 的 chart 创建以下 Kubernetes 对象

namespace “A-Namespace”
statefulset “A-StatefulSet”
service “A-Service”

此外，A 依赖于创建对象的 chart B.

namespace “B-Namespace”
replicaset “B-ReplicaSet”
service “B-Service”

安装/升级 chart A 后，会创建/修改单个 Helm 版本。该版本将按以下顺序创建/更新所有上述 Kubernetes 对象：

A-Namespace
B-Namespace
A-StatefulSet
B-ReplicaSet
A-Service
B-Service

这是因为当 Helm 安装 / 升级 charts 时，charts 中的 Kubernetes 对象及其所有依赖项都是如下

  1. 聚合成一个单一的集合;
  2. 按类型排序，然后按名称排序;
  3. 按该顺序创建/更新。

因此，单个 release 是使用 charts 及其依赖关系创建的所有对象，这意味着 Helm 不管理依赖服务的相关启动顺序，要由上层应用自己控制（比如创建响应探针）。

具体的资源创建顺序可以看 Tiller 相关代码。

总结

总体来说 Helm 基础功能使用还是很方便的，关键在于我们如何划分我们应用的粒度，比如 openstack 是以组件为粒度划分的：nova Chart 包含 api、scheduler、conductor 等服务；比如 TiDB Operator 项目是以具体功能来划分的：tidb-backup、tidb-cluster、tidb-operator 。我们应该根据自己的业务需求，合理划分。

还有一点需要注意的是，Helm 项目还处于快速发展阶段（貌似涉及 k8s 的都变化太快），尤其是最近发布了 Helm3 alpha，如果是生产系统，需要考虑后续是否能够平滑升级的影响。

如果实在不喜欢 Helm Tiller 方式，单纯使用 Helm template 也是可以的。

发表于 |

背景

最近发现一直使用的机房网络不稳定，时常出现网络无法联通，过一会又可以联通的情况，今天又遇到了，要彻底解决它。

问题

在机房网络规划中，地区 A 和地区 B 是通过 OpenVPN 连接的，也就是说每个地区的网关是一台虚拟机，提供 DHCP 服务。
今天地区 A 的机器又无法连接地区 B 了，我登陆网关尝试从网关 ping 目标主机，发现直接提示 :

1
No buffer space available

根据这个提示，感觉像是某些系统参数配置的小了，于是查了一下，发现跟 arp 有关。什么是 arp ？

相信对网络稍微有些概念的同学都不陌生，这里我直接引用维基百科：

地址解析协议（英语：Address Resolution Protocol，缩写：ARP）。在以太网协议中规定，同一局域网中的一台主机要和另一台主机进行直接通信，必须要知道目标主机的MAC地址。而在TCP/IP协议中，网络层和传输层只关心目标主机的IP地址。这就导致在以太网中使用IP协议时，数据链路层的以太网协议接到上层IP协议提供的数据中，只包含目的主机的IP地址。于是需要一种方法，根据目的主机的IP地址，获得其MAC地址。这就是ARP协议要做的事情。所谓地址解析（address resolution）就是主机在发送帧前将目标IP地址转换成目标MAC地址的过程。

另外，当发送主机和目的主机不在同一个局域网中时，即便知道对方的MAC地址，两者也不能直接通信，必须经过路由转发才可以。所以此时，发送主机通过ARP协议获得的将不是目的主机的真实MAC地址，而是一台可以通往局域网外的路由器的MAC地址。于是此后发送主机发往目的主机的所有帧，都将发往该路由器，通过它向外发送。这种情况称为委托ARP或ARP代理（ARP Proxy）。

解决

知道了原因，那么我们来调整参数就好：

1
2
3
4
5
6
gc_thresh1 (since Linux 2.2)
The minimum number of entries to keep in the ARP cache. The garbage collector will not run if there are fewer than this number of entries in the cache. Defaults to 128.
gc_thresh2 (since Linux 2.2)
The soft maximum number of entries to keep in the ARP cache. The garbage collector will allow the number of entries to exceed this for 5 seconds before collection will be performed. Defaults to 512.
gc_thresh3 (since Linux 2.2)
The hard maximum number of entries to keep in the ARP cache. The garbage collector will always run if there are more than this number of entries in the cache. Defaults to 1024.
1
2
3
4
5
6
7
8
9
10
11
12
yiran@test:~$ cat /etc/sysctl.conf |grep -v ^# |grep -v ^$
net.ipv4.tcp_congestion_control = bbr
net.core.default_qdisc = fq
net.ipv4.neigh.default.gc_thresh1 = 4096
net.ipv4.neigh.default.gc_thresh2 = 8192
net.ipv4.neigh.default.gc_thresh3 = 8192
yiran@test:~$ sudo sysctl -p
net.ipv4.tcp_congestion_control = bbr
net.core.default_qdisc = fq
net.ipv4.neigh.default.gc_thresh1 = 4096
net.ipv4.neigh.default.gc_thresh2 = 8192
net.ipv4.neigh.default.gc_thresh3 = 8192

发表于 |

准备工作

本文所有节点 OS 均为 CentOS 7.4 。

1.关闭 selinux

所有节点执行：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
[root@node211 ~]# cat /etc/selinux/config 

# This file controls the state of SELinux on the system.
# SELINUX= can take one of these three values:
#     enforcing - SELinux security policy is enforced.
#     permissive - SELinux prints warnings instead of enforcing.
#     disabled - No SELinux policy is loaded.
SELINUX=disabled
# SELINUXTYPE= can take one of three two values:
#     targeted - Targeted processes are protected,
#     minimum - Modification of targeted policy. Only selected processes are protected. 
#     mls - Multi Level Security protection.
SELINUXTYPE=targeted 


[root@node211 ~]# getenforce 
Disabled

2. 关于 firewalld

所有节点执行：

1
2
3
4
5
6
7
8
[root@node211 ~]# systemctl disable firewalld
[root@node211 ~]# systemctl stop firewalld
[root@node211 ~]# systemctl status firewalld
[root@node211 ~]# systemctl status firewalld
● firewalld.service - firewalld - dynamic firewall daemon
   Loaded: loaded (/usr/lib/systemd/system/firewalld.service; disabled; vendor preset: enabled)
   Active: inactive (dead)
     Docs: man:firewalld(1)

3. 安装必要 yum 源：epel-release

所有节点执行：

1
2
3
[root@node211 ~]# yum install epel-release
[root@node211 ~]# ls /etc/yum.repos.d/epel.repo 
/etc/yum.repos.d/epel.repo

4. 关闭节点 swap 空间

所有节点执行：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
[root@node211 ~]# cat /etc/fstab 

#
# /etc/fstab
# Created by anaconda on Thu Jun 13 09:45:52 2019
#
# Accessible filesystems, by reference, are maintained under '/dev/disk'
# See man pages fstab(5), findfs(8), mount(8) and/or blkid(8) for more info
#
/dev/mapper/centos-root /                       xfs     defaults        0 0
UUID=c0f0a31a-0c36-42cf-b52a-8f3b027ef948 /boot                   xfs     defaults        0 0
#/dev/mapper/centos-swap swap                    swap    defaults        0 0
[root@node211 ~]# free -h
              total        used        free      shared  buff/cache   available
Mem:           3.7G        102M        3.3G        8.3M        230M        3.3G
Swap:            0B          0B          0B

5. 安装 docker-ce

所有节点执行：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
[root@node211 ~]# 
[root@node211 ~]# head -n 6 /etc/yum.repos.d/docker-ce.repo
[docker-ce-stable]
name=Docker CE Stable - $basearch
baseurl=https://download.docker.com/linux/centos/7/$basearch/stable
enabled=1
gpgcheck=1
gpgkey=https://download.docker.com/linux/centos/gpg
[root@node211 ~]# rpm -q docker
docker-1.13.1-96.gitb2f74b2.el7.centos.x86_64
[root@node211 ~]# systemctl enable docker
[root@node211 ~]# systemctl start docker
[root@node211 ~]# systemctl status docker
● docker.service - Docker Application Container Engine
   Loaded: loaded (/usr/lib/systemd/system/docker.service; enabled; vendor preset: disabled)
   Active: active (running) since Fri 2019-06-14 19:48:40 CST; 3s ago
     Docs: http://docs.docker.com
 Main PID: 11488 (dockerd-current)
   CGroup: /system.slice/docker.service
           ├─11488 /usr/bin/dockerd-current --add-runtime docker-runc=/usr/libexec/docker/docker-runc-current --default-runtime=docker-runc --exec-opt native.cgroupdriver=systemd --userland-proxy-path=/usr/libexec/docker/docker-proxy-current --init-path=/usr...
           └─11495 /usr/bin/docker-containerd-current -l unix:///var/run/docker/libcontainerd/docker-containerd.sock --metrics-interval=0 --start-timeout 2m --state-dir /var/run/docker/libcontainerd/containerd --shim docker-containerd-shim --runtime docker-r...

Jun 14 19:48:40 node211 dockerd-current[11488]: time="2019-06-14T19:48:40.282909889+08:00" level=info msg="Docker daemon" commit="b2f74b2/1.13.1" graphdriver=overlay2 version=1.13.1
Jun 14 19:48:40 node211 dockerd-current[11488]: time="2019-06-14T19:48:40.293315055+08:00" level=info msg="API listen on /var/run/docker.sock"
Jun 14 19:48:40 node211 systemd[1]: Started Docker Application Container Engine.

6. 开启必要系统参数 sysctl

所有节点执行：

1
2
3
[root@node211 ~]# sysctl -p
net.bridge.bridge-nf-call-ip6tables = 1
net.bridge.bridge-nf-call-iptables = 1

kubeadm

因为 kubeadm 官方文档中没有详细步骤，因此相关描述尽量具体到命令行。

环境信息

ip role
192.168.77.211 master
192.168.77.212 master
192.168.77.213 master
192.168.77.214 node

1. 安装 kubeadm

所有节点执行：

1
2
3
4
5
6
7
8
9
10
11
12
[root@node211 ~]# cat /etc/yum.repos.d/kubernetes.repo 
[kubernetes]
name=Kubernetes
baseurl=https://packages.cloud.google.com/yum/repos/kubernetes-el7-x86_64
enabled=1
gpgcheck=1
repo_gpgcheck=1
gpgkey=https://packages.cloud.google.com/yum/doc/yum-key.gpg https://packages.cloud.google.com/yum/doc/rpm-package-key.gpg
proxy=socks5://127.0.0.1:1080
[root@node211 ~]# yum install kubeadm kubelet
[root@node211 ~]# which kubeadm 
/usr/bin/kubeadm

2. 安装 keepalived

所有 master 节点执行：

1
2
3
[root@node211 ~]# yum install keepalived
[root@node212 ~]# yum install keepalived 
[root@node213 ~]# yum install keepalived

编辑 node211 配置文件：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
[root@node211 ~]# cat /etc/keepalived/keepalived.conf 
! Configuration File for keepalived

global_defs {
   notification_email {
        feng110498@163.com
   }
   notification_email_from Alexandre.Cassen@firewall.loc
   smtp_server 127.0.0.1
   smtp_connect_timeout 30
   router_id LVS_1
}

vrrp_instance VI_1 {
    state MASTER          
    interface eth0
    lvs_sync_daemon_inteface eth0
    virtual_router_id 79
    advert_int 1
    priority 100         
    authentication {
        auth_type PASS
        auth_pass 1111
    }
    virtual_ipaddress {
      192.168.77.219/20
    }
}

编辑 node212 配置文件：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
[root@node212 ~]# cat /etc/keepalived/keepalived.conf 
! Configuration File for keepalived

global_defs {
   notification_email {
        feng110498@163.com
   }
   notification_email_from Alexandre.Cassen@firewall.loc
   smtp_server 127.0.0.1
   smtp_connect_timeout 30
   router_id LVS_1
}

vrrp_instance VI_1 {
    state MASTER          
    interface eth0
    lvs_sync_daemon_inteface eth0
    virtual_router_id 79
    advert_int 1
    priority 90         
    authentication {
        auth_type PASS
        auth_pass 1111
    }
    virtual_ipaddress {
      192.168.77.219/20
    }
}

编辑 node213 配置文件：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
[root@node213 ~]# cat /etc/keepalived/keepalived.conf 
! Configuration File for keepalived

global_defs {
   notification_email {
        feng110498@163.com
   }
   notification_email_from Alexandre.Cassen@firewall.loc
   smtp_server 127.0.0.1
   smtp_connect_timeout 30
   router_id LVS_1
}

vrrp_instance VI_1 {
    state MASTER          
    interface eth0
    lvs_sync_daemon_inteface eth0
    virtual_router_id 79
    advert_int 1
    priority 70         
    authentication {
        auth_type PASS
        auth_pass 1111
    }
    virtual_ipaddress {
      192.168.77.219/20
    }
}

node211, node212, node213 重启 keepalived：

1
2
3
[root@node211 ~]# systemctl restart keepalived
[root@node212 ~]# systemctl restart keepalived
[root@node213 ~]# systemctl restart keepalived

因为 node211 优先级最高，此时 VIP 192.168.77.219 应该在 node211 节点，查看 node211 节点 IP：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
[root@node211 ~]# ip ad 
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 52:54:00:42:fd:a6 brd ff:ff:ff:ff:ff:ff
    inet 192.168.77.211/20 brd 192.168.79.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet 192.168.77.219/20 scope global secondary eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::5554:b212:7895:c8ad/64 scope link tentative dadfailed 
       valid_lft forever preferred_lft forever
    inet6 fe80::3e97:25b9:cc1a:809c/64 scope link tentative dadfailed 
       valid_lft forever preferred_lft forever
    inet6 fe80::7a4f:3726:af17:18bf/64 scope link tentative dadfailed 
       valid_lft forever preferred_lft forever
3: docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN 
    link/ether 02:42:6f:0e:81:59 brd ff:ff:ff:ff:ff:ff
    inet 172.17.0.1/16 scope global docker0
       valid_lft forever preferred_lft forever

配置无异常，node211,node212,node213 设置开机自启动：

1
2
3
4
5
6
[root@node211 ~]# systemctl enable keepalived
Created symlink from /etc/systemd/system/multi-user.target.wants/keepalived.service to /usr/lib/systemd/system/keepalived.service.
[root@node212 ~]# systemctl enable keepalived
Created symlink from /etc/systemd/system/multi-user.target.wants/keepalived.service to /usr/lib/systemd/system/keepalived.service.
[root@node213 ~]# systemctl enable keepalived
Created symlink from /etc/systemd/system/multi-user.target.wants/keepalived.service to /usr/lib/systemd/system/keepalived.service.

3. 安装 haproxy

所有 master 节点执行：

1
2
3
[root@node211 ~]# yum install haproxy
[root@node212 ~]# yum install haproxy
[root@node213 ~]# yum install haproxy

编辑所有 master 节点配置文件：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
[root@node211 ~]# cat /etc/haproxy/haproxy.cfg 
global
        chroot  /var/lib/haproxy
        daemon
        group haproxy
        user haproxy
        log 127.0.0.1:514 local0 warning
        pidfile /var/lib/haproxy.pid
        maxconn 20000
        spread-checks 3
        nbproc 8

defaults
        log     global
        mode    tcp
        retries 3
        option redispatch

listen https-apiserver
        bind *:8443
        mode tcp
        balance roundrobin
        timeout server 900s
        timeout connect 15s

        server m1 192.168.77.211:6443 check port 6443 inter 5000 fall 5
        server m2 192.168.77.212:6443 check port 6443 inter 5000 fall 5
        server m3 192.168.77.213:6443 check port 6443 inter 5000 fall 5

所有 master 节点启动 haproxy，并设置 开机自启动：

1
2
3
4
5
6
7
8
9
[root@node211 ~]# systemctl start haproxy 
[root@node211 ~]# systemctl enable haproxy
Created symlink from /etc/systemd/system/multi-user.target.wants/haproxy.service to /usr/lib/systemd/system/haproxy.service.
[root@node212 ~]# systemctl start haproxy 
[root@node212 ~]# systemctl enable haproxy
Created symlink from /etc/systemd/system/multi-user.target.wants/haproxy.service to /usr/lib/systemd/system/haproxy.service.
[root@node213 ~]# systemctl start haproxy 
[root@node213 ~]# systemctl enable haproxy
Created symlink from /etc/systemd/system/multi-user.target.wants/haproxy.service to /usr/lib/systemd/system/haproxy.service.

4. 编写 kubeadm 配置文件

在 node211 节点编写 kubeadm 配置文件：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
[root@node211 ~]# cat kubeadm-init.yaml
apiVersion: kubeadm.k8s.io/v1beta1
kind: ClusterConfiguration
apiServer:
  timeoutForControlPlane: 4m0s
certificatesDir: /etc/kubernetes/pki
clusterName: kubernetes
controlPlaneEndpoint: "192.168.77.219:8443"
dns:
  type: CoreDNS
etcd:
  local:
    dataDir: /var/lib/etcd
imageRepository: registry.cn-hangzhou.aliyuncs.com/google_containers
kubernetesVersion: v1.14.3
networking:
  dnsDomain: cluster.local
  podSubnet: "10.123.0.0/16"
scheduler: {}
controllerManager: {}
---
apiVersion: kubeproxy.config.k8s.io/v1alpha1
kind: KubeProxyConfiguration
mode: "ipvs"

5. 初始化

在 node211 节点执行初始化操作：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
[root@node211 ~]# kubeadm init --config=kubeadm-init.yaml --experimental-upload-certs
[init] Using Kubernetes version: v1.14.3
[preflight] Running pre-flight checks
	[WARNING Hostname]: hostname "node211" could not be reached
	[WARNING Hostname]: hostname "node211": lookup node211 on 192.168.64.215:53: no such host
	[WARNING Service-Kubelet]: kubelet service is not enabled, please run 'systemctl enable kubelet.service'
	[WARNING RequiredIPVSKernelModulesAvailable]: 

The IPVS proxier may not be used because the following required kernel modules are not loaded: [ip_vs_rr ip_vs_wrr ip_vs_sh]
or no builtin kernel IPVS support was found: map[ip_vs:{} ip_vs_rr:{} ip_vs_sh:{} ip_vs_wrr:{} nf_conntrack_ipv4:{}].
However, these modules may be loaded automatically by kube-proxy if they are available on your system.
To verify IPVS support:

   Run "lsmod | grep 'ip_vs|nf_conntrack'" and verify each of the above modules are listed.

If they are not listed, you can use the following methods to load them:

1. For each missing module run 'modprobe $modulename' (e.g., 'modprobe ip_vs', 'modprobe ip_vs_rr', ...)
2. If 'modprobe $modulename' returns an error, you will need to install the missing module support for your kernel.

[preflight] Pulling images required for setting up a Kubernetes cluster
[preflight] This might take a minute or two, depending on the speed of your internet connection
[preflight] You can also perform this action in beforehand using 'kubeadm config images pull'
[kubelet-start] Writing kubelet environment file with flags to file "/var/lib/kubelet/kubeadm-flags.env"
[kubelet-start] Writing kubelet configuration to file "/var/lib/kubelet/config.yaml"
[kubelet-start] Activating the kubelet service
[certs] Using certificateDir folder "/etc/kubernetes/pki"
[certs] Generating "ca" certificate and key
[certs] Generating "apiserver" certificate and key
[certs] apiserver serving cert is signed for DNS names [node211 kubernetes kubernetes.default kubernetes.default.svc kubernetes.default.svc.cluster.local] and IPs [10.96.0.1 192.168.77.211 192.168.77.219]
[certs] Generating "apiserver-kubelet-client" certificate and key
[certs] Generating "front-proxy-ca" certificate and key
[certs] Generating "front-proxy-client" certificate and key
[certs] Generating "etcd/ca" certificate and key
[certs] Generating "etcd/server" certificate and key
[certs] etcd/server serving cert is signed for DNS names [node211 localhost] and IPs [192.168.77.211 127.0.0.1 ::1]
[certs] Generating "etcd/peer" certificate and key
[certs] etcd/peer serving cert is signed for DNS names [node211 localhost] and IPs [192.168.77.211 127.0.0.1 ::1]
[certs] Generating "etcd/healthcheck-client" certificate and key
[certs] Generating "apiserver-etcd-client" certificate and key
[certs] Generating "sa" key and public key
[kubeconfig] Using kubeconfig folder "/etc/kubernetes"
[endpoint] WARNING: port specified in controlPlaneEndpoint overrides bindPort in the controlplane address
[kubeconfig] Writing "admin.conf" kubeconfig file
[endpoint] WARNING: port specified in controlPlaneEndpoint overrides bindPort in the controlplane address
[kubeconfig] Writing "kubelet.conf" kubeconfig file
[endpoint] WARNING: port specified in controlPlaneEndpoint overrides bindPort in the controlplane address
[kubeconfig] Writing "controller-manager.conf" kubeconfig file
[endpoint] WARNING: port specified in controlPlaneEndpoint overrides bindPort in the controlplane address
[kubeconfig] Writing "scheduler.conf" kubeconfig file
[control-plane] Using manifest folder "/etc/kubernetes/manifests"
[control-plane] Creating static Pod manifest for "kube-apiserver"
[control-plane] Creating static Pod manifest for "kube-controller-manager"
[control-plane] Creating static Pod manifest for "kube-scheduler"
[etcd] Creating static Pod manifest for local etcd in "/etc/kubernetes/manifests"
[wait-control-plane] Waiting for the kubelet to boot up the control plane as static Pods from directory "/etc/kubernetes/manifests". This can take up to 4m0s
[kubelet-check] Initial timeout of 40s passed.
[apiclient] All control plane components are healthy after 107.014141 seconds
[upload-config] storing the configuration used in ConfigMap "kubeadm-config" in the "kube-system" Namespace
[kubelet] Creating a ConfigMap "kubelet-config-1.14" in namespace kube-system with the configuration for the kubelets in the cluster
[upload-certs] Storing the certificates in ConfigMap "kubeadm-certs" in the "kube-system" Namespace
[upload-certs] Using certificate key:
1436c652cc6bb7e91386b4f744e3376df7b3b6ffd5e9a1a2930f9b6241daac4a
[mark-control-plane] Marking the node node211 as control-plane by adding the label "node-role.kubernetes.io/master=''"
[mark-control-plane] Marking the node node211 as control-plane by adding the taints [node-role.kubernetes.io/master:NoSchedule]
[bootstrap-token] Using token: ptuvy5.hl4rzxugpxpgkgkh
[bootstrap-token] Configuring bootstrap tokens, cluster-info ConfigMap, RBAC Roles
[bootstrap-token] configured RBAC rules to allow Node Bootstrap tokens to post CSRs in order for nodes to get long term certificate credentials
[bootstrap-token] configured RBAC rules to allow the csrapprover controller automatically approve CSRs from a Node Bootstrap Token
[bootstrap-token] configured RBAC rules to allow certificate rotation for all node client certificates in the cluster
[bootstrap-token] creating the "cluster-info" ConfigMap in the "kube-public" namespace
[addons] Applied essential addon: CoreDNS
[endpoint] WARNING: port specified in controlPlaneEndpoint overrides bindPort in the controlplane address
[addons] Applied essential addon: kube-proxy

Your Kubernetes control-plane has initialized successfully!

To start using your cluster, you need to run the following as a regular user:

  mkdir -p $HOME/.kube
  sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
  sudo chown $(id -u):$(id -g) $HOME/.kube/config

You should now deploy a pod network to the cluster.
Run "kubectl apply -f [podnetwork].yaml" with one of the options listed at:
  https://kubernetes.io/docs/concepts/cluster-administration/addons/

You can now join any number of the control-plane node running the following command on each as root:

  kubeadm join 192.168.77.219:8443 --token ptuvy5.hl4rzxugpxpgkgkh \
    --discovery-token-ca-cert-hash sha256:2a190612b1e3a68a549d02b42335bfba4dd4af3bb1361124ad46862e1ab418d4 \
    --experimental-control-plane --certificate-key 1436c652cc6bb7e91386b4f744e3376df7b3b6ffd5e9a1a2930f9b6241daac4a

Please note that the certificate-key gives access to cluster sensitive data, keep it secret!
As a safeguard, uploaded-certs will be deleted in two hours; If necessary, you can use 
"kubeadm init phase upload-certs --experimental-upload-certs" to reload certs afterward.

Then you can join any number of worker nodes by running the following on each as root:

kubeadm join 192.168.77.219:8443 --token ptuvy5.hl4rzxugpxpgkgkh \
    --discovery-token-ca-cert-hash sha256:2a190612b1e3a68a549d02b42335bfba4dd4af3bb1361124ad46862e1ab418d4

按照说明，拷贝 kubectl 配置文件并验证：

1
2
3
4
5
6
[root@node211 ~]# mkdir -p $HOME/.kube
[root@node211 ~]# sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
[root@node211 ~]# sudo chown $(id -u):$(id -g) $HOME/.kube/config
[root@node211 ~]# kubectl get node
NAME      STATUS     ROLES    AGE   VERSION
node211   NotReady   master   82s   v1.14.3

6. 部署 flannel 网络插件

在 node211 节点部署 flannel 插件：

1
2
3
4
5
6
7
8
9
10
[root@node211 ~]# kubectl apply -f https://raw.githubusercontent.com/coreos/flannel/a70459be0084506e4ec919aa1c114638878db11b/Documentation/kube-flannel.yml
clusterrole.rbac.authorization.k8s.io/flannel created
clusterrolebinding.rbac.authorization.k8s.io/flannel created
serviceaccount/flannel created
configmap/kube-flannel-cfg created
daemonset.extensions/kube-flannel-ds-amd64 created
daemonset.extensions/kube-flannel-ds-arm64 created
daemonset.extensions/kube-flannel-ds-arm created
daemonset.extensions/kube-flannel-ds-ppc64le created
daemonset.extensions/kube-flannel-ds-s390x created

查看部署状态：

1
2
3
4
5
6
7
8
9
10
[root@node211 ~]# kubectl get pod -n kube-system
NAME                              READY   STATUS    RESTARTS   AGE
coredns-d5947d4b-rn2wl            0/1     Pending   0          3m17s
coredns-d5947d4b-zdptx            0/1     Pending   0          3m17s
etcd-node211                      1/1     Running   0          2m48s
kube-apiserver-node211            1/1     Running   0          2m28s
kube-controller-manager-node211   1/1     Running   0          2m59s
kube-flannel-ds-amd64-vzk7c       1/1     Running   0          36s
kube-proxy-w5gsg                  1/1     Running   0          3m16s
kube-scheduler-node211            1/1     Running   0          2m41s

7. 添加其他 master 节点

按照 node211 初始化提示，在 node212 节点及 node213 节点添加到集群，角色为 master：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
[root@node212 ~]# kubeadm join 192.168.77.219:8443 --token ptuvy5.hl4rzxugpxpgkgkh \
>     --discovery-token-ca-cert-hash sha256:2a190612b1e3a68a549d02b42335bfba4dd4af3bb1361124ad46862e1ab418d4 \
>     --experimental-control-plane --certificate-key 1436c652cc6bb7e91386b4f744e3376df7b3b6ffd5e9a1a2930f9b6241daac4a
[preflight] Running pre-flight checks
	[WARNING Hostname]: hostname "node212" could not be reached
	[WARNING Hostname]: hostname "node212": lookup node212 on 192.168.64.215:53: no such host
	[WARNING Service-Kubelet]: kubelet service is not enabled, please run 'systemctl enable kubelet.service'
[preflight] Reading configuration from the cluster...
[preflight] FYI: You can look at this config file with 'kubectl -n kube-system get cm kubeadm-config -oyaml'
	[WARNING RequiredIPVSKernelModulesAvailable]: 

The IPVS proxier may not be used because the following required kernel modules are not loaded: [ip_vs_sh ip_vs_rr ip_vs_wrr]
or no builtin kernel IPVS support was found: map[ip_vs:{} ip_vs_rr:{} ip_vs_sh:{} ip_vs_wrr:{} nf_conntrack_ipv4:{}].
However, these modules may be loaded automatically by kube-proxy if they are available on your system.
To verify IPVS support:

   Run "lsmod | grep 'ip_vs|nf_conntrack'" and verify each of the above modules are listed.

If they are not listed, you can use the following methods to load them:

1. For each missing module run 'modprobe $modulename' (e.g., 'modprobe ip_vs', 'modprobe ip_vs_rr', ...)
2. If 'modprobe $modulename' returns an error, you will need to install the missing module support for your kernel.

[preflight] Running pre-flight checks before initializing the new control plane instance
[preflight] Pulling images required for setting up a Kubernetes cluster
[preflight] This might take a minute or two, depending on the speed of your internet connection
[preflight] You can also perform this action in beforehand using 'kubeadm config images pull'
[download-certs] Downloading the certificates in Secret "kubeadm-certs" in the "kube-system" Namespace
[certs] Using certificateDir folder "/etc/kubernetes/pki"
[certs] Generating "etcd/server" certificate and key
[certs] etcd/server serving cert is signed for DNS names [node212 localhost] and IPs [192.168.77.212 127.0.0.1 ::1]
[certs] Generating "apiserver-etcd-client" certificate and key
[certs] Generating "etcd/peer" certificate and key
[certs] etcd/peer serving cert is signed for DNS names [node212 localhost] and IPs [192.168.77.212 127.0.0.1 ::1]
[certs] Generating "etcd/healthcheck-client" certificate and key
[certs] Generating "apiserver" certificate and key
[certs] apiserver serving cert is signed for DNS names [node212 kubernetes kubernetes.default kubernetes.default.svc kubernetes.default.svc.cluster.local] and IPs [10.96.0.1 192.168.77.212 192.168.77.219]
[certs] Generating "apiserver-kubelet-client" certificate and key
[certs] Generating "front-proxy-client" certificate and key
[certs] Valid certificates and keys now exist in "/etc/kubernetes/pki"
[certs] Using the existing "sa" key
[kubeconfig] Generating kubeconfig files
[kubeconfig] Using kubeconfig folder "/etc/kubernetes"
[endpoint] WARNING: port specified in controlPlaneEndpoint overrides bindPort in the controlplane address
[kubeconfig] Writing "admin.conf" kubeconfig file
[kubeconfig] Writing "controller-manager.conf" kubeconfig file
[kubeconfig] Writing "scheduler.conf" kubeconfig file
[control-plane] Using manifest folder "/etc/kubernetes/manifests"
[control-plane] Creating static Pod manifest for "kube-apiserver"
[control-plane] Creating static Pod manifest for "kube-controller-manager"
[control-plane] Creating static Pod manifest for "kube-scheduler"
[check-etcd] Checking that the etcd cluster is healthy
[kubelet-start] Downloading configuration for the kubelet from the "kubelet-config-1.14" ConfigMap in the kube-system namespace
[kubelet-start] Writing kubelet configuration to file "/var/lib/kubelet/config.yaml"
[kubelet-start] Writing kubelet environment file with flags to file "/var/lib/kubelet/kubeadm-flags.env"
[kubelet-start] Activating the kubelet service
[kubelet-start] Waiting for the kubelet to perform the TLS Bootstrap...
[etcd] Announced new etcd member joining to the existing etcd cluster
[etcd] Wrote Static Pod manifest for a local etcd member to "/etc/kubernetes/manifests/etcd.yaml"
[etcd] Waiting for the new etcd member to join the cluster. This can take up to 40s
[upload-config] storing the configuration used in ConfigMap "kubeadm-config" in the "kube-system" Namespace
[mark-control-plane] Marking the node node212 as control-plane by adding the label "node-role.kubernetes.io/master=''"
[mark-control-plane] Marking the node node212 as control-plane by adding the taints [node-role.kubernetes.io/master:NoSchedule]

This node has joined the cluster and a new control plane instance was created:

* Certificate signing request was sent to apiserver and approval was received.
* The Kubelet was informed of the new secure connection details.
* Control plane (master) label and taint were applied to the new node.
* The Kubernetes control plane instances scaled up.
* A new etcd member was added to the local/stacked etcd cluster.

To start administering your cluster from this node, you need to run the following as a regular user:

	mkdir -p $HOME/.kube
	sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
	sudo chown $(id -u):$(id -g) $HOME/.kube/config

Run 'kubectl get nodes' to see this node join the cluster.

按照说明，拷贝 kubectl 配置文件并验证：

1
2
3
4
5
6
7
[root@node212 ~]# mkdir -p $HOME/.kube
[root@node212 ~]# sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
[root@node212 ~]# sudo chown $(id -u):$(id -g) $HOME/.kube/config
[root@node212 ~]# kubectl get node
NAME      STATUS   ROLES    AGE     VERSION
node211   Ready    master   7m48s   v1.14.3
node212   Ready    master   66s     v1.14.3
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
[root@node213 ~]# kubeadm join 192.168.77.219:8443 --token ptuvy5.hl4rzxugpxpgkgkh \
>     --discovery-token-ca-cert-hash sha256:2a190612b1e3a68a549d02b42335bfba4dd4af3bb1361124ad46862e1ab418d4 \
>     --experimental-control-plane --certificate-key 1436c652cc6bb7e91386b4f744e3376df7b3b6ffd5e9a1a2930f9b6241daac4a
[preflight] Running pre-flight checks
	[WARNING Hostname]: hostname "node213" could not be reached
	[WARNING Hostname]: hostname "node213": lookup node213 on 192.168.64.215:53: no such host
	[WARNING Service-Kubelet]: kubelet service is not enabled, please run 'systemctl enable kubelet.service'
[preflight] Reading configuration from the cluster...
[preflight] FYI: You can look at this config file with 'kubectl -n kube-system get cm kubeadm-config -oyaml'
	[WARNING RequiredIPVSKernelModulesAvailable]: 

The IPVS proxier may not be used because the following required kernel modules are not loaded: [ip_vs_wrr ip_vs_sh ip_vs_rr]
or no builtin kernel IPVS support was found: map[ip_vs:{} ip_vs_rr:{} ip_vs_sh:{} ip_vs_wrr:{} nf_conntrack_ipv4:{}].
However, these modules may be loaded automatically by kube-proxy if they are available on your system.
To verify IPVS support:

   Run "lsmod | grep 'ip_vs|nf_conntrack'" and verify each of the above modules are listed.

If they are not listed, you can use the following methods to load them:

1. For each missing module run 'modprobe $modulename' (e.g., 'modprobe ip_vs', 'modprobe ip_vs_rr', ...)
2. If 'modprobe $modulename' returns an error, you will need to install the missing module support for your kernel.

[preflight] Running pre-flight checks before initializing the new control plane instance
[preflight] Pulling images required for setting up a Kubernetes cluster
[preflight] This might take a minute or two, depending on the speed of your internet connection
[preflight] You can also perform this action in beforehand using 'kubeadm config images pull'
[download-certs] Downloading the certificates in Secret "kubeadm-certs" in the "kube-system" Namespace
[certs] Using certificateDir folder "/etc/kubernetes/pki"
[certs] Generating "front-proxy-client" certificate and key
[certs] Generating "etcd/server" certificate and key
[certs] etcd/server serving cert is signed for DNS names [node213 localhost] and IPs [192.168.77.213 127.0.0.1 ::1]
[certs] Generating "etcd/peer" certificate and key
[certs] etcd/peer serving cert is signed for DNS names [node213 localhost] and IPs [192.168.77.213 127.0.0.1 ::1]
[certs] Generating "etcd/healthcheck-client" certificate and key
[certs] Generating "apiserver-etcd-client" certificate and key
[certs] Generating "apiserver" certificate and key
[certs] apiserver serving cert is signed for DNS names [node213 kubernetes kubernetes.default kubernetes.default.svc kubernetes.default.svc.cluster.local] and IPs [10.96.0.1 192.168.77.213 192.168.77.219]
[certs] Generating "apiserver-kubelet-client" certificate and key
[certs] Valid certificates and keys now exist in "/etc/kubernetes/pki"
[certs] Using the existing "sa" key
[kubeconfig] Generating kubeconfig files
[kubeconfig] Using kubeconfig folder "/etc/kubernetes"
[endpoint] WARNING: port specified in controlPlaneEndpoint overrides bindPort in the controlplane address
[kubeconfig] Writing "admin.conf" kubeconfig file
[kubeconfig] Writing "controller-manager.conf" kubeconfig file
[kubeconfig] Writing "scheduler.conf" kubeconfig file
[control-plane] Using manifest folder "/etc/kubernetes/manifests"
[control-plane] Creating static Pod manifest for "kube-apiserver"
[control-plane] Creating static Pod manifest for "kube-controller-manager"
[control-plane] Creating static Pod manifest for "kube-scheduler"
[check-etcd] Checking that the etcd cluster is healthy
[kubelet-start] Downloading configuration for the kubelet from the "kubelet-config-1.14" ConfigMap in the kube-system namespace
[kubelet-start] Writing kubelet configuration to file "/var/lib/kubelet/config.yaml"
[kubelet-start] Writing kubelet environment file with flags to file "/var/lib/kubelet/kubeadm-flags.env"
[kubelet-start] Activating the kubelet service
[kubelet-start] Waiting for the kubelet to perform the TLS Bootstrap...
[etcd] Announced new etcd member joining to the existing etcd cluster
[etcd] Wrote Static Pod manifest for a local etcd member to "/etc/kubernetes/manifests/etcd.yaml"
[etcd] Waiting for the new etcd member to join the cluster. This can take up to 40s
[upload-config] storing the configuration used in ConfigMap "kubeadm-config" in the "kube-system" Namespace
[mark-control-plane] Marking the node node213 as control-plane by adding the label "node-role.kubernetes.io/master=''"
[mark-control-plane] Marking the node node213 as control-plane by adding the taints [node-role.kubernetes.io/master:NoSchedule]

This node has joined the cluster and a new control plane instance was created:

* Certificate signing request was sent to apiserver and approval was received.
* The Kubelet was informed of the new secure connection details.
* Control plane (master) label and taint were applied to the new node.
* The Kubernetes control plane instances scaled up.
* A new etcd member was added to the local/stacked etcd cluster.

To start administering your cluster from this node, you need to run the following as a regular user:

	mkdir -p $HOME/.kube
	sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
	sudo chown $(id -u):$(id -g) $HOME/.kube/config

Run 'kubectl get nodes' to see this node join the cluster.

按照说明，拷贝 kubectl 配置文件并验证：

1
2
3
4
5
6
7
8
[root@node213 ~]# mkdir -p $HOME/.kube
[root@node213 ~]# sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
[root@node213 ~]# sudo chown $(id -u):$(id -g) $HOME/.kube/config
[root@node213 ~]# kubectl get node
NAME      STATUS   ROLES    AGE     VERSION
node211   Ready    master   11m     v1.14.3
node212   Ready    master   4m39s   v1.14.3
node213   Ready    master   72s     v1.14.3

8. 添加其他 node 节点

按照 node211 初始化提示，添加 node214 节点到集群，角色为 node：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
[root@node214 ~]# kubeadm join 192.168.77.219:8443 --token ptuvy5.hl4rzxugpxpgkgkh \
>     --discovery-token-ca-cert-hash sha256:2a190612b1e3a68a549d02b42335bfba4dd4af3bb1361124ad46862e1ab418d4 
[preflight] Running pre-flight checks
	[WARNING Hostname]: hostname "node214" could not be reached
	[WARNING Hostname]: hostname "node214": lookup node214 on 192.168.64.215:53: no such host
	[WARNING Service-Kubelet]: kubelet service is not enabled, please run 'systemctl enable kubelet.service'
[preflight] Reading configuration from the cluster...
[preflight] FYI: You can look at this config file with 'kubectl -n kube-system get cm kubeadm-config -oyaml'
	[WARNING RequiredIPVSKernelModulesAvailable]: 

The IPVS proxier may not be used because the following required kernel modules are not loaded: [ip_vs_wrr ip_vs_sh ip_vs_rr]
or no builtin kernel IPVS support was found: map[ip_vs:{} ip_vs_rr:{} ip_vs_sh:{} ip_vs_wrr:{} nf_conntrack_ipv4:{}].
However, these modules may be loaded automatically by kube-proxy if they are available on your system.
To verify IPVS support:

   Run "lsmod | grep 'ip_vs|nf_conntrack'" and verify each of the above modules are listed.

If they are not listed, you can use the following methods to load them:

1. For each missing module run 'modprobe $modulename' (e.g., 'modprobe ip_vs', 'modprobe ip_vs_rr', ...)
2. If 'modprobe $modulename' returns an error, you will need to install the missing module support for your kernel.

[kubelet-start] Downloading configuration for the kubelet from the "kubelet-config-1.14" ConfigMap in the kube-system namespace
[kubelet-start] Writing kubelet configuration to file "/var/lib/kubelet/config.yaml"
[kubelet-start] Writing kubelet environment file with flags to file "/var/lib/kubelet/kubeadm-flags.env"
[kubelet-start] Activating the kubelet service
[kubelet-start] Waiting for the kubelet to perform the TLS Bootstrap...

This node has joined the cluster:
* Certificate signing request was sent to apiserver and a response was received.
* The Kubelet was informed of the new secure connection details.

Run 'kubectl get nodes' on the control-plane to see this node join the cluster.

至此 kubeadm 配合 keepalived & haproxy 搭建高可用集群就完成了。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
[root@node211 ~]# kubectl get node
NAME      STATUS   ROLES    AGE     VERSION
node211   Ready    master   4h10m   v1.14.3
node212   Ready    master   4h3m    v1.14.3
node213   Ready    master   4h      v1.14.3
node214   Ready    <none>   3h57m   v1.14.3
[root@node211 ~]# kubectl get pod -n kube-system
NAME                              READY   STATUS    RESTARTS   AGE
coredns-d5947d4b-rn2wl            1/1     Running   0          4h10m
coredns-d5947d4b-zdptx            1/1     Running   0          4h10m
etcd-node211                      1/1     Running   0          4h9m
etcd-node212                      1/1     Running   0          4h3m
etcd-node213                      1/1     Running   0          4h
kube-apiserver-node211            1/1     Running   0          4h9m
kube-apiserver-node212            1/1     Running   1          4h3m
kube-apiserver-node213            1/1     Running   0          3h59m
kube-controller-manager-node211   1/1     Running   1          4h9m
kube-controller-manager-node212   1/1     Running   0          4h2m
kube-controller-manager-node213   1/1     Running   0          3h59m
kube-flannel-ds-amd64-gchpj       1/1     Running   0          4h
kube-flannel-ds-amd64-mx44p       1/1     Running   0          3h57m
kube-flannel-ds-amd64-vzk7c       1/1     Running   0          4h7m
kube-flannel-ds-amd64-x9rm7       1/1     Running   0          4h3m
kube-proxy-fj448                  1/1     Running   0          4h
kube-proxy-jmhm7                  1/1     Running   0          4h3m
kube-proxy-s7jdf                  1/1     Running   0          3h57m
kube-proxy-w5gsg                  1/1     Running   0          4h10m
kube-scheduler-node211            1/1     Running   1          4h9m
kube-scheduler-node212            1/1     Running   0          4h2m
kube-scheduler-node213            1/1     Running   0          3h59m

HA 机制

由集群节点上运行的 keepalived & haproxy 提供 VIP & LB，集群中所有节点的 kubelet 连接至 VIP: EndPoints。

当 VIP 所在节点发生故障，VIP 切换到集群中其他 master 节点，即可正常提供服务。

坑

  1. kubeadm 需要正常网络支持，需要确保自己处于正常网络环境下；
  2. kubeadm 在添加节点时，有可能会 hang 住，未查明原因；
  3. kubeadm 默认生成证书有效期为 1年，若想要修改，则需要手动生成证书替换；
  4. …

kubespray

因为 kubespray 项目主要使用 ansible 配合 kubeadm 部署，具体内容可以直接查看 github 文档，因此不详细记录具体步骤。

环境信息

ip role
192.168.77.201 master
192.168.77.202 master
192.168.77.203 master
192.168.77.204 node

1. 安装 kubespray

在 GitHub 项目链接上下载最新 Release 版本代码。

1
[root@node201 ~]# wget https://github.com/kubernetes-sigs/kubespray/archive/v2.10.3.tar.gz

2. 安装必要依赖

项目依赖于 Python3，所以这里采用 Python3.6 版本进行安装。

1
2
3
[root@node201 kubespray-2.10.3]# yum install python36
[root@node201 kubespray-2.10.3]# yum install python36-pip
[root@node201 kubespray-2.10.3]# pip3 install -r requirements.txt
  1. 生成 ansible inventory

项目默认提供了一个 Python 脚本用于自动生成 inventory，该脚本生成 inventory 通常需要根据实际情况自己调整。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
[root@node201 kubespray-2.10.3]# cp -rfp inventory/sample inventory/mycluster
[root@node201 kubespray-2.10.3]# declare -a IPS=(192.168.77.201 192.168.77.202 192.168.77.203 192.168.77.203)
[root@node201 kubespray-2.10.3]# CONFIG_FILE=inventory/mycluster/hosts.yml python3 contrib/inventory_builder/inventory.py ${IPS[@]}
DEBUG: Adding group all
DEBUG: Adding group kube-master
DEBUG: Adding group kube-node
DEBUG: Adding group etcd
DEBUG: Adding group k8s-cluster
DEBUG: Adding group calico-rr
DEBUG: Skipping existing host 192.168.77.203.
DEBUG: adding host node1 to group all
DEBUG: adding host node2 to group all
DEBUG: adding host node3 to group all
DEBUG: adding host node1 to group etcd
DEBUG: adding host node2 to group etcd
DEBUG: adding host node3 to group etcd
DEBUG: adding host node1 to group kube-master
DEBUG: adding host node2 to group kube-master
DEBUG: adding host node1 to group kube-node
DEBUG: adding host node2 to group kube-node
DEBUG: adding host node3 to group kube-node

查看生成 inventory 结果：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
[root@node201 kubespray-2.10.3]# cat inventory/mycluster/hosts.yml 
all:
  hosts:
    node1:
      ansible_host: 192.168.77.201
      ip: 192.168.77.201
      access_ip: 192.168.77.201
    node2:
      ansible_host: 192.168.77.202
      ip: 192.168.77.202
      access_ip: 192.168.77.202
    node3:
      ansible_host: 192.168.77.203
      ip: 192.168.77.203
      access_ip: 192.168.77.203
  children:
    kube-master:
      hosts:
        node1:
        node2:
    kube-node:
      hosts:
        node1:
        node2:
        node3:
    etcd:
      hosts:
        node1:
        node2:
        node3:
    k8s-cluster:
      children:
        kube-master:
        kube-node:
    calico-rr:
      hosts: {}

可以看到跟我们计划中的有所差别，根据实际情况调整 kube-master 数量即可。

4. 编写部署配置参数

在 [root@node201 kubespray-2.10.3]# ls inventory/mycluster/group_vars/all/all.yml 路径下包含了一些全局配置，比如 proxy 之类的，可以手动调整。

5. 编写 k8s 配置参数

在 [root@node201 kubespray-2.10.3]# ls inventory/mycluster/group_vars/k8s-cluster/k8s-cluster.yml 路径下包含了 k8s 所有配置项，根据实际情况编辑修改。

6. 部署

在所有准备工作完成后，执行部署操作。

注意， Kubespray 部署的前提条件是你的网络是一个正常的网络，可以正常访问所有网站，若无法访问，则根据自身实际情况，调整配置，配置路径为： roles/download/defaults/main.yml 。

1
ansible-playbook -i inventory/mycluster/hosts.yml --become --become-user=root cluster.yml

等待部署完成即可。

HA 机制

集群中所有的 Node 节点自己启动一个 Nginx Static Pod，用于代理转发，将所有指定 127.0.0.1:6443 的请求转发至所有 master 节点真实 apiserver ，这样所有的 kubelet 只需要自己节点即可，无需其他节点参与。

坑

  1. CentOS 默认 Python2.7，需要单独安装 Python3.6
  2. 通过 pip 安装依赖，部分软件包需要 gcc,python36-devel,openssl-devel 等依赖包，需要根据错误提示自行安装，文档中没有提到
  3. 默认会安装 docker & containerd 服务，但是 containerd 服务未设置开机自启动，会导致 docker 无法自动运行
  4. 在安装过程中，会安装 selinux 相应 Python 库，但是该依赖未在 requirements.txt 声明
  5. …

总结

无论是直接只用 kubeadm + vip 方式部署 HA 集群，还是通过 Kubespray 部署，在网络正常情况下，是很快可以完成的。

在使用 kubeadm 过程中，因为无需引入第三方依赖库，导致整体流程顺畅，体验极佳。

在 Kubespray 过程中，因为采用 Python3 方式，但相关依赖又未显示声明，导致部署过程繁琐。但是也比较好理解，Kubespray 作为一个致力于部署企业级 k8s 集群的项目，需要处理大量的边界条件了，这个项目中 YAML 就写了 15k 行，可见一斑。

发表于 |

磁盘扇区

引用维基百科：

In computer disk storage, a sector is a subdivision of a track on a magnetic disk or optical disc. Each sector stores a fixed amount of user-accessible data, traditionally 512 bytes for hard disk drives (HDDs) and 2048 bytes for CD-ROMs and DVD-ROMs. Newer HDDs use 4096-byte (4 KiB) sectors, which are known as the Advanced Format (AF).

扇区大小常见的可以分为 512 bytes, 2048 bytes 和 4096 bytes。

查看扇区大小

通过 lsblk 命令可以查看。

物理扇区 512 byte：

1
2
3
4
5
6
7
[root@yiran 20:51:59 ~]$lsblk -o NAME,PHY-SEC,LOG-SEC /dev/sdg
NAME      PHY-SEC LOG-SEC
sdg           512     512
├─sdg1        512     512
├─sdg2        512     512
├─sdg3        512     512
└─sdg4        512     512

物理扇区 4096 byte：

1
2
3
4
5
6
7
[root@yiran 20:52:03 ~]$lsblk -o NAME,PHY-SEC,LOG-SEC /dev/sdb
NAME      PHY-SEC LOG-SEC
sdb          4096     512
├─sdb1       4096     512
├─sdb2       4096     512
├─sdb3       4096     512
└─sdb4       4096     512

CDROM 比较特殊，是 2048 byte：

1
2
3
[root@yiran 21:07:35 ~]$lsblk -o NAME,PHY-SEC,LOG-SEC /dev/sr0
NAME PHY-SEC LOG-SEC
sr0     2048    2048

发表于 |

背景

本来计划这周写一下如何定制 UEFI Linux 发行版的，但是计划赶不上变化，加上 UEFI 的改动比想象中的多，这周还是继续 k8s 系列好了。

说起来 k8s 写了 3 篇博客一直没有写集群部署相关的，一是当时对 k8s 了解不多，集群搭建大多是 GitHub 上的开源项目或 Rancher 快速搭建起来的；二是 k8s 官方工具 kubeadm 现在还有很多的不确定性，随着 v1.14 版本的发布，可用性大大提高，虽然还不支持 HA，但是要写一下了。

本文并不会介绍具体的部署步骤，望周知。

Kubernetes 主要组件

因为主要说集群部署相关的，因此只列出 Master 和 Node 的主要组件，k8s 内部资源不再罗列：

Master

  • apiserver： 集群中所有其他组件通过 apiserver 进行交互

  • scheduler： 按照 Pod 配置来对 Pod 进行节点调度

  • controller-manager：负责节点管理，资源的具体创建动作， desired state management 具体实行者

  • etcd：用于存储集群中数据的键值存储

Node

  • kubelet：处理 master 及其上运行的 node 之间的所有通信。它与容器运行时配合，负责部署和监控容器

  • kube-proxy：负责维护 node 的网络规则，还负责处理 Pod,Node和外部之间的通信

  • 容器运行时：在节点上运行容器的具体实现，常见的有 Docker/rkt/CRI-O

Kubernetes 集群准备

所需资源

大部分的安装文档中，都会先写明 os 要求，计算 & 存储资源需求，k8s 自身对资源消耗很低，通常的 2c4g + 30GiB 足够运行起来。

上面说完了硬件资源，那么我们来说下软件资源， k8s 作为一个容器编排系统，它需要的软件资源也是很重要的一部分，这里我们来说一下网络部分。

假设我们集群中存在 5 个节点，使用 kubeadm init 方式部署集群，那么最基本的，需要 5 个节点的 IP。那如果是高可用的集群呢？我们需要加一个 VIP，也就是 6 个 IP 地址。

在考虑了 IP 地址之后，我们来说下网段划分，以 flannel 为例，在创建网络时，每个 k8s 节点都会分配一段子网用于 Pod 分配 IP，这里的网段是不可以跟宿主机的网络重叠的，所以这里的网络划分也是一个很重要的资源。

具体其他网络类型，我会在之后的网络部分详细的写一下。

部署方式

好了，现在我们已经有了资源了（无论是硬件资源还是软件资源），那么我们可以部署了，那此时采用什么方式部署，或者说怎么部署成了问题。

首先说下最特殊的服务，kubelet，它作为节点的实际管控者，它如果运行在容器中，那么谁来控制kubelet 容器的启停呢？当节点故障恢复后，又如何自启动呢？最开始我使用 Rancher 部署的时候发现他们是将 kubelet 直接部署在容器中的，那是因为他们在节点上还有其他 Agent 用于管理节点，Rancher 相当于 k8s 集群之外的上帝，管控着一切。

当我们没有 Rancher 这类管理工具时，还是老老实实将 kubelet 以服务的形式部署在宿主机上吧。

官方推荐使用 kubeadm 进行集群部署，简单快捷，只是还在快速迭代中，存在较多不确定性，那么现在那些大厂是如何部署的呢？

我花了点时间阅读了下 Github 上面一些关于 k8s 部署项目，简单的罗列一下：

项目名称 项目地址 星 服务运行方式 ha
ansible-kubeadm https://github.com/4admin2root/ansible-kubeadm 3 Static Pod -
ansible-kubeadm-ha-cluster https://github.com/sv01a/ansible-kubeadm-ha-cluster 5 Docker keepvalied
kubeadm-playbook https://github.com/ReSearchITEng/kubeadm-playbook 117 Static Pod keepalived
Kubernetes-ansible https://github.com/zhangguanzhang/Kubernetes-ansible 208 Service keepalived & Haproxy
kubeadm-ansible https://github.com/kairen/kubeadm-ansible 281 Static Pod -
kubeadm-ha https://github.com/cookeem/kubeadm-ha 502 Service keepalived & nginx
kubeasz https://github.com/easzlab/kubeasz 2987 Service keepalived & Haproxy

可以看到虽然有些细微的差别，但是大家做的都围绕着一个目的，就是把上一节提到的 k8s 所有必要组件部署到集群中，我们根据服务运行方式和 HA 方式来说一下。

服务运行方式

根据我上面总结的各个项目，大体分为 3 类，分别是：Host Service、Docker、Static Pod。我们一个一个的过一下。

Host Service

在没有容器的时代，我们要部署一个服务，都是采用 Host Service 方式，我们在宿主机的 OS 上配置一个服务，管理方式可能是 init.d ，也可能是 systemd 。k8s 所有的服务都可以通过 Host Service 方式运行。

优点：

在 systemd 大法加持下，所有服务均可通过 systemd 统一管理，可以配置随着系统进行启停。

缺点：

如果通过 systemd 方式部署，那么服务配置修改、服务升级是一个大麻烦。

Docker

既然我们觉得 Host Service 的方式服务配置修改、升级都比较麻烦，那我们直接通过 Docker 启动就好了，升级直接更新 image 重新启动，一切问题放佛都解决了。

但是考虑一个问题，当集群全部掉电，系统开机后，k8s 如何自启动？以 Docker 作为容器运行时的基础上，Docker 比较让人诟病的一点就是它是一个 Daemon，在这里反而是优点，我们可以设置 Docker 随开机自启动，并将 k8s 所有服务对应镜像设置为 --restart=always，就可以解决这个问题。

优点：

服务配置、升级方便。

缺点：

依赖于 Docker，若更换其他 CRI，无法处理极端情况。

Static Pod

最后我们来说说 Static Pod，这种方式是 kubeadm 目前所采用的方式，也是 k8s 所推荐的方式。

什么是 Static Pod？其实就是字面意义， 静态 Pod，k8s 不去调度的 Pod，而是由 kubelet 直接管理。前面我们在讨论 kubelet 提到，kubelet 是以服务的形式运行在宿主机上的，那么也就是 kubelet 的启停是通过 systemd 控制的，不受 k8s 控制。

Static Pod 由 kubelet 控制，当 kubelet 启动后，会自动拉起 Static Pod，且 Static Pod 不受 k8s 控制，无论是通过 kubectl 进行删除，还是通过 docker 对该 Pod 进行 stop 动作，kubelet 都会保证 Static Pod 正常运行。

这个方式很适合我们来处理 k8s 自身的服务，比如 apiserver/scheduler ，每个 master 节点上通过 Static Pod 配置，当 kubelet 启动后，自动拉起 apiserver/scheduler 等服务，那么 k8s 集群也就自启动了，也就解决了我们上面提到的集群全部掉电的情况。

优点：

跟随 kubelet 启停，完美适配 k8s 升级场景。

缺点：

因为随着 kubelet 启停，所以导致更新 kubelet 配置时需要指定 manifest 文件路径。

HA 配置

k8s 作为一个基础架构服务，它的可用性关乎着我们整个业务的稳定，所以一定要保证不会出现单点故障。

在公有云场景下，由公有云提供 LB 的支持，只要我们部署了多个 master 节点，就不用担心了。

那在裸机场景下怎么办呢？

目前通用解决方案是 VIP 配合 LB（也就是 keepalived & haproxy/nginx）。

keepalived 提供了 VIP。在 k8s 集群部署过程中，所有节点都指定 controlPlaneEndpoint 为 VIP，而 VIP 在集群中的一个 master 节点上。当 VIP 所在节点故障时， VIP 自动漂浮到集群中其他 master 节点上，保证高可用。

haproxy/nginx 作为 LB，当我们 k8s 集群中所有节点都连接一个 apiserver 时，通过 LB 按照既定策略将请求分发到集群中多个 master 节点上，保证性能。

总结

关于 k8s 集群的部署大概就是上述这些内容，具体的操作步骤都可以通过官网或者 github 找到相关资料。目前如果个人学习的话，直接通过 kubeadm 部署就好；如果想要在生产环境中部署，那么需要根据自身业务类型，仔细考虑自己是否需要 HA，如何配置 HA。

发表于 |

背景

大家应该都安装过操作系统，PC 或者服务器上。那么我们在安装操作系统时通常需要进入到 BIOS 或 UEFI 界面去安装。之前维护的一个 ISO 版本只支持 BIOS，最近有了支持 UEFI 安装的需求，今天来了解一下其中的差异，之后尝试编写一个支持 UEFI 的 KickStart 配置。

Legacy BIOS

按照惯例，引用维基百科中（不同语言对于名词解释信息可能是完全不同的，最好直接看英文）的解释：

BIOS (/ˈbaɪɒs/ BY-oss; an acronym for Basic Input/Output System and also known as the System BIOS, ROM BIOS or PC BIOS) is non-volatile firmware used to perform hardware initialization during the booting process (power-on startup), and to provide runtime services for operating systems and programs.[1] The BIOS firmware comes pre-installed on a personal computer’s system board, and it is the first software to run when powered on. The name originates from the Basic Input/Output System used in the CP/M operating system in 1975.[2][3] The BIOS originally proprietary to the IBM PC has been reverse engineered by companies looking to create compatible systems. The interface of that original system serves as a de facto standard.

主要功能有：

  • POST - 在加载操作系统之前， 检测硬件确保没有错误
  • Bootstrap Loader - 寻找引导加载程序，并将控制权转
  • BIOS 驱动程序 - 低级驱动程序，使计算机可以对计算机硬件进行基本操作控制
  • BIOS/CMOS 设置 - 允许配置硬件设置，包括系统设置，如计算机密码，硬件时钟等

BIOS vs CMOS

更改BIOS配置时，设置不会存储在BIOS芯片本身。相反，它们存储在一个特殊的存储芯片上，称为CMOS。

与大多数RAM芯片一样，存储BIOS设置的芯片使用CMOS工艺制造。它包含少量数据，通常为256 个字节。CMOS 芯片上的信息包括计算机上安装的磁盘驱动器类型，系统时钟的当前日期和时间以及计算机的引导顺序。

BIOS是非易失性的：即使计算机没电也会保留其信息，因为即使计算机已关闭，计算机也需要记住其BIOS设置。这就是为什么CMOS有自己的专用电源，即CMOS电池。 通常我们在使用电脑的时候，如果忘记了 BIOS 密码，无法更改 BIOS 设置时， 那么可以通过拔掉 CMOS 电池，再安装即可恢复。

(U)EFI

The Unified Extensible Firmware Interface (UEFI) is a specification that defines a software interface between an operating system and platform firmware. UEFI replaces the Basic Input/Output System (BIOS) firmware interface originally present in all IBM PC-compatible personal computers,[1][2] with most UEFI firmware implementations providing legacy support for BIOS services. UEFI can support remote diagnostics and repair of computers, even with no operating system installed.[3]

Intel 为了解决 BIOS 的一些缺点，提出了 EFI ，后来由于各种历史原因，EFI 转变为了 UEFI，其中的 U 是 Unified 。

那么 BIOS 有啥缺点呢？ 对于服务器级别来说，最大的缺点可能就是不支持 2TiB 以上空间的磁盘引导，关于为什么不支持大家可以自己查阅下 MBR vs GPT 相关资料，这里不详细解释。

那么老大哥提出了 UEFI，除了解决了引导磁盘的容量限制，还有如下优点（这几点看上去就跟普通用户没啥关系）：

  • 独立于CPU的架构
  • 独立于CPU的驱动程序
  • 灵活的pre-OS环境，包括网络功能
  • 模块化设计
  • 向后和向前兼容性

Linux 安装识别

了解了大概的概念，那么我们来实际看看 Linux 分别从 BIOS 启动和 UEFI 启动安装有什么不同吧，接下来示例以 CentOS 为例。

首先我们看下 CentOS ISO 中的目录结构：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
[root@dell-r720xd-1 CentOS-7.4]# tree . -d 1
.
├── EFI # EFI 模式下引导程序路径
│   └── BOOT
│       └── fonts
├── images # 系统启动镜像
│   └── pxeboot
├── isolinux   # 默认引导程序路径，包括引导选项配置，引导背景图片，引导内核镜像等
├── LiveOS    # 临时加载镜像
├── Packages   # ISO 附带所有软件包，以 RPM 形式存放
└── repodata    # ISO 中 YUM Repo 配置文件，保存了在只做 YUM Repo 时指定的软件组，支持语言等信息
1 [error opening dir]

9 directories

BIOS

我们来看下在 BIOS 下如何指定安装 KickStart 配置：

在 isolinux/isolinux.cfg 中指定即可

1
2
3
4
5
label linux
  menu label ^Install yiran'OS
  menu default
  kernel vmlinuz
  append initrd=initrd.img inst.stage2=hd:LABEL=YIRANOS-2 ks=hd:LABEL=YIRANOS-2:/ks_yiranos.cfg quiet

UEFI

跟 BIOS 一样，只是换了一个配置位置，只需要在 EFI/BOOT/grub.cfg 中指定 KS 配置即可。

1
2
3
4
5
### BEGIN /etc/grub.d/10_linux ###
menuentry 'Install CentOS 7' --class fedora --class gnu-linux --class gnu --class os {
        linuxefi /images/pxeboot/vmlinuz inst.stage2=hd:LABEL=CentOS\x207\x20x86_64 inst.ks=hd:LABEL=YIRANOS-2:/ks_yiranos.cfg quiet
        initrdefi /images/pxeboot/initrd.img
}

总结

随着越来越多服务器厂商将 UEFI 设置为默认模式，哪怕我们没有用到 UEFI 的高级功能，也最好将自己的 ISO 支持到 UEFI，避免因为 BIOS 的一些历史遗留问题导致后续技术支持出现困难。后续找时间写一下关于 UEFI 的 KickStart 配置文件。主要变化应该是在 /boot 分区部分有些变化，之后再说啦。