Loading's blog


  • 首页

  • 分类

  • 关于

  • 归档

  • 标签
Loading's blog

centos7部署kuberbetes集群

发表于 2017-03-23

Prerequisites

To configure Kubernetes with CentOS, you’ll need a machine to act as a master, and one or more CentOS 7 hosts to act as cluster nodes.

Starting a cluster

This is a getting started guide for CentOS. It is a manual configuration so you understand all the underlying packages / services / ports, etc…

The Kubernetes package provides a few services: kube-apiserver, kube-scheduler, kube-controller-manager, kubelet, kube-proxy. These services are managed by systemd and the configuration resides in a central location: /etc/kubernetes. We will break the services up between the hosts. The first host, centos-master, will be the Kubernetes master. This host will run the kube-apiserver, kube-controller-manager and kube-scheduler. In addition, the master will also run etcd. The remaining hosts, centos-minion-n will be the nodes and run kubelet, proxy, cadvisor and docker.

All of them run flanneld as networking overlay.

System Information:

Hosts:

Please replace host IP with your environment.

1
2
3
4
centos-master = 192.168.121.9
centos-minion-1 = 192.168.121.65
centos-minion-2 = 192.168.121.66
centos-minion-3 = 192.168.121.67

Prepare the hosts:

  • Create a /etc/yum.repos.d/virt7-docker-common-release.repo on all hosts - centos-{master,minion-n} with following information.
1
2
3
4
[virt7-docker-common-release]
name=virt7-docker-common-release
baseurl=http://cbs.centos.org/repos/virt7-docker-common-release/x86_64/os/
gpgcheck=0
  • Install Kubernetes, etcd and flannel on all hosts - centos-{master,minion-n}. This will also pull in docker and cadvisor.
1
yum -y install --enablerepo=virt7-docker-common-release kubernetes etcd flannel
  • Add master and node to /etc/hosts on all machines (not needed if hostnames already in DNS)
1
2
3
4
echo "192.168.121.9 centos-master
192.168.121.65 centos-minion-1
192.168.121.66 centos-minion-2
192.168.121.67 centos-minion-3" >> /etc/hosts
  • Edit /etc/kubernetes/config which will be the same on all hosts to contain:
1
2
3
4
5
6
7
8
9
10
11
# logging to stderr means we get it in the systemd journal
KUBE_LOGTOSTDERR="--logtostderr=true"
# journal message level, 0 is debug
KUBE_LOG_LEVEL="--v=0"
# Should this cluster be allowed to run privileged docker containers
KUBE_ALLOW_PRIV="--allow-privileged=false"
# How the replication controller and scheduler find the kube-apiserver
KUBE_MASTER="--master=http://centos-master:8080"
  • Disable the firewall on the master and all the nodes, as docker does not play well with other firewall rule managers. CentOS won’t let you disable the firewall as long as SELinux is enforcing, so that needs to be disabled first.
1
2
3
setenforce 0
systemctl disable iptables-services firewalld
systemctl stop iptables-services firewalld

Configure the Kubernetes services on the master.

  • Edit /etc/etcd/etcd.conf to appear as such:
1
2
3
4
5
6
7
# [member]
ETCD_NAME=default
ETCD_DATA_DIR="/var/lib/etcd/default.etcd"
ETCD_LISTEN_CLIENT_URLS="http://0.0.0.0:2379"
#[cluster]
ETCD_ADVERTISE_CLIENT_URLS="http://0.0.0.0:2379"
  • Edit /etc/kubernetes/apiserver to appear as such:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
# The address on the local server to listen to.
KUBE_API_ADDRESS="--address=0.0.0.0"
# The port on the local server to listen on.
KUBE_API_PORT="--port=8080"
# Port kubelets listen on
KUBELET_PORT="--kubelet-port=10250"
# Comma separated list of nodes in the etcd cluster
KUBE_ETCD_SERVERS="--etcd-servers=http://centos-master:2379"
# Address range to use for services
KUBE_SERVICE_ADDRESSES="--service-cluster-ip-range=10.254.0.0/16"
# Add your own!
KUBE_API_ARGS=""
  • Start ETCD and configure it to hold the network overlay configuration on master:
    Warning This network must be unused in your network infrastructure! 172.30.0.0/16 is free in our network.
