云原生是什么?和Docker、K8s是什么关系?又带来了何种影响?希望这篇文章给自己及大家解点疑惑

文章探讨了云原生技术为何兴起,重点介绍了Docker和K8s在云原生架构中的作用,以及它们如何帮助企业实现数字化转型,降低成本,提高效率。同时,提到了云原生对传统开发模式的影响,包括对中间件使用方式的改变和对开发者角色的重塑。

1. 为什么要云原生?

现在容器化和云原生十分火爆,但如果要理解为什么这个技术在近几年突然爆火,身为传统的Springboot和Springcloud体系开发者都有很多困惑,怎么就突然这么火爆了呢?诸如我就产生了以下问题:

  1. 传统的springboot或springcloud体系和云原生对比起来有何差别?
  2. 传统的spring体系和云原生可以给开发者带来何种便利?
  3. 对接云原生具有何种代价?
  4. 使用云原生后业务系统使用MQ或Reids此类的中间件方式会有何种改变?
  5. 云原生能提供何种服务?
  6. 云原生对传统开发模式的对比?
  7. 云原生所说的DevOps和持续交付具体如何实现?
  8. Docker和K8S赋予了程序何种能力?又让程序付出了何种代价?
  9. 云原生对传统开发模式中的开发人员有何影响?
  10. 云原生和微服务的关系?
  11. 不使用云原生的开发模式和使用云原生的开发模式?
  12. 云原生和云计算的关系?

要解答这些疑问还是要了解清楚云原生是什么,以及其技术基础和应用场景到底是什么。

2. 简单了解云原生的技术基础

2.1 云计算

云计算本质是一个可以提供IaaS、PaaS和Saas三种不同服务的产品。

  • SaaS:提供固定的功能,客户可根据需要的功能购买对应的产品,用户无需开发,直接付费使用;
  • PasS:为程序运行时提供用于开发、测试和管理的应用程序,用户需要自行开发程序,但对程序的各种管理软件和资源都无需关心;
  • IaaS:把IT的基础资源(如服务器、存储和网络)封装为产品,用户需要自行开发、维护和管理整个开发周期,包括一些公共框架。

2.2 云原生

云原生官方的定义:基于分布部署和统一运管的分布式云,以容器、微服务、DevOps等技术为基础建立的一套云技术产品体系。

直白的说云原生就是制定一系列的应用规范,并将其集成封装后的云计算PaaS产品。

云原生带来的好处:

  1. 便利性:公司自己购买维护机器和聘请技术人员开发维护技术框架都是成本,而云原生则是自己承担服务器资源和框架维护的成本,对外公共开放其使用权限,以避免处处都需要维护服务器和框架;
  2. 低成本:中小型公司或技术薄弱的公司要想立马搭建起一套高可用高并发的微服务体系, 可直接购买云原生的服务支持;
  3. 可靠性:云原生的产品基本都有大公司支持,稳定性、性能和容灾等各种指标都能兼顾;
  4. 伸缩性:可针对不同的业务阶段进行性能伸缩,而无需考虑机器应该如何处置;

与Springcloud的差别:Springcloud体系要求开发者自己对技术较为熟悉,与Java程序绑定,且技术维护都需要自己做;而云原生则是为开发者提供基础资源,开发者只需要会使用即可,而无需自己再去维护基础资源;因此使用云原生,开发者就可以把更多的精力放到如何使用这些技术完成业务需求,而无需关心基础设施是否安全可靠稳定。

2.3 Docker

Docker是运行在Linux的开源的应用容器引擎程序,基于Go语言并遵从Apache2.0协议开源。

其最大优势就是只要目标方提供了容器的镜像,就可以直接拉取镜像运行,诸如MySQL、nginx和JDK这些开源资源都可以直接拉取其镜像。

当拉取了镜像后需要使用Dockerfile文本文件来定制镜像,如使用哪个镜像去运行镜像支持的可执行文件。

一台机器可运行多个镜像文件,即多个容器。

2.4 K8s

Kubernetes是一个用于自动化部署、扩展和管理容器化应用的开源容器编排工具,Docker官方的Docker Swarm是其竞争对手,其通过在集群上形成一个抽象层来部署和管理容器中的应用程序。

