19-Kubenetes简介

本文回顾了DockerSwarm与Kubernetes的发展历程,分析了两者在容器编排领域的竞争态势。从Kubernetes的架构出发,详细介绍了master节点与node节点的功能,对比了它们与DockerSwarm的Manager和Worker节点的区别。

Kubernetes单词起源于希腊语, 是「舵手」或者「领航员」的意思,是“管理者”和“控制论”的根源。 K8s是把用8代替8个字符“ubernete”而成的缩写。

1. Docker Swarm 和 k8s的前世今生

可以很明确的说 先有的k8s,后有的docker swarm。

  • 容器编排工具Kubernetes诞生,并迅速得到Google和RedHat的支持。2014年7月,Docker收购Orchard Labs,由此Docker公司开始涉足容器编排领域,Orchard Labs这家2013年由两位牛逼的年轻人创建的公司,有一个当时非常著名的容器编排工具fig,而这个fig就是docker-compose的前身。Docker Compose虽然能编排多容器的APP,但是却不能实现在多个机器上进行容器的创建和管理。所以此时Docker公司和Kubernetes并未开始正面竞争和冲突。

  • 10月17日,Docker公司在其丹麦哥本哈根举行的 DockerCon 大会上宣布,将扩大其Docker平台并拥抱支持Kubernetes。显然,在容器编排领域的战火已然分出结果,尘埃落定,Kubernetes得到了包括Google、Huawei、Microsoft、IBM、AWS、Rancher、Redhat、CoreOS等容器玩家的一致认可。

  • Docker容器不关心用户使用哪种编排框架,它的工作是让用户轻松地选择最喜欢的编排框架,无论Kubernetes、Mesos、Docker Swarm还是其他。这个选择在价值上无关紧要,真正的价值在于平台,那才是钱。因此,将Kubernetes与Docker容器进行比较是没有意义的,Docker的真正的竞争对手是VMWare、CloudFoundry等平台。

Kubernetes和docker swarm的Google Trends如下:
在这里插入图片描述
在这里插入图片描述

2. docker Swarm回顾

docker Swarm分为Manager节点和Worker节点,Manager具备管理功能,维持这个cls的状态,提供对外的接口,可以通过manager部署我们的application,部署service,部署stack。
在这里插入图片描述

3. Kubennetes介绍

相比docker Swarm来说manager等于master,worker等于node节点。
在这里插入图片描述

3.1 k8s的master节点

master节点主要是k8s的一个大脑,k8s集群的管理节点,负责管理集群,提供集群的资源数据访问入口。拥有Etcd存储服务,运行Api Server进程,Controller Manager服务进程及Scheduler服务进程,关联工作节点Node。Kubernetes API server提供HTTP Rest接口的关键服务进程,是Kubernetes里所有资源的增、删、改、查等操作的唯一入口。也是集群控制的入口进程;Kubernetes Controller Manager是Kubernetes所有资源对象的自动化控制中心;Kubernetes Schedule是负责资源调度(Pod调度)的进程。
在这里插入图片描述

3.2 k8s的node节点

Node是Kubernetes集群架构中运行Pod的服务节点(亦叫agent或minion)。Node是Kubernetes集群操作的单元,用来承载被分配Pod的运行,是Pod运行的宿主机。关联Master管理节点,拥有名称和IP、系统资源信息。运行docker eninge服务,守护进程kunelet及负载均衡器kube-proxy。

Pod是k8s中容器调度的最小单位,是具有相同namespace的container的组合,可能是一个或多个container。这里的namespace包含的所有的namespace,比如usernamespace、networknamespace等。

Node节点主要部件:

  • Docker Engine(Docker):Docker引擎,负责本机容器的创建和管理工作;
  • kubelet:负责对Pod对于的容器管理,如容器创建、volume、network等;
  • kube-proxy:实现Kubernetes Service的通信与负载均衡机制的重要组件;
  • Fluentd:负责日志的采集、存储、查询等。
    Node节点可以在运行期间动态增加到Kubernetes集群中,默认情况下,kubelet会向master注册自己,这也是Kubernetes推荐的Node管理方式,kubelet进程会定时向Master汇报自身情报,如操作系统、Docker版本、CPU和内存,以及有哪些Pod在运行等等,这样Master可以获知每个Node节点的资源使用情况,实现高效均衡的资源调度策略。
    在这里插入图片描述

