-
Notifications
You must be signed in to change notification settings - Fork 26
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
- Loading branch information
Showing
12 changed files
with
456 additions
and
8 deletions.
There are no files selected for viewing
File renamed without changes.
File renamed without changes.
File renamed without changes.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,219 @@ | ||
# 2. Kubernetes 基础 | ||
|
||
## 2.1 Kubernetes 概述 | ||
|
||
### Kubernetes 是什么 | ||
|
||
Kubernetes(k8s)是Google开源由CNCF基金会管理的容器集群管理系统。为容器化的应用提供部署运行、资源调度、服务发现和动态伸缩等一系列完整功能。Kubernetes 被称为现在化的数据中心操作系统,大家都知道,操作系统是用来管理硬件资源比如 CPU、内存、硬盘、输入输出设备等资源,并完成这些资源的调度。同样 Kubernetes 是将数据中心里的物理节点作为管理对象,进行资源编排、调度的。 | ||
|
||
## 2.2 Kubernetes 架构 | ||
|
||
### 控制节点 | ||
|
||
- kube-apiserver 对外暴露了Kubernetes API,所有对集群的操作都是通过这组API完成,包括集群资源信息的收集、应用的编排 | ||
- kube-controller-manager 负责整个Kubernetes的管理工作,保证集群中各种资源的状态处于期望状态,当监控到集群中某个资源状态不正常时,管理控制器会触发对应的调度操作 | ||
- kube-scheduler 调度器负责Kubernetes集群的具体调度工作,接收来自于管理控制器(kube-controller-manager)触发的调度操作请求,然后根据请求规格、调度约束、整体资源情况等因素进行调度计算,最后将任务发送到目标节点的kubelet组件执行。 | ||
- etcd etcd是一款用于共享配置和服务发现的高效KV存储系统,具有分布式、强一致性等特点。在Kubernetes环境中主要用于存储所有需要持久化的数据。 | ||
|
||
### 计算节点 | ||
|
||
- kubelet kubelet是Node节点上最重要的核心组件,负责Kubernetes集群具体的计算任务,具体功能包括:通过与docker daemon的交互运行docker容器;配置Volume和网络;监控上报节点资源等 | ||
- kube-proxy kube-proxy主要负责Service Endpoint到POD实例的请求转发及负载均衡的规则管理。 | ||
|
||
以上这些组件的运行原理在进阶篇中会详细讲述。 | ||
|
||
## 2.3 Kubernetes解决了什么问题 | ||
|
||
编排?调度?容器云?还是集群管理?我个人觉得都是,在不同的阶段,Kubernetes 的作用也是不一样的。我们希望 Kubernetes 提供负载均衡、水平扩展、监控、备份、灾难恢复等一系列运维能力。 | ||
|
||
Kubernetes 项目最主要的设计思想是,从更宏观的角度,以统一的方式来定义任务之间的各种关系,更甚至我们可以运用 Kubernetes 扩展能力灵活的自定义任务之间的关系。 | ||
|
||
比如,Kubernetes 项目对容器间的交互关系进行了分类,首先总结出了一类非常常见的“紧密交互”的关系,即:这些应用之间需要直接通过本地文件进行信息交换。 | ||
|
||
在常规环境下,这些应用往往会被直接部署在同一台机器上,通过 Localhost 通信,通过本地磁盘上的文件进行交互。而在 Kubernetes 项目中,这些容器则会被划分为一个“Pod”,Pod 里的容器共享同一个 Network Namespace、同一组数据卷,从而达到高效率交换信息的目的。 | ||
|
||
Pod 是 Kubernetes 项目中最基础的一个对象,下一张中我会重中对 Pod 做更进一步地阐述。 | ||
|
||
而对于另外一种更为常见的需求,比如 Web 应用与数据库之间的访问关系,Kubernetes 项目则提供了一种叫作“Service”的服务。像这样的两个应用,往往故意不部署在同一台机器上,这样即使 Web 应用所在的机器宕机了,数据库也完全不受影响。可是,我们知道,对于一个容器来说,它的 IP 地址等信息不是固定的,那么 Web 应用又怎么找到数据库容器的 Pod 呢? | ||
|
||
所以,Kubernetes 项目的做法是给 Pod 绑定一个 Service 服务,而 Service 服务声明的 IP 地址等信息是“终生不变”的。这个Service 服务的主要作用,就是作为 Pod 的代理入口,从而代替 Pod 对外暴露一个固定的网络地址。 | ||
|
||
## 2.4 Kubernetes 集群搭建 | ||
|
||
### 使用 Docker CE 自带的 Kubernetes | ||
|
||
安装 Docker 参考:https://docs.docker.com/install/ | ||
|
||
- Install Docker for Mac | ||
- Install Docker for Windows | ||
|
||
### 使用 minikube | ||
|
||
#### MacOS 安装 minikube | ||
|
||
- 安装minikube | ||
|
||
```bash | ||
brew cask install minikube | ||
``` | ||
|
||
- 安装vm驱动 | ||
|
||
```bash | ||
curl -LO https://storage.googleapis.com/minikube/releases/latest/docker-machine-driver-hyperkit \\n&& sudo install -o root -g wheel -m 4755 docker-machine-driver-hyperkit /usr/local/bin/ | ||
``` | ||
|
||
- 启动 minikube(minikube会安装kubernetes需要的组件,这些组件的镜像存储在google的常客中,所有需要能够翻墙才能够安装成功) | ||
|
||
、、、bash | ||
minikube start --vm-driver=hyperkit --memory=4096 --insecure-registry="hub.xin.com" --registry-mirror="https://m9sl8pb5.mirror.aliyuncs.com" --docker-opt="bip=172.87.0.1/16" | ||
|
||
参数介绍: | ||
--vm-driver 使用的虚拟机驱动 | ||
--memory 给虚拟机的内存大小 | ||
--cpu 给虚拟机的cpu核数,默认是2核 | ||
--insecure-registry 指定私有仓库地址 | ||
--registry-mirror 指定镜像缓存地址,加快镜像下载速度 | ||
--docker-opt 指定docker的启动参数,bip 指定 docker 网桥使用的网段 | ||
、、、 | ||
|
||
- 停止minikube | ||
|
||
、、、bash | ||
minikube stop | ||
、、、 | ||
|
||
- 删除集群 | ||
|
||
、、、bash | ||
minikube delete | ||
、、、 | ||
|
||
- 登录虚拟机 | ||
|
||
、、、bash | ||
minikube ssh | ||
、、、 | ||
|
||
#### Windows 安装 minikube | ||
|
||
Windows 安装minikube,需要Windows系统支持Hyper-V,目前 Windows 10 Enterprise, Windows 10 Professional, and Windows 10 Education 支持Hyper-V。安装minikube时,最好命令行使用powershell,并且以管理员身份打开并执行。 | ||
|
||
##### 安装方法 1: | ||
|
||
- 安装 https://chocolatey.org/ | ||
- choco install minikube kubernetes-cli | ||
|
||
##### 安装方法 2: | ||
|
||
下载 minikube-installer.exe (https://github.com/kubernetes/minikube/releases/latest)并进行安装。 | ||
|
||
启动 minikube | ||
|
||
、、、bash | ||
minikube start --vm-driver=hyperv --memory=4096 --insecure-registry="hub.xin.com" --registry-mirror="https://m9sl8pb5.mirror.aliyuncs.com" --docker-opt="bip=172.87.0.1/16" | ||
、、、 | ||
|
||
## 2.5 访问 Kubernetes | ||
|
||
### Dashboard | ||
|
||
#### 访问Dashboard | ||
|
||
、、、bash | ||
kubectl proxy | ||
、、、 | ||
|
||
访问地址: http://localhost:8001/api/v1/namespaces/kube-system/services/kubernetes-dashboard/proxy/#!/overview?namespace=default | ||
|
||
#### 基本概念 | ||
|
||
##### 集群 | ||
|
||
- namespace 逻辑隔离空间,可以在不同的 namespace 里运行不同的微服务,默认使用 default 命名空间 | ||
- node 部署集群使用的物理节点,包括控制节点和计算节点 | ||
|
||
##### 工作负载 | ||
|
||
- deployment 我们实际部署的服务,所谓部署就是用来描述我们待编排的服务的期望状态的,比如我们这个服务启动的副本数,使用的镜像等等,后面会做详细讲解 | ||
|
||
##### 服务发现 | ||
|
||
- service 应用想被其他应用访问,需要先定义一个service,kubernetes自动帮我们解析这个service name,然后其他服务就可以通过service name访问这个服务了 | ||
|
||
##### 配置 | ||
|
||
- configmap 定义应用的配置文件,在应用容器启动时挂载到容器中 | ||
- secret 同configmap,定义某些敏感的、需要加密的配置文件,在应用容器启动时挂载到容器中 | ||
|
||
### kubectl | ||
|
||
#### 下载安装 kubectl | ||
|
||
MacOS 安装: | ||
|
||
、、、bash | ||
brew install kubernetes-cli | ||
、、、 | ||
|
||
Windows 安装: | ||
|
||
、、、bash | ||
choco install kubernetes-cli | ||
cd C:\users\yourusername | ||
mkdir .kube | ||
cd .kube | ||
New-Item config -type file | ||
、、、 | ||
|
||
#### 配置 kubectl 客户端连接到 kubernetes 集群 | ||
|
||
kubectl配置文件 ~/.kube/config | ||
|
||
- clusters | ||
- users | ||
- contexts | ||
|
||
#### 获取集群信息 | ||
|
||
、、、bash | ||
kubectl get nodes | ||
kubectl get pods | ||
kubectl get pods -n xxx | ||
、、、 | ||
|
||
#### 使用命令行部署nginx服务 | ||
|
||
、、、bash | ||
kubectl run nginx --image=nginx:1.15 | ||
、、、 | ||
|
||
#### 为nginx创建服务 | ||
|
||
、、、bash | ||
kubectl expose deployment nginx --port 80 | ||
、、、 | ||
|
||
#### 获取部署列表 | ||
|
||
、、、bash | ||
kubectl get svc | ||
、、、 | ||
|
||
#### 启动工具容器进行访问测试 | ||
|
||
、、、bash | ||
kubectl run -ti busybox --image=busybox --restart=Never -- sh | ||
、、、 | ||
|
||
#### 测试能否访问服务 | ||
|
||
、、、bash | ||
wget http://nginx | ||
、、、 | ||
|
||
## 2.6 小结 | ||
|
||
本章中我向你讲述了 Kubernetes 是什么,Kubernetes 的架构,以及它解决了什么问题。在工作中,我们的目标是帮我们的应用部署到 Kubernetes 容器云中,在部署我们的应用时,首先遇到了应用间亲密关系的难题,于是就扩展到了 Pod;有了 Pod 之后,我们希望能一次启动多个应用的实例,这样就需要 Deployment 这个 Pod 的多实例管理器;而有了这样一组相同的 Pod 后,我们又需要通过一个固定的 IP 地址和端口以负载均衡的方式访问它,于是就有了 Service。在以后的章节中我会给你重中讲解 Pod、Deployment、Service 这些资源对象。 | ||
|
||
最后我介绍了如何在我们的客户端上搭建一个用于测试的 Kubernetes 集群。并通过Dashboard、kubectl访问了我们搭建的集群。在下一章我会着重给你讲解如何在 Kubernetes 集群中部署、升级我们的应用。 |
Binary file not shown.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,76 @@ | ||
# 1. 容器基础 | ||
|
||
## 1.1 容器技术 | ||
|
||
### 容器技术的兴起 | ||
|
||
容器技术是怎样兴起的呢?2007年 谷歌实现的cgroups 正式添加到Linux内核中,次年LXC发布,实现了第一套Linux容器管理方案。但是从容器技术被提出到2013年Docker的出现,容器技术一直不温不火,直到Docker出现后容器相关技术才兴起起来。在LXC被创造出来后为什么没有迅速火起来呢?LXC解决了什么问题呢?LXC通过内核的cgroup特性实现了资源的限制,通过namespace特性实现了隔离,但是它并不容易使用。随着云计算的发展,PaaS平台即服务的概念不断普及,服务部署成了摆在人们面前亟待解决的问题,各个厂商急需找到一种标准化的部署应用的方法。直到2013年,Docker项目发布后,他对于应用打包技术的小创新迅速赢得了开发者的心。开发者通过容器镜像可以非常方便的将自己的应用部署到PaaS平台上。Docker技术快速在开发者社区传播开来,带来了容器技术的大发展。 | ||
|
||
### 容器解决了什么问题 | ||
|
||
那容器技术到底解决了什么问题呢?就像Docker 公司声称的 build, ship, run anywhere。Docker解决的是应用打包、传输和运行的问题,我们可以通过docker build创建应用镜像,通过docker push、pull传输镜像,通过docker run运行应用。Docker让应用的部署更方便,而容器本身又自带了对资源限制和隔离的能力。 | ||
|
||
### 容器的管理问题 | ||
|
||
随着我们运行的容器项目的增多,如果对容器进行管理成了摆在开发者面前的问题。Docker公司也开始意识到这个问题,于是发布了自己的容器编排服务Docker Compose,随后发布了跨主机的应用编排服务Docker Swarm。Docker Compose、Docker Swarm、Docker Machine并称Docker公司的编排三剑客。随着Docker 公司发布自己的容器编排服务,触动了CoreOS、Google、RedHat等PaaS平台公司的利益,为了切割Docker公司在容器领域的话语权,Google公司联和RedHat公司以Google公司的Borg为原型发布了Kubernetes容器编排平台。所谓容器编排就是指我们如何将我们的应用容器部署到PaaS平台上,对于比较复杂的应用编排,容器编排平台需要帮我们处理应用间的拓扑关系亲和性和反亲和性,服务发现及服务监控,以及共享存储方案等等所有问题。而Docker Swarm和Mesos+马拉松的组合在处理复杂应用的编排问题上就捉襟见肘了,于是Kubernetes逐渐成为了编排领域的事实标准。 | ||
|
||
本教程主要以实例的方式讲解如何将我们的应用部署到Kubernetes集群上,这是一个实践课程,需要你和我一起动手操作。 | ||
|
||
## 1.2 使用容器技术构建应用 | ||
|
||
在讲解应用部署之前,我们先来回顾一下容器相关的知识,因为他是我们在接下来编排的主要对象。 | ||
|
||
在日常的运维过程中,我们通常会遇到这样的需求,某个服务需要运行在不同的中间件版本之下,但是使用当前的包管理程序比如yum、apt-get很难在同一个系统中同时安装两个不同版本的中间件。而容器的出现很好的为我们解决了这个问题,通过将我们的代码和我们使用的中间件一起打包,然后将我们打包的镜像运行在同一操作系统下,就很简单的解决了我们上面遇到的问题。 | ||
|
||
接下来我们一起打包一个Flask框架的Python Web应用。 | ||
|
||
### 讲解 Dockerfile 文件 | ||
|
||
v1版本,通过socket通信 | ||
|
||
- 查看应用代码 | ||
- 查看应用的uwsgi配置 | ||
- 应用依赖的第三方库requirements.txt | ||
- 全局uwsgi配置 | ||
- Dockerfile | ||
|
||
v2版本,通过监听端口通信 | ||
|
||
- 查看应用代码 | ||
- 全局uwsgi配置 | ||
|
||
### 镜像打包 | ||
|
||
v1版本,通过socket通信 | ||
|
||
```bash | ||
docker build -t ist0ne/hello:v1 . | ||
docker login | ||
docker push ist0ne/hello:v1 | ||
``` | ||
|
||
v2版本,通过监听端口通信 | ||
|
||
```bash | ||
docker build -t ist0ne/hello:v2 . | ||
docker login | ||
docker push ist0ne/hello:v2 | ||
``` | ||
|
||
### 运行容器 | ||
|
||
```bash | ||
docker run -ti -d --name flask ist0ne/hello:v1 | ||
``` | ||
|
||
### 进入容器 | ||
|
||
```bash | ||
docker exec -ti flask bash | ||
``` | ||
|
||
## 1.3 小结 | ||
|
||
本章中我向你讲述了容器的兴起过程以及容器能做什么以及解决了什么问题。其实容器实际上是一个由 Linux Namespace、Linux Cgroups 和 rootfs 三种技术构建出来的进程的隔离环境。容器的rootfs部分称为“容器镜像”(Container Image),是容器的静态视图;Namespace+Cgroups 构成的隔离环境,这一部分我们称为“容器运行时”(Container Runtime),是容器的动态视图。然后我向你阐述了容器兴起后出现的管理问题,于是出现了容器编排系统。从一个开发者和单一的容器镜像,到无数开发者和庞大的容器集群,容器技术实现了从“容器”到“容器云”的飞跃,标志着它真正得到了市场和生态的认可。 | ||
|
||
接下来我以实例的方式向你讲述了如何打包一个Flask架构的Python Web应用及如何将它运行起来。下一张我将向你讲述 Kubernetes 这个编排工具存在的意义及其架构,已经它是如何解决容器编排问题,从而走向容器编排的事实标准的。 |
Oops, something went wrong.