K8s的作用:

  1. 控制和管理应用程序对资源的使用;
  2. 自动负载均衡多个实例之间的请求;
  3. 如果主机资源耗尽或主机死机,将应用程序实例从一台主机迁移到另一台主机上;
  4. 当有新的主机加入集群时,新增额外可被自动使用的资源。

K8s被CNCF基金会倡议的项目,增长迅速,其优势在于:

  1. 可移植性和灵活性:K8s可在各种基础设施和环境设置下运行,其它的容器编排器则做不到;
  2. 开源支持:CNCF负责管理K8s,是一个完全开源、由社区驱动的项目,没有一家公司可以控制平台框架的发展方向,由很多大公司背书,因此不用担心稳定性和维护性;
  3. 多云兼容性:K8s能够轻松的扩展到另一个云,简单来说就是跨机房;

K8s的组件:

  • K8s使用Etcd来完成整个集群的服务注册与发现,Etcd是由golang语言编写的,在集群中每个机器都被称为节点;
  • K8s通过控制平面来管理不同节点,使用HTTP发送接收命令或连接到系统运行命令行脚本,控制了K8s与应用程序的交互;
  • K8s的Pod是K8s管理容器集的最小单位,每个Pod中都有被分配的单独IP地址,在Pod中的容器内存和存储资源都是共享的,Pod也可以只有一个容器;
  • Kubelet被用来跟踪Pod及其容器的运行状态,检查Pod规则并确认Pod是否健康;
  • Kube代理被用来实现网络代理和负载均衡,充当在每个节点和API服务器之间的连接,在每个节点上都会运行,外部和内部请求到Pod都会经过Kube代理;

3. 关联解疑

3.1 Docker和K8s的关系

到这里可以很好的理解Docker和K8s的关系了,Docker是运行在机器上的容器引擎,可以看成是虚拟机,但性能比虚拟机强很多,直接对接底层Kernel核心。Docker能够让一台机器可以创建多个容器以运行多个应用程序。而由于Docker的容器编排器Swarm由于易用性不能满足要求,被开源框架K8s所代替,因此K8s成为了运行在Docker容器上的最主流容器编排器,用来支持在容器上快速部署管理应用程序。

3.2 容器化的爆火

一个技术的兴起爆火原因是多方面的,但云原生和容器化的流行个人认为主要还是有两个原因:企业数字化转型大背景和云计算提供者的降本增效

3.2.1 企业数字化转型大背景

现在每个企业都想进行数字化转型,特别是传统行业,在看到新兴互联网行业依靠各种软件系统混的风生水起,谁不想来掺和一脚?况且数字化管理是真真切切可以提高企业的管理能力和效率,所以企业数字化转型对于企业的发展来说是必要的。

此时企业有两种选择,一是购买SaaS产品服务,但自定义产品的代价十分高昂且效率无法保证;二是自己成立一个业务开发组,所有需求从内部孵化落地。第二个方案现实问题就是传统企业中程序员的占比是非常小的,如果靠自己从无到有做数字化转型,招聘大量的程序员且不说,各种机房服务器的搭建都是一笔巨大的开销。此时就产生了一个很大的需求缺口:很多企业都需要PaaS服务。

这些企业只需要购买基础的服务器和设备资源,并招一些相对资深程序员更加便宜的初中级程序员,就能开始开发自己系统和产品。对于大部分企业而言这相对于从头到尾自己搭建机房性价比要高很多。

3.2.2 云计算企业降本增效缺口

市场存在巨大的PaaS需求缺口,云计算火爆是必然的事情。但对于云计算企业而言,如何以客户相对满意的价格提供服务是最重要的事情,如果还是和以前一样,以机房服务器租赁的方式提供云计算服务,大部分企业还是无法接收这种成本。

对于云计算企业而言,巴不得可以一台服务器可以服务N家企业,这样自己的收益才会最高。

3.2.3 Docker和K8s火爆的必然性

云计算企业要求一台服务器可以服务N家企业来提高自己的收益,而Docker和K8s正是为这种场景而诞生的,因此众多云计算企业选择Docker和K8s来实现PaaS服务就是很理所当然的事情了。