3.3 Kubernetes architecture

在这里插入图片描述

yousatech@Rack-Server:~$ sudo kubeadm init --apiserver-advertise-address=172.19.35.232 --pod-network-cidr=192.168.1.0/24 --image-repository=registry.aliyuncs.com/google_containers W1106 13:24:54.518952 5802 version.go:104] could not fetch a Kubernetes version from the internet: unable to get URL "https://dl.k8s.io/release/stable-1.txt": Get "https://cdn.dl.k8s.io/release/stable-1.txt": context deadline exceeded (Client.Timeout exceeded while awaiting headers) W1106 13:24:54.519153 5802 version.go:105] falling back to the local client version: v1.28.15 [init] Using Kubernetes version: v1.28.15 [preflight] Running pre-flight checks error execution phase preflight: [preflight] Some fatal errors occurred: [ERROR Port-10259]: Port 10259 is in use [ERROR Port-10257]: Port 10257 is in use [ERROR FileAvailable--etc-kubernetes-manifests-kube-apiserver.yaml]: /etc/kubernetes/manifests/kube-apiserver.yaml already exists [ERROR FileAvailable--etc-kubernetes-manifests-kube-controller-manager.yaml]: /etc/kubernetes/manifests/kube-controller-manager.yaml already exists [ERROR FileAvailable--etc-kubernetes-manifests-kube-scheduler.yaml]: /etc/kubernetes/manifests/kube-scheduler.yaml already exists [ERROR FileAvailable--etc-kubernetes-manifests-etcd.yaml]: /etc/kubernetes/manifests/etcd.yaml already exists [ERROR Port-10250]: Port 10250 is in use [preflight] If you know what you are doing, you can make a check non-fatal with `--ignore-preflight-errors=...` To see the stack trace of this error execute with --v=5 or higher
最新发布
11-07
<think>我们面对的是两个主要问题: 1. 端口被占用:10259、10257、10250 2. 文件已存在:/etc/kubernetes/manifests/ 下的kube-apiserver.yaml等文件 这两个问题通常是因为之前安装Kubernetes失败或未完全清理导致的。解决方法是彻底清理之前的安装残留。 ### 🔧 步骤1:重置kubeadm安装 使用`kubeadm reset`命令清除之前安装生成的文件和状态。 ```bash sudo kubeadm reset --force ``` ### 📍 步骤2:手动清理残留文件 由于`kubeadm reset`可能无法完全清除手动创建的文件,需要检查并清理: ```bash # 清理manifest文件 sudo rm -rf /etc/kubernetes/manifests/*.yaml # 清理配置文件 sudo rm -rf /etc/kubernetes/*.conf sudo rm -rf /etc/kubernetes/admin.conf sudo rm -rf /etc/kubernetes/kubelet.conf sudo rm -rf /etc/kubernetes/pki/ # 清理数据目录 sudo rm -rf /var/lib/kubelet/ sudo rm -rf /var/lib/etcd/ ``` ### 步骤3:释放被占用的端口 找出占用10250、10257、10259端口的进程并终止: ```bash # 查找占用端口的进程 sudo lsof -i :10250 sudo lsof -i :10257 sudo lsof -i :10259 # 如果上述命令无输出,使用netstat sudo netstat -tulnp | grep -E ':10250|:10257|:10259' # 终止相关进程(示例) # 假设发现进程ID为1234 sudo kill -9 1234 ``` ### 🔄 步骤4:重新初始化集群 完成清理后,重新执行初始化命令: ```bash sudo kubeadm init \ --apiserver-advertise-address=172.19.35.232 \ --pod-network-cidr=192.168.1.0/24 \ --image-repository=registry.aliyuncs.com/google_containers ``` ### ️ 注意事项 1. **网络冲突**:确保`--pod-network-cidr`与主机网络不重叠(192.168.1.0/24是常见局域网段,建议更换为如10.244.0.0/16) 2. **镜像仓库**:阿里云镜像仓库可用,但需确保网络可达 3. **端口监听**:初始化前确认端口已被释放: ```bash sudo ss -tuln | grep -E '10250|10257|10259' ``` ### 📌 故障排除 | 错误类型 | 解决方案 | |---------|----------| | 端口仍被占用 | 检查kubelet是否在运行:`sudo systemctl stop kubelet` | | manifest文件残留 | 手动删除`/etc/kubernetes/manifests/`下所有文件 | | etcd数据残留 | 清理`/var/lib/etcd`目录 | --- §§ 相关问题 §§ 1. 如何彻底卸载Kubernetes并清理所有相关文件? 2. 如何修改kubeadm默认监听的端口以避免冲突? 3. kubeadm初始化时如何指定特定版本的Kubernetes? 4. 如何解决kubeadm初始化过程中镜像拉取失败的问题? 5. 为什么需要设置`--pod-network-cidr`参数?它与CNI插件有什么关系? </think>### 解决 kubeadm init 端口占用和文件冲突问题 针对您遇到的端口被占用和配置文件残留问题,以下是完整的解决方案: #### 🔧 步骤1:终止占用端口的进程 ```bash # 查找并终止占用端口的进程 sudo ss -tulnp | grep -E ':(10250|10257|10259)' | awk '{print $7}' | cut -d= -f2 | sort -u | xargs -r sudo kill -9 ``` #### 🗑️ 步骤2:彻底清理 Kubernetes 残留文件 ```bash # 重置 kubeadm 安装 sudo kubeadm reset -f # 手动删除残留文件(关键步骤) sudo rm -rf /etc/kubernetes/manifests/*.yaml sudo rm -rf /etc/kubernetes/admin.conf sudo rm -rf /etc/kubernetes/kubelet.conf sudo rm -rf /etc/kubernetes/pki/ sudo rm -rf /var/lib/kubelet/ sudo rm -rf /var/lib/etcd/ ``` #### 🔍 步骤3:验证端口和文件状态 ```bash # 检查端口占用情况 sudo netstat -tulnp | grep -E '10250|10257|10259' # 检查文件残留 ls -l /etc/kubernetes/manifests/ ``` #### ⚙️ 步骤4:安全重新初始化 ```bash sudo kubeadm init \ --apiserver-advertise-address=172.19.35.232 \ --pod-network-cidr=192.168.1.0/24 \ --image-repository=registry.aliyuncs.com/google_containers ``` #### 🔄 替代方案:强制覆盖安装 如果仍有冲突,添加 `--ignore-preflight-errors` 参数: ```bash sudo kubeadm init \ --apiserver-advertise-address=172.19.35.232 \ --pod-network-cidr=192.168.1.0/24 \ --image-repository=registry.aliyuncs.com/google_containers \ --ignore-preflight-errors=Port-10250,Port-10257,Port-10259,FileAvailable--etc-kubernetes-manifests ``` ### ⚠️ 关键注意事项 1. **CIDR 冲突问题**: `192.168.1.0/24` 是常见局域网段,可能导致路由冲突。建议改用: ```bash --pod-network-cidr=10.244.0.0/16 # Flannel 默认 # 或 --pod-network-cidr=192.168.0.0/16 # 扩展范围 ``` 2. **端口占用根源**: 端口 10250/10257/10259 通常被以下进程占用: - 未完全卸载的 kubelet (`systemctl stop kubelet`) - 残留的 etcd 进程 (`sudo pkill etcd`) - 之前的控制平面组件 3. **文件冲突预防**: 每次初始化前执行完整清理: ```bash sudo kubeadm reset -f && \ sudo rm -rf $HOME/.kube /etc/kubernetes/* /var/lib/etcd/* ``` ### 📊 故障排查表 | 错误现象 | 解决方案 | |---------|----------| | `[ERROR Port-10250]` | 执行 `sudo ss -K dst :10250` 强制释放 | | `[ERROR FileAvailable]` | 手动删除 `/etc/kubernetes/manifests/` | | `etcd.yaml already exists` | 清理 `/var/lib/etcd` 目录 | | 端口释放后立即被占用 | 检查 kubelet 服务状态 `systemctl status kubelet` | ---
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

逍遥俊子

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

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

余额充值