标签：设计 环境变量 schedule 目的 bind resource sse 环境部署 条件
kubernetes简单介绍和实战在本文中，我们从技术细节上对kubernetes进行简单运用介绍，利用一些yaml脚本层面上实例告诉大家kubernetes基本概念。Kubernetes以及它呈现出的编程范式值得你去使用和整合到自己的技术栈中。
Kubernetes最初认为是谷歌开源的容器集群管理系统，是Google多年大规模容器管理技术Borg或Omega的开源版本。准确来说的话，kubernetes更是一个全新的平台，一个全新的
平台管理工具，它是专门为job和service设计。完全开放，2014年6月开始接受公开的commit，任何人都可以提供意见。由于kubernetes简化了开发、运维和管理负荷，越来越多
的企业开始在生产环境使用，因此kubernetes得到了迅速的发展。
Kubernetes主要由以下几个核心组件组成：
如果只是为了了解kubernetes，可以使用minikube的方式进行单机安装，minikube 实际就是本地创建了一个虚拟机,里面运行了kubernetes 的一些必要的环境,相当于 k8s 的服务环境,创建 pod,service,deployment等都是在里面进行创建和管理。
在本文中，我使用kubeadm方式安装kubernetes 1.10.0，具体kubernetes部署步骤：
请注意：上述环境只是测试环境，生产环境部署大同小异。
Container（容器）是一种便携式、轻量级的操作系统级虚拟化技术。它使用 namespace 隔离不同的软件运行环境，并通过镜像自包含软件的运行环境，
从而使得容器可以很方便的在任何地方运行。由于容器体积小且启动快，因此可以在每个容器镜像中打包一个应用程序。这种一对一的应用镜像关系拥有很多好处。使用容器，
不需要与外部的基础架构环境绑定, 因为每一个应用程序都不需要外部依赖，更不需要与外部的基础架构环境依赖。完美解决了从开发到生产环境的一致性问题。
容器同样比虚拟机更加透明，这有助于监测和管理。尤其是容器进程的生命周期由基础设施管理，而不是由容器内的进程对外隐藏时更是如此。最后，
每个应用程序用容器封装，管理容器部署就等同于管理应用程序部署。
在 Kubernetes 必须要使用 Pod 来管理容器，每个 Pod 可以包含一个或多个容器。
上面已经说了“Pod是kubernetes中你可以创建和部署的最小也是最简的单位。一个Pod代表着集群中运行的一个进程。”Pod中封装着应用的容器（有的情况下是好几个容器）,
存储、独立的网络IP，管理容器如何运行的策略选项。Pod代表着部署的一个单位：kubernetes中应用的一个实例，可能由一个或者多个容器组合在一起共享资源。
请注意：Docker是kubernetes中最常用的容器运行时，但是Pod也支持其他容器运行时。
（1）一个Pod中运行一个容器
“每个Pod中一个容器”的模式是最常见的用法；在这种使用方式中，你可以把Pod想象成是单个容器的封装，kuberentes管理的是Pod而不是直接管理容器。
apiVersion: v1
kind: Pod
metadata:
name: nginx-test
labels:
app: web
spec:
containers:
- name: front-end
image: nginx:1.7.9
ports:
- containerPort: 80创建Pod：
kubectl create -f ./pod1-deployment查看Pod：
kubectl get po
查看Pod详细情况：
kubectl describe po nginx-test
进入到Pod（容器）内部：
kubectl exec -it nginx-test /bin/bash（2）在一个Pod中同时运行多个容器
说明：在一个Pod中同时运行多个容器是一种比较高级的用法。只有当你的容器需要紧密配合协作的时候才考虑用这种模式。
一个Pod中也可以同时封装几个需要紧密耦合互相协作的容器，它们之间共享资源。这些在同一个Pod中的容器可以互相协作成为一个service单位——一个容器共享文件，
另一个“sidecar”容器来更新这些文件。Pod将这些容器的存储资源作为一个实体来管理。
apiVersion: v1
kind: Pod
metadata:
name: rss-site
labels:
app: web
spec:
containers:
- name: front-end
image: nginx:1.7.9
ports:
- containerPort: 80
- name: rss-reader
image: redis
ports:
- containerPort: 88创建Pod：
kubectl create -f ./test-deployment
查看pod
kubectl get po
查看Pod详细情况
kubectl describe po rss-site
进入front-end内部：
kubectl exec -it rss-site -c front-end /bin/bash
进入rss-reade内部：
kubectl exec -it rss-site -c rss-reader /bin/bash以上是关于Pod的简单介绍，如需了解更多，请参考Pod
Node 是 Pod 真正运行的主机，可以物理机，也可以是虚拟机。为了管理 Pod，每个 Node 节点上至少要运行 container runtime（比如 docker 或者 rkt）、kubelet 和 kube-proxy 服务。
Namespace 是对一组资源和对象的抽象集合，比如可以用来将系统内部的对象划分为不同的项目组或用户组。常见的 pods, services, replication controllers 和 deployments 等都是属于
某一个 namespace 的（默认是 default），而 node, persistentVolumes 等则不属于任何 namespace。
我们既然有Pod了，为什么还要使用Deployment呢？这是因为实际工作中，我们很少会直接在kubernetes中创建单个Pod。因为Pod的生命周期是短暂的，用后即焚的实体。
Deployment 为 Pod 和 ReplicaSet 提供了一个声明式定义(declarative)方法，用来替代以前的ReplicationController 来方便的管理应用。
你只需要在 Deployment 中描述想要的目标状态是什么，Deployment controller 就会帮你将 Pod 和ReplicaSet 的实际状态改变到你的目标状态。你可以定义一个全新的 Deployment 来创建
ReplicaSet 或者删除已有的 Deployment 并创建一个新的来替换。
RC是K8s集群中最早的保证Pod高可用的API对象。通过监控运行中的Pod来保证集群中运行指定数目的Pod副本。指定的数目可以是多个也可以是1个；少于指定数目，RC就会启动运行新的Pod副本；
多于指定数目，RC就会杀死多余的Pod副本。即使在指定数目为1的情况下，通过RC运行Pod也比直接运行Pod更明智，因为RC也可以发挥它高可用的能力，保证永远有1个Pod在运行。RC是K8s较早期
的技术概念，只适用于长期伺服型的业务类型，比如控制小机器人提供高可用的Web服务。
RS是新一代RC，提供同样的高可用能力，区别主要在于RS后来居上，能支持更多种类的匹配模式。副本集对象一般不单独使用，而是作为Deployment的理想状态参数使用。
比如，我们这里定义一个简单的nginx应用：
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
name: nginx-test
namespace: test
spec:
replicas: 3
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.7.9
ports:
- containerPort: 80创建deploy
kubectl create -f ./nginx-deployment
查看deploy
kubectl get deploy --namespace=test
查看rs（副本集）
kubectl get rs --namespace=test
查看pods（容器组）
kubectl get po --namespace=test关于Deployment的应用还有很多，如：扩容、缩容、滚动升级、回滚应用等，这里由于篇幅的问题不再一一介绍，详见Deployment的应用
Label 是识别 Kubernetes 对象的标签，以 key/value 的方式附加到对象上（key 最长不能超过 63 字节，value 可以为空，也可以是不超过 253 字节的字符串）。
Label 不提供唯一性，并且实际上经常是很多对象（如 Pods）都使用相同的 label 来标志具体的应用。
Label 定义好后其他对象可以使用 Label Selector 来选择一组相同 label 的对象（比如 ReplicaSet 和 Service 用 label 来选择一组 Pod）。Label Selector 支持以下几种方式：
Service account是为了方便Pod里面的进程调用Kubernetes API或其他外部服务。
运行在pod里的进程需要调用Kubernetes API以及非Kubernetes API的其它服务。Service Account它并不是给kubernetes集群的用户使用的，而是给pod里面的进程使用的，它为pod提供必要的身份认证。
apiVersion: v1
kind: Namespace
metadata:
name: datagrand
labels:
name: test创建namespace：test
kubectl create -f ./test.yaml
查看命名空间test的sa
kubectl get sa -n test
查看命名空间test生成的default
kubectl get sa default -o yaml -n test
我们可以创建Deployment时，使用这个test命名空间了，如上例Deployment实战。Service Account为服务提供了一种方便的认知机制，但它不关心授权的问题。可以配合RBAC来为Service Account鉴权：
我们在Kubernetes Dashboard1.8.3部署中，碰到首次登入出现访问权限报错的问题，原因就是ServiceAccount的创建问题。
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: ClusterRoleBinding
metadata:
name: kubernetes-dashboard
labels:
k8s-app: kubernetes-dashboard
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: cluster-admin
subjects:
- kind: ServiceAccount
name: kubernetes-dashboard
namespace: kube-systemService Account介绍请参考博文
Secret解决了密码、token、密钥等敏感数据的配置问题，而不需要把这些敏感数据暴露到镜像或者Pod Spec中。Secret可以以Volume或者环境变量的方式使用。
Opaque类型的数据是一个map类型，要求value是base64编码格式：
创建admin账户
echo -n "admin" | base64
YWRtaW4=
echo -n "1f2d1e2e67df" | base64
MWYyZDFlMmU2N2Rm创建secret.yaml
cat >> secrets.yml << EOF
apiVersion: v1
kind: Secret
metadata:
name: mysecret
type: Opaque
data:
password: MWYyZDFlMmU2N2Rm
username: YWRtaW4=创建secret
kubectl create -f secrets.yml查看secret运行状态
kubectl get secret --all-namespacesapiVersion: v1
kind: Pod
metadata:
name: mypod
labels:
name: wtf
spec:
volumes:
- name: secrets
secret:
secretName: mysecret
containers:
- image: nginx:1.7.9
name: nginx
volumeMounts:
- name: secrets
mountPath: "/etc/secrets"
readOnly: true
ports:
- name: cp
containerPort: 5432
hostPort: 5432说明：这样就可以通过文件的方式挂载到容器内，在/etc/secrets目录下回
生成这个文件。
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
name: wordpress-deployment
spec:
replicas: 2
template:
metadata:
labels:
app: wordpress
spec:
containers:
- name: "wordpress"
image: "wordpress:latest"
ports:
- containerPort: 80
env:
- name: WORDPRESS_DB_USER
valueFrom:
secretKeyRef:
name: mysecret
key: username
- name: WORDPRESS_DB_PASSWORD
valueFrom:
secretKeyRef:
name: mysecret
key: password查看Pod运行状态
kubectl get po
NAME READY STATUS RESTARTS AGE
wordpress-deployment-6b569fbb7d-8qcpg 1/1 Running 0 2m
wordpress-deployment-6b569fbb7d-xwwkg 1/1 Running 0 2m进入容器内部查看环境变量
kubectl exec -it wordpress-deployment-694f4c79b4-cpsxw /bin/bash
root@wordpress-deployment-694f4c79b4-cpsxw:/var/www/html# env
WORDPRESS_DB_USER=admin
WORDPRESS_DB_PASSWORD=1f2d1e2e67df想要了解更多，请详见Kubernetes的Secret
ConfigMaps允许你将配置文件、命令行参数或环境变量中读取的配置信息与docker image分离，以保持集装箱化应用程序的便携性。即ConfigMap API给我们提供了向容器中注入配置信息的机制。
ConfigMap API资源用来保存key-value pair配置数据，这个数据可以在pods里使用，或者被用来为像controller一样的系统组件存储配置数据。虽然ConfigMap跟Secrets类似，但是ConfigMap更方便的处理不含敏感信息的字符串。
注意：ConfigMaps不是属性配置文件的替代品。ConfigMaps只是作为多个properties文件的引用。你可以把它理解为Linux系统中的/etc目录，专门用来存储配置文件的目录。
kind: ConfigMap
apiVersion: v1
metadata:
creationTimestamp: 2016-02-18T19:14:38Z
name: example-config
namespace: default
data:
example.property.1: hello
example.property.2: world
example.property.file: |-
property.1=value-1
property.2=value-2
property.3=value-3data一栏包括了配置数据，ConfigMap可以被用来保存单个属性，也可以用来保存一个配置文件。 配置数据可以通过很多种方式在Pods里被使用。ConfigMaps可以被用来：
更多ConfigMap实战，详见ConfigMap - Kubernetes
容器磁盘上文件的生命周期是短暂的，这就使得在容器中运行重要应用时出现一些问题。比如，当容器崩溃时，kubelet会重启它，但是容器中的文件将丢失--容器以干净的状态
（镜像最初的状态）重新启动。其次，在 Pod 中同时运行多个容器时，这些容器之间通常需要共享文件。Kubernetes 中的 Volume 抽象就很好的解决了这些问题。
Docker 中也有一个 volume 的概念，尽管它稍微宽松一些，管理也很少。在 Docker 中，卷就像是磁盘或是另一个容器中的一个目录。它的生命周期不受管理，直到最近才有了 local-disk-backed 卷。Docker 现在提供了卷驱动程序，但是功能还非常有限（例如Docker1.7只允许每个容器使用一个卷驱动，并且无法给卷传递参数）。
Kubernetes 中的卷有明确的寿命——与封装它的 Pod 相同。所以，卷的生命比 Pod 中的所有容器都长，当这个容器重启时数据仍然得以保存。当然，当 Pod 不再存在时，卷也将不复存在。也许更重要的是，Kubernetes 支持多种类型的卷，Pod 可以同时使用任意数量的卷。
要使用卷，需要为 pod 指定为卷（spec.volumes 字段）以及将它挂载到容器的位置（spec.containers.volumeMounts 字段）。
Kubernetes 支持以下类型的卷：
awsElasticBlockStore、azureDisk、azureFile、cephfs、csi、downwardAPI、emptyDir、fc (fibre channel)、flocker、gcePersistentDisk、gitRepo、glusterfs、hostPath、iscsi、local、nfs、persistentVolumeClaim、projected、portworxVolume、quobyte、rbd、scaleIO、secret、storageos、vsphereVolume等K8S的存储系统从基础到高级大致分为三个层次：普通Volume，Persistent Volume 和动态存储供应。
最简单的普通Volume是单节点Volume。它和Docker的存储卷类似，使用的是Pod所在K8S节点的本地目录。
它和普通Volume的区别是什么呢？
普通Volume和使用它的Pod之间是一种静态绑定关系，在定义Pod的文件里，同时定义了它使用的Volume。Volume 是Pod的附属品，我们无法单独创建一个Volume，因为它不是一个独立的K8S资源对象。
而Persistent Volume 简称PV是一个K8S资源对象，所以我们可以单独创建一个PV。它不和Pod直接发生关系，而是通过Persistent Volume Claim，简称PVC来实现动态绑定。Pod定义里指定的是PVC，然后PVC会根据Pod的要求去自动绑定合适的PV给Pod使用。
PV的访问模式有三种：
一般来说，PV和PVC的生命周期分为5个阶段：
根据这5个阶段，Volume的状态有以下4种：
变成Released的PV会根据定义的回收策略做相应的回收工作。有三种回收策略：
在实际使用场景里，PV的创建和使用通常不是同一个人。这里有一个典型的应用场景：管理员创建一个PV池，开发人员创建Pod和PVC，PVC里定义了Pod所需存储的大小和访问模式，然后PVC会到PV池里自动匹配最合适的PV给Pod使用。
前面在介绍PV的生命周期时，提到PV的供给有两种方式，静态和动态。其中动态方式是通过StorageClass来完成的，这是一种新的存储供应方式。
使用StorageClass有什么好处呢？除了由存储系统动态创建，节省了管理员的时间，还有一个好处是可以封装不同类型的存储供PVC选用。在StorageClass出现以前，PVC绑定一个PV只能根据两个条件，一个是存储的大小，另一个是访问模式。在StorageClass出现后，等于增加了一个绑定维度。
比如这里就有两个StorageClass，它们都是用谷歌的存储系统，但是一个使用的是普通磁盘，我们把这个StorageClass命名为slow。另一个使用的是SSD，我们把它命名为fast。
在PVC里除了常规的大小、访问模式的要求外，还通过annotation指定了Storage Class的名字为fast，这样这个PVC就会绑定一个SSD，而不会绑定一个普通的磁盘。
限于篇幅问题，我这里简单说一下emptyDir、nfs、PV和PVC。
EmptyDir类型的volume创建于pod被调度到某个宿主机上的时候，而同一个pod内的容器都能读写EmptyDir中的同一个文件。一旦这个pod离开了这个宿主机，EmptyDir中的数据就会被永久删除。所以目前EmptyDir类型的volume主要用作临时空间，比如Web服务器写日志或者tmp文件需要的临时目录。
apiVersion: v1
kind: Pod
metadata:
labels:
name: test-emptypath
role: master
name: test-emptypath
spec:
containers:
- name: test-emptypath
image: nginx:1.7.9
volumeMounts:
- name: log-storage
mountPath: /tmp/
volumes:
- name: log-storage
emptyDir: {}apiVersion: v1
kind: Pod
metadata:
name: datagrand
spec:
containers:
- name: test1
image: nginx:1.7.9
volumeMounts:
- name: log-storage
mountPath: /usr/share/nginx/html
- name: test2
image: centos
volumeMounts:
- name: log-storage
mountPath: /html
command: ["/bin/sh","-c"]
args:
- while true;do
data >> /html/index.html;
sleep 1;
done
volumes:
- name: log-storage
emptyDir: {}简单解释下上面的内容：
在这个例子中，我们定义了一个名为HTML的卷。它的类型是emptyDir，这意味着当一个Pod被分配到一个节点时，卷先被创建，并只要Pod在节点上运行时，这个卷仍存在。正如名字所说，它最初是空的。第一容器运行nginx的
服务器并将共享卷挂载到目录/ usr /share/ nginx /html。第二容器使用centos的镜像，并将共享卷挂载到目录/HTML。每一秒，第二容器添加当前日期和时间到index.html文件中，它位于共享卷。当用户发出一个HTTP请求到Pod，
nginx的服务器读取该文件并将其传递给响应请求的用户。
更多volume实战，详见Kubernetes部分Volume类型介绍及yaml示例--emptyDir
nfs 卷允许将现有的 NFS（网络文件系统）共享挂载到你的容器中。不像 emptyDir，当删除 Pod 时，nfs 卷的内容被保留，卷仅仅是被卸载。这意味着 NFS 卷可以预填充数据，并且可以在 pod 之间“切换”数据。 NFS 可以被多个写入者同时挂载。
apiVersion: v1
kind: Pod
metadata:
name: nginx-test
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.7.9
ports:
- containerPort: 80
volumeMounts:
#Mount the path to the container
- mountPath: "/tmp/"
name: pv0003
volumes:
- name: pv0003
nfs:
#fixed：This ip is the address of the nfs server
server: 192.168.246.169
#fixed：This path is shared externally by the nfs server
path: "/data"更多volume实战，详见Kubernetes部分Volume类型介绍及yaml示例--NFS（网络数据卷)
nfs 作为 k8s 的网络存储驱动，可以满足持久存储业务的需求，支持多节点读写。下面是两个Pod同时使用一个持久性volume实例。
#创建PV
apiVersion: v1
kind: PersistentVolume
metadata:
name: nfs-pv
spec:
capacity:
storage: 4Gi
accessModes:
- ReadWriteMany
nfs:
server: 192.168.246.168 ##NFS服务器的ip地址
path: "/data" ##NFS服务器上的共享目录#创建PVC
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: nfs-pvc
spec:
accessModes:
- ReadWriteMany
storageClassName: ""
resources:
requests:
storage: 3Gi#创建Deployment
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
labels:
app: nginx
spec:
replicas: 2
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.7.9
volumeMounts:
- mountPath: "/wtf"
name: datadir
volumes:
- name: datadir
persistentVolumeClaim:
claimName: nfs-pvc更多PV和PVC实战，详见实战kubernetes持久性卷使用
Kubernetes Pod 是有生命周期的，它们可以被创建，也可以被销毁，然而一旦被销毁生命就永远结束。 通过 ReplicaSets 能够动态地创建和销毁 Pod（例如，需要进行扩缩容，或者执行 滚动升级）。 每个 Pod 都会获取它自己的 IP 地址，即使这些 IP 地址不总是稳定可依赖的。 这会导致一个问题：在 Kubernetes 集群中，如果一组 Pod（称为 backend）为其它 Pod （称为 frontend）提供服务，那么那些 frontend 该如何发现，并连接到这组 Pod 中的哪些 backend 呢？
Kubernetes Service 定义了这样一种抽象：一个 Pod 的逻辑分组，一种可以访问它们的策略 —— 通常称为微服务。 这一组 Pod 能够被 Service 访问到，通常是通过 Label Selector（查看下面了解，为什么可能需要没有 selector 的 Service）实现的。
举个例子，考虑一个图片处理 backend，它运行了3个副本。这些副本是可互换的 —— frontend 不需要关心它们调用了哪个 backend 副本。 然而组成这一组 backend 程序的 Pod 实际上可能会发生变化，frontend 客户端不应该也没必要知道，而且也不需要跟踪这一组 backend 的状态。 Service 定义的抽象能够解耦这种关联。
对 Kubernetes 集群中的应用，Kubernetes 提供了简单的 Endpoints API，只要 Service 中的一组 Pod 发生变更，应用程序就会被更新。 对非 Kubernetes 集群中的应用，Kubernetes 提供了基于 VIP 的网桥的方式访问 Service，再由 Service 重定向到 backend Pod。
一个 Service 在 Kubernetes 中是一个 REST 对象，和 Pod 类似。 像所有的 REST 对象一样， Service 定义可以基于 POST 方式，请求 apiserver 创建新的实例。 例如，假定有一组 Pod，它们对外暴露了 9376 端口，同时还被打上 "app=MyApp" 标签。
kind: Service
apiVersion: v1
metadata:
name: my-service
spec:
selector:
app: MyApp
ports:
- protocol: TCP
port: 80
targetPort: 9376上述配置将创建一个名称为 “my-service” 的 Service 对象，它会将请求代理到使用 TCP 端口 9376，并且具有标签 "app=MyApp" 的 Pod 上。 这个 Service 将被指派一个 IP 地址（通常称为 “Cluster IP”），它会被服务的代理使用（见下面）。 该 Service 的 selector 将会持续评估，处理结果将被 POST 到一个名称为 “my-service” 的 Endpoints 对象上。
需要注意的是， Service 能够将一个接收端口映射到任意的 targetPort。 默认情况下，targetPort 将被设置为与 port 字段相同的值。 可能更有趣的是，targetPort 可以是一个字符串，引用了 backend Pod 的一个端口的名称。 但是，实际指派给该端口名称的端口号，在每个 backend Pod 中可能并不相同。 对于部署和设计 Service ，这种方式会提供更大的灵活性。 例如，可以在 backend 软件下一个版本中，修改 Pod 暴露的端口，并不会中断客户端的调用。
Kubernetes Service 能够支持 TCP 和 UDP 协议，默认 TCP 协议。
很多 Service 需要暴露多个端口。对于这种情况，Kubernetes 支持在 Service 对象中定义多个端口。 当使用多个端口时，必须给出所有的端口的名称，这样 Endpoint 就不会产生歧义，例如：
kind: Service
apiVersion: v1
metadata:
name: my-service
spec:
selector:
app: MyApp
ports:
- name: http
protocol: TCP
port: 80
targetPort: 9376
- name: https
protocol: TCP
port: 443
targetPort: 9377Service 抽象了该如何访问 Kubernetes Pod，但也能够抽象其它类型的 backend，例如：
根据以上的应用场景，我们都能够定义没有selector的Service，如下：
kind: Service
apiVersion: v1
metadata:
name: my-service
spec:
ports:
- protocol: TCP
port: 80
targetPort: 9376由于这个 Service 没有 selector，就不会创建相关的 Endpoints 对象。可以手动将 Service 映射到指定的 Endpoints：
kind: Endpoints
apiVersion: v1
metadata:
name: my-service
subsets:
- addresses:
- ip: 10.0.0.3 ##Endpoint IP = PodIP + ContainerPort
ports:
- port: 9376注意：Endpoint IP 地址不能是 loopback（127.0.0.0/8）、 link-local（169.254.0.0/16）、或者 link-local 多播（224.0.0.0/24）。
访问没有 selector 的 Service，与有 selector 的 Service 的原理相同。请求将被路由到用户定义的 Endpoint（该示例中为 10.0.0.3:9376）。
对一些应用（如 Frontend）的某些部分，可能希望通过外部（Kubernetes 集群外部）IP 地址暴露 Service。
Kubernetes ServiceTypes 允许指定一个需要的类型的 Service，默认是 ClusterIP 类型。
Type 的取值以及行为如下：
如果设置 type 的值为 "NodePort"，Kubernetes master 将从给定的配置范围内（默认：30000-32767）分配端口，每个 Node 将从该端口（每个 Node 上的同一端口）代理到 Service。该端口将通过 Service 的 spec.ports[*].nodePort 字段被指定。
如果需要指定的端口号，可以配置 nodePort 的值，系统将分配这个端口，否则调用 API 将会失败（比如，需要关心端口冲突的可能性）。
# pwd
/data
# tree -L 3
.
├── mysql
│?? ├── conf
│?? │?? └── my.cnf
│?? └── data
│?? ├── auto.cnf
│?? ├── edusoho
│?? ├── ibdata1
│?? ├── ib_logfile0
│?? ├── ib_logfile1
│?? ├── mysql
│?? └── performance_schema
├── nginx
│?? ├── conf
│?? │?? └── nginx.conf
│?? ├── edusoho
│?? │?? ├── api
│?? │?? ├── app
│?? │?? ├── bootstrap
│?? │?? ├── plugins
│?? │?? ├── src
│?? │?? ├── vendor
│?? │?? ├── vendor_user
│?? │?? └── web
│?? └── log
│?? └── error.log
├── php
│?? ├── log
│?? │?? └── php-fpm.log
│?? ├── php-fpm.conf
│?? ├── php.ini
│?? └── www.confapiVersion: v1
kind: Pod
metadata:
name: lamp-edusoho
labels:
app: lamp-edusoho
restartPolicy: Always
spec:
containers:
- name: nginx
abels:
app: lamp-nginx
image: dockerhub.datagrand.com/global/nginx:v1
ports:
- containerPort: 80
volumeMounts:
- name: datadir
mountPath: "/var/log/nginx/error.log"
subPath: ./nginx/log/error.log
- name: datadir
mountPath: "/etc/nginx/nginx.conf"
subPath: ./nginx/conf/nginx.conf
- name: datadir
mountPath: "/usr/share/nginx/html"
subPath: ./nginx/edusoho
- name: php
image: dockerhub.datagrand.com/global/php:v1
ports:
- containerPort: 9000
volumeMounts:
- mountPath: /usr/local/php/etc/php-fpm.conf
name: datadir
subPath: ./php/php-fpm.conf
- mountPath: /usr/local/php/etc/php-fpm.d/www.conf
name: datadir
subPath: ./php/www.conf
- mountPath: /usr/local/php/etc/php.ini
name: datadir
subPath: ./php/php.ini
- mountPath: /usr/local/php/var/log/php-fpm.log
name: datadir
subPath: ./php/log/php-fpm.log
- mountPath: /usr/share/nginx/html
name: datadir
subPath: ./nginx/edusoho
- name: mysql
image: dockerhub.datagrand.com/global/mysql:5.6
ports:
- containerPort: 3306
env:
- name: MYSQL_ROOT_PASSWORD
value: "123456"
- name: MYSQL_DATABASE
value: "edusoho"
- name: MYSQL_USER
value: "edusoho"
- name: MYSQL_PASSWORD
value: "edusoho"
args: [‘--character-set-server=utf8‘]
volumeMounts:
- name: datadir
mountPath: "/var/lib/mysql"
subPath: ./mysql/data
- name: datadir
mountPath: "/etc/my.cnf"
subPath: ./mysql/conf/my.cnf
volumes:
- name: datadir
persistentVolumeClaim:
claimName: nfs-pvcapiVersion: v1
kind: PersistentVolume
metadata:
name: nfs-pv
spec:
capacity:
storage: 4Gi
accessModes:
- ReadWriteMany
nfs:
server: 192.168.246.168 ##NFS服务器的ip地址
path: "/data" ##NFS服务器上的共享目录apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: nfs-pvc
spec:
accessModes:
- ReadWriteMany
storageClassName: ""
resources:
requests:
storage: 3GiapiVersion: v1
kind: Service
metadata:
name: edusoho
labels:
app: edusoho
spec:
type: NodePort
ports:
- port: 80
nodePort: 32756
selector:
app: lamp-edusoho查看Pod
kubectl get po -o wide
查看Service
kubectl get svc
进入容器内部某个应用，如这里的nginx
kubectl exec -it lamp-edusoho -c nginx /bin/bashhttp://192.168.246.168:32756/install/start-install.php
说明：这里的192.168.246.168是kubernetes的node节点IP，32756是Service中定义的nodePort。标签：设计 环境变量 schedule 目的 bind resource sse 环境部署 条件
原文地址：http://blog.51cto.com/wutengfei/2160771
