7. 网络
由于大量的Pods需要大量的手工网络配置，我们可以使用Service和Ingress对象来定义和抽象网络
ClusterIP
最常见的服务类型。ClusterIP是Kubernetes内部的一个虚拟IP，可以作为一组pods的单个端点使用。这种服务类型可以用作轮询负载均衡器。
NodePort
NodePort服务类型通过添加简单的路由规则扩展了ClusterIP。它在集群中的每个节点上打开一个端口(默认在30000-32767之间)，并将其映射到ClusterIP。这种服务类型允许将外部流量路由到集群。
loadbalance
LoadBalancer服务类型通过部署外部LoadBalancer实例来扩展NodePort。只有当你在一个有API来配置LoadBalancer实例的环境中，比如GCP、AWS、Azure甚至OpenStack，这才会起作用。
ExternalName
一种没有任何路由的特殊服务类型。ExternalName使用Kubernetes内部DNS服务器创建DNS别名。您可以使用它创建一个简单的别名来解析一个相当复杂的主机名，比如:my-cool-database-az1-uid123.cloud-provider-i-like.com。如果您想从Kubernetes集群获取外部资源，这一点尤其有用。
ClusterIP、NodePort和LoadBalancer相互扩展
如果需要更大的灵活性来公开应用程序，可以使用Ingress对象。入口提供了一种从集群外部为集群内的服务公开HTTP和HTTPS路由的方法。它通过配置路由规则来实现这一点，用户可以通过入口控制器设置和实现路由规则。
一个Ingress将所有流量发送到一个Service的例子，从Kubernetes文档中获取
入口控制器的标准特性可能包括:
LoadBalancing
TLS offloading/termination
Name-based virtual hosting
Path-based routing
许多入口控制器甚至提供了更多的功能，比如:
Redirects
Custom errors
Authentication
Session affinity
Monitoring
Logging
Weighted routing
Rate limiting.
Kubernetes还提供了一个具有NetworkPolicy概念的集群内部防火墙。NetworkPolicies是一个简单的IP防火墙(OSI三层或四层)，可以基于规则控制流量。您可以为传入(进入)和传出(出口)流量定义规则。NetworkPolicies的一个典型用例是限制两个不同名称空间之间的流量。
交互式教程-展示你的应用程序
现在，您可以在Kubernetes文档提供的交互式教程的第4部分中了解如何使用Service公开应用程序
7.1 demo
apiVersion: apps/v1 kind: Deployment metadata: name: nginx-deployment labels: app: nginx spec: replicas: 3 selector: matchLabels: app: nginx template: metadata: labels: app: nginx spec: containers: - name: nginx image: nginx:1.14.2 ports: - containerPort: 80
$ k apply -f nginx-deployment.yaml $ k expose deployment nginx-deployment 80 $ k get svc NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE kubernetes ClusterIP 10.96.0.1 <none> 443/TCP 51d nginx-deployment ClusterIP 10.101.106.248 <none> 80/TCP 8s $ curl 10.101.106.248:80 <!DOCTYPE html> <html> <head> <title>Welcome to nginx!</title> <style> body { width: 35em; margin: 0 auto; font-family: Tahoma, Verdana, Arial, sans-serif; } </style> </head> <body> <h1>Welcome to nginx!</h1> <p>If you see this page, the nginx web server is successfully installed and working. Further configuration is required.</p> <p>For online documentation and support please refer to <a href="http://nginx.org/">nginx.org</a>.<br/> Commercial support is available at <a href="http://nginx.com/">nginx.com</a>.</p> <p><em>Thank you for using nginx.</em></p> </body> </html>
8. Volume & Storage
如前所述，在设计容器时并没有考虑到持久存储，特别是当存储跨越多个节点时。Kubernetes介绍了一些解决方案，但请注意，这些解决方案并没有自动消除使用容器管理存储的所有复杂性。
集装箱已经有了安装卷的概念，但由于我们没有直接使用集装箱，Kubernetes将卷作为Pod的一部分，就像集装箱一样。
下面是一个hostPath卷挂载的例子，类似于Docker引入的主机挂载:
apiVersion: v1 kind: Pod metadata: name: test-pd spec: containers: - image: k8s.gcr.io/test-webserver name: test-container volumeMounts: - mountPath: /test-pd name: test-volume volumes: - name: test-volume hostPath: # directory location on host path: /data # this field is optional type: Directory
卷允许在同一个Pod中的多个容器之间共享数据。当您想要使用侧车模式时，这个概念允许极大的灵活性。它们的第二个用途是在Pod崩溃并在同一节点上重新启动时防止数据丢失。pod以干净的状态启动，但所有数据会丢失，除非写入卷。
不幸的是，包含多个服务器的集群环境在持久性存储方面需要更多的灵活性。根据环境的不同，我们可以使用像Amazon EBS、谷歌Persistent Disks、Azure Disk storage这样的云块存储，也可以使用像Ceph、GlusterFS这样的存储系统或更传统的系统，比如NFS。
这些只是Kubernetes中可以使用的存储的几个例子。为了让用户体验更加统一，Kubernetes使用了容器存储接口CSI (Container Storage Interface)，它允许存储供应商编写一个可以在Kubernetes中使用的插件(存储驱动程序)。
为了使用这个抽象，我们还有两个可以使用的对象:
PersistentVolumes (PV)
存储片的抽象描述。对象配置包含卷的类型、卷大小、访问模式和唯一标识符以及如何挂载它的信息。
PersistentVolumeClaims (PVC)
用户对存储的请求。如果集群有多个持久化卷，用户可以创建一个PVC，根据用户的需要预留一个持久化卷。
apiVersion: v1 kind: PersistentVolume metadata: name: test-pv spec: capacity: storage: 50Gi volumeMode: Filesystem accessModes: - ReadWriteOnce csi: driver: ebs.csi.aws.com volumeHandle: vol-05786ec9ec9526b67 --- apiVersion: v1 kind: PersistentVolumeClaim metadata: name: ebs-claim spec: accessModes: - ReadWriteOnce resources: requests: storage: 50Gi --- apiVersion: v1 kind: Pod metadata: name: app spec: containers: - name: app image: centos command: ["/bin/sh"] args: ["-c", "while true; do echo $(date -u) >> /data/out.txt; sleep 5; done"] volumeMounts: - name: persistent-storage mountPath: /data volumes: - name: persistent-storage persistentVolumeClaim: claimName: ebs-claim
这个例子展示了一个PersistentVolume，它使用了一个使用CSI驱动程序实现的AWS EBS卷。在配置了PersistentVolume之后，开发人员可以使用PersistentVolumeClaim来预留它。最后一步是在Pod中使用PVC作为卷，就像我们之前看到的hostPath示例一样。
可以直接在Kubernetes中操作存储集群。像Rook这样的项目提供云本地存储业务编排，并与经过实战测试的存储解决方案(如Ceph)集成。
Rook架构，从Rook文档中检索
9. 配置对象
12因素应用程序建议将配置存储在环境中。但这到底是什么意思呢?运行应用程序需要的不仅仅是应用程序代码和一些库。应用程序有配置文件，连接到其他服务、数据库、存储系统或缓存，这需要像连接字符串这样的配置。
将配置直接合并到容器构建中被认为是不好的做法。任何配置更改都需要重新构建整个映像，并重新部署整个容器或吊舱。当使用多个环境(开发、登台、生产)并为每个环境构建映像时，这个问题只会变得更糟。12因素应用程序更详细地解释了这个问题:Dev/prod奇偶性。
在Kubernetes中，这个问题是通过使用ConfigMap将配置从Pods中解耦来解决的。ConfigMaps可用于将整个配置文件或变量存储为键-值对。有两种可能的方式使用ConfigMap:
将ConfigMap挂载为Pod中的卷
将ConfigMap中的变量映射到Pod中的环境变量。
下面是一个包含nginx配置的ConfigMap示例:
apiVersion: v1 kind: ConfigMap metadata: name: nginx-conf data: nginx.conf: | user nginx; worker_processes 3; error_log /var/log/nginx/error.log; ... server { listen 80; server_name _; location / { root html; index index.html index.htm; } } }
一旦ConfigMap被创建，你就可以在Pod中使用它:
apiVersion: v1 kind: Pod metadata: name: nginx spec: containers: - name: nginx image: nginx:1.19 ports: - containerPort: 80 volumeMounts: - mountPath: /etc/nginx name: nginx-conf volumes: - name: nginx-conf configMap: name: nginx-conf
从一开始，Kubernetes也提供了一个对象来存储敏感信息，如密码、密钥或其他凭证。这些对象被称为Secrets。秘密与ConfigMaps非常相关，基本上它们唯一的区别是秘密是base64编码的。
关于使用“秘密”的风险，人们一直在争论不休，因为“秘密”(与名称相反)并不被认为是安全的。在原生云环境中，已经出现了专门创建的秘密管理工具，它们可以很好地与Kubernetes集成。HashiCorp Vault就是一个例子。
10. Autoscaling
自动伸缩机制
Horizontal Pod Autoscaler (HPA)
Horizontal Pod Autoscaler (HPA)是Kubernetes中最常用的自动定标器。HPA可以监视deployments或ReplicaSets，并在达到某个阈值时增加副本的数量。成像Pod可以使用500MiB的内存，并且您配置了80%的阈值。如果利用率超过400MiB(80%)，将调度第二个Pod。现在您的容量为1000MiB。如果使用了800MiB，将调度第三个Pod，以此类推。
Cluster Autoscaler
当然，如果集群容量是固定的，那么启动越来越多的pod副本是没有意义的。如果需求增加，Cluster Autoscaler可以向集群添加新的工作节点。集群自动伸缩器与水平自动伸缩器协同工作。
Vertical Pod Autoscaler
Vertical Pod Autoscaler 相对较新，允许吊舱动态增加资源请求和限制。如前所述，垂直扩展受到节点容量的限制。
不幸的是，Kubernetes的(水平)自动伸缩是无法开箱即用的，需要安装一个名为metrics-server的附加组件。
但是，用Kubernetes Metrics api的Prometheus Adapter替换度量服务器是可能的。prometheus-adapter允许您在Kubernetes中使用自定义指标，并根据系统上的请求或用户数量等因素进行放大或缩小。
像KEDA这样的项目可以根据外部系统触发的事件来扩展Kubernetes工作负载，而不是仅仅依赖于指标。KEDA是基于kubernetes的事件驱动自动scaler的缩写，于2019年作为微软和红帽公司的合作伙伴启动。与HPA类似，KEDA可以扩展部署、复制集、pod等，还可以扩展Kubernetes作业等其他对象。通过大量现成的扩展器的选择，KEDA可以扩展到特殊的触发器，比如数据库查询，甚至Kubernetes集群中pod的数量。
交互式教程-缩放您的应用程序
在交互式教程的第五部分:运行应用程序的多个实例中，你可以学习如何手动扩展应用程序。
11. Additional Resources
Learn more about…
Differences between Containers and Pods
What are Kubernetes Pods Anyway?, by Ian Lewis (2017)
Containers vs. Pods - Taking a Deeper Look, by Ivan Velichko (2021)
kubectl tips & tricks
kubectl Cheat Sheet
Storage and CSI in Kubernetes
Container Storage Interface (CSI) for Kubernetes GA, by Saad Ali
(2019)
Kubernetes Storage: Ephemeral Inline Volumes, Volume Cloning,Snapshots and more!, by Henning Eggers (2020)
Autoscaling in Kubernetes
Architecting Kubernetes clusters - choosing the best autoscaling strategy, by Daniele Polencic (2021)
✈推荐阅读：
KCNA考试 第一章：cloud foundry云原生工程师考试
KCNA考试 第二章：Cloud Native Architecture
KCNA考试 第三章：容器编排
KCNA考试 第四章：kubernetes需要掌握的基础知识
KCNA考试 第五章：kubernetes实践
KCNA考试 第六章：持续交付
KCNA考试 第七章：监控与探测
十二个因素的应用程序
KCNA（云原生入门）测试题
