导航:首页 > 程序命令 > 重启k8s的命令

重启k8s的命令

 发布时间：2022-10-09 09:31:27

⑴ K8S常用命令介绍

k8s常用命令：

禁止|恢复node节点调度：
kubectl cordon|uncordon nodename
删除节点（慎用）:
kubectl drain nodename（驱除非系统pod）
kubectl delete nodename （删除节点）

创建资源：
kubectl create|apply -f file.yaml
create 命令一般用于创建新资源。 因此，如果再次运行该命令，则会抛出错误，因为资源名称在名称空间中应该是唯一的
apply 命令一般用于更新资源配置。 如果资源不在那里，那么它将被创建。 kubectl apply命令可以运行更多次，只要资源定义没变，资源将不会变动

查看资源列表：
kubectl get node|pod|service|deployment|configmap|... -n namespace [-o wide] [-w]

查看特定资源详情：
kubectl describe pod podname -n namespace

查看资源定义：
kubectl get deploy deployname -n namespace -o yaml [>file.yaml] 重定向到文件里，可以再次apply -f yaml

编辑资源（只对spec字段下内容生效）：
kubectl edit node|pod|service|deployment|configmap|... -n namespace

删除资源（慎用）：
kubectl delete pod podname -n namespace [--force --grace-period=0] 强制删除
grace-period表示过渡存活期，默认30s，在删除POD之前允许POD慢慢终止其上的容器进程，从而优雅退出，0表示立即终止POD

查看pod log：
kubectl logs [-f] podname -n namespace

进入pod（容器），或执行命令:
kubectl exec -it podname -n namespace [-c containername] -- /bin/sh [CMD]
-c 是进入多个容器中的某个指定容器
-- 指的是不用进入容器就可以执行命令

pod扩缩容：k
手动扩缩容：kubectl scale deployment deployname -n namespace --replicas=x；也可用kubectl edit对deployment进行编辑后apply