在此基础上CNCF提出了云原生的规范,为提供云计算PaaS服务的企业提供了规范和背书,在这种背景下,容器化想不火都由不得它了。

3.2.4 容器化带来的影响

私以为容器化带来的最大影响就是业务型开发需求进一步扩张,而各种中间件维护开发工程师需求量会被压缩。

当越来越多的企业加入到云原生,一起平摊服务器成本后,越来越多的技术维护将会慢慢淡出我们的视野。以最常见且重要的负载均衡来说,阿里云提供SLB服务,可以实现内网调用和外网调用的负载均衡,这样我们只需要知道对应的域名直接调用即可,无需再考虑使用负载均衡中间件来控制流量。

这种变化会导致一个趋势:

  1. 业务开发将占绝对主流:业务开发只需要会熟练使用各种中间件来解决业务问题即可;
  2. 维护中间件开发的技术大佬生存空间被挤压:由于大部分企业都不再需要维护中间件,出了问题后直接找云服务商,中间件开发的大佬岗位将会减少。

但毕竟经过这么多年的发展,技术存量摆在那里,岗位需求一定是会有的,只是岗位增量会逐步减少。

而对于业务开发来说,这种趋势虽然不再要求精通各种中间件管理知识,但对中间件的使用要求将会越来越高,毕竟要关注的技术点变少,那就只能精通剩余的技术了。

