摘要

本文介绍k8s集群管理命令Kubectl分类和命令详解。

内容

1. kubectl命令列表分类

（1）Basic Commands(Beginner)基础命令（初级）

kubectl create  通过yaml/json 文件或者标准输入创建一个资源对象，支持很多子命令 例如namespace pod deployment service等
kubectl expose  将json/yaml文件中定义的资源对象的端口暴露给新的service资源对象
kubectl run 创建并运行一个或多个容器镜像
kubectl set 配置资源对象设置特定功能

（2）Basic Commands（Intermediate）基础命令（中级）

kubectl explain 查看资源对象的详细信息(一般用一编写yaml的时候做一个提示 kubectl explain deployment 会出现deployment下面可以写的字段以及字段属性还有 可以逐级使用)
kubectl get 获取一个或多个资源对象的信息
kubectl edit    使用默认编辑器编辑服务器上定义的资源对象
kubectl delete  通过json/yaml文件、标准舒服、资源名称或标签选择器来删除资源

（3）DeployCommands 部署命令

kubectl rollout 资源管理对象的部署
kubectl rollout-update  使用rc（replication controller）来做滚动恩星
kubectl scale   扩容或者缩容deployment replicaset replication contrller等
kubectl autoscale   自动设置在k8s系统中运行的pod数量（水平自动伸缩）

（4）Cluster Manager Commands 集群管理命令

kubectl cetificate  修改证书资源对象
kubectl cluster-info    查看集群信息
kubectl top 显示资源 cpu 内存 存储使用情况
kubectl cordon  标记节点为不可调度
kubectl uncordon    指定节点为可调度
kubectl drain   安全的驱逐节点的所有pod
kubectl taint   将一个或多个节点设置为污点

（5）Troubleshooting adn Debugging Commands 故障排查和调试命令

kubectl describe    显示一个或多个资源对象的详细信息
kubectl logs    输出pod资源对象中一个容器的日志
kubectl attach  连接到一个运行的容器
kubectl exec    在指定容器内执行命令
kubectl port-forward    将本机指定端口映射到pod资源对象的端口
kubectl proxy   将本机指定端口映射到kube-apiserver
kubectl cp  用于pod与主机交换文件
kubectl auth    检查验证

（6） Advanced Commands 高级命令

kubectl diff    对比本地json/yaml文件与kube-apiserver中运行的配置文件是否有差异
kubectl apply   通过json/yaml文件 标准输入对资源进行配置更新或者创建
kubectl patch   通过patch方式修改资源对象字段（补丁式）
kubectl replace 通过json/yaml文件或者标准输入来替换资源对象
kubectl wait    在一个或者多个资源上等待条件达成
kubectl convert 转换json/yaml文件为不同的资源版本
kubectl kustomize   定制kubernetes配置

（7）Settings Commands 设置命令

kubectl label   增删改资源的标签
kubectl annotate    更新一个或者多个资源对象的注释（annotaion）信息
kubectl completion  命令自动补全

（8）Other Commands 其他命令

kubectl config  管理kubeconfig配置文件
kubectl plugin  运行命令行插件功能
kubectl version 查看客户端服务端的系统版本信息
kubectl api-versions    列出当前kubernetes系统支持的资源组和资源版本表现形式为/
kubectl api-resources   列出当前kubernetes系统支持的resource资源列表
kubectl options 查看支持的参数列表

2. Basic Commands(Beginner)基础命令（初级）

（1）kubectl create

通过配置文件名或stdin创建一个集群资源对象。 支持JSON和YAML格式的文件。

语法

$ create -f FILENAME

示例 通过pod.json文件创建一个pod。

kubectl create -f ./pod.json

通过stdin的JSON创建一个pod。

cat pod.json | kubectl create -f -

API版本为v1的JSON格式的docker-registry.yaml文件创建资源。

kubectl create -f docker-registry.yaml --edit --output-version=v1 -o json

（2）kubectl expose

将资源暴露为新的Kubernetes Service。 指定deployment、service、replica set、replication controller或pod ，并使用该资源的选择器作为指定端口上新服务的选择器。deployment 或 replica set只有当其选择器可转换为service支持的选择器时，即当选择器仅包含matchLabels组件时才会作为暴露新的Service。 资源包括(不区分大小写)： pod（po），service（svc），replication controller（rc），deployment（deploy），replica set（rs）。

语法

$ expose (-f FILENAME | TYPE NAME) [--port=port] [--protocol=TCP|UDP] [--target-port=number-or-name] [--name=name] [--external-ip=external-ip-of-service] [--type=type]

示例

为RC的nginx创建service，并通过Service的80端口转发至容器的8000端口上。

kubectl expose rc nginx --port=80 --target-port=8000

由“nginx-controller.yaml”中指定的type和name标识的RC创建Service，并通过Service的80端口转发至容器的8000端口上。

kubectl expose -f nginx-controller.yaml --port=80 --target-port=8000

其它详细说明