pod升级与回滚：
deployment：
升级：kubectl set image deployment/deplyname -n namespce image=imagename:xxx; 也可用kubectl edit对deployment进行编辑后apply
更新策略：
Recreate: 更新时先杀掉正在运行的pod，然后创建新的pod
RollingUpdate： 滚动方式进行更新，参数maxUnavailable和maxSurge来控制滚动更新的过程
回滚(不常用）：kubectl rollout status|history deployment/deployname -n namespace [--to-revision=x]

pod调度：
NodeName定向调度：通过node节点的主机名进行定向调度
NodeSelector定向调度：通过Node节点标签和pod资源属性nodeSelector匹配实现pod的定向调度
查看node节点标签：
kubectl get node --show-labels
查看指定标签的节点： kubectl get node -l key=value
节点增加标签：kubectl label nodes nodename key=value
删除节点标签：kubectl label nodes nodename key-
修改节点标签： kubectl label nodes nodename key=newvalue --overwrite

⑵ k8s 基本使用（上）

本文将介绍 k8s 中的一些最基本的命令，并辅以解释一些基本概念来方便理解，也就是说，本文是一篇偏向实用性而非学术性的文章，如果你想提前了解一下 k8s 相关的知识的话，可以通过以下链接进行学习：

k8s 是经典的一对多模型，有一个主要的管理节点 master 和许多的工作节点 slaver 。当然，k8s 也可以配置多个管理节点，拥有两个以上的管理节点被称为 高可用 。k8s 包括了许多的组件，每个组件都是单运行在一个 docker 容器中，然后通过自己规划的虚拟网络相互访问。你可以通过 kubectl get pod -n kube-system 查看所有节点上的组件容器。

在管理节点中会比工作节点运行更多的 k8s 组件，我们就是靠着这些多出来的组件来对工作节点发号施令。他们都叫什么这里就不详细提了。反正对于”基本使用“来说，这些名字并不重要。

要想理解一个东西就要先明白它的内在理念。通俗点就是，k8s 做了什么？为了提供更加可靠的服务，就要增加服务器的数量，减少每个服务器的体量来平摊负载，而越来越多的虚拟机就会带来越来越高的运维成本。如何让少量的运维人员就可以管理数量众多的服务器及其上的服务呢？这就是 k8s 做的工作。

k8s 把数量众多的服务器重新抽象为一个统一的资源池 ，对于运维人员来说，他们面前没有服务器1、服务器2的概念，而是一个统一的资源池，增加新的服务器对运维人员来说，只是增加自资源池的可用量。不仅如此，k8s 把所有能用的东西都抽象成了资源的概念，从而提供了一套更统一，更简洁的管理方式。

接下来，我会把每个基本命令当做一节来进行介绍，并辅以介绍一些基本概念。本文介绍的命令涵盖了增删改查四方面，可参加下面表格，因为篇幅较长，我们将 create 及之后的不那么常用的命令放在下一篇文章 k8s 基本使用（下） 里讲：

接下来进入正题，首先来了解一下 k8s 中最最最常用的命令 kubectl get ，要记住，k8s 把所有的东西都抽象成了资源，而 kubectl get 就是用来查看这些资源的。最常见的资源就是 pod 。

不仅我们自己的服务是要包装成 pod 的，就连 k8s 自己也是运行在一堆 pod 上。接下来就让我们查看一下 k8s 的 pod ：

-n 参数指定了要查看哪个命名空间下的 pod 。 k8s 所有的 pod 都被放置在 kube-system 命名空间下。

执行了 kubectl get pod -n kube-system 命令后，你就可以看到如下内容：

其中每一行就是一个资源，这里我们看到的资源是 pod 。你看到的 pod 数量可能和我的不一致，因为这个列表里包含了 k8s 在所有节点上运行的 pod ，你加入的节点越多，那么显示的 pod 也就越多。我们来一列一列的看：

kubectl get 可以列出 k8s 中所有资源

这里只介绍了如何用 kubectl 获取 pod 的列表。但是不要把 get 和 pod 绑定在一起，pod 只是 k8s 中的一种服务，你不仅可以 get pod ，还可以 get svc ( 查看服务 )、 get rs ( 查看副本控制器 )、 get deploy ( 查看部署 )等等等等，虽然说 kubectl get pod 是最常用的一个，但是如果想查看某个资源而又不知道命令是什么， kbuectl get <资源名> 就对了。

如果你想看更多的信息，就可以指定 -o wide 参数，如下：

加上这个参数之后就可以看到资源的所在 ip 和所在节点 node 了。

记得加上 -n

-n 可以说是 kubectl get 命令使用最频繁的参数了，在正式使用中，我们永远不会把资源发布在默认命名空间。所以，永远不要忘记在 get 命令后面加上 -n 。

kubectl get 命令可以列出 k8s 中的资源，而 kubectl get pod 是非常常用的查看 pod 的命令。而 -n 参数则可以指定 pod 所在的命名空间。

kubectl describe 命令可以用来查看某一资源的具体信息，他同样可以查看所有资源的详情， 不过最常用的还是查看 pod 的详情 。他也同样可以使用 -n 参数指定资源所在的命名空间。

举个例子，我们可以用下面命令来查看刚才 pod 列表中的某个 pod，注意不要忘记把 pod 名称修改成自己的：

然后你就可以看到很多的信息，咱们分开说，首先是基本属性，你可以在详细信息的开头找到它：

基本属性

其中几个比较常用的，例如 Node 、 labels 和 Controlled By 。通过 Node 你可以快速定位到 pod 所处的机器，从而检查该机器是否出现问题或宕机等。通过 labels 你可以检索到该 pod 的大致用途及定位。而通过 Controlled By ，你可以知道该 pod 是由那种 k8s 资源创建的，然后就可以使用 kubectl get <资源名> 来继续查找问题。例如上文 DaemonSet/kube-flannel-ds-amd64 ，就可以通过 kubectl get DaemonSet -n kube-system 来获取上一节资源的信息。

内部镜像信息

在中间部分你可以找到像下面一样的 Containers 段落。该段落详细的描述了 pod 中每个 docker 容器的信息，常用的比如 Image 字段，当 pod 出现 ImagePullBackOff 错误的时候就可以查看该字段确认拉取的什么镜像。其他的字段名都很通俗，直接翻译即可。

事件

在 describe 查看详情的时候，最常用的信息获取处就是这个 Event 段落了，你可以在介绍内容的末尾找到它，如下：

是的，如果你看到上面这样，没有任何 Events 的话，就说明该 pod 一切正常。当 pod 的状态不是 Running 时，这里一定会有或多或少的问题，长得像下面一样，然后你就可以通过其中的信息分析 pod 出现问题的详细原因了：

kubectl describe <资源名> <实例名> 可以查看一个资源的详细信息，最常用的还是比如 kubectl describe pod <pod名> -n <命名空间> 来获取一个 pod 的基本信息。如果出现问题的话，可以在获取到的信息的末尾看到 Event 段落，其中记录着导致 pod 故障的原因。

如果你想查看一个 pod 的具体日志，就可以通过 kubectl logs <pod名> 来查看。注意，这个只能查看 pod 的日志。通过添加 -f 参数可以持续查看日志。例如，查看 kube-system 命名空间中某个 flannel pod 的日志，注意修改 pod 名称：

然后就可以看到如下输出：

如果你发现某个 pod 的服务有问题，但是状态还是显示 Running ，就可以使用 kubectl logs 来查看其详细日志。

在本篇文章里，我们了解了 k8s 的宗旨和一些基本概念，并知道了最为常用的 get 、 descibe 及 logs 命令，知道了这三条命令之后就几乎可以从 k8s 中获取所有常用信息了。接下来的 k8s 基本使用（下） 里，我们会更深一步，来了解 k8s 中如何创建、修改及删除资源。

⑶ k8s常用命令

命令行 敲出的指令分为2种，

资源管理方式分类

直接使用命令去操作k8s资源，命令和参数一起出现

通过命令和配置文件去操作作k8s资源，命令还是那个命令，只不过参数都放在配置文件里面

使用apply创建资源，

说明

在master节点执行以下命令即可删除

还需要在work节点上执行以下命令来清空ini配置

先在主节点创建令牌

然后在需要加入集群的节点中执行令牌，注意这里的命令是通过 kubeadm token create --print-join-command 命令返回的结果

说明

记住，名称中不能用下划线 _ ，可以用横行 - 第一种创建方式–命令行创建

第二种创建方式–命令行 + 配置文件
创建一个名为namespace-dev.yaml的文件，内容如下(注意大小写，kind的头字母必须大写)

然后偶执行命令进行创建

需要注意的是，删除后，当前命名空间下的pod、deployment、 container 也会一起删掉

第一种–使用命令删除

第二种–使用配置文件删除

说明

获取所有namespace的pod并监视资源变动
加上 -w 表示监视资源变动信息，此时命令行进入阻塞状态，如果pod有变化将会马上呈现出来；

其他参数

因为pod里面至少要有一个容器，所以pod是和容器一起创建的，新建一个文件 pod.ymal ，内容如下

然后执行命令并指定配置文件进行创建

以下示例是为pod资源打标签，这种方式是和pod一起创建的，新建一个配置文件 label.yaml

执行命令创建pod

适合更新label值，前提是label的key必须已存在；

删除key为lebelKey的标签

pod控制器有很多种，我们这里就用deployment

使用以下run命令运行一个nginx，deployment名称为 app=run-cmd-nginx-deploy-3

通过以下命令可以看到，会自动生成一个 app=run-cmd-nginx-deploy-3 的标签

新建一个deployment.yaml文件，内容如下

需要注意的是，一旦删除pod控制器，此pod控制器下的所有pod和容器也会一并删除；

默认创建的pod是只能对内访问的，所以需要创建一个对外的访问端口，创建一个service其实就是暴露对外的访问端口

说明

创建好service之后，查看service信息，可以看到，暴露的端口为：30474，

新建一个service.ymal文件，内容如下

以下三种用法都可以

查询pod控制器和pod

Endpoint是kubernetes中的一个资源对象，存储在etcd中，用来记录一个service对应的所有pod的访问地址，它是根据service配置文件中selector描述产生的。

一个Service由一组Pod组成，这些Pod通过Endpoints暴露出来，Endpoints是实现实际服务的端点集合。换句话说，service和pod之间的联系是通过endpoints实现的。

每创建一个service，k8s会自动创建一个同名的 Endpoint出来

如果是由service创建出来的endpoints，删除后会马上创建出一个同名的endpoint出来，如果要删除必须先删除service

因为每次创建一个service，k8s会自动创建一个同名的 Endpoint出来，所我们直接创建service就可以了

--help 用来查看帮助文档，如果你不知道某个命令怎么使用了，就可以用 --help 查询命令的用法

explain用来查看配置文件的 资源结构，如果不知道配置文件中的资源用有哪些结构，那么就可以使用explain命令来查看

⑷ linux里面k8s里面kind:service代表什么意思

1 Service 含义
K8s service可以理解为对一组Pod的抽象。类似于Nginx能够把请求转发 的 对应的服务上。
2 Service作用

2.1 pod使用时因某些问题重启，从而导致pod 的IP发生变化，会导致旧的IP不能用，影响用户对系统使用。service的出现很好 的 解决此问题，客户端通过service 访问pod，当podIP有变化也不会影响(service通过Label Selector跟pod绑定)。
2.2 对外暴露pod访问请求端口。
2.3 固定IP。
2.4 负载均衡。
3 Service 工作机制
3.1 userspace代理模型流程
userspace指Linux操作系统的用户空间(物理上为内存)。对于service会对外暴露端口号，用户空间中的kube-proxy会监控service端口上请求，并把请求转发到对应的pod上。
请求到达内核空间后经由套接字送往用户空间的kube-proxy，并调度至后端pod。请求会在内核和用户空间之间来回转发导致效率不高。(如下图)
3.2 iptables代理模型流程
kube-proxy负责跟踪API Server上的Service和Endpoints对象的变动，并根据变动做出iptables的变动。
iptables捕捉到达clusterIP与端口的请求，并将请求转发到当前service后端pod。
iptables模型不用将流量在用户空间和内核空间来回切换，因而更加高效和可靠，不过其缺点是iptables代理模型不会在被挑中的后端Pod资源无响应时进行重定向。
3.3 ipvs代理模型
K8s从1.9版本引入ipvs代理模型，且从1.11版本起成为默认设置。
它和iptables模型很类似，唯一一点不同的是在其请求流量的调度功能由ipvs实现，余下的功能仍由iptables完成。
ipvs是建立在netfilter的钩子函数上，但它使用hash表作为底层数据结构并工作于内核空间，因此流量转发速度特别快、规则同步性很好，
而且它支持众多调度算法，rr（轮询）、lc（最小连接数）、dh（目标哈希）、sh（源哈希）、sed(最短期望延迟)、nq（不排队调度）。
3 Service 类型
3.1 ClusterIp：默认类型，自动分配一个仅Cluster内部可以访问的虚拟IP.
3.2 NodePort：在ClusterIP基础上为Service在每台机器上绑定一个端口，这样可以通过NodeIP:NodePort来访问服务。
也可以这样理解在于在 node 上暴露了一个端口，将向该端口的流量导入到 kube-proxy，然后由 kube-proxy 进一步到给对应的 pod。
k8s配置好对外访问端口后，linux防火墙也需要通过命令配置(-A INPUT -m state --state NEW -m tcp -p tcp --dport 8080 -j ACCEPT)
3.3 LoadBalancer：在NodePort基础上，借助cloud provider创建一个外部负载均衡器，并将请求转发到NodeIP:NodePort。
另一种理解调用cloud provider 去创建 LB 来向节点导流
3.4 ExternalName: 把集群外部的服务引入到集群内部来，在集群内部直接使用，没有任何类型代理被创建，这只有kubernetes1.7 或更高版本的kube-dns才支持
4 port nodePort targetPod 区别
4.1 port service暴露在cluster ip上的端口，<cluster ip>:port 是提供给集群内部客户访问service的入口
4.2 nodePort 是kubernetes提供给集群外部客户访问service入口的一种方式（另一种方式是LoadBalancer），所以，<nodeIP>:nodePort 是提供给集群外部客户访问service的入口.
4.3 targetPort 是pod上的端口，从port和nodePort上到来的数据最终经过kube-proxy流入到后端pod的targetPort上进入容器

4 Service脚本创建
apiVersion: v1
kind: Service
metadata:
name: myService
spec:
selector:
app: tomcat
ports:
- name: http
protocol: TCP
port: 80
targetPort: 80
- name: https
protocol: TCP
port: 443
targetPort: 443
selector字段中指定了为哪一个标签的app进行负载均衡即暴露pod 的name为tomcat对外的访问端口。

⑸ k8s 网络基础

author：sufei
说明：本文主要记录在学习k8s网络方面的相关知识

 Linux在内核网络栈中引入网络命名空间，将 独立的网络协议栈隔离 到不同的命令空间中，彼此间无法通信；

1、Linux操作系统，解析和封装网络包是通过一个网络协议栈完成，下层为上层服务，这个 协议栈中即包括如软件也包括硬件网络设 备。网络命名空间就是以软件方式隔离出单独的网络栈信息；

2、不同network namespace的软硬件资源相互不可见，好像处在物理隔离的不同物理机上一样，彼此隔离；

3、不同的网络命名空间会有自己独立的网卡、路由表、ARP 表、iptables 等和网络相关的资源

4、实验：可以借助 ip netns 命令来完成对 Network Namespace 的各种操作，如：

问题 ：什么是转移设备？

 可以在不同的 Network Namespace 之间转移设备（如veth）。由于一个设备只能属于一个 Network Namespace ，所以转移后在这个 Network Namespace 内就看不到这个设备了。 veth设备属于可转移设备 ，而很多其它设备（如lo、bridge等）是不可以转移的。

 veth pair 全称是 Virtual Ethernet Pair，是一个成对的端口，所有从这对端口一 端进入的数据包都将从另一端出来，反之也是一样。而veth pair就是为了在不同的 Network Namespace 直接进行通信，利用它可以直接将两个 Network Namespace 连接起来。

实验

 veth pair打破了 Network Namespace 的限制，实现了不同 Network Namespace 之间的通信。但veth pair有一个明显的缺陷，就是只能实现两个网络接口之间的通信。如果我们想实现多个网络接口之间的通信，就可以使用下面介绍的网桥（Bridge）技术（ 类似于物理交换机 ）。
 简单来说，网桥就是把一台机器上的若干个网络接口“连接”起来。其结果是，其中一个网口收到的报文会被复制给其他网口并发送出去。以使得网口之间的报文能够互相转发。

 网桥是一个二层网络设备，通过网桥可以将linux支持的不同的端口连接起来,并实现类似交换机那样的多对多的通信。

实验：

 

 Netfilter负责在内核中执行各种挂接的规则(过滤、修改、丢弃等)，运行在内核 模式中；Iptables模式是在用户模式下运行的进程，负责协助维护内核中Netfilter的各种规则表；通过二者的配合来实现整个Linux网络协议栈中灵活的数据包处理机制。

 iptables/netfilter(简称iptables)组成了Linux平台下的包过滤防火墙，可以完成封包过滤、封包重定向和网络地址转换（NAT）等功能。这部分主要了解两部分知识：

 应用层不管是要发送还是接收网络消息，都需要通过linux内核提供的一系列关卡。每个”关卡“担负着不同的工作。这里的”关卡“被称为”链“。如下图：

 Docker启动一个容器时会根据Docker网桥的网段分配给容器一个IP地址，称为Container-IP，同时Docker网桥是每个容器的默认网关(如上面的172.17.0.1)。因为在同一宿主机内的容器都接入同一个网桥，这样容器之间就能够通过容器的Container-IP直接通信。

 Docker网桥是宿主机虚拟出来的，并不是真实存在的网络设备，外部网络是无法寻址到的，这也意味着外部网络无法通过直接Container-IP访问到容器。如果容器希望外部访问能够访问到，可以通过映射容器端口到宿主主机（端口映射），即docker run创建容器时候通过 -p 或 -P 参数来启用，访问容器的时候就通过[宿主机IP]:[容器端口]访问容器。

 下面具体来说说docker容器的几种网络模式，以便后续学习k8s网络。

 在host模式下（ –net=host），容器不会去建立新的网络命名空间，而直接使用宿主机的网络设备以及网络协议栈。这样自然不会虚拟出自己的网卡，配置自己的IP等。其特点如下：

 这个模式就是在创建容器时，指定网络（–net=container:NAME_or_ID）与之前容器在同一个网络命名空间中，而不是和宿主机共享（这也就是k8s中pod内各容器的一种网络模式）。下面说明几点：

 none模式(–net=none)Docker容器拥有自己的Network Namespace，但是，并不为Docker容器进行任何网络配置。也就是说，这个Docker容器没有网卡、IP、路由等信息。需要我们自己为Docker容器添加网卡、配置IP等。

 bridge模式是docker容器的默认模式，当Docker进程启动时，会在主机上创建一个名为docker0的虚拟网桥，此主机上启动的Docker容器在bridge模式下会连接到这个虚拟网桥上，并由网桥自动分配ip。虚拟网桥的工作方式和物理交换机类似，这样主机上的所有容器就通过交换机连在了一个二层网络中。

 下面说明这个模式下的工作方式：

 首先我们来看看k8s想要一个什么样的网络，也就是k8s网络设计的要求，具体如下：

 下面简单从几中不同的通信要求来看看k8s网络实现。

 在 Kubernetes 的世界里，IP 是以 Pod 为单位进行分配的。一个 Pod 内部的所有容器共享一个网络堆栈。实际上就是docker container网络模式。可以直接通过本地localhost进行网络访问。这个模式在mysql容器化中就是agent容器与mysql容器的网络通信方式。

 Pod1和Pod2都是通信veth pair连接到同一个docker0网桥上，它们的IP地址都是从docker0网段上动态获取的，它们和网桥本身的IP是同一个网段的。可以通过docker0作为交换机进行通信，也就是采用的docker bridge网络模式进行通信。

 由于在同一个网桥docker0上即可以保证分配的pod IP不会冲突，且可以相互通信，而如果需要跨Node物理节点，则无法通过docker网络直接满足要求了，那这些要求具体有哪些呢？

解决方案

方法一：k8s中通过在etcd中记录正在运行中pod的IP分配信息，这样我们就可以满足Pod IP与Node IP之间映射关系的记录；

方法二：可以在etcd中规划配置好所有主机docker0网桥的子网范围，从而满足Pod IP不冲突的要求；如：

方法三：要实现Pod跨Node通信，以k8s默认网络Flannel为例，就是采用overlay（覆盖网络）实现。具体下面说明：

问题：什么是覆盖网络？

覆盖网络就是应用层网络，是指建立在另一个网络上的网络。怎么理解呢？简单理解就是将TCP数据包装在另一种网络包里面进行路由转发和通信，另一种网络包目前可以是UDP、VxLAN、AWS VPC和GCE路由等数据转发方式。默认以UDP为例来说明flannel工作方式。

下面看看具体实现

问题 ：为保证各node内docker容器分配的ip地址不冲突，每个节点上的Docker会使用不同的IP地址段？如何实现的呢？

问题 ：为什么在发送节点上的数据会从docker0路由到flannel0虚拟网卡，在目的节点会从flannel0路由到docker0虚拟网卡？

⑹ K8S有什么作用

K8s在什么情况会杀掉服务？使用Rancher来运行Kubernetes有很多优势。大多数情况下能使用户和IT团队部署和管理工作更加方便。Rancher自动在Kubernetes后端实现etcd 的HA，并且将所需要的服务部署到此环境下的任何主机中。在设置访问控制，可以轻易连接到现有的LDAP和AD基础构架。Rancher还可以自动实现容器联网以及为Kubernetes提供负载均衡服务。通过使用Rancher，你将会在几分钟内有拥有Kubernetes的HA实现。命名空间现在我们的集群已经运行了，让我们进入并查看一些基本的Kubernetes资源吧。你可以访问Kubernetes集群也可以直接通过kubectl CLI访问，或者通过Rancher UI 访问。Rancher的访问管理图层控制可以访问集群，所以你需要在访问CLI前从Rancher UI那里生成API密匙。我们来看下第一个Kubernetes资源命名空间，在给定的命名空间中，所有资源名称必须有唯一性。此外,标签是用来连接划定到单个命名空间的资源。这就是为什么同一个Kubernetes集群上可以用命名空间来隔离环境。例如，你想为应用程序创建Alpha, Beta和生产环境，以便可以测试最新的更改且不会影响到真正的用户。最后创建命名空间，复制下面的文本到namespace.yaml文件，并且运行 kubectl -f namespace.yaml 命令，来创建一个beta命名空间。kind: NamespaceapiVersion: v1metadata:name: betalabels:name: beta当然你还可以使用顶部的命名空间菜单栏从Rancher UI上创建、查看和选择命名空间。你可以使用下面的命令，用kubectl来为CLI交互设置命名空间：$ kubectl config set-context Kubernetes --namespace=beta.为了验证目前context是否已经被设置好，你可以使用config view命令，验证一下输出的命名空间是否满足你的期望。$ kubectl config view | grep namespace command namespace: betaPods现在我们已经定义好了命名空间，接下来开始创建资源。首先我们要看的资源是Pod。一组一个或者多个容器的Kubernetes称为pod，容器在pod 里按组来部署、启动、停止、和复制。在给定的每个主机种类里，只能有一个Pod,所有pod里的容器只能在同一个主机上运行，pods可以共享网络命名空间,通过本地主机域来连接。Pods也是基本的扩展单元,不能跨越主机,因此理想状况是使它们尽可能接近单个工作负载。这将消除pod在扩展或缩小时产生的副作用，以及确保我们创建pods不太耗资源而影响到主机。我们来给名为mywebservice的pod定义，在规范命名web-1-10中它有一个容器并使用nginx容器镜像，然后把端口为80下的文本添加至pod.yaml文档中。apiVersion: v1kind: Podmetadata:name: mywebservicespec:containers:- name: web-1-10image: nginx:1.10ports:- containerPort: 80使用kubetl create命令创建pod，如果您使用set-context command设置了您的命名空间，pods将会在指定命名空间中被创立。在通过运行pods命令去验证pod状态。完成以后，我们可以通过运行kubetl delete命令删除pod。$ kubectl create -f ./pod.yamlpod "mywebservice" created$ kubectl get podsNAME READY STATUS RESTARTS AGEmywebservice 1/1 Running 0 37s$ kubectl delete -f pod.yamlpod "mywebservice" deleted在Rancher UI 中查看pod，通过顶端的菜单栏选择 Kubernetes > Pods 。

⑺ K8S安装和创建集群终极教程（单master多worker）

本文会以 最简单 、 最直接 、 最完整 的方式记录kubernetes（下面统称K8S）单master多工作节点（worker nodes）的集群步骤

首先要简单了解一下本文的3个核心概念：

内存建议至少4G

问：如何查看主机名？

答：执行命令hostname

问：如何修改主机名？

答：永久生效的做法：执行命令vi /etc/hostname，把第一行去掉（不能注释掉，要去掉），然后重新写上自定义的主机名（注意命名规范），保存并重启后生效；

临时生效的做法：执行以下命令

问：如何查看MAC地址？

答：执行命令ip link，然后看你的第一网卡

问：如何查看proct_uuid？

答：执行命令sudo cat /sys/class/dmi/id/proct_uuid

注意：30000-32767这个端口范围是我们创建服务的端口必须要设置的一个范围（如果设置范围以外的会有限制提示并创建失败），这是K8S规定的。

另外，如果你要直接关闭防火墙可以执行

⑥必须禁用Swap

Swap total大于0，说明Swap分区是开启的

问：如何关闭Swap？

答：编辑文件/etc/fstab，在swap行前面加上#号注释， 保存并重启服务器

再次查看分区状态，已生效

常见的容器引擎（Container runtime，简称runtime）：

本文使用的容器引擎是Docker

安装完成后查看版本：

当出现可能跟Docker引擎相关的奇怪异常时可以尝试把Docker卸载干净并重新安装，但一定要注意镜像、容器、卷或配置文件这些是否需要备份。

下面记录卸载Docker引擎的步骤：

①卸载 Docker Engine、CLI 和 Containerd 包：

②主机上的映像、容器、卷或自定义配置文件不会自动删除。删除所有镜像、容器和卷：

③配置文件如果有不合法的字符时会导致启动失败，我们需要将其删除然后重建

此时Docker引擎已卸载干净

官网用的是谷歌的yum源，因为国内是连不上的，所以这里替换成阿里提供的yum源

①安装

从安装信息中可以看到版本号是1.22

Installing:

kubeadm x86_64 1.22.4-0 kubernetes 9.3 M

kubectl x86_64 1.22.4-0 kubernetes 9.7 M

kubelet x86_64 1.22.4-0 kubernetes 20 M

②启动



这就是一个驱动程序，注意cgroup和cgroupfs不要混淆了

引用官方的一段话

“由于 kubeadm 把 kubelet 视为一个系统服务来管理，所以对基于 kubeadm 的安装， 我们推荐使用 systemd 驱动，不推荐 cgroupfs 驱动。”

kubeadm默认是使用systemd 驱动，而我们的Docker默认驱动是cgroupfs（docker info可以查看），所以需要将Docker的驱动改成systemd

①编辑Docker配置文件

②重启Docker服务

再次docker info查看驱动信息已变成了systemd

工作节点（worker nodes）的最小配置就到这里了

①镜像源参数说明

默认情况下, kubeadm 会从 k8s.gcr.io 仓库拉取镜像，国内是拉不了的。官方文档明确表示允许你使用其他的 imageRepository 来代替 k8s.gcr.io。

--image-repository 你的镜像仓库地址

接下来我找了一些国内的镜像源，并简单做了下分析

综合上述统计，我选择阿里云的镜像源

②ip地址范围参数说明

--pod-network-cidr =192.168.0.0/16

注意:如果192.168.0.0/16已经在您的网络中使用，您必须选择一个不同的pod网络CIDR，在上面的命令中替换192.168.0.0/16。

集群初始化命令：

因为我用的是演示机器，所以这里把完整的执行信息都贴出来方便查阅，平时工作中一定要注意保护好敏感的信息（我的ip地址范围是自定义的便于下面的功能演示，另外初次init需要下载镜像文件，一般需要等几分钟）

如上所示，集群初始化成功，此时一定要注意看上面执行结果最后的那部分操作提示，我已用标明了初始化成功后还需要执行的3个步骤

注意：如果init成功后发现参数需要调整，可以执行kubeadm reset，它的作用是尽最大努力恢复kubeadm init 或者 kubeadm join所做的更改。

To start using your cluster, you need to run the following as a regular user:

翻译：开始使用集群前，如果你是普通用户（非root），你需要执行以下的命令：

Alternatively, if you are the root user, you can run:

翻译：或者，如果你使用的是root，你可以执行以下命令：

（注意：export只是临时生效，意味着每次登录你都需要执行一次）

网络配置配的就是Pod的网络，我的网络插件选用calico

cidr就是ip地址范围，如果您使用 pod CIDR 192.168.0.0/16，请跳到下一步。

但本文中使用的pod CIDR是192.100.0.0/16，所以我需要取消对清单中的 CALICO_IPV4POOL_CIDR 变量的注释，并将其设置为与我选择的 pod CIDR 相同的值。（注意一定要注意好格式，注意对齐）

可根据需求自定义清单，一般不需要的就直接跳过这步

在所有的工作节点上执行join命令（复制之前初始化成功后返回的加入集群命令到所有的工作节点执行即可）

master上查看所有节点的状态

到这里集群已经创建完成

最后我再安装K8S的可视化界面kubernetes-dashboard，方便我们日常使用

①下载yaml文件

②修改yaml文件，新增type和nodePort，使服务能够被外部访问

③安装并查看运行情况

④新建用户

文件创建完成后保存并apply

⑤获取Token，用于界面登录

⑥登录dashboard

192.168.189.128是我的master服务器ip，另外要注意必须使用https，并且不能使用ie内核模式

复制⑤生成的token到输入框，点击登录

dashboard安装配置完成

问：如何在查看资源情况？

答：在master上执行以下命令可查看资源情况（-o wide是显示更详细的信息），

①查看所有节点

②查看所有命名空间

③查看命名空间下的pod

④查看所有命名空间的pod

⑤实时查看查看命名空间下的pod运行情况

问：kubeadm join 出现异常[ERROR Port-10250]: Port 10250 is in use，如何解决？

答：这是因为你之前join失败过了，需要先执行kubeadm reset再重新join

问：虚拟机上测试时网卡突然消失如何解决（题外问题记录）？

答：

①确认丢失的网卡信息，ens开头（可选步骤）

ifconfig -a

②执行以下命令解决

问：如何查看K8S版本？

答：kubectl version

问：join命令忘记或者过期了怎么办？

答：

生成永不过期的

生成时效24小时的

问：Pod不断重启并且无其它报错信息时怎么办？

答：这种情况通常是因为你的集群中只有master，没有worker节点，master的创建默认是有污点的，即不允许调度新的Pod，如果你需要（当然这并不推荐），就需要删除 master 上的污点。删除污点可以执行以下命令，

它应该返回以下内容。

⑻ k8s如何管理服务

声明式资源清单
陈述式命令
dashboard仪表盘管理
基于其他k8s二次开发的管理工具

⑼ 什么是K8S

‍


k8s是什么?

Kubernetes 是一个可移植的，可扩展的开源容器编排平台，用于管理容器化的工作负载和服务，方便了声明式配置和自动化。它拥有一个庞大且快速增长的生态系统。Kubernetes 的服务，支持和工具广泛可用。

为什么现在流行使用容器?

早期: 在物理服务器上面部署应用程序存在资源分配问题,因为其不能在物理服务器中的应用程序定义资源边界,导致应用程序资源利用不足而无法扩展.

后来: 为了解决该问题,引入了虚拟化技术, 虚拟化技术是指允许你在单个物理服务器的 CPU 上运行多个虚拟机,可以让多个应用程序在虚拟机之间进行隔离,具有一定的安全性, 每一个虚拟机就是一台完整的计算机, 在虚拟化硬件之上运行所有组件.

现在: 多数在物理服务器上面部署应用程序都是采kubectl用容器的方式,容器类似于虚拟机,它们都具有自己的文件系统、CPU、内存、进程空间等, 且由于它们与基础架构分离，因此可以跨云和 OS 发行版本进行移植。基于此特点被企业大范围使用.

为什么需要使用k8s容器?

若出现这样一个环境: 在生产环境中如果一个容器发生故障,则我们需要手动去启动另外一个容器,这样的操作是对我们的管理员来说是不太方便的, 若一个容器出现故障,另一个容器可以自动启动容器接管故障的容器,这样是最好的.

k8s就可以实现该效果,Kubernetes 提供了一个可弹性运行分布式系统的框架。 Kubernetes 会满足你的扩展要求、故障转移、部署模式等。

k8s功能: 服务发现和负载均衡, 存储编排, 自动部署和回滚, 自动完成装箱计算, 自我修复, 密钥与配置管理

名词解释

secret

Secret有三种类型：

k8s的组成

k8s是由组件,API,对象等组成.

包含所有相互关联组件的 Kubernetes 集群图如下:

组件


API

Kubernetes 控制面 的核心是 API 服务器。 API 服务器负责提供 HTTP API，以供用户、集群中的不同部分和集群外部组件相互通信。

对象

Kubernetes对象是Kubernetes系统中的持久实体。Kubernetes使用这些实体来表示集群的状态.

具体来说，他们可以描述：

Kubernetes 架构

Kubernetes 架构由节点,控制面到节点通信, 控制器, 云控制器管理器组成.

master 流程图


节点

节点可以是一个虚拟机或者物理机器，取决于所在的集群配置。 每个节点包含运行 Pods 所需的服务， 这些 Pods 由 控制面 负责管理.

节点上的组件包括 kubelet、 容器运行时以及 kube-proxy。

节点状态

可以使用 kubectl 来查看节点状态和其他细节信息：

kubectl describe node <�节点名称>

一个节点包含以下信息:

控制面到节点通信

控制器

在 Kubernetes 中，控制器通过监控集群 的公共状态，并致力于将当前状态转变为期望的状态。

举个例子: 当前室内温度为20度, 我们通过调节遥控器,使其温度上升至24度, 这20度到24度的变化即为让其从当前状态接近期望状态。

控制器模式分为直接控制和通过API服务器来控制.

云控制器管理器

云控制器管理器是指嵌入特定云的控制逻辑的 控制平面组件。 云控制器管理器允许您链接聚合到云提供商的应用编程接口中， 并分离出相互作用的组件与您的集群交互的组件。

云控制器管理器中的控制器包括：

Kubernetes 安全性

云原生安全

云原生安全4个C: 云(Cloud)、集群(Cluster)、容器(Container)和代码(Code)

云原生安全模型的每一层都是基于下一个最外层，代码层受益于强大的基础安全层（云、集群、容器）。我们无法通过在代码层解决安全问题来为基础层中糟糕的安全标准提供保护。

基础设施安全

Kubetnetes 基础架构关注领域

建议

通过网络访问 API 服务（控制平面)