<think>好的,我现在需要帮助用户解决在特定Linux系统上启动Docker容器的问题。用户提到的系统是k8s-master,版本为6.4.0-10.1.0.20.oe2309.x86_64,看起来是基于openEuler的发行版。首先,我需要确认用户的需求。他们之前已经配置了HarborKubeSphere,现在可能是在搭建Kubernetes集群时遇到需要启动Docker容器的情况。 首先,我应该检查用户提供的系统信息。根据引用[2],系统使用的是Linux内核6.4.0,openEuler 2309版本。这可能意味着用户的环境是专门为容器云原生应用优化的。考虑到用户之前使用了KubeKey(kk)来部署KubernetesKubeSphere,可能他们的环境中已经安装了Docker或者containerd作为容器运行时。 接下来,用户的问题是如何在这个特定系统上启动Docker容器。我需要分步骤来解答。首先,确认Docker是否已安装。因为不同的Linux发行版安装方式不同,openEuler可能使用dnf或yum包管理器。如果Docker未安装,需要指导用户安装,包括添加必要的仓库依赖。 然后,考虑到用户可能在使用Kubernetes,需要确认Docker是否与Kubernetes兼容。Kubernetes 1.23.10可能默认使用containerd,但用户可能仍需要Docker作为运行时。需要提醒用户注意版本兼容性,并确保Docker配置正确,特别是如果使用Harbor作为私有仓库,需要配置Docker的认证信息,如引用[1]中提到的config-sample.yaml中的认证信息。 此外,用户可能需要启动容器时映射端口、挂载卷或设置环境变量,这些在之前的回答中已经涉及,但需要根据当前系统环境进行调整。例如,使用私有仓库时,需要登录到Harbor,拉取镜像,然后运行容器。需要确保用户了解如何在命令行中传递这些参数,特别是涉及认证的部分。 还需要注意用户提到的特定Linux版本可能存在某些依赖或配置差异。例如,SELinux或防火墙设置可能影响Docker的运行,需要检查这些方面。另外,如果用户遇到权限问题,可能需要指导他们使用sudo或者将用户加入docker组。 最后,用户可能希望了解如何验证容器是否成功启动,以及如何查看日志调试问题。这部分内容也应该包含在回答中,确保用户能够全面理解操作。同时,结合之前的回答,用户的问题可能涉及KubeSphere的集成,所以可能需要简要说明Docker在Kubernetes环境中的角色,但主要焦点还是放在启动容器本身。</think>### 在 openEuler 6.4.0 系统上启动 Docker 容器的完整指南 --- #### **一、环境验证** 根据引用[2]的配置信息,系统为 **openEuler 2309**(Linux 6.4.0内核),具体验证步骤: ```bash # 查看系统版本 [root@k8s-master ~]# cat /etc/os-release | grep PRETTY_NAME PRETTY_NAME="openEuler 23.09" # 确认 Docker 安装状态 [root@k8s-master ~]# docker --version Docker version 24.0.7, build 24.0.7-0.oe2309 # 若未安装需先安装 ``` --- #### **二、安装 Docker(如未预装)** ##### 1. 添加 Docker 仓库 ```bash # 安装依赖工具 [root@k8s-master ~]# dnf install -y yum-utils device-mapper-persistent-data lvm2 # 添加 Docker CE 仓库 [root@k8s-master ~]# dnf config-manager --add-repo https://download.docker.com/linux/openeuler/docker-ce.repo ``` ##### 2. 安装 Docker 引擎 ```bash [root@k8s-master ~]# dnf install docker-ce docker-ce-cli containerd.io ``` ##### 3. 启动并验证服务 ```bash # 启动 Docker 服务 [root@k8s-master ~]# systemctl start docker && systemctl enable docker # 验证安装 [root@k8s-master ~]# docker run hello-world Hello from Docker! # 出现此提示表示成功 ``` --- #### **三、对接私有 Harbor 仓库(引用[1]配置)** ##### 1. 登录 Harbor 仓库 ```bash # 使用引用[1]中的认证信息 [root@k8s-master ~]# docker login dockerhub.kubekey.local -u admin -p Harbor12345 Login Succeeded # 认证成功提示 ``` ##### 2. 从 Harbor 拉取镜像 ```bash # 示例:拉取 nginx 镜像 [root@k8s-master ~]# docker pull dockerhub.kubekey.local/kubesphereio/nginx:alpine ``` --- #### **四、启动容器的两种场景** ##### **场景 1:普通容器启动** ```bash # 启动一个后台运行的 Nginx 容器 [root@k8s-master ~]# docker run -d \ --name my_nginx \ -p 8080:80 \ -v /opt/nginx/html:/usr/share/nginx/html \ dockerhub.kubekey.local/kubesphereio/nginx:alpine ``` ##### **场景 2:Kubernetes 环境兼容启动** 根据引用[2]的 Kubernetes 版本(v1.23.10),需注意: ```bash # 添加 --cgroupns=host 参数确保与 Kubernetes 兼容 [root@k8s-master ~]# docker run -d \ --cgroupns=host \ --name k8s_compat_container \ busybox:latest sleep 3600 ``` --- #### **五、特殊配置项** | 场景 | 参数 | 说明 | |------|------|------| | **内核兼容性** | `--security-opt seccomp=unconfined` | 解决 openEuler 6.4.0 内核的 seccomp 限制[^1] | | **存储驱动** | `--storage-driver=overlay2` | 推荐在 openEuler 中使用 overlay2 驱动 | | **时区同步** | `-e TZ=Asia/Shanghai` | 同步容器与宿主机的时区 | --- #### **六、验证容器状态** ```bash # 查看运行中的容器 [root@k8s-master ~]# docker ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES a1b2c3d4e5f6 nginx:alpine "/docker-entrypoint.…" 2 minutes ago Up 2 minutes 0.0.0.0:8080->80/tcp my_nginx # 查看容器日志 [root@k8s-master ~]# docker logs my_nginx ``` --- #### **七、故障排查** ##### 1. **权限拒绝错误** ```bash # 解决方案:添加 --privileged 参数(临时测试用) docker run -it --privileged ubuntu:22.04 ``` ##### 2. **cgroup 报错** ```bash # 添加 cgroup 挂载参数 docker run -d \ --volume /sys/fs/cgroup:/sys/fs/cgroup:ro \ centos:7 /usr/sbin/init ``` --- ### 相关问题 1. 如何查看 Docker 容器占用的资源? 2. openEuler 系统如何配置 Docker 镜像加速? 3. 容器与宿主机之间的文件传输方法? 4. 如何限制 Docker 容器的 CPU 内存使用? 5. Docker 与 Kubernetes 中的容器运行时有何区别? --- [^1]: 根据 openEuler 官方文档,6.4.0 内核默认启用严格 seccomp 策略,部分容器需特殊配置
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值