1
2
3
systemctl start etcd
etcdctl mkdir /kube-centos/network
etcdctl mk /kube-centos/network/config "{ \"Network\": \"172.30.0.0/16\", \"SubnetLen\": 24, \"Backend\": { \"Type\": \"vxlan\" } }"
  • Configure flannel to overlay Docker network in /etc/sysconfig/flanneld on the master (also in the nodes as we’ll see):
1
2
3
4
5
6
7
8
9
10
11
# Flanneld configuration options
# etcd url location. Point this to the server where etcd runs
FLANNEL_ETCD_ENDPOINTS="http://centos-master:2379"
# etcd config key. This is the configuration key that flannel queries
# For address range assignment
FLANNEL_ETCD_PREFIX="/kube-centos/network"
# Any additional options that you want to pass
#FLANNEL_OPTIONS=""
  • Start the appropriate services on master:
1
2
3
4
5
for SERVICES in etcd kube-apiserver kube-controller-manager kube-scheduler flanneld; do
systemctl restart $SERVICES
systemctl enable $SERVICES
systemctl status $SERVICES
done

Configure the Kubernetes services on the nodes.

We need to configure the kubelet and start the kubelet and proxy

  • Edit /etc/kubernetes/kubelet to appear as such:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
# The address for the info server to serve on
KUBELET_ADDRESS="--address=0.0.0.0"
# The port for the info server to serve on
KUBELET_PORT="--port=10250"
# You may leave this blank to use the actual hostname
# Check the node number!
KUBELET_HOSTNAME="--hostname-override=centos-minion-n"
# Location of the api-server
KUBELET_API_SERVER="--api-servers=http://centos-master:8080"
# Add your own!
KUBELET_ARGS=""
  • Configure flannel to overlay Docker network in /etc/sysconfig/flanneld (in all the nodes)
1
2
3
4
5
6
7
8
9
10
11
# Flanneld configuration options
# etcd url location. Point this to the server where etcd runs
FLANNEL_ETCD_ENDPOINTS="http://centos-master:2379"
# etcd config key. This is the configuration key that flannel queries
# For address range assignment
FLANNEL_ETCD_PREFIX="/kube-centos/network"
# Any additional options that you want to pass
#FLANNEL_OPTIONS=""
  • Start the appropriate services on node (centos-minion-n).
1
2
3
4
5
for SERVICES in kube-proxy kubelet flanneld docker; do
systemctl restart $SERVICES
systemctl enable $SERVICES
systemctl status $SERVICES
done
  • Configure kubectl
1
2
3
kubectl config set-cluster default-cluster --server=http://centos-master:8080
kubectl config set-context default-context --cluster=default-cluster --user=default-admin
kubectl config use-context default-context

You should be finished!

  • Check to make sure the cluster can see the node (on centos-master)
1
2
3
4
5
$ kubectl get nodes
NAME LABELS STATUS
centos-minion-1 <none> Ready
centos-minion-2 <none> Ready
centos-minion-3 <none> Ready

The cluster should be running! Launch a test pod.

You should have a functional cluster, check out.

Loading's blog

Hello World

发表于 2017-03-16

Welcome to Hexo! This is your very first post. Check documentation for more info. If you get any problems when using Hexo, you can find the answer in troubleshooting or you can ask me on GitHub.

Quick Start

Create a new post

1
$ hexo new "My New Post"

More info: Writing

Run server

1
$ hexo server

More info: Server

Generate static files

1
$ hexo generate

More info: Generating

Deploy to remote sites

1
$ hexo deploy

More info: Deployment

test

Loading's blog

Linux常见系统进程

发表于 2017-01-22 | 分类于 system

转载于:http://www.178-go.com/archives/linux-proces.html

1. kswapd0

系统每过一定时间就会唤醒kswapd,看看内存是否紧张,如果不紧张,则睡眠,在kswapd中,有2个阀值,pages_hige和pages_low,当空闲内存页的数量低于pages_low的时候,kswapd进程就会扫描内存并且每次释放出32个free pages,直到free page的数量到达pages_high。具体回收内存有如下原则:

1. 如果页未经更改就将该页放入空闲队列;
2. 如果页已经更改并且是可备份回文件系统的,就理解将内存页的内容写回磁盘;
3. 如果页已经更改但是没有任何磁盘上的备份,就将其写入swap分区。

同样,属于核心的内存管理线程,这个线程也不能被关闭。

2. pdflush