所有对 Kubernetes 控制平面的访问不允许在 Internet 上公开，同时应由网络访问控制列表控制，该列表包含管理集群所需的 IP 地址集。

通过网络访问 Node（节点)

节点应配置为 仅能 从控制平面上通过指定端口来接受（通过网络访问控制列表）连接，以及接受 NodePort 和 LoadBalancer 类型的 Kubernetes 服务连接。如果可能的话，这些节点不应完全暴露在公共互联网上。

Kubernetes 云访问提供商的 API

每个云提供商都需要向 Kubernetes 控制平面和节点授予不同的权限集。为集群提供云提供商访问权限时，最好遵循对需要管理的资源的最小特权原则。Kops 文档提供有关 IAM 策略和角色的信息。

访问 etcd

对 etcd（Kubernetes 的数据存储）的访问应仅限于控制平面。根据配置情况，你应该尝试通过 TLS 来使用 etcd。更多信息可以在 etcd 文档中找到。

etcd 加密

在所有可能的情况下，最好对所有驱动器进行静态数据加密，但是由于 etcd 拥有整个集群的状态（包括机密信息），因此其磁盘更应该进行静态数据加密。

集群组件安全

容器安全

代码安全

Kubernetes架构常见问题

Kubernetes ATTACK 矩阵

