# 1.kubernetes 集群网络体系

![image.png](/static/img/1c8ca29c310949961776057738ee0835.image.png)


# 2. 部署架构

![image.png](/static/img/7b13e458f27ea08e785310f8fa638fc6.image.png)
```
集群架构：
  角色角度：
     - 带头大哥 master 所有请求的入口
     - 工作小弟 node。所有应用的载体
  应用角度：
     - 管理平台 master + node
     - 仓库平台 harbor
 容器角度：
     - 容器环境 
     - cri服务 
  
```

![image.png](/static/img/8e251e230acd30b16f078c6abd3906e4.image.png)
# 3. Kubernetes集群命令行工具kubectl

## 1.概述
kubectl是Kubernetes集群的命令工具，通过kubectl能够对集群本身进行管理，并能够在集群上进行容器化应用的安装部署


## 2. kubectl命令的语法
```shell
kubectl [command][TYPE][NAME][flags]
```
* command：指定要对资源执行的操作，例如create、get、describe和delete
* TYPE：指定资源类型，资源类型是大小写敏感的，开发者能够以单数、复数和缩略的形式，例如：
```shell
kubectl get pod pod1
kubectl get pods pod1
kubectl get po pod1
```
* NAME：指定资源的名称，名称是也大小写敏感的，如果省略名，则会显示所有的资源。例如：
```shell
kubectl get pods
```
* flags:指定可选的参数。例如，可用-s或者-server参数指定kubernetes API server的地址和端口。


## 3. kubectl help获取更多的信息
kubectl --help 可以查看更多信息
```shell
kubectl get --help
```
### 3.1 kubectl 子命令使用分类
1. 基础命令
 
 |基础命令 |中文说明 |
 |:---|:---|
 |create|通过文件名或标准输入创建资源 | 
 |expose|将一个资源公开为一个新的Service | 
 |run|在集群中运行一个特定的镜像 | 
 |set|在对象上设置特定的功能 | 
 |get|显示一个或多个资源 | 
 |explain|文档参考资料 | 
 |edit|使用默认的编辑器编辑一个资源 | 
 |delete|通过文件名、标准输入、资源名称或标签选择器来删除资源 | 
 
2. 部署和集群管理命令

 |部署命令 |中文说明 |
 |:---|:---|
 |rollout |管理资源的发布 |
 |rolling-update |对给定的复制控制器滚动更新 |
 |scale |扩容或缩容Pod数量，Deployment、ReplicaSet、RC或Job |
 |autoscale |创建一个自动选择扩容或缩容并设置Pod数量 |

 |集群管理命令 |中文说明 |
 |:---|:---|
 |certificate |修改证书资源 |
 |cluster-info |显示集群信息 |
 |top |显示资源（cpu/memory/storage）使用，需要Heapster运行 |
 |cordon |标记节点不可调度 |
 |uncordon |标记节点可调度 |
 |drain |驱逐节点上的应用，准备下线维护 |
 |taint |修改节点taint标记 |
3. 故障调试命令
  
  |故障诊断和调试命令 |中文说明 |
  |:---|:---|
  |describe |显示特定资源或者资源组的详细信息 |
  |logs |在一个Pod中打印一个容器日志，如果pod只有一个容器，容器名称是可选的 |
  |attach |附加到一个运行的容器 |
  |exec |执行命令到容器 |
  |port-forward |转发一个或多个本地端口到一个pod |
  |porxy |运行一个proxy到Kubernetes API Server |
  |cp |拷贝文件或目录到容器中 |
  |auth |检查授权 |
  