pdflush用于将内存中的内容和文件系统进行同步,比如说,当一个文件在内存中进行修改,pdflush负责将它写回硬盘.每当内存中的垃圾页(dirty page)超过10%的时候,pdflush就会将这些页面备份回硬盘.这个比率是可调节的,通过/etc/sysctl.conf中的 vm.dirty_background_ratio项 默认值为10 也可以。

cat /proc/sys/vm/dirty_background_ratio 查看当前的值。

这种内核线程共有两个,线程名都是pdflush,主要作用是回写内存中的脏页,回收脏页占据的空间。由于页高速缓存的缓存作用,写操作实际上会被延迟。当页高速缓存中的数据比后台存储的数据更新时,那么该数据就被称做脏数据。在内存中累积起来的脏页最终必须被写回。在以下两种情况发生时,脏页被写回:

1. 当空闲内存低于一个特定的阈值时,内核必须将脏页写回磁盘,以便释放内存。
2. 当脏页在内存中驻留时间超过一个特定的阈值时,内核必须将超时的脏页写回磁盘,以确保脏页不会无限期地驻留在内存中。

对于第一个目标,pdflush线程在系统中的空闲内存低于一个特定的阈值时,将脏页刷新回磁盘。该后台回写例程的目的在于在可用物理内存过低时,释放脏页以重新获得内存。特定的内存阈值可以通过dirty_backgroundratiosysctl系统调用设置。当空闲内存比阈值:dirty background_ratio还低时,内核便会调用函数wakeup_bdflush()唤醒一个pdflush线程,随后pdflush线程进一步 调用函数backgroundwriteout()开始将脏页写回磁盘。函数background writeout()需要一个长整型参数,该参数指定试图写回的页面数目。函数background_writeout()会连续地写出数据,直到满足以下两个条件:

1. 已经有指定的最小数目的页被写出到磁盘。
2. 空闲内存数已经回升,超过了阈值dirty_background_ratio。

上述条件确保了pdflush操作可以减轻系统中内存不足的压力。回写操作不会在达到这两个条件前停止,除非pdflush写回了所有的脏页,没有剩下的脏页可再被写回了。

对于第二个目标,pdflush后台例程会被周期性唤醒(和空闲内存是否过低无关),将那些在内存中驻留时间过长的脏页写出,确保内存中不会有长期存在的脏页。如果系统发生崩溃,由于内存处于混乱之中,所以那些在内存中还没来得及写回磁盘 的脏页就会丢失,所以周期性同步页高速缓存和磁盘非常重要。在系统启动时,内核初始化一个定时器,让它周期地唤醒pdflush线程,随后使其运行函数 wb_kupdate()。该函数将把所有驻留时间超过百分之dirty_expire_centisecs秒的脏页写回。然后定时器将再次被初始化为百 分之dirtyexpire centisecs秒后唤醒pdflush线程。总而言之,pdflush线程周期地被唤醒并且把超过特定期限的脏页写回磁盘。

系统管理员可以在/proc/sys/vm中设置回写相关的参数,也可以通过sysctl系统调用设置它们。属于核心的内存管理线程,这个线程也不能被关闭

3. kblockd 块读写子系统

4.kthreadd

这种内核线程只有一个,它的作用是管理调度其它的内核线程。它在内核初始化的时候被创建,会循环运行一个叫做kthreadd的函数,该函数的作用是运行kthread_create_list全局链表中维护的kthread。可以调用kthread_create创建一个kthread,它会被加入到kthread_create_list链表中,同时kthread_create会weak up kthreadd_task。kthreadd在执行kthread会调用老的接口——kernel_thread运行一个名叫“kthread”的内核线程去运行创建的kthread,被执行过的kthread会从kthread_create_list链表中删除,并且kthreadd会不断调用scheduler 让出CPU。这个线程不能关闭。

5. watchdog

每个处理器核对应一个watchdog 内核线程,watchdog用于监视系统的运行,在系统出现故障时自动重新启动系统,包括一个内核 watchdog module 和一个用户空间的 watchdog 程序。在Linux 内核下, watchdog的基本工作原理是:当watchdog启动后(即/dev/watchdog设备被打开后),如果在某一设定的时间间隔(1分钟)内/dev/watchdog没有被执行写操作, 硬件watchdog电路或软件定时器就会重新启动系统,每次写操作会导致重新设定定时器。/dev/watchdog是一个主设备号为10, 从设备号130的字符设备节点。 Linux内核不仅为各种不同类型的watchdog硬件电路提供了驱动,还提供了一个基于定时器的纯软件watchdog驱动。