信息泄露

云账号AK泄露

API凭证（即阿里云AccessKey）是用户访问内部资源最重要的身份凭证。用户调用API时的通信加密和身份认证会使用API凭证.

API凭证是云上用户调用云服务API、访问云上资源的唯一身份凭证。

API凭证相当于登录密码，用于程序方式调用云服务API.

k8s configfile泄露

kubeconfig文件所在的位置:

$HOME/.kube/config

Kubeconfig文件包含有关Kubernetes集群的详细信息，包括它们的位置和凭据。

云厂商会给用户提供该文件,以便于用户可以通过kubectl对集群进行管理. 如果攻击者能够访问到此文件（如办公网员工机器入侵、泄露到Github的代码等），就可以直接通过API Server接管K8s集群，带来风险隐患。

Master节点SSH登录泄露

常见的容器集群管理方式是通过登录Master节点或运维跳板机，然后再通过kubectl命令工具来控制k8s。

云服务器提供了通过ssh登陆的形式进行登陆master节点.

若Master节点SSH连接地址泄露,攻击者可对ssh登陆进行爆破,从而登陆上ssh,控制集群.

容器组件未鉴权服务

Kubernetes架构下常见的开放服务指纹如下:

注:前六个重点关注: 一旦被控制可以直接获取相应容器、相应节点、集群权限的服务