4. 其他命令
  |高级命令 |中文说明 |
  |:---|:---|
  |apply |通过文件名或标准输入对资源应用配置 |
  |patch |使用补丁修改、更新资源的字段 |
  |replace |通过文件名或标准输入替换一个资源 |
  |convert |不同的API版本之间转换配置文件 |
  
  |设置命令 |中文说明 |
  |:---|:---|
  |label |更新资源上的标签 |
  |annotate |更新资源上的注释 |
  |completion |用于实现kubectl工具自动补全 |
  
  |其他命令 |中文说明 |
  |:---|:---|
  |api-versions |打印受支持的API版本 |
  |config |修改kubeconfig文件（用于访问API，比如配置认证信息） |
  |help |所有命令帮助 |
  |plugin |运行一个命令行插件 |
  |version |打印客户端和服务版本信息 |

03 k8s的特性

04  集群yaml文件详解

**软件版本还需要修改，仅可查看安装流程**
# kubeadm部署方式



kubeadm是官方社区推出的一个用于快速部署kubernetes集群的工具，这个工具能通过两条指令完成一饿kubernetes集群部署：

* 第一、创建一个Master节点 kubeadm init
* 第二、将node节点加入到当前集群中 $kubeadm join <Master 节点的Ip和端口>


## 1. 要求：

1. 新建3个虚拟机Ip地址，分别代表Master、node1、node2。
2. 机器配置：Centos7.x x_86_x64。硬件配置：2G或更多Ram，2个CPU或者更多GPu，硬盘30G
3. 集群中所有机器之间网络互通，可以访问外网。
4. 要禁止SWAP分区
5. 

```shell
yum install wget
```

## 2. 准备环境
![image.png](/static/img/2ec22252063ae80a75aaee2372c1c97f.image.png)

|角色|IP|
|:---|:---|
|master|192.168.1.11|
|node1|192.168.1.12|
|node2|192.168.1.13|

```shell
# 关闭防火墙
systemctl stop firewalld
systemctl disable firewalld

# 关闭selinux
sed -i 's/enforcing/disabled/' /etc/selinue/config. # 永久
setenforce 0 # 临时

# 关闭swap
swapoff -a # 临时
sed -ri 's/.*swap.*/#$/' /etc/fstab   # 永久

# 根据规划设置主机名
hostnamectl set-hostname <hostname>


# 在master添加hosts
cat >> /etc/hosts <<EOF
192.168.44.141 master
192.168.44.142 node1
192.168.44.143 node2
EOF


# 将桥接的IPV4流量传递到iptables的链
cat > /etc/sysctl.d/k8s.confg << EOF
net.bridge.bridge-nf-call-iptables=1
net.bridge.bridge-nf-call-ip6tables=1
EOF
sysctl --system # 生效

# 时间同步
yum install ntpdate -y
ntpdate time.windows.com


```
> TODO 想想将以上的脚本写为shell，直接在三个服务中运行



## 3. 所有节点安装Docker/kubeadm/kubelet
Kubernetes默认CRI（容器运行时）为Docker，因此先安装Docker

### 3.1 安装Docker
```shell
wget https://mirros.aliyun.com/docker-ce/linux/centos/docker-ce.repo -o /etc/yum.repos.d/docker-ce.repo

yum -y install docker-ce-18.06.1.ce-3.e17
systemctl enable docker && systemctl start docker

docker --version

```
```shell
cat > /etc/docker/daemon.json << EOF
{
    "registry-mirrors":["https://b9pmyelo.mirror.aliyuncs.com"]
}
EOF


```
### 3.2 添加阿里云YUM软件源
```shell
cat > /etc/yum.repos.d/kubernetes.repo << EOF
[kubernets]
name=Kubernets
baseurl=https://mirros.aliyun.com/kubernetes/yum/repos/kubernets-el7-x86_64
enabled=1
gpgcheck=0
repo_gpgcheck=0
```