6. events

每个处理器核对应一个 events内核线程。用来处理内核事件很多软硬件事件(比如断电,文件变更)被转换为events,并分发给对相应事件感兴趣的线程进行响应。用来处理内核事件的重要线程,不能被去掉。

7. khelper

这种内核线程只有一个,主要作用是指定用户空间的程序路径和环境变量, 最终运行指定的user space的程序,属于关键线程,不能关闭。

8. kblockd

每个处理器核对应一个 kblockd 内核线程。用于管理系统的块设备,它会周期地激活系统内的块设备驱动。如果拥有块设备,那么这些线程就不能被去掉。

9. kseriod

这种内核线程只有一个,主要作用是管理Serio总线上的设备的各种事件,Serio是一种虚拟总线,是Serial I/O的输写,表示串行的输入输出设备。对应内核中的serio_thread函数,流程大致是这样的:调用serio_get_event()从链表中取出struct serio_event元素,然后对这个元素的事件类型做不同的时候,处理完了之后,调用serio_remove_duplicate_events()在链表中删除相同请求的event。例如:如果要注册新的serio设备,它产生的事件类型是SERIO_REGISTER_PORT,然后流程会转入serio_add_port()。使用Serio总线的主要是标准AT键盘、PS/2鼠标、串口鼠标、Sun键盘,以及一些游戏手柄,不过由于I2C依赖于Serio,所以不关闭I2C就无法关闭Serio。

10.aio

每个处理器核对应一个 aio 内核线程, 代替用户进程管理I/O,用以支持用户态的AIO(异步I/O),不应该被关闭。

11.unionfs_siod

每个处理器核对应一个 unionfs_siod 内核线程

12.nfsiod

这种内核线程只有一个,主要作用是为nfs提供高效的缓冲机制,从而改善nfs文件系统的性能,如果不需nfs,可以取消这一线程。

13.rpciod

每个处理器核对应一个rpciod内核线程,主要作用是作为远过程调用服务的守护进程,用于从客户端启动I/O服务,通常启动NFS服务时要用到它。

14.kpsmoused

这种内核线程只有一个,主要作用是支持ps/2接口的鼠标驱动。如要没有鼠标,可以取消。

15. Migration 进程迁移

  • 什么是进程迁移?

进程迁移就是将一个进程从当前位置移动到指定的处理器上。它的基本思想是在进程执行过程中移动它,使得它在另一个计算机上继续存取它的所有资源并继续运行,而且不必知道运行进程或任何与其它相互作用的进程的知识就可以启动进程迁移操作,这意味着迁移是透明的。

  • 进程迁移的好处:

进程迁移是支持负载平衡和高容错性的一种非常有效的手段。对一系列的负载平衡策略的研究表明进程迁移是实现负载平衡的基础,进程迁移在很多方面具有适用性:

1. 动态负载平衡:将进程迁移到负载轻或空闲的节点上,充分利用可用资源,通过减少节点间负载的差异来全面提高性能。
2. 容错性和高可用性:某节点出现故障时,通过将进程迁移到其它节点继续恢复运行,这将极大的提高系统的可靠性和可用性。在某些关键性应用中,这一点尤为重要。
3. 并行文件IO:将进程迁移到文件服务器上进行IO,而不是通过传统的从文件服务器通过网络将数据传输给进程。对于那些需向文件服务器请求大量数据的进程,这将有效的减少了通讯量,极大的提高效率。
4. 充分利用特殊资源:进程可以通过迁移来利用某节点上独特的硬件或软件能力。
5. 内存导引(Memory Ushering)机制:当一个节点耗尽它的主存时,Memory Ushering机制将允许进程迁移到其它拥有空闲内存的节点,而不是让该节点频繁地进行分页或和外存进行交换。这种方式适合于负载较为均衡,但内存使用存在差异或内存物理配置存在差异的系统。
  • 进程迁移的实现角度:

进程迁移的实现复杂性及对OS的依赖性阻碍了进程迁移的广泛使用 ,尤其是对透明的进程迁移实现。根据应用的级别,进程迁移可以作为OS的一部分、用户空间、系统环境的一部分或者成为应用程序的一部分。