了解各个组件被攻击时所造成的影响

组件分工图:

假如用户想在集群里面新建一个容器集合单元, 流程如下:

  1. 用户与 kubectl进行交互,提出需求(例: kubectl create -f pod.yaml)
  2. kubectl 会读取 ~/.kube/config 配置，并与 apiserver 进行交互，协议：http/https
  3. apiserver 会协同 ETCD, kube-controller-manager, scheler 等组件准备下发新建容器的配置给到节点，协议：http/https
  4. apiserver 与 kubelet 进行交互，告知其容器创建的需求，协议：http/https；
  5. kubelet 与Docker等容器引擎进行交互，创建容器，协议：http/unix socket.
  6. 容器已然在集群节点上创建成功

攻击apiserver

apiserver介绍:
在Kubernetes中,对于未鉴权对apiserver, 能访问到 apiserver 一般情况下就能获取了集群的权限.

在攻击者眼中Kubernetes APIServer

默认情况下apiserver都有鉴权:

未鉴权配置如下:

对于这类的未鉴权的设置来说，访问到 apiserver 一般情况下就获取了集群的权限：

如何通过apiserver来进行渗透,可参考:https://Kubernetes.io/docs/reference/generated/kubectl/kubectl-commands

攻击kubelet

每一个Node节点都有一个kubelet(每个节点上运行的代理)服务，kubelet监听了10250，10248，10255等端口。

