containerd与kubernetes集成部署
概念介绍
cri (Container runtime interface)
cri is a containerd plugin implementation of Kubernetes container runtime interface (CRI). cri是 kubernetes的容器运行时接口的容器插件实现。
containerd
containerd is an industry-standard container runtime with an emphasis on simplicity, robustness and portability. containerd完全支持运行容器的的CRI运行时规范。 cri在containerd1.1以上的版本的原生插件。它内置于containerd并默认启用。
cri-o
OCI-based implementation of Kubernetes Container Runtime Interface. kubernetes为了兼容cri和oci孵化了项目cri-o。为了架设在cri和oci之间的一座桥梁。由此cri-o既兼容cri插件实现又兼容oci的容器运行时标准。
oci (Open Container Initiative)
oci是由多家公司成立的项目,并由linux基金会进行管理,致力于container runtime 的标准的制定和runc的开发等工作。
runc
runc is a CLI tool for spawning and running containers according to the OCI specification. runc,是对于OCI标准的一个参考实现,是一个可以用于创建和运行容器的CLI(command-line interface)工具。
概述
由于docker嵌入了太多自身内容,为了减轻容器负担。此次选用containerd作为kubernetes的容器实现方案。本文将带大家讲述如何搭建一个集成了containerd的k8s集群。
环境准备
下载containerd二进制包。我这里已经编译并打包了好了,内含containerd、runc、crictl、ctr等。
下载链接:https://github.com/cuisongliu/containerd-dist/releases/download/v1.2.4/containerd-v1.2.4.tar.gz
runc版本: 1.0.1-dev containerd版本: v1.2.4
安装containerd
解压二进制包并生成默认文件
tar -C /usr/local/bin -xzf containerd-v1.2.4.tar.gz chmod a+x /usr/local/bin/* containerd config default > /etc/containerd/config.toml
生成的默认配置文件注意 [grpc] 的 address 字段默认为 /run/containerd/containerd.sock
配置文件其他参数含义参照github地址: https://github.com/containerd/containerd/blob/master/docs/man/containerd-config.toml.5.md
在 /etc/systemd/system 目录下编写文件 containerd.service内容如下
[Unit] Description=containerd container runtime Documentation=https://containerd.io After=network.target [Service] ExecStartPre=/sbin/modprobe overlay ExecStart=/usr/local/bin/containerd Restart=always RestartSec=5 Delegate=yes KillMode=process OOMScoreAdjust=-999 LimitNOFILE=1048576 # Having non-zero Limit*s causes performance problems due to accounting overhead # in the kernel. We recommend using cgroups to do container-local accounting. LimitNPROC=infinity LimitCORE=infinity [Install] WantedBy=multi-user.target
启动containerd
systemctl enable containerd systemctl restart containerd systemctl status containerd
看containerd启动状态如果是running就没有问题。下面我们测试拉取一下hub的镜像。
测试containerd
ctr images pull docker.io/library/nginx:alpine
看到输出done,说明containerd运行一切正常。
使用crictl连接containerd,下一步我们使用crictl连接containerd。
修改crictl的配置文件,在 /etc/crictl.yaml 写入以下内容:
runtime-endpoint: unix:///run/containerd/containerd.sock image-endpoint: unix:///run/containerd/containerd.sock timeout: 10 debug: false
这里注意runtime-endpoint 和image-endpoint 必须与/etc/containerd/config.toml中配置保持一致。
验证一下cri插件是否可用
crictl pull nginx:alpine crictl rmi nginx:alpine crictl images
其中 crictl images 会列出所有的cri容器镜像。
到此我们的cri + containerd已经完成整合了。下一步我们需要修改kubeadm配置进行安装。
导入kubenetes离线镜像包
这里我们就需要导入k8s的离线镜像包了。这里需要注意一下,kubernetes是调用的cri接口,所以导入时也需要从cri插件导入镜像。
cri导入镜像命令(cri导入镜像):
ctr cri load images.tar
containerd导入镜像命令(containerd导入镜像):
ctr images import images.tar
修改kubelet配置和kubeadm安装时配置
在 kubelet配置文件 10-kubeadm.conf 的[Service] 结点加入以下配置:
Environment="KUBELET_EXTRA_ARGS=--container-runtime=remote --runtime-request-timeout=15m --container-runtime-endpoint=unix:///run/containerd/containerd.sock"
在kubeadm配置文件 kubeadm.yaml 中加入
apiVersion: kubeadm.k8s.io/v1beta1 kind: InitConfiguration nodeRegistration: criSocket: /run/containerd/containerd.sock name: containerd
到此containerd和kubernetes的集成就完成了。下面可以直接安装即可。

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
由for update引发的血案
微信公众号「后端进阶」,专注后端技术分享:Java、Golang、WEB框架、分布式中间件、服务治理等等。 老司机倾囊相授,带你一路进阶,来不及解释了快上车! 公司的某些业务用到了数据库的悲观锁 for update,但有些同事没有把 for update 放在 Spring 事务中执行,在并发场景下发生了严重的线程阻塞问题,为了把这个问题吃透,秉承着老司机的职业素养,我决定要给同事们一个交代。 案发现场 最近公司的某些 Dubbo 服务之间的 RPC 调用过程中,偶然性地发生了若干起严重的超时问题,导致了某些模块不能正常提供服务。我们的数据库用的是 Oracle,经过 DBA 排查,发现了一些 sql 的执行时间特别长,对比发现这些执行时间长的 sql 都带有 for update 悲观锁,于是相关开发人员查看 sql 对应的业务代码,发现 for update 没有放在 Spring 事务中执行,但是按照常理来说,如果 for update 没有加 Spring 事务,每次执行完 Mybatis 都会帮我们 commit 释放掉资源,并发时出现的问题应该是没有锁住对应资源产生脏数据...
- 下一篇
马蜂窝推荐系统容灾缓存服务的设计与实现
数据库突然断开连接、第三方接口迟迟不返回结果、高峰期网络发生抖动...... 当程序突发异常时,我们的应用可以告诉调用方或者用户「对不起,服务器出了点问题」;或者找到更好的方式,达到提升用户体验的目的。 一、背景 用户在马蜂窝 App 上「刷刷刷」时,推荐系统需要持续给用户推荐可能感兴趣的内容,主要分为根据用户特性和业务场景,召回根据各种机器学习算法计算过的内容,然后对这些内容进行排序后返回给前端这几个步骤。 推荐的过程涉及到 MySQL 和 Redis 查询、REST 服务调用、数据处理等一系列操作。对于推荐系统来说,对时延的要求比较高。马蜂窝推荐系统对于请求的平均处理时延要求在 10ms 级别,时延的 99 线保持在 1s 以内。 当外部或者内部系统出现异常时,推荐系统就无法在限定时间内返回数据给到前端,导致用户刷不出来新内容,影响用户体验。 所以我们希望通过设计一套容灾缓存服务,实现在应用本身或者依赖的服务发生超时等异常情况时,可以返回缓存数据给到前端和用户,来减少空结果数量,并且保证这些数据尽可能是用户感兴趣的。 二、设计与实现 设计思路和技术选型 不仅仅是推荐系统,缓存技...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- Eclipse初始化配置,告别卡顿、闪退、编译时间过长
- CentOS8安装MyCat,轻松搞定数据库的读写分离、垂直分库、水平分库
- SpringBoot2全家桶,快速入门学习开发网站教程
- CentOS7设置SWAP分区,小内存服务器的救世主
- CentOS7安装Docker,走上虚拟化容器引擎之路
- CentOS7编译安装Cmake3.16.3,解决mysql等软件编译问题
- Docker快速安装Oracle11G,搭建oracle11g学习环境
- CentOS8安装Docker,最新的服务器搭配容器使用
- SpringBoot2初体验,简单认识spring boot2并且搭建基础工程
- CentOS7编译安装Gcc9.2.0,解决mysql等软件编译问题