Name	Shorthand	Default	Usage
allow-missing-template-keys		true	If true, ignore any errors in templates when a field or map key is missing in the template. Only applies to golang and jsonpath output formats.
cluster-ip			ClusterIP to be assigned to the service. Leave empty to auto-allocate, or set to ‘None’ to create a headless service.
container-port			Synonym for –target-port
dry-run		false	If true, only print the object that would be sent, without sending it.
external-ip			Additional external IP address (not managed by Kubernetes) to accept for the service. If this IP is routed to a node, the service can be accessed by this IP in addition to its generated service IP. 用于接受服务的额外的外部IP地址(不被kubernetes管理)。如果这个IP被路由到一个节点，则这个服务处理被它产生的service IP接入外，还可以被这个IP接入。
filename	f	[]	Filename, directory, or URL to files identifying the resource to expose a service
generator		service/v2	The name of the API generator to use. There are 2 generators: ‘service/v1’ and ‘service/v2’. The only difference between them is that service port in v1 is named ‘default’, while it is left unnamed in v2. Default is ‘service/v2’.
labels	l		Labels to apply to the service created by this call.
load-balancer-ip			IP to assign to the Load Balancer. If empty, an ephemeral IP will be created and used (cloud-provider specific).
name			The name for the newly created object.
no-headers		false	When using the default or custom-column output format, don’t print headers (default print headers).
output	o		Output format. One of: json|yaml|wide|name|custom-columns=…|custom-columns-file=…|go-template=…|go-template-file=…|jsonpath=…|jsonpath-file=… See custom columns [http://kubernetes.io/docs/user-guide/kubectl-overview/#custom-columns], golang template [http://golang.org/pkg/text/template/#pkg-overview] and jsonpath template [http://kubernetes.io/docs/user-guide/jsonpath].
output-version			DEPRECATED: To use a specific API version, fully-qualify the resource, version, and group (for example: ‘jobs.v1.batch/myjob’).
overrides			An inline JSON override for the generated object. If this is non-empty, it is used to override the generated object. Requires that the object supply a valid apiVersion field.
port			The port that the service should serve on. Copied from the resource being exposed, if unspecified
protocol			The network protocol for the service to be created. Default is ‘TCP’.
record		false	Record current kubectl command in the resource annotation. If set to false, do not record the command. If set to true, record the command. If not set, default to updating the existing annotation value only if one already exists.
recursive	R	false	Process the directory used in -f, –filename recursively. Useful when you want to manage related manifests organized within the same directory.
save-config		false	If true, the configuration of current object will be saved in its annotation. Otherwise, the annotation will be unchanged. This flag is useful when you want to perform kubectl apply on this object in the future.
selector			A label selector to use for this service. Only equality-based selector requirements are supported. If empty (the default) infer the selector from the replication controller or replica set.)
session-affinity			If non-empty, set the session affinity for the service to this; legal values: ‘None’, ‘ClientIP’
show-all	a	false	When printing, show all resources (default hide terminated pods.)
show-labels		false	When printing, show all labels as the last column (default hide labels column)
sort-by			If non-empty, sort list types using this field specification. The field specification is expressed as a JSONPath expression (e.g. ‘{.metadata.name}’). The field in the API resource specified by this JSONPath expression must be an integer or a string.
target-port			Name or number for the port on the container that the service should direct traffic to. Optional.
template			Template string or path to template file to use when -o=go-template, -o=go-template-file. The template format is golang templates [http://golang.org/pkg/text/template/#pkg-overview].
type			Type for this service: ClusterIP, NodePort, or LoadBalancer. Default is ‘ClusterIP’.

（3）kubectl run

（4）kubectl set 配置资源对象设置特定功能

配置应用资源。 使用这些命令能帮你更改现有应用资源一些信息。

语法

$ set SUBCOMMAND

子命令 image resources selector subject

3. Basic Commands（Intermediate）基础命令（中级）

（1）kubectl explain

（2）kubectl get

语法

kubectl get resource_name

常见resource_name

all
certificatesigningrequests (缩写 csr)
clusterrolebindings
clusterrol
componentstatuses (缩写 cs)
configmaps (缩写 cm)
controllerrevisions
cronjobs
customresourcedefinition (缩写 crd)
daemonsets (缩写 ds)
deployments (缩写 deploy)
endpoints (缩写 ep)
events (缩写 ev)
horizontalpodautoscalers (缩写 hpa)
ingresses (缩写 ing)
jobs
limitranges (缩写 limits)
namespaces (缩写 ns)
networkpolicies (缩写 netpol)
nodes (缩写 no)
persistentvolumeclaims (缩写 pvc)
persistentvolumes (缩写 pv)
poddisruptionbudgets (缩写 pdb)
podpreset
pods (缩写 po)
podsecuritypolicies (缩写 psp)
podtemplates
replicasets (缩写 rs)
replicationcontrollers (缩写 rc)
resourcequotas (缩写 quota)
rolebindings
roles
secrets
serviceaccounts (缩写 sa)
services (缩写 svc)
statefulsets (缩写 sts)
storageclasses (缩写 sc)

其它可选参数 用不同的格式查看：

 -o wide/yaml/json

看指定标签的pods，支持’=’, ‘==’, and ‘!=’操作符

-l key=value

举例

# 查看Master状态
kubectl get componentstatuses
 
# 查看所有命名空间
kubectl get namespaces
 
# 列出所有的pods
kubectl get pods
 
# 显示更多的pods列表信息(例如 pod的ip和所处的node)
kubectl get pods -o wide
 
# 列出名字为web的rc
kubectl get replicationcontroller web
 
# 获取名字为web-pod-13je7的pod的信息，并以json格式输出
kubectl get -o json pod web-pod-13je7
 
# 根据pod文件查找pod，并以json格式输出
kubectl get -f pod.yaml -o json
 
# 获取pod容器的状态
kubectl get -o template pod/kube-dns-795f5f6f9c-ldxxs --template {{.status.phase}}
 
# 同时获取所有的rc和service
kubectl get rc,services
 
# 获取符合条件的所有rc,svc,pod
kubectl get rc/web service/frontend pods/web-pod-13je7
 
# 获取所有resource
kubectl get all

（3）kubectl edit

使用默认编辑器 编辑服务器上定义的资源。 使用命令行工具获取的任何资源都可以使用edit命令编辑。edit命令会打开使用KUBE_EDITOR，GIT_EDITOR 或者EDITOR环境变量定义的编辑器，可以同时编辑多个资源，但所编辑过的资源只会一次性提交。edit除命令参数外还接受文件名形式。 文件默认输出格式为YAML。要以JSON格式编辑，请指定“-o json”选项。 如果在更新资源时报错，将会在磁盘上创建一个临时文件来记录。在更新资源时最常见的错误是几个用户同时使用编辑器更改服务器上资源，发生这种情况，你需要将你的更改应用到最新版本的资源上，或者更新保存的临时副本。

语法

$ edit (RESOURCE/NAME | -f FILENAME)

示例 编辑名为’docker-registry’的service：

kubectl edit svc/docker-registry

使用替代的编辑器

KUBE_EDITOR="nano" kubectl edit svc/docker-registry

编辑名为“myjob”的service，输出JSON格式 V1 API版本

kubectl edit job.v1.batch/myjob -o json

以YAML格式输出编辑deployment“mydeployment”，并将修改的配置保存在annotation中：

kubectl edit deployment/mydeployment -o yaml --save-config

（4）kubectl delete

通过配置文件名、stdin、资源名称或label选择器来删除资源。 支持JSON和YAML格式文件。可以只指定一种类型的参数：文件名、资源名称或label选择器。

有些资源，如pod，支持优雅的（graceful）删除，因为这些资源一般是集群中的实体，所以删除不可能会立即生效，这些资源在强制终止之前默认定义了一个周期（宽限期），但是你可以使用–grace-period flag来覆盖该值，或者通过pass –now设置该周期为1。 如果托管Pod的Node节点已经停止或者无法连接API Server，使用delete命令删除Pod需等待时间更长。要强制删除资源，需指定- force flag，且设置周期（宽限期）为0。 如果执行强制删除Pod，则调度程序会在节点释放这些Pod之前将新的Pod放在这些节点上，并使之前Pod立即被逐出。

注意：执行delete命令时不会检查资源版本，如果在执行delete操作时有人进行了更新操作，那么更新操作将连同资源一起被删除。

语法

$ delete ([-f FILENAME] | TYPE [(NAME | -l label | --all)])

示例 使用 pod.json中指定的资源类型和名称删除pod。

kubectl delete -f ./pod.json

根据传入stdin的JSON所指定的类型和名称删除pod。

cat pod.json | kubectl delete -f -

删除名为“baz”和“foo”的Pod和Service。

kubectl delete pod,service baz foo

删除 Label name = myLabel的pod和Service。

kubectl delete pods,services -l name=myLabel

强制删除dead node上的pod

kubectl delete pod foo --grace-period=0 --force

删除所有pod

kubectl delete pods --all

Flags

Name	Shorthand	Default	Usage
all		false	select all resources in the namespace of the specified resource types.
cascade		true	If true, cascade the deletion of the resources managed by this resource (e.g. Pods created by a ReplicationController). Default true.
filename	f	[]	Filename, directory, or URL to files containing the resource to delete.
force		false	Immediate deletion of some resources may result in inconsistency or data loss and requires confirmation.
grace-period		-1	Period of time in seconds given to the resource to terminate gracefully. Ignored if negative.
ignore-not-found		false	Treat “resource not found” as a successful delete. Defaults to “true” when –all is specified.
include-extended-apis		true	If true, include definitions of new APIs via calls to the API server. [default true]
now		false	If true, resources are signaled for immediate shutdown (same as –grace-period=1).
output	o		Output mode. Use “-o name” for shorter output (resource/name).
recursive	R	false	Process the directory used in -f, –filename recursively. Useful when you want to manage related manifests organized within the same directory.
selector	l		Selector (label query) to filter on.
timeout		0s	The length of time to wait before giving up on a delete, zero means determine a timeout from the size of the object

4. DeployCommands 部署命令

（1）kubectl rollout

对资源进行管理，可用资源包括： deployments daemonsets

子命令

• history（查看历史版本）
• pause（暂停资源）
• resume（恢复暂停资源）
• status（查看资源状态）
• undo（回滚版本）

语法

$ rollout SUBCOMMAND

示例 回滚到之前的deployment

kubectl rollout undo deployment/abc

查看daemonet的状态

kubectl rollout status daemonset/foo

[1] kubectl rollout history

查看之前推出的版本（历史版本）。

语法

$ history (TYPE NAME | TYPE/NAME) [flags]

示例 查看deployment的历史记录

kubectl rollout history deployment/abc

查看daemonset修订版3的详细信息

kubectl rollout history daemonset/abc --revision=3

[2] kubectl rollout pause

将提供的资源标记为暂停,被pause命令暂停的资源不会被控制器协调使用，可以是“kubectl rollout resume”命令恢复已暂停资源。 目前仅支持的资源：deployments。

语法

$ pause RESOURCE

示例 将deployment标记为暂停。＃只要deployment在暂停中，使用deployment更新将不会生效。

kubectl rollout pause deployment/nginx

[3] kubectl rollout resume

恢复已暂停的资源

被pause命令暂停的资源将不会被控制器协调使用。可以通过resume来恢复资源。目前仅支持恢复deployment资源。

语法

$ resume RESOURCE

示例 恢复已暂停的 deployment

kubectl rollout resume deployment/nginx

[4] kubectl rollout status

查看资源的状态。

使用—watch = false 来查看当前状态，需要查看特定修订版本状态 请使用–revision = N 来指定。

语法

$ status (TYPE NAME | TYPE/NAME) [flags]

示例 查看deployment的状态

kubectl rollout status deployment/nginx

[5] kubectl rollout undo

回滚到之前的版本。

语法

$ undo (TYPE NAME | TYPE/NAME) [flags]

示例 回滚到之前的deployment版本

kubectl rollout undo deployment/abc
kubectl rollout undo --dry-run=true deployment/abc

回滚到daemonset 修订3版本

kubectl rollout undo daemonset/abc --to-revision=3

（2）kubectl rollout-update

（3）kubectl scale

扩容或缩容 Deployment、ReplicaSet、Replication Controller或 Job 中Pod数量。 scale也可以指定多个前提条件，如：当前副本数量或 –resource-version ，进行伸缩比例设置前，系统会先验证前提条件是否成立。

语法

scale [--resource-version=version] [--current-replicas=count] --replicas=COUNT (-f FILENAME | TYPE NAME)

示例 将名为foo中的pod副本数设置为3。

kubectl scale --replicas=3 rs/foo

将由“foo.yaml”配置文件中指定的资源对象和名称标识的Pod资源副本设为3。

kubectl scale --replicas=3 -f foo.yaml

如果当前副本数为2，则将其扩展至3。

kubectl scale --current-replicas=2 --replicas=3 deployment/mysql

设置多个RC中Pod副本数量。

kubectl scale --replicas=5 rc/foo rc/bar rc/baz

选项

Name	Shorthand	Default	Usage
current-replicas		-1	Precondition for current size. Requires that the current size of the resource match this value in order to scale.
filename	f	[]	Filename, directory, or URL to files identifying the resource to set a new size
include-extended-apis		true	If true, include definitions of new APIs via calls to the API server. [default true]
output	o		Output mode. Use “-o name” for shorter output (resource/name).
record		false	Record current kubectl command in the resource annotation. If set to false, do not record the command. If set to true, record the command. If not set, default to updating the existing annotation value only if one already exists.
recursive	R	false	Process the directory used in -f, –filename recursively. Useful when you want to manage related manifests organized within the same directory.
replicas		-1	The new desired number of replicas. Required.
resource-version			Precondition for resource version. Requires that the current resource version match this value in order to scale.
timeout		0s	The length of time to wait before giving up on a scale operation, zero means don’t wait. Any other values should contain a corresponding time unit (e.g. 1s, 2m, 3h).

（4）kubectl autoscale

5. Cluster Manager Commands 集群管理命令

（1）kubectl cetificate

修改证书资源对象

（2）kubectl cluster-info

查看集群信息

（3）kubectl top

显示资源 cpu 内存 存储使用情况

（4）kubectl cordon

标记节点为不可调度

（5）kubectl uncordon

指定节点为可调度

（6）kubectl drain

安全的驱逐节点的所有pod

（7）kubectl taint（污点和容忍）

Taint（污点）和 Toleration（容忍）可以作用于 node 和 pod 上，其目的是优化 pod 在集群间的调度，这跟节点亲和性类似，只不过它们作用的方式相反，具有 taint 的 node 和 pod 是互斥关系，而具有节点亲和性关系的 node 和 pod 是相吸的。另外还有可以给 node 节点设置 label，通过给 pod 设置 nodeSelector 将 pod 调度到具有匹配标签的节点上。

Taint 和 toleration 相互配合，可以用来避免 pod 被分配到不合适的节点上。每个节点上都可以应用一个或多个 taint ，这表示对于那些不能容忍这些 taint 的 pod，是不会被该节点接受的。如果将 toleration 应用于 pod 上，则表示这些 pod 可以（但不要求）被调度到具有相应 taint 的节点上。

以下分别以为 node 设置 taint 和为 pod 设置 toleration 为例。

为 node 设置 taint

kubectl taint nodes node1 key1=value1:NoSchedule
kubectl taint nodes node1 key1=value1:NoExecute
kubectl taint nodes node1 key2=value2:NoSchedule

删除上面的 taint：

kubectl taint nodes node1 key1:NoSchedule-
kubectl taint nodes node1 key1:NoExecute-
kubectl taint nodes node1 key2:NoSchedule-

查看 node1 上的 taint：

kubectl describe nodes node1

为 pod 设置 toleration 只要在 pod 的 spec 中设置 tolerations 字段即可，可以有多个 key，如下所示：

tolerations:
- key: "key1"
  operator: "Equal"
  value: "value1"
  effect: "NoSchedule"
- key: "key1"
  operator: "Equal"
  value: "value1"
  effect: "NoExecute"
- key: "node.alpha.kubernetes.io/unreachable"
  operator: "Exists"
  effect: "NoExecute"
  tolerationSeconds: 6000

value 的值可以为 NoSchedule、PreferNoSchedule 或 NoExecute。 tolerationSeconds 是当 pod 需要被驱逐时，可以继续在 node 上运行的时间。

详细使用方法请参考官方文档。

6. Troubleshooting adn Debugging Commands 故障排查和调试命令

（1）kubectl describe

输出指定的一个/多个资源的详细信息。

此命令组合调用多条API，输出指定的一个或者一组资源的详细描述。

$ kubectl describe TYPE NAME_PREFIX

首先检查是否有精确匹配TYPE和NAME_PREFIX的资源，如果没有，将会输出所有名称以NAME_PREFIX开头的资源详细信息。

支持的资源包括但不限于（大小写不限）：pods (po)、services (svc)、 replicationcontrollers (rc)、nodes (no)、events (ev)、componentstatuses (cs)、 limitranges (limits)、persistentvolumes (pv)、persistentvolumeclaims (pvc)、 resourcequotas (quota)和secrets。

语法

kubectl describe (-f FILENAME | TYPE [NAME_PREFIX | -l label] | TYPE/NAME)

示例 # 描述一个node

$ kubectl describe nodes kubernetes-minion-emt8.c.myproject.internal

# 描述一个pod

$ kubectl describe pods/nginx

# 描述pod.json中的资源类型和名称指定的pod

$ kubectl describe -f pod.json

# 描述所有的pod

$ kubectl describe pods

# 描述所有包含label name=myLabel的pod

$ kubectl describe po -l name=myLabel

# 描述所有被replication controller “frontend”管理的pod（rc创建的pod都以rc的名字作为前缀）

$ kubectl describe pods frontend

选项 -f, –filename=[]: 用来指定待描述资源的文件名，目录名或者URL。 -l, –selector=””: 用于过滤资源的Label。

继承自父命令的选项

      --alsologtostderr[=false]: 同时输出日志到标准错误控制台和文件。
      --api-version="": 和服务端交互使用的API版本。
      --certificate-authority="": 用以进行认证授权的.cert文件路径。
      --client-certificate="": TLS使用的客户端证书路径。
      --client-key="": TLS使用的客户端密钥路径。
      --cluster="": 指定使用的kubeconfig配置文件中的集群名。
      --context="": 指定使用的kubeconfig配置文件中的环境名。
      --insecure-skip-tls-verify[=false]: 如果为true，将不会检查服务器凭证的有效性，这会导致你的HTTPS链接变得不安全。
      --kubeconfig="": 命令行请求使用的配置文件路径。
      --log-backtrace-at=:0: 当日志长度超过定义的行数时，忽略堆栈信息。
      --log-dir="": 如果不为空，将日志文件写入此目录。
      --log-flush-frequency=5s: 刷新日志的最大时间间隔。
      --logtostderr[=true]: 输出日志到标准错误控制台，不输出到文件。
      --match-server-version[=false]: 要求服务端和客户端版本匹配。
      --namespace="": 如果不为空，命令将使用此namespace。
      --password="": API Server进行简单认证使用的密码。
  -s, --server="": Kubernetes API Server的地址和端口号。
      --stderrthreshold=2: 高于此级别的日志将被输出到错误控制台。
      --token="": 认证到API Server使用的令牌。
      --user="": 指定使用的kubeconfig配置文件中的用户名。
      --username="": API Server进行简单认证使用的用户名。
      --v=0: 指定输出日志的级别。
      --vmodule=: 指定输出日志的模块，格式如下：pattern=N，使用逗号分隔。

（2）kubectl logs

输出pod中一个容器的日志。如果pod只包含一个容器则可以省略容器名。

语法格式

kubectl logs [-f] [-p] POD [-c CONTAINER]

选项

  -c, --container="": 容器名。
  -f, --follow[=false]: 指定是否持续输出日志。
  --interactive[=true]: 如果为true，当需要时提示用户进行输入。默认为true。
  --limit-bytes=0: 输出日志的最大字节数。默认无限制。
  -p, --previous[=false]: 如果为true，输出pod中曾经运行过，但目前已终止的容器的日志。
  --since=0: 仅返回相对时间范围，如5s、2m或3h，之内的日志。默认返回所有日志。只能同时使用since和since-time中的一种。
  --since-time="": 仅返回指定时间（RFC3339格式）之后的日志。默认返回所有日志。只能同时使用since和since-time中的一种。
  --tail=-1: 要显示的最新的日志条数。默认为-1，显示所有的日志。
  --timestamps[=false]: 在日志中包含时间戳。

示例

# 返回仅包含一个容器的pod nginx的日志快照
$ kubectl logs nginx

# 返回pod ruby中已经停止的容器web-1的日志快照
$ kubectl logs -p -c ruby web-1

# 持续输出pod ruby中的容器web-1的日志
$ kubectl logs -f -c ruby web-1

# 仅输出pod nginx中最近的20条日志
$ kubectl logs --tail=20 nginx

# 输出pod nginx中最近一小时内产生的所有日志
$ kubectl logs --since=1h nginx

（3）kubectl attach

（4）kubectl exec

在容器内部执行命令。

语法格式

kubectl exec POD [-c CONTAINER] -- COMMAND [args...]

选项

  -c, --container="": 容器名。如果未指定，使用pod中的一个容器。
  -p, --pod="": Pod名。
  -i, --stdin[=false]: 将控制台输入发送到容器。
  -t, --tty[=false]: 将标准输入控制台作为容器的控制台输入。

举例

# 默认在pod 123456-7890的第一个容器中运行“date”并获取输出
$ kubectl exec 123456-7890 date

# 在pod 123456-7890的容器ruby-container中运行“date”并获取输出
$ kubectl exec 123456-7890 -c ruby-container date

# 切换到终端模式，将控制台输入发送到pod 123456-7890的ruby-container的“bash”命令，并将其输出到控制台/
# 错误控制台的信息发送回客户端。
$ kubectl exec 123456-7890 -c ruby-container -i -t -- bash -il

（5）kubectl port-forward

（6）kubectl proxy

（7）kubectl cp

（7）kubectl auth

7. Advanced Commands 高级命令

（1）kubectl diff

（2）kubectl apply

语法：

kubectl apply -f FILENAME

选项

  -f, --filename=[]: 包含配置信息的文件名，目录名或者URL。
  -o, --output="": 输出格式，使用“-o name”来输出简短格式（资源类型/资源名）。
      --schema-cache-dir="/tmp/kubectl.schema": 如果不为空，将API schema缓存为指定文件，默认缓存到“/tmp/kubectl.schema”。
      --validate[=true]: 如果为true，在发送到服务端前先使用schema来验证输入。

继承自父命令的选项

      --alsologtostderr[=false]: 同时输出日志到标准错误控制台和文件。
      --api-version="": 和服务端交互使用的API版本。
      --certificate-authority="": 用以进行认证授权的.cert文件路径。
      --client-certificate="": TLS使用的客户端证书路径。
      --client-key="": TLS使用的客户端密钥路径。
      --cluster="": 指定使用的kubeconfig配置文件中的集群名。
      --context="": 指定使用的kubeconfig配置文件中的环境名。
      --insecure-skip-tls-verify[=false]: 如果为true，将不会检查服务器凭证的有效性，这会导致你的HTTPS链接变得不安全。
      --kubeconfig="": 命令行请求使用的配置文件路径。
      --log-backtrace-at=:0: 当日志长度超过定义的行数时，忽略堆栈信息。
      --log-dir="": 如果不为空，将日志文件写入此目录。
      --log-flush-frequency=5s: 刷新日志的最大时间间隔。
      --logtostderr[=true]: 输出日志到标准错误控制台，不输出到文件。
      --match-server-version[=false]: 要求服务端和客户端版本匹配。
      --namespace="": 如果不为空，命令将使用此namespace。
      --password="": API Server进行简单认证使用的密码。
  -s, --server="": Kubernetes API Server的地址和端口号。
      --stderrthreshold=2: 高于此级别的日志将被输出到错误控制台。
      --token="": 认证到API Server使用的令牌。
      --user="": 指定使用的kubeconfig配置文件中的用户名。
      --username="": API Server进行简单认证使用的用户名。
      --v=0: 指定输出日志的级别。
      --vmodule=: 指定输出日志的模块，格式如下：pattern=N，使用逗号分隔。

使用kubectl create 和 kubectl apply创建资源对象的区别

序号	kubectl apply	kubectl create
1	根据yaml文件中包含的字段（yaml文件可以只写需要改动的字段），直接升级集群中的现有资源对象	首先删除集群中现有的所有资源，然后重新根据yaml文件（必须是完整的配置信息）生成新的资源对象
2	yaml文件可以不完整，只写需要的字段	yaml文件必须是完整的配置字段内容
3	kubectl apply只工作在yaml文件中的某些改动过的字段	kubectl create工作在yaml文件中的所有字段
4	在只改动了yaml文件中的某些声明时，而不是全部改动，你可以使用kubectl apply	在没有改动yaml文件时，使用同一个yaml文件执行命令kubectl replace，将不会成功（fail掉），因为缺少相关改动信息

（3）kubectl patch

（4）kubectl replace

（5）kubectl wait

（6）kubectl convert

（7）kubectl kustomize

8. Settings Commands 设置命令

（1）kubectl label

更新（增加、修改或删除）资源上的 label（标签）。 label 必须以字母或数字开头，可以使用字母、数字、连字符、点和下划线，最长63个字符。 如果–overwrite 为 true，则可以覆盖已有的 label，否则尝试覆盖 label 将会报错。 如果指定了–resource-version，则更新将使用此资源版本，否则将使用现有的资源版本。

语法

$ label [--overwrite] (-f FILENAME | TYPE NAME) KEY_1=VAL_1 ... KEY_N=VAL_N [--resource-version=version]

示例 给名为foo的Pod添加label unhealthy=true。

kubectl label pods foo unhealthy=true

给名为foo的Pod修改label 为 ‘status’ / value ‘unhealthy’，且覆盖现有的value。

kubectl label --overwrite pods foo status=unhealthy

给 namespace 中的所有 pod 添加 label

kubectl label pods --all status=unhealthy

仅当resource-version=1时才更新 名为foo的Pod上的label。

kubectl label pods foo status=unhealthy --resource-version=1

删除名为“bar”的label 。（使用“ – ”减号相连）

kubectl label pods foo bar-

（2）kubectl annotate

更新一个或多个资源的Annotations信息。

• Annotations由key/value组成。
• Annotations的目的是存储辅助数据，特别是通过工具和系统扩展操作的数据，更多介绍在这里。
• 如果–overwrite为true，现有的annotations可以被覆盖，否则试图覆盖annotations将会报错。
• 如果设置了–resource-version，则更新将使用此resource version，否则将使用原有的resource version。

有效资源类型包括： all certificatesigningrequests (aka ‘csr’) clusterrolebindings clusterroles clusters (valid only for federation apiservers) componentstatuses (aka ‘cs’) configmaps (aka ‘cm’) controllerrevisions cronjobs daemonsets (aka ‘ds’) deployments (aka ‘deploy’) endpoints (aka ‘ep’) events (aka ‘ev’) horizontalpodautoscalers (aka ‘hpa’) ingresses (aka ‘ing’) jobs limitranges (aka ‘limits’) namespaces (aka ‘ns’) networkpolicies (aka ‘netpol’) nodes (aka ‘no’) persistentvolumeclaims (aka ‘pvc’) persistentvolumes (aka ‘pv’) poddisruptionbudgets (aka ‘pdb’) podpreset pods (aka ‘po’) podsecuritypolicies (aka ‘psp’) podtemplates replicasets (aka ‘rs’) replicationcontrollers (aka ‘rc’) resourcequotas (aka ‘quota’) rolebindings roles secrets serviceaccounts (aka ‘sa’) services (aka ‘svc’) statefulsets storageclasses thirdpartyresources

语法

$ annotate [--overwrite] (-f FILENAME | TYPE NAME) KEY_1=VAL_1 ... KEY_N=VAL_N [--resource-version=version]

示例 更新Pod“foo”，设置annotation “description”的value “my frontend”，如果同一个annotation多次设置，则只使用最后设置的value值。

kubectl annotate pods foo description='my frontend'

根据“pod.json”中的type和name更新pod的annotation

kubectl annotate -f pod.json description='my frontend'

更新Pod”foo”，设置annotation“description”的value“my frontend running nginx”，覆盖现有的值。

kubectl annotate --overwrite pods foo description='my frontend running nginx'

更新 namespace中的所有pod

kubectl annotate pods --all description='my frontend running nginx'

只有当resource-version为1时，才更新pod ‘ foo ‘。

kubectl annotate pods foo description='my frontend running nginx' --resource-version=1

通过删除名为“description”的annotations来更新pod ‘ foo ‘。#不需要- overwrite flag。

kubectl annotate pods foo description-

（3）kubectl completion

9. Other Commands 其他命令

（1）kubectl config

（2）kubectl plugin

（3）kubectl version

（4）kubectl api-versions

（5）kubectl api-resources

本次分析的版本为1.17.4，使用Calico作为网络组件，总共有67种不同的api-resources。

1.  Binding: 已弃用。用于记录一个object和另一个object的绑定关系。实际上主要用于将pod和node关系，所以在1.7版本后已经改为在pods.bindings中记录了。
2.  ComponentStatus: 是一个全局的list（即不受命名空间影响），记录了k8s中所有的组件的的相关信息，比如创建时间，现在状态等。
3.  Configmap: 是一种用于记录pod本身或其内部配置信息的API资源，可以认为是通过API形式存储的配置文件。
4.  Endpoints: 用于记录每个service的pod的**真实物理**ip和port的对应关系，包括service是TCP还是UDP等。
5.  Event: 用于记录集群中的事件，可以认为类似于日志里的一条记录。
6.  LimitRange: 用于记录各个命名空间中的pod或container对每种资源的使用限制，一般被包含在pod的定义中。
7.  Namespace: 是一个全局的list，保存集群中所有的命名空间。
8.  Node: 是一个全局的list，详细记录了每个节点的name, labels, PodCIDR, host IP, hostname, 总资源（cpu，内存），可分配资源，各心跳状态（网络，内存，硬盘，PID数量，kubelet等），kubelet的物理port，各k8s组件image信息，node环境信息（os, CRI version, kubeProxy version, kubelet version等）。
9.  PersistentVolumeClaim: 记录用户对持久化存储的要求。
10.  PersistentVolume: 是一个全局的object，记录了所有的持久化存储设备的信息（类似于node）
11.  Pod: 是对于使用k8s的开发者而言最重要的资源，其中包含ownerReference (Node, Demonset等），containers相关信息（image，启动命令，probe，资源信息，存储信息，结束时行，是否接受service注入环境变量为等），网络设置（dns设置，port设置等），集群调度相关信息（优先级，tolerations，affinity，重启规则等），pod状态（hostIP，podIP，启动时间等）
12.  PodTemplate: 一般是被包含在其它资源中的一部分，比如Jobs, DaemonSets, Replication Controllers。其初始化刚被创建的pod的k8s相关的信息，一般是label等。
13.  Replication Controller: 是系统内建的最常用的controller，用来保证Pod的实际运行数量满足定义。如果不足则负责创建，如果过多则通知一些pod terminate。
14.  ResourceQuota: 用于记录和限制某个namespace的中的总的资源消耗，一般用于多用户下利用namespace对资源进行限制。
15.  Secrets: 实际上将文件内容通过base64编码后存在etcd中。在Pod中container启动时可以将secretes作为文件挂载在某一路径下，如此避免重要信息存储在image中。
16.  ServiceAccout: 用于授权集群内的pod访问apiServer。
17.  Service: 非常重要且常见的资源，用于对外提供统一的Service IP和port，将流量负载均衡调整至集群中多个pod。重要的配置有：cluster IP，port，selector（选择转发流量的目的pod），sessionAffinity等。这里提供的负载均衡是L3 TCP的。
18.  MutatingWebhookConfiguration: 不明（内部object）
19.  ValidatingWebhookConfiguration: 不明（内部object）
20.  CustomerResourceDefinitions: 自定义资源也是非常重要的一种资源，是各种k8s插件能够存在的基础。比如当要实现Clico之类的自定义插件时，首先需要考虑的就是apiServer如何能够处理相关的请求信息。自定义资源的定义便是apiServer处理资源的依据。这个话题比较复杂，在这里不详细讨论。
21.  APIService: 定义API服务的资源。一个API请求有两种形式，`/apis/GROUP/VERSION/*`这种不被包含在namespace中的（即全局的）和`/apis/GROUP/VERSION/namespaces/NAMESPACE/*`这种被包含在namespace中的。当一个请求到达apiServer后，必然需要有相应的代码去处理它。每一对GROUP和VERSION确定一种API，响应每一种API请求的代码被抽象为一种服务（service）。想象一下自定义资源的相关API请求到达apiServer后如何被处理呢？相关的service也是自定义的并且运行在master中，k8s正是根据APIService来正确地将请求与正确的service关联。在这里可以定义service名称，安全设置，优先级等。
22.  ControllerRevision: 是一个beta功能，用于Controller保存自己的历史状态便于更新和回滚。
23.  Daemenset: 常见的Pod set种类，用于控制每种pod状态（数量，计算资源使用，probe等）在定义的范围内，且在每node上最多有一个。
24.  Replicaset: 常见的Pod set种类但现在基本上不直接使用，用于控制每种pod的状态（数量，计算资源使用，probe等）在定义的范围内。一个Replicasets中的各个pod都应是等同的、可互换的，即对外表现完全相同。就好比所有的氢原子（1质子0中子）都是不可区分的。
25.  Deployment: 最常见的Pod set种类，可以拥有Replicasets和Pod。用于控制拥有的资源的状态（数量，计算资源使用，probe等）在定义的范围内。
26.  StatefulSet: 常见的Pod set种类。和Deployment的区别之处是它控制的pod不是可互换的而是在整个生命周期有不变的标签。这样，每个pod可以有自己的DNS名，存储等。即使pod被删除后这些信息也会被恢复。
27.  TokenReview: 不明，似乎和apiServer的Webhook的token授权相关。
28.  LocalSubjectAccessReview: 不明（内部object），和一个命名空间对用户/组的授权检查相关。
29.  SelfSubjectAccessReview: 不明（内部object），和当前用户检查自己是否有权限对一个命名空间进行操作相关。
30.  SelfSubjectRulesReivew: 不明（内部object），含有当前用户在一个命名空间内能进行的操作的列表。和apiServer的授权安全模式相关
31.  SubjectAccessReviews: 不明（内部object），和用户/组的授权检查相关，并不限定于某个命名空间。
32.  HorizontalPodAutoScaler: 控制Pod set（比如Deployment）的pod数量的资源。可以根据pod的CPU、内存、自定义数据动态调节pod数量。在[这里](https://link.zhihu.com/?target=https%3A//kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/)可以找到相关的例子。
33.  CronJob: 定时运行Job pod的资源。
34.  Job: 常见的Pod set种类，会创建一定数量的pod，仅当特定数量的pod成功结束后这个Job才算成功结束。创建的pod在结束后不会被重启。
35.  CertificateSigningRequests: 可以认为是一个接口，便于Pod等资源申请获得一个X.509证书。这个证书应该被controller approve或者被手动approve，之后被合适的对象签名。具体可以参考这里。
36.  Lease: 是一个在1.13版本中加入的资源类型，用于Node向master通知自己的心跳信息。之前的版本中kebulet是通过更新NodeStatus通知master心跳，后来发现NodeStatus太大了而心跳信息更新频繁，导致master压力较大，于是增加了Lease这种资源。
37.  EndpointSlice: 是含有一个service的Endpoint的部分信息的资源。原因和Lease类似，对于含有较多信息的service（比如有很多pod分布在多个node上）一个endpoint object可能会比较大而且被频繁访问，所以这种情况下会有多个endpointSlice被创建减轻master的压力。
38.  Event: 描述一个集群内的事件的资源，含有message，event，reason，报告来源等详细的信息。
39.  Ingresse (APIGroup=extensions): 将被deprecated。
40.  Ingresse (APIGroup=[http://networking.k8s.io](https://link.zhihu.com/?target=http%3A//networking.k8s.io)): 可以简单理解为是定义loadbalancer的资源。其中含有一系列规则，定义了不同url的对应后端，SSL termination等。为什么这个新的API会取代前面那个APIGroup=extensions的Ingress API呢？我查了很多地方没有找到具体的文字解释，但是可以推测是Ingress正式成为k8s的网络模块的一部分，对应的server（代码）从extensions迁移到[http://networking.k8s.io](https://link.zhihu.com/?target=http%3A//networking.k8s.io)。
41.  NetworkPolicy: 定义了那些网络流量可以去哪些pod的资源。一个NetworkPolicy可以指定一组pods，定义只有满足了特定条件（比如源/目的IP，port，pod名等）的网络流量可以被相应的pod收发。
42.  RuntimeClass: 这是2019年讨论加入的新API资源。[文档](https://link.zhihu.com/?target=https%3A//github.com/kubernetes/enhancements/blob/master/keps/sig-node/runtime-class.md%23summary)说明其目的是将容器运行时（Container Runtime）环境的属性暴露给k8s的控制层，便于在一个集群或节点中支持多种容器运行时环境。这样便于未来创建更具有兼容性的k8s集群。
43.  PodDisruptionBudget: 这一个API资源使用户可以对一组pod定义“k8s可以容忍的实际running状态的pod数量与预期的差距”。考虑这样一个情景：一集群中某个service后一共有5个相同pod处理其流量，要求至少有一半的pod是可用的，但其中3个pod由于调度运行在node A上。如果出现node A突然故障等情况导致服务不可用，暂时没有好的办法处理这种不可避免地意外情况（或者需要让调度算法知道这些pod应该被尽量均匀分布在个节点上，但目前k8s没有功能强制这种调度）。但除此之外还有很多可以避免的意外情况，比如在集群维护或者其它事件的处理过程中，集群管理员可能drain node A，导致三个pod同时被结束从而影响业务。针对这种可避免的意外，若一组pod的数量因为可避免的k8s操作将会低于可容忍程度（在PodDisruptionBudget中定义），那么这个命令会被阻止并返回失败。
44.  PodSecurityPolicy: 定义了一个pod在集群中被创建/运行/更新时需要满足的条件。
45.  ClusterRole: 定义了集群中policy rule的一些常见集合，比如`system-node`等，用于控制账户权限。
46.  ClusterRoleBinding: 定义了某个账户/组对ClusterRole的引用，用于赋权。
47.  Roles: 和前面ClusterRole类似，但是顾名思义ClusterRole是和集群账户相关，Role则被用于其它的账户（比如controller使用的service account）
48.  RoleBindings: 定义了某个账户/组对Role的引用，用于赋权。
49.  PriorityClass: 定义了pod优先级名称和对应值的映射。比如`system-cluster-critical`对应的优先级为2000000000。值越大代表优先级越高，那么当集群资源不足等情况发生必须终止一些pod时，优先级小的pod会先被终止。为什么不直接用数值代表优先级呢？因为这样子很容易出现确定随意性。比如开发人员A开发了一个非常重要的pod，于是在代码中将其优先级的值设置为9999。但是集群集群管理员B可能认为9999是一个小数字，他创建的随便一个pod的优先级都是999999+。于是需要PriorityClass来进行优先级的统一管理和比较。
50.  CSIDriver: 定义了集群中容器存储驱动的API资源。[CSI](https://link.zhihu.com/?target=https%3A//kubernetes-csi.github.io/docs/introduction.html)代表的是Container Storage Interface，即容器存储接口。k8s应该可以利用各种各样的存储服务，各家云厂商的活开源的。k8s如何知道怎么去用这些存储服务呢？那么就是通过这个CSIDriver资源找到相应的驱动。
51.  CSINode: 前面CSIDriver产生的节点相关的信息便存在CSINode中。
52.  StorageClass: 定义了可以存在的存储类型的API资源。
53.  Volumeattachments: 定义了对一个node分配/回收存储空间的请求的API资源。
54.  NetworkSets: 接下来的都是Calico自定义API资源，就不一一分析了，都与网络协议/安全/管理相关。
55.  NetworkPolicies: Calico自定义API资源
56.  IPPools: Calico自定义API资源
57.  IPAMHandles: Calico自定义API资源
58.  IPAMConfigs: Calico自定义API资源
59.  IPAMBlocks: Calico自定义API资源
60.  HostEndpoints: Calico自定义API资源
61.  GlobalNetworkSets: Calico自定义API资源
62.  GlobalNetworkPolicies: Calico自定义API资源
63.  FelixConfiguration: Calico自定义API资源
64.  ClusterInformation: Calico自定义API资源
65.  BlockAffinity: Calico自定义API资源
66.  BGPPeer: Calico自定义API资源
67.  BGPConfiguration: Calico自定义API资源

kubernetes 中yaml文件数据定义介绍

apiVersion： api版本
kind: 资源类型
metadata: #元数据
  name: 名字
  namespace:所在命名空间
  labels: 标签信息（可以多个）
    ##标签是key：value格式的key，value最长只能使用63个字符
    # key只能是以数字、之母、_、-、点（.）这五类的组合，
     #value可以为空，但只能以数字及字母开头或结尾
    app: 标签内容
  annotations: #注释（不具备什么功能 就是注释 ）
    zhushi： ”lalalalalalalal saddas”
spec:期望状态
  containers:容器信息（可以多个名称云镜像）
  - name: 自定义name名称
    image：镜像名
  - name： 
    image：
  nodeSelector:#节点选择器（如给指定运行在disk为ssd的node上）
    disk: ssd
  imagePullPolicy:#是否使用本地或远端的下载镜像
    #1、Always
    #2、Never
    #3、IfNotPresent
  livenessProbe：#存活性探针
　　　　#1、exec #命令
　　　　#2、httpGet #http请求 指定ip:port
　　　　#3、tcpSocket  #
   readinessProbe：#就绪状态探针
 　　　　#1、exec #命令
 　　　　#2、httpGet #http请求 指定ip:port
　　　　#3、tcpSocket  #

（6）kubectl options

参考

（1）英文官方 – https://kubernetes.io/docs/reference/kubectl/overview/

（2）中文文档 – http://docs.kubernetes.org.cn/683.html

（3）Kubectl常用命令详解 https://blog.csdn.net/weixin_44631350/article/details/89450781

1. 开启 Cgroup V2

版本检查

通过下面这条命令来查看当前系统使用的 Cgroups V1 还是 V2

stat -fc %T /sys/fs/cgroup/

如果输出是cgroup2fs 那就是 V2，就像这样

root@tezn:~# stat -fc %T /sys/fs/cgroup/ cgroup2fs

如果输出是tmpfs 那就是 V1，就像这样

[root@docker cgroup]# stat -fc %T /sys/fs/cgroup/ tmpfs

启用 cgroup v2

如果当前系统未启用 Cgroup V2，也可以通过修改内核 cmdline 引导参数在你的 Linux 发行版上手动启用 cgroup v2。

如果你的发行版使用 GRUB，则应在 /etc/default/grub 下的 GRUB_CMDLINE_LINUX 中添加 systemd.unified_cgroup_hierarchy=1， 然后执行 sudo update-grub。

具体如下：

1）编辑 grub 配置

vi /etc/default/grub

内容大概是这样的：

GRUB_DEFAULT=0 GRUB_TIMEOUT_STYLE=hidden GRUB_TIMEOUT=0 GRUB_DISTRIBUTOR=`lsb_release -i -s 2> /dev/null || echo Debian` GRUB_CMDLINE_LINUX_DEFAULT="quiet splash" GRUB_CMDLINE_LINUX=""

对最后一行GRUB_CMDLINE_LINUX进行修改

GRUB_CMDLINE_LINUX="quiet splash systemd.unified_cgroup_hierarchy=1"

2）然后执行以下命令更新 GRUB 配置

sudo update-grub

3）最后查看一下启动参数，确认配置修改上了

cat /boot/grub/grub.cfg | grep "systemd.unified_cgroup_hierarchy=1"

4）然后就是重启

reboot

重启后查看，不出意外切换到 cgroups v2 了

root@cgroupv2:~# stat -fc %T /sys/fs/cgroup/ cgroup2fs

AWS海外区域和国内区域是互相隔离的两套系统，它们之间的信息数据无法共享。所以直接在账户层面将无法对海外账号和国内账号设置权限来共享数据。

接下来，我们将通过海外区域创建的EC2实例制作成AMI镜像，利用S3存储桶和中转主机的aws-cli工具，将海外区域的EC2实例迁移到国内区域。

解决思路

---

1. 将EC2实例导出为AMI镜像（海外账号）。
2. 将该镜像存储到S3存储桶（海外账号）。
3. 使用中转主机，将S3存储桶中的AMI镜像下载到中转主机。
4. 中转主机重新配置登录国内账号，将下载好的AMI镜像上传到国内账号的S3存储桶。
5. 还原AMI镜像。

实现过程

---

海外账号和国内账号均需创建AKSK

1. 在AWS控制台界面创建Access keys (access key ID and secret access key)。
2. 使用账号密码登录到AWS控制台主界面。
3. 在主界面右上角点击你的用户名，出来下拉菜单，在下拉菜单界面点击My Security Credentials。
4. 在Your Security Credentials界面当中，点击Access keys (access key ID and secret access key)栏目，然后点击Create New Access key。
5. 在创建成功时会弹出对话框告诉你AKSK，记得把文件下载下来，因为这个文件只有在第一次创建时才能获取，以后是无法获取的。

| 注：以下操作均在中转主机上执行。这台主机可以是海外EC2实例、国内EC2实例、甚至可以是本地主机或者其他云平台的主机。

确保中转主机安装aws-cli

执行以下命令安装aws-cli，此方式适用于Linux系统。

curl "<https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip>" -o "awscliv2.zip"

unzip awscliv2.zip

./aws/install

aws --version

使用aws-cli登录海外账号

[root@localhost ~] aws configure

AWS Access Key ID [None]: # 输入海外账号的access key

AWS Secret Access Key [None]: # 输入海外账号的 secret key

Default region name [None]: us-east-1 # 你的默认区域

Default output format [None]: json # 输出内容格式

为EC2实例创建AMI镜像

aws ec2 create-image --instance-id i-0fa1e28ba0e99b2f6 --name "ami-test" --description "ami test"

{

"ImageId": "ami-0591c2c1b99828acb"

}

创建海外区域的S3存储桶并将镜像存储到存储桶

1. 创建海外区域的S3存储桶

aws s3api create-bucket --bucket s3-ami-test-source --region us-east-1

{

"Location": "/s3-ami-test-source"

}

2. 将AMI镜像存储到S3存储桶

aws ec2 create-store-image-task --image-id ami-0591c2c1b99828acb --bucket s3-ami-test-source

{

"ObjectKey": "ami-0591c2c1b99828acb.bin"

}

将S3存储桶中的镜像文件下载到中转主机

aws s3 cp s3://s3-ami-test/ami-0591c2c1b99828acb.bin ./

使用AWS-CLI配置登录国内账号

[root@localhost ~] aws configure

AWS Access Key ID [None]: #输入国内账号的access key

AWS Secret Access Key [None]: # 输入国内账号的 secret key

Default region name [None]: cn-northwest-1 # 你的默认区域

Default output format [None]: json # 输出内容格式

创建国内区域的S3存储桶并将镜像上传到存储桶

1. 创建国内区域的S3存储桶

aws s3api create-bucket --bucket s3-ami-test-destination --region cn-northwest-1 --create-bucket-configuration LocationConstraint=cn-northwest-1

{

"Location": "<http://s3-ami-test-destination.s3.cn-northwest-1.amazonaws.com.cn/>"

}

2. 将下载到中转主机本地的AMI镜像上传到国内区域的S3存储桶

aws s3 cp ami-0591c2c1b99828acb.bin s3://s3-ami-test-destination

从S3存储桶中还原AMI镜像

aws ec2 create-restore-image-task --object-key ami-0591c2c1b99828acb.bin --bucket s3-ami-test-destination --name "ami-test"

{

"ImageId": "ami-0591c2c1b99828acb"

}

此时可以看到镜像创建还原成功。

Firewall access

You will need to set your firewall(s) to allow access to the following ports:

• SMTP: 25
• POP3: 110
• IMAP: 143
• SMTP Secure: 465
• MSA: 587
• IMAP Secure: 993
• POP3 Secure: 995

By default, the Cloud Panel Firewall denies access to all but the most commonly-used ports.

Install Postfix

To install Postfix, first update your packages:

sudo apt-get update

Then install Postfix:

sudo apt-get install postfix

Postfix is installed by default on most Ubuntu 16.04 systems, so this command will most likely exit with a message that postfix is already the newest version (3.1.0-3)..

If Postfix continues with an installation, simply accept all of the defaults at each prompt to complete the process.

Configure Postfix

After the installation is complete, run the command to configure Postfix:

sudo dpkg-reconfigure postfix

Enter the following values at the prompts, replacing example.com with your own domain name. Use the up arrow and down arrow to move up and down to highlight answers, and Enter to select your answer.

1. Select OK to proceed.
2. Choose Internet Site.
3. System Mail Name: example.com
4. Root and postmaster mail recipient: root
5. Other destinations for mail: example.com, localhost.example.com, localhost
6. Force synchronous updates on mail queue?: No
7. Local networks: 127.0.0.0/8
8. Use procmail for local delivery?: No
9. Mailbox size limit (bytes): 0
10. Local address extension character: +
11. Internet protocols to use: all

After the initial Postfix configuration has been done, you can change Postfix settings with the command:

sudo postconf -e '[new setting]'

Create an SSL certificate

We will create a self-signed SSL certificate to secure incoming and outgoing email connections:

sudo openssl req -x509 -nodes -newkey rsa:2048 -keyout mailserver.key -out mailserver.crt -nodes -days 365

sudo openssl req -new -x509 -extensions v3_ca -keyout cakey.pem -out cacert.pem -days 3650

Answer the questions at the prompts, or just hit [Enter] to leave an answer blank. This command will create two files: mailserver.key and mailserver.crt.

Create a folder for the SSL certificate files:

sudo mkdir /etc/postfix/ssl

Then move the files into this folder:

sudo mv mailserver.key /etc/postfix/ssl
sudo mv mailserver.crt /etc/postfix/ssl
sudo mv cakey.pem /etc/postfix/ssl
sudo mv cacert.pem /etc/postfix/ssl

Set up SMTP AUTH

SMTP AUTH is a basic method of securing your mail server. We strongly recommend the use of SMTP AUTH on all mail servers.

To begin, use the following commands to configure Postfix to use SMTP AUTH:

sudo postconf -e 'smtpd_sasl_local_domain ='
sudo postconf -e 'smtpd_sasl_auth_enable = yes'
sudo postconf -e 'smtpd_sasl_security_options = noanonymous'
sudo postconf -e 'broken_sasl_auth_clients = yes'
sudo postconf -e 'smtpd_recipient_restrictions =  permit_sasl_authenticated,permit_mynetworks,reject_unauth_destination'
sudo postconf -e 'inet_interfaces = all'
sudo postconf -e 'smtp_tls_security_level = may'
sudo postconf -e 'smtpd_tls_security_level = may'
sudo postconf -e 'smtpd_tls_auth_only = no'
sudo postconf -e 'smtp_tls_note_starttls_offer = yes'
sudo postconf -e 'smtpd_tls_key_file = /etc/postfix/ssl/mailserver.key'
sudo postconf -e 'smtpd_tls_cert_file = /etc/postfix/ssl/mailserver.crt'
sudo postconf -e 'smtpd_tls_CAfile = /etc/postfix/ssl/cacert.pem'
sudo postconf -e 'smtpd_tls_loglevel = 1'
sudo postconf -e 'smtpd_tls_received_header = yes'
sudo postconf -e 'smtpd_tls_session_cache_timeout = 3600s'
sudo postconf -e 'tls_random_source = dev:/dev/urandom'

Replace example.com with your own domain name:

sudo postconf -e 'myhostname = example.com' 

Next, create the file /etc/postfix/sasl/smtpd.conf and open it for editing:

sudo nano /etc/postfix/sasl/smtpd.conf

Add the following content:

pwcheck_method: saslauthd
mech_list: plain login

After you have finished configuring Postfix, restart the Postfix daemon with the command:

sudo systemctl restart postfix

Install SASL

Postfix will use SASL to handle the authentication with SMTP AUTH. Now that Postfix has been configured to use SMTP AUTH, install SASL with the command:

sudo apt-get install libsasl2-2 sasl2-bin libsasl2-modules

After the installation is done, edit /etc/default/saslauthd:

sudo nano /etc/default/saslauthd

Scroll down to the line:

# Should saslauthd run automatically on startup? (default: no)
START=no

Change START to yes:

# Should saslauthd run automatically on startup? (default: no)
START=yes

Below that line, add the following three lines:

PWDIR="/var/spool/postfix/var/run/saslauthd"
PARAMS="-m ${PWDIR}"
PIDFILE="${PWDIR}/saslauthd.pid"

Scroll down to the bottom of the file to the line:

OPTIONS="-c -m /var/run/saslauthd"

Change the last line to read:

OPTIONS="-c -m /var/spool/postfix/var/run/saslauthd"

Save and exit the file.

Next, run the following command to update the dpkg state:

sudo dpkg-statoverride --force --update --add root sasl 755 /var/spool/postfix/var/run/saslauthd

Note: If you get an error message that /var/spool/postfix/var/run/saslauthd does not exist, ignore it. This directory will be created when you start the SASL daemon.

Create a symlink for the config file:

sudo ln -s /etc/default/saslauthd /etc/saslauthd

And finally, start the SASL daemon:

sudo /etc/init.d/saslauthd start