10250端口,是kubelet与apiserver进行通信对主要端口, 通过该端口,kubelet可以知道当前应该处理的任务.该端口在最新版Kubernetes是有鉴权的, 但在开启了接受匿名请求的情况下，不带鉴权信息的请求也可以使用10250提供的能力, 在Kubernetes早期,很多挖矿木马基于该端口进行传播.

在配置文件中,若进行如下配置,则可能存在未授权访问漏洞.

/var/bin/kubulet/config/yaml

若10250端口存在未授权访问漏洞,我们可以直接访问/pods进行查看

根据在pods中获取的信息,我们可以在容器中执行命令

curl -Gks https://host:10250/exec/{namespace}/{podname}/{containername} -d 'input=1' -d 'output=1' -d 'tty=1' -d 'command=whoami'

上述命令得到websocket地址，连接websocket得到命令结果：

使用wscat工具连接websocket

wscat -c “https://X.X.X.X:10250/{websocket}” --no-check

即可得到我们执行命令的结果.

获取token

/var/run/secrets/kubernetes.io/serviceaccount

然后即可访问kube-api server,获取集群权限

curl -ks -H "Authorization: Bearer ttps://master:6443/api/v1/namespaces/{namespace}/secrets

"

攻击kubelet总体步骤如下:

攻击dashboard