### 3.3 安装kubeadm，kubelet和kubectl
```shell
yum install -y kubelet-1.18.0 kubeadm-1.18.0 kubectl-1.18.0
systemctl enable kubelet

```
### 3.4 部署kubernets Master
在192.168.31.61（Master）执行：
```shell
kubeadm init \
--apiserver-advertises-address=192.168.44.141 \
--image-repository registry.aliyuncs.com/google_containers \
--kubernetes-version v1.18.0 \
--service-cidr=10.96.0.0/12 \
--pod-network-cidr=10.244.0.0/16

```
由于默认拉取景象地址为k8s.gcr.lo国内无法访问，这里指定阿里云镜像仓库地址。
使用kubectl工具：
```shell
mkdir -p $HOME/.kube
sudo cp -i /etc/kubernetes/admin.conf  $HOME/.kube/config
sudo chown $(id -u):$(id -g) $HOME/.kube/config

kubectl get nodes
```
### 3.5 加入kubernetes Node
在192.168.1.12/13（node）运行。
向集群添加新节点，执行在kubeadm init输出的kubeadm join明亮：
```shell
kubeadm join 192.168.1.11:6443 --token esce21.q6hetwm8si29qxwn --discovery-token-ca-cert-hash


```
默认token有效期24小时，当过期之后，该token就不可用了，这时就需要重新创建token，操作如下：
```shell
kubeadm token create --print-join-command
```

### 3.6 部署CNI网络插件
```shell
wget https://raw.githubusercontent.com/coreos/flannel/masster/Documentation/kube-flannel.yml
```
默认镜像地址无法访问，sed命令修改为docker hub镜像仓库
```shell
kubectl apply -f https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel.yml

kubectl get pods -n kube-system
```