1.用户级迁移:用户级实现较为简单,软件开发和维护也较为容易,因此,现有的很多系统都是采用用户级实现,如Condor和Utopia。但由于在用户级无法获得Kernel的所有状态,因此,对于某类进程,无法进行迁移。另外,由于Kernel空间和User空间之间存在着壁垒,打破这个边界获得 Kernel提供的服务需要巨大的开销。因此,用户级实现效率远远低于内核级实现。
2.应用级迁移:应用级迁移实现较为简单,可移植性好,但是需要了解应用程序语义并可能需对应用程序进行修改或重编译,透明性较差,这方面的系统有Freedman、Skordos等。
3.内核级迁移:基于内核的实现可以充分利用OS提供的功能,全面的获取进程和OS状态,因此实现效率较高,能够为用户提供很好的透明性。但是由于需要对OS进行修改,实现较为复杂。这方面的典型系统有MOSIX和 Sprite系统。
  • 进程状态:

进程迁移的主要工作就在于提取进程状态,然后在目的节点根据进程状态再生该进程。在现实中,一个进程拥有很多状态,并且随着操作系统的演化,进程状态也越来越多样。一般来说,一个进程的状态可以分为以下几类:

1.进程执行状态(Execution State):表示当前运行进程的处理器状态,和机器高度相关。包括内核在上下文切换时保存和恢复的信息,如通用和浮点寄存器值、栈指针、条件码等。
2.进程控制(Process Control):操作系统系统用来控制进程的所有信,一般包括进程优先级、进程标识,父进程标识等。一旦系统编排了进程控制信息,进程迁移系统必须冻结该进程的运行。
3.进程Memory状态和进程地址空间:包括进程的所有虚存信息,进程数据和进程的堆栈信息等,是进程状态的最主要的一部分。
4.进程的消息(Message)状态:包括进程缓冲的消息和连接(Link)的控制信息。进程迁移中通讯连接的保持以及迁移后连接的恢复是进程迁移中一项较有挑战意义的问题。
文件状态:进程的文件状态包括文件描述符和文件缓冲快。保持文件的Cache一致性和进程间文件同步访问也是进程迁移机制需要着重考虑的。

由于在同构的环境下(相同或兼容的机器体系结构和指令集以及操作系统)提取和恢复进程状态相对容易,现有的工作大多是以同构环境为前提的。不过,越来越多的人开始研究异构环境下的进程迁移机制,如TUI 系统。