dashboard登陆链接如下:

http://xxx.xxx.xxx.xxx:xxxx/api/v1/namespaces/kubernetes-dashboard/services/https:kubernetes-dashboard:/proxy/#/login

dashboard界面如下:

dashboard是Kubernetes官方推出的控制Kubernetes的图形化界面.在Kubernetes配置不当导致dashboard未授权访问漏洞的情况下，通过dashboard我们可以控制整个集群。

默认情况下, dashboard是需要进行鉴权操作的,当用户开启了enable-skip-login时可以在登录界面点击Skip跳过登录进入dashboard.

通过skip登陆的dashboard默认是没有操作集群的权限,因为Kubernetes使用RBAC(Role-based access control)机制进行身份认证和权限管理，不同的serviceaccount拥有不同的集群权限。

但有些开发者为了方便或者在测试环境中会为Kubernetes-dashboard绑定cluster-admin这个ClusterRole（cluster-admin拥有管理集群的最高权限）.

为Kubernetes-dashboard绑定cluster-admin 设置如下:

  1. 新建dashboard-admin.yaml内容
  2. apiVersion: rbac.authorization.k8s.io/v1kind: ClusterRoleBindingmetadata: name: kubernetes-dashboardroleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: cluster-adminsubjects : kind: ServiceAccount name: kubernetes-dashboard namespace: kubernetes-dashboard
  3. kubectl create -f dashboard-admin.yaml

后通过skip登陆dashboard便有了管理集群的权限.

创建Pod控制node节点,该pod主要是将宿主机根目录挂载到容器tmp目录下。

新建一个Pod如下:

通过该容器的tmp目录管理node节点的文件

攻击etcd