### 3.7 测试Kubernetes集群
在Kubernetes集群中创建一个pod，验证是否正常运行：
```
kubectl create deployment nginx --imgae=nginx
kubectl expose deployment nginx --port=80 --type=NodePort
kubectl get pod.svc

```
# 二进制包部署方式
[【尚硅谷】Kubernetes（k8s）入门到实战教程丨全新升级完整版](https://www.bilibili.com/video/BV1GT4y1A756/?p=9&share_source=copy_web&vd_source=ef6c842229f8fecfc4dcb8aa804c79b8)
## 1.环境搭建（同上）
## 2.操作系统初始化（同上）
## 3. 为etcd和apiserver 自签证书
### 3.1 准备cfssl证书

02  实战：k8s两种部署方式

## 1.概述和特征
### 概述
最早在2014年google开源的
主要做的是：容器化操作



传统化部署：脚本式或者安装的方式来实现
新的方式：容器化安装，带环境安装，关键技术：docker，docker一般用于单机编排

k8s：可以管理docker，进行容器化应用部署，使用k8s利于应用扩展，
    
    目标：实施让部署容器化应用更加简洁和高效
### kubernetes的设计理念
大多数用户，希望kubernetes项目带来的体验是确定的：

我有应用的容器景象，请在一个给定的集群上把应用运行起来。此外，用户还希望kubernetes提供路由网关、水平扩展、监控、备份、灾难恢复等一系列运维能力。

**这其实就是最经典的PasS项目的能力**，用户使用docker的Compose+Swarm，完全可以自己开发出这些功能。

而kubernetes项目着重解决的问题是：

### 有哪些优势？
1. 自动装箱和回滚更新
   
   自动装箱即自我部署。Kubernetes采用滚动更新策略更新应用，一次更新一个pod，当更新过程中出现问题，Kubernetes会进行回滚更新，保证升级业务不受影响
   
3. 自我修复（自愈能力）
    
    在节点产生故障时，保证预期的副本数量不会减少，在产生故障的同时，终止健康检查失败的容器并部署新的容器，保证上线服务不会中断
    
5. 水平扩展
6. 服务发现（或者叫负载均衡）：对外提供统一接口的功能

    为多个容器提供统一的访问入口（内部IP地址和一个DNS名称），使所有的容器负载均衡，集群内应用可以通过DNS名称完成互相反问。
8. 密钥和配置管理

    kubernetes允许存储和管理敏感信息，如密码、OAuth令牌和SSh密钥。用户可以部署和更新机密和应用程序配置，而无须重建容器镜像，也不会在堆栈配置中暴露机密。
10. 存储编排

    Kubernetes挂载外部存储系统，将这些存储作为集群资源的一部分来使用，增强存储使用的灵活性。

12. 弹性伸缩

    kubernetes可以使用命令或基于CPU使用情况自动快速扩容和缩容应用程序，保证在高峰期的高可用性和业务低档期回收资源，降低运行成本
14. 提供认证和授权

    控制用户是否有权限使用API进行操作，精细化权限分配
16. 资源监控
    
    工作节点纪恒Advisor资源收集工具，可以快速实现对集群资源的监控
## 2.k8s架构组件
1. Master组件：主控节点

    * apiserver：集群统一入口，以restful方式，交给etcd存储
    * scheduler：节点的调度，选择node节点应用部署
    * controller-manager：处理集群中常规后台任务，一个资源对应一个控制器
    * etcd：存储，用于保存集群中各种数据，例如状态数据等。
3. Node组件：工作节点
    
    * kuberlet；master派到node节点代表，管理本机容器
    * kube-proxy：提供网络代理，负载均衡等操作。
    * docker

## 3.k8s核心概念
### pod
* pod是k8s中最小的部署单元，一组容器的集合
* 1个pod中的容器是共享网络的
* 生命周期是短暂的，重启之后就找不到了。
* 一组pod叫做命名空间
### Controlller
* 确保预期的pod副本数量
* 无状态的应用部署：有两个节点，其中1个节点故障，其节点中的容器可以移到另一个节点中直接用。随便用
* 有状态的应用部署：需要依赖存储，网络ip要唯一。有状态是必须要在特定条件下才能用
* 确保所有的node运行同一个pod
* 一次性任务和定时任务

### Service
* 定义一组pod的访问规则


## 4. 搭建k8s集群
### 搭建k8s环境平台规划
1. 单master集群

![image.png](https://www.choumaomi.com/static/img/b0dd4ebc9786983867eaaa6bb9e8cc14.image.png)

2. 多master集群（也可以叫做：高可用集群）
![image.png](https://www.choumaomi.com/static/img/3c208e240172c45d273b2dc60cfdfb74.image.png)

### 服务器硬件配置要求
* 测试环境：

![image.png](https://www.choumaomi.com/static/img/7e7e3c271c8ebdf127142f93b76d3a1b.image.png)
* 正式环境：更高要求


### 搭建k8s集群部署方式
* kubeadm
Kubeadm是一个K8s部署工具，提供kubeadm init和kubeadm join，用于快速部署kubernetes集群


* 二进制包
从github下载发行版的二进制包，手动部署每个组件，组成Kubernetes集群。可以学习很多工作原理，有利于后期维护

01  k8s简介

## 1. 什么是restful？
    
rest全称是Representational  State Transfer  ，中文意识是表述性状态转移。作者曾在他的论文中提到：“我这篇文章的写作目的，就是想在符合架构原理的前提下，理解和评估以网络为基础的应用软件的架构设计，

得到一个功能强，性能好、适宜通信的架构”，REST指的是一组交约束条件和原则，如果一个架构符合REST的约束条件和原则，我们就称它为RESTful架构。



## 2. 理解RESTful？
    
要理解RESTFUl架构，需要理解Representational  State Transfer这个词组到底是什么意思，它的每一个词都有些什么涵义。

下面我们结合REST原则，围绕资源展开讨论，从`资源的定义`、`获取`、`表述`、`关联`、`状态变迁`等角度，列举一些关键概念并加以解释。

* 资源与URI
* 统一资源接口
* 资源的表述
* 资源的链接
* 状态的转移

### 2.1 资源与URI

REST全称是表述性状态转移，指的就是资源。任何事物，只要有被引用到的必要，它就是一个资源，资源可以是实体（例如手机号码），也可以只是一个抽象的概念（例如价值）。下面是一些资源的例子：
* 某用户的手机号码
* 某用户的个人信息
* 最多用户订购的GPRS套餐
* 两个产品之间的依赖关系
* 某用户可以办理的优惠套餐
* 某手机号码的潜在价值

要让一个资源可以被识别 ，需要一个唯一标识，在web中这个唯一标识就是URI（uniform Resource Identifier）。

urI既可以看成是资源的地址，也可以看成是资源的名称。如果某些信息没有使用URI来标识，那它就不算是一个资源，只能算是资源的一些 信息而已。

URI的设计应该遵循 `可寻址性原则，具有描述性`，需要在形式上给人以直觉上的关联。这里以GitHub网站为例，给出一些还算不错的URI：
```
* https://github.com/git
* https://github.com/git/git
* https://github.com/git/git/blob/master/block-sha1/sha1.h
* https://github.com/git/git/commit/e3af72cdafab5993d18fae056f87e1d675913d08
* https://github.com/git/git/pulls
* https://github.com/git/git/pulls?state=closed
* https://github.com/git/git/compare/master…next 
```
下面我们来看看URI设计上的一些技巧：
* 使用_或-来让URI可读性更好
* 使用/来标识资源的层级关系
* 使用?用来过滤器

很多人只是把？简单的当做是参数的传递，很容易造成URI过于复杂、难以理解。可以把？用于对资源的过滤，例如
- /git/git/pulls  用来表示git项目的所有推入请求，
- 而/pull?state=closed用来表示git项目中已经关闭的推入请求，这种url通常对应的是一些特定条件的查询结果或算法运算结果。
- ,或；用来表示同级资源的关系

### 2.2 统一资源接口
RESTful架构应该遵循统一接口规则，统一接口包含了一组受限的预定义的操作，不论什么样的资源，都是通过使用相同的接口进行资源的访问。

接口应该使用标准的HTTPs方法如Get、PUT、和post，并遵循这些方法的语义。
            
如果按照http方法的语义来暴露资源。那么接口将会拥有安全性和幂等性的特性。

例如
- Get和Head请求都是安全的，无论请求多少次，都不会改变服务器的状态。
- 而Get、Head、Put和Delete请求都是幂等的，无论对资源操作多少次，结果总是一样的，后面的请求 并不会产生比第一次更多的影响。  


下面列出了GET，DELETE，PUT和POST的典型用法:
    
    ### HTTP 方法与状态码对照

| **HTTP 方法** | **描述** | **常见状态码** | **含义** |
|---------------|----------|----------------|----------|
| **GET**       | 安全且幂等。用于获取资源。 | 200（OK） | 资源已在响应中返回。 |
|               |          | 204（No Content） | 资源无内容。 |
|               |          | 301（Moved Permanently） | 资源的 URI 已更新。 |
|               |          | 303（See Other） | 重定向到其他位置（如负载均衡）。 |
|               |          | 304（Not Modified） | 资源未更改（使用缓存）。 |
|               |          | 400（Bad Request） | 请求参数错误。 |
|               |          | 404（Not Found） | 资源不存在。 |
|               |          | 406（Not Acceptable） | 服务端不支持所请求的表示。 |
|               |          | 500（Internal Server Error） | 服务器内部错误。 |
|               |          | 503（Service Unavailable） | 服务不可用，暂时无法处理请求。 |
| **POST**      | 不安全且不幂等。用于创建资源或部分更新。 | 200（OK） | 现有资源已更改。 |
|               |          | 201（Created） | 新资源已被创建。 |
|               |          | 202（Accepted） | 请求已接受，但尚未完成（异步处理）。 |
|               |          | 301（Moved Permanently） | 资源的 URI 已更新。 |
|               |          | 303（See Other） | 重定向到其他位置。 |
|               |          | 400（Bad Request） | 请求参数错误。 |
|               |          | 404（Not Found） | 资源不存在。 |
|               |          | 406（Not Acceptable） | 服务端不支持所请求的表示。 |
|               |          | 409（Conflict） | 请求存在冲突。 |
|               |          | 412（Precondition Failed） | 前置条件失败（如乐观锁冲突）。 |
|               |          | 415（Unsupported Media Type） | 请求的媒体类型不被支持。 |
|               |          | 500（Internal Server Error） | 服务器内部错误。 |
|               |          | 503（Service Unavailable） | 服务不可用，暂时无法处理请求。 |
| **PUT**       | 不安全但幂等。用于更新资源。 | 200（OK） | 现有资源已更改。 |
|               |          | 201（Created） | 新资源已被创建。 |
|               |          | 301（Moved Permanently） | 资源的 URI 已更新。 |
|               |          | 303（See Other） | 重定向到其他位置。 |
|               |          | 400（Bad Request） | 请求参数错误。 |
|               |          | 404（Not Found） | 资源不存在。 |
|               |          | 406（Not Acceptable） | 服务端不支持所请求的表示。 |
|               |          | 409（Conflict） | 请求存在冲突。 |
|               |          | 412（Precondition Failed） | 前置条件失败（如乐观锁冲突）。 |
|               |          | 415（Unsupported Media Type） | 请求的媒体类型不被支持。 |
|               |          | 500（Internal Server Error） | 服务器内部错误。 |
|               |          | 503（Service Unavailable） | 服务不可用，暂时无法处理请求。 |
| **DELETE**    | 不安全但幂等。用于删除资源。 | 200（OK） | 资源已删除。 |
|               |          | 301（Moved Permanently） | 资源的 URI 已更新。 |
|               |          | 303（See Other） | 重定向到其他位置。 |
|               |          | 400（Bad Request） | 请求参数错误。 |
|               |          | 404（Not Found） | 资源不存在。 |
|               |          | 409（Conflict） | 请求存在冲突。 |
|               |          | 500（Internal Server Error） | 服务器内部错误。 |
|               |          | 503（Service Unavailable） | 服务不可用，暂时无法处理请求。 |
   

#### 实践中常见问题
1. `POST和PUT用于创建资源时有什么区别?`

    POST和PUT在创建资源的区别在于，所创建的资源的名称(URI)是否由客户端决定。 例如为我的博文增加一个java的分类，生成的路径就是分类名/categories/java，那么就可以采用PUT方法。
    ___
    不过很多人直接把POST、GET、PUT、DELETE直接对应上CRUD，例如在一个典型的rails实现的RESTful应用中就是这么做的。 我认为，这是因为rails默认使用服务端生成的ID作为URI的缘故，而不少人就是通过rails实践REST的，所以很容易造成这种误解。

2. `客户端不一定都支持这些HTTP方法吧?`
    
    的确有这种情况，特别是一些比较古老的基于浏览器的客户端，只能支持GET和POST两种方法。 在实践上，客户端和服务端都可能需要做一些妥协。
    ___
    例如rails框架就支持通过隐藏参数_method=DELETE来传递真实的请求方法， 而像Backbone这样的客户端MVC框架则允许传递_method传输和设置X-HTTP-Method-Override头来规避这个问题。

3. `统一接口是否意味着不能扩展带特殊语义的方法?`

    统一接口并不阻止你扩展方法，只要方法对资源的操作有着具体的、可识别的语义即可，并能够保持整个接口的统一性。 像WebDAV就对HTTP方法进行了扩展，增加了LOCK、UPLOCK等方法。而github的API则支持使用PATCH方法来进行issue的更新，
    ___
    例如: `PATCH /repos/:owner/:repo/issues/:number`。不过，需要注意的是，像PATCH这种不是HTTP标准方法的，服务端需要考虑客户端是否能够支持的问题。


4. `统一资源接口对URI有什么指导意义?`

    统一资源接口要求使用标准的HTTP方法对资源进行操作，所以URI只应该来表示资源的名称，而不应该包括资源的操作。 通俗来说，URI不应该使用动作来描述。例如，下面是一些不符合统一接口要求的URI:
    ```
    GET /getUser/1
    POST /createUser
    PUT /updateUser/1
    DELETE /deleteUser/1
    ```
5. `如果GET请求增加计数器，这是否违反安全性?`

    安全性不代表请求不产生副作用，例如像很多API开发平台，都对请求流量做限制。像github，就会限制没有认证的请求每小时只能请求60次。 
    ___
    但客户端不是为了追求副作用而发出这些GET或HEAD请求的，产生副作用是服务端“自作主张”的。 另外，服务端在设计时，也不应该让副作用太大，因为客户端认为这些请求是不会产生副作用的。
6. `直接忽视缓存可取吗?`

    即使你按各个动词的原本意图来使用它们，你仍可以轻易禁止缓存机制。 最简单的做法就是在你的HTTP响应里增加这样一个报头： Cache-control: no-cache。
    ___
    但是，同时你也对失去了高效的缓存与再验证的支持(使用Etag等机制)。 对于客户端来说，在为一个REST式服务实现程序客户端时，也应该充分利用现有的缓存机制，以免每次都重新获取表示。
7. `响应代码的处理有必要吗?`

    HTTP的响应代码可用于应付不同场合，正确使用这些状态代码意味着客户端与服务器可以在一个具备较丰富语义的层次上进行沟通。 例如，201（“Created”）响应代码表明已经创建了一个新的资源，其URI在Location响应报头里。 
    ___
    假如你不利用HTTP状态代码丰富的应用语义，那么你将错失提高重用性、增强互操作性和提升松耦合性的机会。 如果这些所谓的RESTful应用必须通过响应实体才能给出错误信息，那么SOAP就是这样的了，它就能够满足了。

## 3. 资源的表述

上面提到，客户端通过HTTP方法可以获取资源，是吧? 不，确切的说，客户端获取的只是资源的表述而已。 

资源在外界的具体呈现，可以有多种表述(或成为表现、表示)形式，在客户端和服务端之间传送的也是资源的表述，而不是资源本身。 

例如文本资源可以采用html、xml、json等格式，图片可以使用PNG或JPG展现出来。 资源的表述包括数据和描述数据的元数据，例如，HTTP头“Content-Type” 就是这样一个元数据属性。
　　

### 3.1 客户端如何知道服务端提供哪种表述形式呢?
答案是可以通过HTTP内容协商，客户端可以通过`Accept头`请求一种特定格式的表述，服务端则通过`Content-Type`告诉客户端资源的表述形式。

以github为例，请求某组织资源的json格式的表述形式:

假如github也能够支持xml格式的表述格式，那么结果就是这样的:

下面我们来看一些实践上常见的设计: 在URI里边带上版本号, 有些API在URI里边带上版本号，

例如:
```
http://api.example.com/1.0/foo
http://api.example.com/1.2/foo
http://api.example.com/2.0/foo
```

如果我们把版本号理解成资源的不同表述形式的话，就应该只是用一个URL，并通过Accept头部来区分，还是以github为例，它的Accept的完整格式是:
```
application/vnd.github[.version].param[+json]
```

对于v3版本的话，就是`Accept: application/vnd.github.v3`。对于上面的例子，同理可以使用使用下面的头部:
```
Accept: vnd.example-com.foo+json; version=1.0
Accept: vnd.example-com.foo+json; version=1.2
Accept: vnd.example-com.foo+json; version=2.0
```

### 3.2 使用URI后缀来区分表述格式
像rails框架，就支持使用/users.xml或/users.json来区分不同的格式。 这样的方式对于客户端来说，无疑是更为直观，但混淆了资源的名称和资源的表述形式。

我个人认为，还是应该优先使用内容协商来区分表述格式。
　　
### 3.3 如何处理不支持的表述格式
当服务器不支持所请求的表述格式，那么应该怎么办？

若服务器不支持，它应该返回一个`HTTP 406响应`，表示拒绝处理该请求。

## 4. 资源的链接
我们知道REST是使用标准的HTTP方法来操作资源的，但仅仅因此就理解成带CURD的Web数据库架构就太过于简单了。 

这种反模式忽略了一个核心概念：`“超媒体即应用状态引擎（hypermedia as the engine of application state）”`。 超媒体是什么? 当你浏览Web网页时，从一个连接跳到一个页面，再从另一个连接跳到另外一个页面，就是利用了超媒体的概念：`把一个个把资源链接起来`.

要达到这个目的，就要求在表述格式里边加入链接来引导客户端。在《RESTful Web Services》一书中，作者把这种具有链接的特性成为连通性。下面我们具体来看一些例子。

下面展示的是github获取某个组织下的项目列表的请求，可以看到在响应头里边增加Link头告诉客户端怎么访问下一页和最后一页的记录。 而在响应体里边，用url来链接项目所有者和项目地址。

又例如下面这个例子，创建订单后通过链接引导客户端如何去付款。


上面的例子展示了如何使用超媒体来增强资源的连通性。很多人在设计RESTful架构时，使用很多时间来寻找漂亮的URI，而忽略了超媒体。所以，应该多花一些时间来给资源的表述提供链接，而不是专注于“资源的CRUD”。

## 5. 状态的转移
有了上面的铺垫，再讨论REST里边的状态转移就会很容易理解了。 不过，我们先来讨论一下REST原则中的无状态通信原则。初看一下，好像自相矛盾了，既然无状态，何来状态转移一说?

其实，这里说的无状态通信原则，并不是说客户端应用不能有状态，而是指服务端不应该保存客户端状态。

### 5.1 应用状态与资源状态
实际上，状态应该区分`应用状态`和`资源状态`，客户端负责维护应用状态，而服务端维护资源状态。 

客户端与服务端的交互必须是无状态的，并在每一次请求中包含处理该请求所需的一切信息。 

服务端不需要在请求间保留应用状态，只有在接受到实际请求的时候，服务端才会关注应用状态。 

这种无状态通信原则，使得服务端和中介能够理解独立的请求和响应。 在多次请求中，同一客户端也不再需要依赖于同一服务器，方便实现高可扩展和高可用性的服务端。

但有时候我们会做出违反无状态通信原则的设计，例如利用Cookie跟踪某个服务端会话状态，常见的像J2EE里边的JSESSIONID。 

这意味着，浏览器随各次请求发出去的Cookie是被用于构建会话状态的。 当然，如果Cookie保存的是一些服务器不依赖于会话状态即可验证的信息（比如认证令牌），这样的Cookie也是符合REST原则的。

### 5.2 应用状态的转移
状态转移到这里已经很好理解了， “会话”状态不是作为资源状态保存在服务端的，而是被客户端作为应用状态进行跟踪的。

客户端应用状态在服务端提供的超媒体的指引下发生变迁。服务端通过超媒体告诉客户端当前状态有哪些后续状态可以进入。 这些类似“下一页”之类的链接起的就是这种推进状态的作用——指引你如何从当前状态进入下一个可能的状态。

## 6. 总结

现在广东XXX版本、XXX等项目中均使用传统的RPC、SOAP方式的Web服务，而移动南方基地XXXX项目的后台， 虽然采用了JSON格式进行交互，但还是属于RPC风格的。本文从资源的定义、获取、表述、关联、状态变迁等角度， 试图快速理解RESTful架构背后的概念。RESTful架构与传统的RPC、SOAP等方式在理念上有很大的不同，希望本文能对各位理解REST有所帮助。

1.kubernetes 集群网络体系

1. yaml文件概述

kubeadm部署方式

1.概述和特征

概述

1. 什么是restful？