在昨天我们谈完如何使用Azure Container Registry异地复写建立多份Container Image後
我们来聊聊如何企业中使用Azure Kubernetes Service,我们会谈到Azure
Kubernetes Service Cluster,部署YAML档案,整合Azure Container
Registry以部署container images。
Cluster是基於Node的 , Kubernetes Cluster中有两种类型的Node可以提供特定
的功能。
-Control plane nodes:这些Node承载Cluster Control plane,并保留用於
控制Cluster服务。他们负责提供您和所有其他Node用於通信的API。这些Node上
没有部署或计划任何工作负载。
-Nodes:这些Node负责执行自定义工作负载和应用程序。
-Single control plane and multiple nodes
Single control plane and multiple nodes是最常见的架构模式。此模式最
容易部署,但不能为Cluster的cluster's core management提供高可用性。
尽管可用性不如其他架构好,但这种架构对於大多数情况而言应该足够了。如果
您要处理生产方案,则此体系结构可能不是最佳解决方案。
-Single control plane and a single node
Single control plane and a single node结构是先前体系结构的变体,并用
於开发环境中。此体系结构仅提供一个同时承载control plane和Work Node,在
测试或尝试不同的Kubernetes概念时,它很有用。Single control plane and
a single node限制了Cluster扩展,并使该体系结构不适用於生产使用。
当建立新的AKS Cluster时,需要设定几个不同的资讯项目。 每个项目都会影响
Cluster的最後设定。
这些项目包括:
-Node pools
-Node count
-Automatic routing
你要建立「 node pools 」,以分组 AKS Cluster中的Node。 当建立Node
Pool时,您要为node pool.中的每个Node指定VM大小,node pool会使用virtual
machine scale sets作为基础结构,以供Cluster调整node pool中的node数目
。 在node pool中建立的新Node,其大小一律与您在建立node pool时所指定的
大小相同。
Node count是Cluster在Node Pool中将拥有的Node数目,Node是Azure VM,你
可以变更其大小和计数以符合使用模式。
根据预设,Kubernetes Cluster会封锁所有的外部通讯。 例如,假设你要部署
可供所有用户端存取的网站,你必须以手动方式建立「输入」,其包含允许连入
用户端连线到该特定服务的例外状况。 此设定需要与网路相关的变更,以将要求
从用户端转送到丛集上的内部 IP,最後再送达应用程序。 视特定需求而定,
此程序可能会很复杂。
输入控制器可供将应用程序部署至全球并予以公开,却不必设定与网路相关的服务。
Ingress controllers会建立反向 Proxy 服务器,其会自动允许从单一DNS输出
提供所有要求,你不必在每次部署新服务时建立 DNS 记录,输入控制器会负责处理
。 当新的输入部署到Cluster时,Ingress controller会在Azure受控DNS区域
上建立一笔新记录,并将其连结至现有的负载平衡器。 此功能可供透过网际网路
轻松存取资源,而不需要额外的设定。
Kubernetes Pod 会将容器和应用程序分组成逻辑结构。 这些 Pod 没有智慧,
且由一或多个应用程序Container所组成,其每一个都有一个 IP 位址、网路规则
和公开的连接埠。
Kubernetes manifest files可供以宣告方式使用YAML 格式来描述工作负载,
并简化 Kubernetes 物件管理,假设必须手动部署工作负载,你必须考虑和管理
数个层面,你必须建立Container、选取特定的Node、将Node包在Pod 中、
执行 Pod、监视执行等,manifest files范例如下:
# deployment.yaml
# ...
spec:
selector:
matchLabels:
app: contoso-website
# ...
容器的网路设定为暂时性。 容器的设定和容器内资料不会在执行之间持续。 在
删除容器之後,除非设定使用磁碟区,否则便会遗失所有资讯。 这同样适用於
容器的网路设定和任何指派给容器的 IP 位址。
Kubernetes 服务是一种工作负载,其会抽象化网路工作负载的 IP 位址。
Kubernetes 服务会作为负载平衡器,并使用连接埠转送规则,将流量重新导向
到特定连接埠的特定连接埠。
-ClusterIP:这个值只会在内部公开应用程序。 此选项允许服务作为连接埠
转寄站,并会在Cluster内部开放使用服务。 根据预设在省略时会使用这个值。
-NodePort:这个值会向外部公开服务。 其会为每个Node指派能回应该服务
的静态连接埠,透过 nodeIp:port 存取时,节点会自动将要求重新导向到
ClusterIP 类型的内部服务。 此服务接着会将要求转送至应用程序。
-LoadBalancer:这个值会使用 Azure 的负载平衡解决方案向外部公开
服务。 建立时,这个资源会启动 Azure 订用帐户内的 Azure Load
Balancer资源。 此外,这个类型会自动建立 NodePort 服务,负载平衡器
的流量会重新导向到这个服务,且会建立 ClusterIP 服务以在内部进行转送。
-ExternalName:这个值会透过 CNAME 记录使用 DNS 解析来对应
服务。 您可以使用这个服务类型来将流量导向位於 Kubernetes Cluster
外部的服务。
Ingress会向Cluster内部的服务公开来自Cluster外部的 HTTP 和 HTTPS 流量
的路由,你会使用ingress rules来定义ingress routes。 若没有定义这些route
,Kubernetes Cluster会拒绝所有传入流量。
假设想要允许用户端透过 http://contoso.com 网址存取网站。 若要让
用户端存取Cluster内部的应用程序,则Cluster必须回应网站的 CNAME,并将要求
路由到相关的 Pod。
以下为ingress.yaml范例档内容
#ingress.yaml
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
name: contoso-website
annotations:
kubernetes.io/ingress.class: addon-http-application-routing
spec:
rules:
- host: contoso.<uuid>.<region>.aksapp.io
http:
paths:
- backend: # How the ingress will handle the requests
serviceName: contoso-website # Which service the request will be forwarded to
servicePort: http # Which port in that service
path: / # Which path is this rule referring to
手把手建立Azure Kubernetes Service Cluster步骤
手把手建立Azure Kubernetes Service Cluster部署应用程序步骤
https://docs.microsoft.com/zh-tw/learn/modules/aks-deploy-container-app/5-exercise-deploy-app
手把手启用应用程序的网路存取步骤
https://docs.microsoft.com/zh-tw/learn/modules/aks-deploy-container-app/7-exercise-expose-app
Day27教学教材:
https://docs.microsoft.com/zh-tw/learn/modules/aks-deploy-container-app/
好的,昨天的星飨道是5点起床,温莎就更拚了,4点半XD 今天还是用早餐跟大家道声早安呦~~ 由於台中...
以下是将各项风险汇整,IoT应用之前,可以先考虑各层面的风险之後,评估自身条件,是否能透过其他辅助机...
本篇文章请参考 [Vue2Leaflet系列一] 从vue-cli安装到建置地图 之前介绍过Leaf...
今天的影片内容为介绍具有强大功能的Pandas模组(对...熊猫模组) 利用这个模组,可以很方便的执...
准备出游,6.2 的 Raft 之後再补 5.3 提到 state machine replica...