Kubernetes默认使用了etcd v3来存储数据, 若能na
etcd对内暴露2379端口，本地127.0.0.1可免认证访问. 其他地址要带—endpoint参数和cert进行认证。

未授权访问流程:

攻击docker remote api(Docker daemon公网暴露)

2375是docker远程操控的默认端口，通过这个端口可以直接对远程的docker 守护进程进行操作。Docker 守护进程默认监听2375端口且未鉴权.

当机器以方式启动daemon时，可以在外部机器对该机器的docker daemon进行直接操作：

docker daemon -H=0.0.0.0:2375

之后依次执行systemctl daemon-reload、systemctl restart docker

外部主机使用 即可操作暴露2375端口的主机.

-H

因此当你有访问到目标Docker API 的网络能力或主机能力的时候，你就拥有了控制当前服务器的能力。我们可以利用Docker API在远程主机上创建一个特权容器，并且挂载主机根目录到容器.

检测目标是否存在docker api未授权访问漏洞的方式也很简单，访问http://[host]:[port]/info路径是否含有ContainersRunning、DockerRootDir等关键字。

攻击kubectl proxy

二次开发所产生的问题

管理Kubernetes无论是使用 kubectl 或 Kubernetes dashboard 的UI功能，其实都是间接在和 APIServer 做交互.

如果有需求对k8s进行二次开发的话,大部分的开发功能请求了 APIServer 的 Rest API 从而使功能实现的。

例如:

类似于这样去调用apiserver, 攻击者若修改namespace、pod和容器名, 那么即可造成越权.

推荐工具

Kube-Hunter扫描漏洞

kube-hunter是一款用于寻找Kubernetes集群中的安全漏洞扫描器

下载地址: https://github.com/aquasecurity/kube-hunter

CDK(强推)

CDK是一款为容器环境定制的渗透测试工具，在已攻陷的容器内部提供零依赖的常用命令及PoC/EXP。集成Docker/K8s场景特有的 逃逸、横向移动、持久化利用方式，插件化管理。

下载地址: https://github.com/cdk-team/CDK/wiki/CDK-Home-CN

参考链接

https://developer.aliyun.com/article/765449?groupCode=aliyunsecurity
https://xz.aliyun.com/t/4276#toc-2
https://www.secrss.com/articles/29544
https://kubernetes.io/zh/docs/concepts/workloads/pods/#what-is-a-pod
https://www.huweihuang.com/kubernetes-notes/concepts/architecture/kubernetes-architecture.html
https://www.kubernetes.org.cn/service-account
https://www.aquasec.com/cloud-native-academy/cloud-native-applications/cloud-native-infrastructure/
https://www.cdxy.me/?p=827

⑽ kubernetes与docker的关系是什么

合作关系，Docker作为单一的容器技术工具并不能很好地定义容器的“组织方式”和“管理规范”，难以独立地支撑起生产级大规模容器化部署的要求。因此容器技术的发展就迅速走向了以Kubernetes为代表的“容器编排”的技术路线.

Kubernetes的出现也重新定义了微服务架构的技术方向，“云原生”及“ServiceMesh(服务网格)”等概念，很大程度上也是依赖于Kubernetes所提供的基础能力。




(10)重启k8s的命令扩展阅读：

常用命令分享

拉取docker镜像

docker pull image_name

查看宿主机上的镜像，Docker镜像保存在/var/lib/docker目录下:

docker images

删除镜像

docker rmi
docker.io/tomcat:7.0.77-jre7 或者 docker rmi b39c68b7af30

查看当前有哪些容器正在运行

docker ps

查看所有容器

docker ps -a

启动、停止、重启容器命令：

docker start container_name/container_iddocker stop container_name/container_iddocker restart container_name/container_id

后台启动一个容器后，如果想进入到这个容器，可以使用attach命令：

docker attach container_name/container_id

删除容器的命令：

docker rm container_name/container_id

查看当前系统Docker信息

docker info

阅读全文

与重启k8s的命令相关的资料

热点内容
新电脑管家下载好怎么解压 浏览：524
php获取接口数据 浏览：763
最后的命令 浏览：921
如何添加手机app桌面快捷图标 浏览：427
ui设计师与程序员 浏览：417
寿司pdf 浏览：828
pythonbg是什么 浏览：248
c数值算法程序大全 浏览：785
android整点报时 浏览：221
稀土pdf 浏览：536
单片机电子锁 浏览：596
通达信机智资金流指标公式源码 浏览：216
php安装xsl扩展 浏览：842
python如何使用help 浏览：367
上汽荣威app在哪里查询 浏览：903
冰柜压缩机温度108 浏览：720
阿里云邮smtp服务器地址 浏览：252
解压馆认知理解 浏览：239
为什么使用非官方服务器会封号 浏览：9
佛山加密文档软件 浏览：813
  • beijing
  • tianjin
  • anshun
  • baoding
  • baoshan
  • benxi
  • changde
  • chaozhou
  • chengde
  • chengdu
  • chenggu
  • conghua
  • dazhou
  • dongying
  • enshi
  • fenghua
  • fuyang
  • ganzhou
  • gaoming
  • geermu
  • gubaotou
  • hami
  • hefei
  • hetian
  • heyuan
  • huaian
  • huaibei
  • huaihua
  • huizhou
  • huzhou
  • jiashan
  • jiexiu
  • jimo
  • jingzhou
  • jinhua
  • jintan
  • jiujiang
  • jurong
  • kuerle
  • kunming
  • laixi
  • liaocheng
  • lingbao
  • liuan
  • lvshun
  • maanshan
  • maoming
  • meizhou
  • mianxian
  • nanan
  • nanjing
  • nantong
  • panzhihua
  • pingdu
  • pinghu
  • puning
  • qingdao
  • qingyuan
  • rugao
  • rushan
  • sanya
  • shenyang
  • shuyang
  • siping
  • taiyuan
  • taizhou1
  • tongchuan
  • weihai
  • wendeng
  • wuhan
  • wulanhaote
  • xiangfan
  • xichang
  • xingtai
  • xinzhou
  • yanbian
  • yancheng
  • yangzhou
  • yantai
  • yanzhou
  • yichang
  • yichun1
  • yili
  • yining
  • yiwu
  • yuhuan
  • yulin1
  • yuxi
  • zengcheng
  • zhangjiagang
  • changle
  • changsha
  • changzhi
  • zhaodong
  • zhaoqing
  • zhucheng
  • zhuji
  • xinji
  • xiangyin
  • gongzhuling