PS: 相关进程(k开头的基本上都是内核驱动,不建议杀掉)

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
PID TTY STAT TIME COMMAND
1 ? Ss 0:00 init [3] (引导用户空间服务,管理孤儿线程,不能杀)
2 ? S 0:00 [migration/0]
3 ? SN 0:00 [ksoftirqd/0] (内核调度/管理第0个CPU软中断的守护进程,不能杀)
4 ? S 0:00 [watchdog/0] (系统监控应用,能够在系统出现故障时自动重新启动系统。不能杀)
5 ? S 0:00 [migration/1] (管理多核心(包括HypterThreading衍生的那个不大管用的、线程在各核心的迁移,不能杀)
6 ? SN 0:00 [ksoftirqd/1] (内核调度/管理第1个CPU软中断的守护进程,不能杀)
7 ? S 0:00 [watchdog/1] (系统监控应用,能够在系统出现故障时自动重新启动系统。不能杀)
8 ? S< 0:00 [events/0] (处理内核事件守护进程,不能杀)
9 ? S< 0:00 [events/1] (处理内核事件守护进程,不能杀)
10 ? S< 0:00 [khelper] (没查出来,感觉不能杀)
11 ? S< 0:00 [kthread] (父内核线程,不能杀)
15 ? S< 0:00 \_ [kblockd/0] (管理磁盘块读写,不能杀)
16 ? S< 0:00 \_ [kblockd/1] (管理磁盘块读写,不能杀)
17 ? S< 0:00 \_ [kacpid] (内核电源管理,不能杀)
120 ? S< 0:00 \_ [cqueue/0] (队列数据结构,不能杀)
121 ? S< 0:00 \_ [cqueue/1] (队列数据结构,不能杀)
124 ? S< 0:00 \_ [khubd] (内核的usb hub,不能杀)
126 ? S< 0:00 \_ [kseriod] 内核线程
193 ? S 0:00 \_ [pdflush] (pdflush内核线程池是Linux为了回写文件系统数据而创建的进程,不能杀)
194 ? S 0:00 \_ [pdflush] (pdflush内核线程池是Linux为了回写文件系统数据而创建的进程,不能杀)
195 ? S< 0:00 \_ [kswapd0] (内存回收,确保系统空闲物理内存的数量在一个合适的范围,不能杀)
196 ? S< 0:00 \_ [aio/0] (代替用户进程管理io,不能杀)
197 ? S< 0:00 \_ [aio/1] (代替用户进程管理io,不能杀)
354 ? S< 0:00 \_ [kpsmoused] (内核鼠标支持,可以杀掉)
387 ? S< 0:00 \_ [ata/0] (ata硬盘驱动,不能杀)
388 ? S< 0:00 \_ [ata/1] (ata硬盘驱动,不能杀)
389 ? S< 0:00 \_ [ata_aux] (ata硬盘驱动,不能杀)
393 ? S< 0:00 \_ [scsi_eh_0] (scsi设备,不建议杀)
394 ? S< 0:00 \_ [scsi_eh_1] (scsi设备,不建议杀)
395 ? S< 0:00 \_ [scsi_eh_2] (scsi设备,不建议杀)
396 ? S< 0:00 \_ [scsi_eh_3] (scsi设备,不建议杀)
432 ? S< 0:00 \_ [kauditd] (内核审核守护进程,不能杀)
1160 ? S< 0:00 \_ [hda_codec]
1418 ? S< 0:00 \_ [kmirrord] (内核守护进程控制和监视镜像模块,不能杀)
400 ? S< 0:00 \_ [kjournald]
1442 ? S< 0:00 \_ [kjournald]
1444 ? S< 0:00 \_ [kjournald]
1446 ? S< 0:00 \_ [kjournald] (kjournald Ext3文件系统的日志管理,通常每个mount_的 Ext3分区会有一个 kjournald看管,各分区的日志
是独立的,不能杀)
466 ? S<s 0:00 /sbin/udevd -d (udevd 支持用户态设备操作,不能杀)
1825 ? Ss 0:00 syslogd -m 0 (syslogd 系统日志进程,不能杀)
1828 ? Ss 0:00 klogd -x (klogd 从内核信息缓冲区获取打印信息,不能杀)
1844 ? Ss 0:00 irqbalance (多个CPU之间均衡分配硬件中断,可以关闭,但不建议)
1864 ? Ss 0:00 /usr/sbin/sshd (sshd守护进程,不能杀)
1881 ? Ss 0:00 crond (执行定时任务,不能杀)
1888 tty1 Ss+ 0:00 /sbin/mingetty tty1 (mingetty 等待用户从tty登录,可以杀)
1892 tty2 Ss+ 0:00 /sbin/mingetty tty2 (mingetty 等待用户从tty登录,可以杀)
1893 tty3 Ss+ 0:00 /sbin/mingetty tty3 (mingetty 等待用户从tty登录,可以杀)
Loading's blog

Centos 6升级内核

发表于 2017-01-22 | 分类于 system

1. 使用epel源

升级内核需要使用elrepo的yum源,在安装yum源之前还需要我们导入elrepo的key,如下:

1
2
3
rpm --import https://www.elrepo.org/RPM-GPG-KEY-elrepo.org
rpm -Uvh http://www.elrepo.org/elrepo-release-6-6.el6.elrepo.noarch.rpm

2. 升级内核

在yum的elrepo源中有ml和lt两种内核,其中ml(mainline)为最新版本的内核,lt为长期支持的内核。

如果要安装ml内核(更新一点)使用如下命令:

1
yum --enablerepo=elrepo-kernel -y install kernel-ml

如果要安装lt内核(稳定版本),使用如下命令:

1
yum --enablerepo=elrepo-kernel -y install kernel-lt

3. 修改系统grub.conf

内核升级一般需要重启操作才可以完成,为了使得重启之后能使用最新的内核,所以需要修改grub文件,用最新的内核引导。

1
2
vim /etc/grub.conf
default=0

4. 重启系统,查看新内核

完成上述操作之后

1
reboot

检查内核已升级到4.10。

Loading's blog

test

发表于 2017-01-22 | 分类于 other
Loading

Loading

5 日志
2 分类
2 标签
© 2017 Loading
由 Hexo 强力驱动
主题 - NexT.Pisces