資訊專欄INFORMATION COLUMN
ELK/EFK日志系統
提到日志系統，一般首先想到的都是經典的ELK架構，或者現在被稱為Elastic Stack。Elastic Stack架構為Elasticsearch + Logstash + Kibana + Beats的組合，其中，Beats負責日志的采集， Logstash負責做日志的聚合和處理，Elasticsearch作為日志的存儲和搜索系統，Kibana作為可視化前端展示，整體架構如下圖所示：
此外，在容器化場景中，尤其是在Kubernetes環境中，用戶經常使用的另一套框架是EFK架構。其中，E還是Elasticsearch，K還是Kibana，其中的F代表Fluent Bit，一個開源多平臺的日志處理器和轉發器。Fluent Bit可以讓用戶從不同的來源收集數據/日志，統一并發送到多個目的地，并且它完全兼容Docker和Kubernetes環境。
PLG日志系統
但是，Grafana Labs提供的另一個日志解決方案PLG目前也逐漸變得流行起來。PLG架構為Promtail + Loki + Grafana的組合，整體架構圖下所示：
其中，Grafana大家應該都比較熟悉，它是一款開源的可視化和分析軟件，它允許用戶查詢、可視化、警告和探索監控指標。Grafana主要提供時間序列數據的儀表板解決方案，支持超過數十種數據源（還在陸續添加支持中）。
這里稍微介紹下另外兩個軟件Promtail和Loki。官方介紹Grafana Loki是一組可以組成一個功能齊全的日志堆棧組件，與其它日志系統不同的是，Loki只建立日志標簽的索引而不索引原始日志消息，而是為日志數據設置一組標簽，這意味著Loki的運營成本更低，效率也能提高幾個數量級。
Loki的設計理念收到了很多Prometheus的啟發，可以實現可水平擴展、高可用的多租戶日志系統。Loki整體架構也是由不同的組件來協同完成日志收集、索引、存儲等工作的，各個組件如下所示，有關Loki架構的更多信息這里不再展開描述，可以參考官方文檔Loki’s Architecture進一步深入了解。最后，一句話形容下Loki就是like Prometheus, but for logs。
Promtail是一個日志收集的代理，它會將本地日志的內容發送到一個Loki實例，它通常部署到需要監視應用程序的每臺機器/容器上。Promtail主要是用來發現目標、將標簽附加到日志流以及將日志推送到Loki。截止到目前，Promtail可以跟蹤兩個來源的日志：本地日志文件和systemd日志（僅支持AMD64架構）。
這樣看上去，PLG和ELK都能完成類似的日志管理工作，那它們之間的差別在哪里呢？
日志方案對比
首先，ELK/EFK架構功能確實強大，也經過了多年的實際環境驗證，其中存儲在Elasticsearch中的日志通常以非結構化JSON對象的形式存儲在磁盤上，并且Elasticsearch為每個對象都建立了索引，以便進行全文搜索，然后用戶可以特定查詢語言來搜索這些日志數據。與之對應的Loki的數據存儲是解耦的，既可以在磁盤上存儲數據，也可以使用如Amazon S3的云存儲系統。Loki中的日志帶有一組標簽名和值，其中只有標簽對被索引，這種權衡使得它比完整索引的操作成本更低，但是針對基于內容的查詢，需要通過LogQL再多帶帶查詢。
和Fluentd相比，Promtail是專門為Loki量身定制的，它可以為運行在同一節點上的Kubernetes Pods做服務發現，從指定文件夾讀取日志。Loki采用了類似于Prometheus的標簽方式。因此，當與Prometheus部署在同一個環境中時，因為相同的服務發現機制，來自Promtail的日志通常具有與應用程序指標相同的標簽，統一了標簽管理。
Kibana提供了許多可視化工具來進行數據分析，高級功能比如異常檢測等機器學習功能。Grafana專門針對Prometheus和Loki等時間序列數據打造，可以在同一個儀表板上查看日志的指標。
部署解決方案
在EKS上部署Promtail + Loki + Grafana解決方案
接下來，我們將演示如何在EKS上部署Promtail + Loki + Grafana組合，下面演示需要有滿足一些前提條件：
一個正常運行的EKS集群
可以執行kubectl命令行的環境
可以執行helm命令行的環境
演示環境如下：
EKS集群版本19.8
EKS集群為2個托管節點
Helm版本5.1
1. 部署Promtail + Loki + Grafana
首先，添加helm的repo信息。
$ helm repo add grafana https://grafana.github.io/helm-charts
然后，更新helm repo。
$ helm repo update
更新完成后，使用helm安裝loki和grafana。默認情況下，Loki和Grafana都是安裝在default命名空間的，可以添加 –namespace <命名空間> 參數將Loki和Grafana部署在指定的命名空間，這里演示創建一個新的命名空間loki，并將Loki和Grafana都安裝在這里。其中grafana.enabled=true選項可以將Grafana一起進行部署，如果希望同時安裝Prometheus，則也可以選擇配置prometheus.enabled=true參數，演示中并未開啟此參數。
$ kubectl create namespace loki
$ helm upgrade --install loki --namespace=loki grafana/loki-stack --set grafana.enabled=true
PowerShell
正常安裝會返回以下輸出結果：
Binding
NAME: loki
LAST DEPLOYED: Thu May 13 12:38:52 2021
NAMESPACE: loki
STATUS: deployed
REVISION: 1
NOTES:
The Loki stack has been deployed to your cluster. Loki can now be added as a datasource in Grafana.
See http://docs.grafana.org/features/datasources/loki/ for more detail.
部署完成后，我們來檢查下使用helm部署的資源情況：
$ kubectl -n loki get all
NAME READY STATUS RESTARTS AGE
pod/loki-0 1/1 Running 0 113s
pod/loki-grafana-b664d6c4f-qlg87 1/1 Running 0 113s
pod/loki-promtail-jm8x8 1/1 Running 0 113s
pod/loki-promtail-lb8jq 1/1 Running 0 113s
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
service/loki ClusterIP 10.100.52.513100/TCP 114s
service/loki-grafana ClusterIP 10.100.134.8180/TCP 114s
service/loki-headless ClusterIP None3100/TCP 114s
NAME DESIRED CURRENT READY UP-TO-DATE AVAILABLE NODE SELECTOR AGE
daemonset.apps/loki-promtail 2 2 2 2 2114s
NAME READY UP-TO-DATE AVAILABLE AGE
deployment.apps/loki-grafana 1/1 1 1 114s
NAME DESIRED CURRENT READY AGE
replicaset.apps/loki-grafana-b664d6c4f 1 1 1 114s
NAME READY AGE
statefulset.apps/loki 1/1 114s
可以看到通過Helm部署后自動完成了Promtail + Loki + Grafana組合的安裝，其中Promtail部署模式為daemonset，在每個計算節點上都有部署，來收集節點以及Pod上的日志信息，具體配置如下所示：
$ kubectl describe ds loki-promtail -n loki
Name: loki-promtail
Selector: app=promtail,release=loki
Node-Selector: <none>
Labels: app=promtail
app.kubernetes.io/managed-by=Helm
chart=promtail-2.2.0
heritage=Helm
release=loki
Annotations: deprecated.daemonset.template.generation: 1
meta.helm.sh/release-name: loki
meta.helm.sh/release-namespace: loki
Desired Number of Nodes Scheduled: 2
Current Number of Nodes Scheduled: 2
Number of Nodes Scheduled with Up-to-date Pods: 2
Number of Nodes Scheduled with Available Pods: 2
Number of Nodes Misscheduled: 0
Pods Status: 2 Running / 0 Waiting / 0 Succeeded / 0 Failed
Pod Template:
Labels: app=promtail
release=loki
Annotations: checksum/config: 8c87a13d751c87f1b8726a725bffbe18c827c5e60d4a7aea47cd4871ea8271f3
prometheus.io/port: http-metrics
prometheus.io/scrape: true
Service Account: loki-promtail
Containers:
promtail:
Image: grafana/promtail:2.1.0
Port: 3101/TCP
Host Port: 0/TCP
Args:
-config.file=/etc/promtail/promtail.yaml
-client.url=http://loki:3100/loki/api/v1/push
Readiness: http-get http://:http-metrics/ready delay=10s timeout=1s period=10s #success=1 #failure=5
Environment:
HOSTNAME: (v1:spec.nodeName)
Mounts:
/etc/promtail from config (rw)
/run/promtail from run (rw)
/var/lib/docker/containers from docker (ro)
/var/log/pods from pods (ro)
Volumes:
config:
Type: ConfigMap (a volume populated by a ConfigMap)
Name: loki-promtail
Optional: false
run:
Type: HostPath (bare host directory volume)
Path: /run/promtail
HostPathType:
docker:
Type: HostPath (bare host directory volume)
Path: /var/lib/docker/containers
HostPathType:
pods:
Type: HostPath (bare host directory volume)
Path: /var/log/pods
HostPathType:
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal SuccessfulCreate 14m daemonset-controller Created pod: loki-promtail-lb8jq
Normal SuccessfulCreate 14m daemonset-controller Created pod: loki-promtail-jm8x8
Loki本身默認是通過statefulset的方式部署，這是為了避免在數據攝入組件崩潰時丟失索引，因此官方建議將Loki通過statefulset運行，并使用持久化存儲來存儲索引文件，具體配置如下所示：
$ kubectl describe deployment loki-grafana -n loki
Name: loki-grafana
Namespace: loki
CreationTimestamp: Thu, 13 May 2021 12:38:53 +0000
Labels: app.kubernetes.io/instance=loki
app.kubernetes.io/managed-by=Helm
app.kubernetes.io/name=grafana
app.kubernetes.io/version=6.7.0
helm.sh/chart=grafana-5.7.10
Annotations: deployment.kubernetes.io/revision: 1
meta.helm.sh/release-name: loki
meta.helm.sh/release-namespace: loki
Selector: app.kubernetes.io/instance=loki,app.kubernetes.io/name=grafana
Replicas: 1 desired | 1 updated | 1 total | 1 available | 0 unavailable
StrategyType: RollingUpdate
MinReadySeconds: 0
RollingUpdateStrategy: 25% max unavailable, 25% max surge
Pod Template:
Labels: app.kubernetes.io/instance=loki
app.kubernetes.io/name=grafana
Annotations: checksum/config: 19aac1c3228c4f4807da30538c8541c01e6b17fa3b518f80ab4f400621bb175c
checksum/dashboards-json-config: 01ba4719c80b6fe911b091a7c05124b64eeece964e09c058ef8f9805daca546b
checksum/sc-dashboard-provider-config: 01ba4719c80b6fe911b091a7c05124b64eeece964e09c058ef8f9805daca546b
checksum/secret: 416bf8ba1672c41e905574cab63bd1f658e30bc29309dcb7e68effdfbcb989f6
Service Account: loki-grafana
Init Containers:
grafana-sc-datasources:
Image: kiwigrid/k8s-sidecar:0.1.209
Port: <none>
Host Port: <none>
Environment:
METHOD: LIST
LABEL: grafana_datasource
FOLDER: /etc/grafana/provisioning/datasources
RESOURCE: both
Mounts:
/etc/grafana/provisioning/datasources from sc-datasources-volume (rw)
Containers:
grafana:
Image: grafana/grafana:6.7.0
Ports: 80/TCP, 3000/TCP
Host Ports: 0/TCP, 0/TCP
Liveness: http-get http://:3000/api/health delay=60s timeout=30s period=10s #success=1 #failure=10
Readiness: http-get http://:3000/api/health delay=0s timeout=1s period=10s #success=1 #failure=3
Environment:
GF_SECURITY_ADMIN_USER: <set to the key admin-user in secret loki-grafana> Optional: false
GF_SECURITY_ADMIN_PASSWORD: <set to the key admin-password in secret loki-grafana> Optional: false
Mounts:
/etc/grafana/grafana.ini from config (rw,path="grafana.ini")
/etc/grafana/provisioning/datasources from sc-datasources-volume (rw)
/var/lib/grafana from storage (rw)
Volumes:
config:
Type: ConfigMap (a volume populated by a ConfigMap)
Name: loki-grafana
Optional: false
storage:
Type: EmptyDir (a temporary directory that shares a pods lifetime)
Medium:
SizeLimit:
sc-datasources-volume:
Type: EmptyDir (a temporary directory that shares a pod
Medium:
SizeLimit:
Conditions:
Type Status Reason
---- ------ ------
Available True MinimumReplicasAvailable
Progressing True NewReplicaSetAvailable
OldReplicaSets: loki-grafana-b664d6c4f (1/1 replicas created)
NewReplicaSet: <none>
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal ScalingReplicaSet 16m deployment-controller Scaled up replica set loki-grafana-b664d6c4f to 1最后Grafana是通過deployment來完成的，具體配置如下所示：
$ kubectl describe deployment loki-grafana -n loki
Name: loki-grafana
Namespace: loki
CreationTimestamp: Thu, 13 May 2021 12:38:53 +0000
Labels: app.kubernetes.io/instance=loki
app.kubernetes.io/managed-by=Helm
app.kubernetes.io/name=grafana
app.kubernetes.io/version=6.7.0
helm.sh/chart=grafana-5.7.10
Annotations: deployment.kubernetes.io/revision: 1
meta.helm.sh/release-name: loki
meta.helm.sh/release-namespace: loki
Selector: app.kubernetes.io/instance=loki,app.kubernetes.io/name=grafana
Replicas: 1 desired | 1 updated | 1 total | 1 available | 0 unavailable
StrategyType: RollingUpdate
MinReadySeconds: 0
RollingUpdateStrategy: 25% max unavailable, 25% max surge
Pod Template:
Labels: app.kubernetes.io/instance=loki
app.kubernetes.io/name=grafana
Annotations: checksum/config: 19aac1c3228c4f4807da30538c8541c01e6b17fa3b518f80ab4f400621bb175c
checksum/dashboards-json-config: 01ba4719c80b6fe911b091a7c05124b64eeece964e09c058ef8f9805daca546b
checksum/sc-dashboard-provider-config: 01ba4719c80b6fe911b091a7c05124b64eeece964e09c058ef8f9805daca546b
checksum/secret: 416bf8ba1672c41e905574cab63bd1f658e30bc29309dcb7e68effdfbcb989f6
Service Account: loki-grafana
Init Containers:
grafana-sc-datasources:
Image: kiwigrid/k8s-sidecar:0.1.209
Port: <none>
Host Port: <none>
Environment:
METHOD: LIST
LABEL: grafana_datasource
FOLDER: /etc/grafana/provisioning/datasources
RESOURCE: both
Mounts:
/etc/grafana/provisioning/datasources from sc-datasources-volume (rw)
Containers:
grafana:
Image: grafana/grafana:6.7.0
Ports: 80/TCP, 3000/TCP
Host Ports: 0/TCP, 0/TCP
Liveness: http-get http://:3000/api/health delay=60s timeout=30s period=10s #success=1 #failure=10
Readiness: http-get http://:3000/api/health delay=0s timeout=1s period=10s #success=1 #failure=3
Environment:
GF_SECURITY_ADMIN_USER: <set to the key admin-user in secret loki-grafana> Optional: false
GF_SECURITY_ADMIN_PASSWORD: <set to the key admin-password in secret loki-grafana> Optional: false
Mounts:
/etc/grafana/grafana.ini from config (rw,path="grafana.ini")
/etc/grafana/provisioning/datasources from sc-datasources-volume (rw)
/var/lib/grafana from storage (rw)
Volumes:
config:
Type: ConfigMap (a volume populated by a ConfigMap)
Name: loki-grafana
Optional: false
storage:
Type: EmptyDir (a temporary directory that shares a pods lifetime)
Medium:
SizeLimit:s lifetime)
sc-datasources-volume:
Type: EmptyDir (a temporary directory that shares a pod
Medium:
SizeLimit:
Conditions:
Type Status Reason
---- ------ ------
Available True MinimumReplicasAvailable
Progressing True NewReplicaSetAvailable
OldReplicaSets: loki-grafana-b664d6c4f (1/1 replicas created)
NewReplicaSet: <none>
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal ScalingReplicaSet 16m deployment-controller Scaled up replica set loki-grafana-b664d6c4f to 1
接下來，訪問Grafana UI界面來查看部署結果。首先，通過以下命令獲取Grafana管理員的密碼：
$ kubectl get secret --namespace loki loki-grafana -o jsonpath="{.data.admin-password}" | base64 --decode ; echo
然后通過以下命令轉發Grafana的接口，以便通過Web UI進行訪問。默認情況下，端口轉發的地址localhost，可以根據kubectl所在實例的情況補充設置–address
$ kubectl port-forward --namespace loki service/loki-grafana 3000:80
打開localhost:3000或者
成功登錄后可以正常進入到Grafana首頁，如下圖所示。
默認Loki數據源（http://loki:3100）已經添加進去了。
在Grafana側邊欄選擇Explore進行快速日志查看，進入到Explore頁面后選擇Loki數據源，然后選擇Logs標簽，最后在Logs Labels中輸入標簽的查詢條件，例如{namespace=”loki”}，執行查詢后就可以看到類似下圖中的日志信息。
上面的日志信息是通過默認部署的Daemon Set的Promtail收集到的日志。
默認情況下，Loki的索引存儲是通過boltdb-shipper來實現的，關于boltdb-shipper的更多信息請參考官方文檔Single Store Loki (boltdb-shipper index type)。這些配置是通過secret（內容為loki.yaml的詳細配置）掛載到Pod中的，查看Loki配置文件的默認值：
$ kubectl get secrets loki -n loki -o "jsonpath={.data[loki.yaml]}" | base64 -d
auth_enabled: false
chunk_store_config:
max_look_back_period: 0s
compactor:
shared_store: filesystem
working_directory: /data/loki/boltdb-shipper-compactor
ingester:
chunk_block_size: 262144
chunk_idle_period: 3m
chunk_retain_period: 1m
lifecycler:
ring:
kvstore:
store: inmemory
replication_factor: 1
max_transfer_retries: 0
limits_config:
enforce_metric_name: false
reject_old_samples: true
reject_old_samples_max_age: 168h
schema_config:
configs:
- from: "2020-10-24"
index:
period: 24h
prefix: index_
object_store: filesystem
schema: v11
store: boltdb-shipper
server:
http_listen_port: 3100
storage_config:
boltdb_shipper:
active_index_directory: /data/loki/boltdb-shipper-active
cache_location: /data/loki/boltdb-shipper-cache
cache_ttl: 24h
shared_store: filesystem
filesystem:
directory: /data/loki/chunks
table_manager:
retention_deletes_enabled: false
retention_period: 0s其中store: boltdb-shipper和object_store: filesystem分別指定了使用boltdb-shipper和文件系統來作為索引和日志文件的存儲，這些都需要額外的維護，因為Loki實現了計算存儲分離，所以這里可以充分借助云上的資源來減輕運維管理的負擔，在亞馬遜云平臺上可以使用Amazon DynamoDB作為索引實現快速的鍵值存儲的讀寫，使用Amazon S3作為日志存儲實現大規模日志存儲，同時也具備極高的存儲性價比，下面將演示這些內容的配置。
2. 使用DynamoDB作為索引，S3作為日志存儲
首先，節點要操作DynamoDB和S3就需要有足夠的IAM權限：
具體權限請參考官方文檔Loki Storage為EKS的節點配置相應權限。
接下來，要想真正使用DynamoDB作為Loki的索引存儲、S3作為日志存儲，需要配置loki.yaml文件，這里可以修改secret文件，也可以配置新的configmap來掛載到Pod上。無論采用哪一種方式，主要的修改內容為schema_config和storage_config，具體配置如下所示：
schema_config:
configs:
- from: "2020-10-24"
index:
period: 0
prefix: loki_index
object_store: s3
schema: v11
store: aws
server:
http_listen_port: 3100
storage_config:
aws:
s3: s3://us-east-1/loki-shtian
dynamodb:
dynamodb_url: dynamodb://us-east-1其中，schema_config 中的store: aws設置指定索引存儲，object_store: s3設置指定日志存儲，需要注意的是period的值需要設置為0，否則Loki將會為每個時間段的日志都創建出多帶帶的索引表，設置為0可以保證只有一個DynamaDB表被創建出來，存儲所有索引信息。prefix為我們指定的DynamoDB表的名稱。
存儲配置storage_config中分別填寫了DynamaDB和S3的相關信息，這里的S3存儲桶以之前創建的loki-shtian為例，請根據實際情況進行調整，示例選擇的區域以美東區（us-east-1）為例。其他配置保持默認不變。
完成上述配置編寫后，前文提到既可以通過修改secret對象loki來生效，也可以使用configmap多帶帶配置掛載，這里以更新secrets對象為例，通過以下命令更新secret對象（假設當前路徑下有配置好的loki.yaml文件）：
$ kubectl -n loki create secret generic loki --from-file=./loki.yaml -o yaml --dry-run=client | kubectl apply -f -
PowerShell
之后，通過以下命令重啟statefulset中的Pod：
$ kubectl -n loki rollout restart statefulset loki
查看Pod日志信息，如下所示，可以看到Loki會自動創建DynamoDB表loki_index，并按照默認的參數配置DynamoDB的WCU（1000）和RCU值（300），這些都可以參考官方文檔Configuring Loki進行定制化配置。
$ kubectl -n loki logs -f loki-0
level=info ts=2021-05-13T15:17:41.673886077Z caller=table_manager.go:476 msg="creating table" table=loki_index
level=info ts=2021-05-13T15:19:41.603526262Z caller=table_manager.go:324 msg="synching tables" expected_tables=1
level=info ts=2021-05-13T15:19:42.627187815Z caller=table_manager.go:531 msg="provisioned throughput on table, skipping" table=loki_index read=300 write=1000
level=info ts=2021-05-13T15:21:41.603525185Z caller=table_manager.go:324 msg="synching tables" expected_tables=1
level=info ts=2021-05-13T15:21:42.623189111Z caller=table_manager.go:531 msg="provisioned throughput on table, skipping" table=loki_index read=300 write=1000
關于DynamaDB和S3的配置示例可以參考官方文檔Loki Configuration Examples，詳細的配置信息可以參考官方文檔Configuring Loki。配置后的DynamoDB表使用h作為分區鍵，使用r作為排序鍵，如下圖所示：
根據日志中的信息可以看到DynamoDB的WCU和RCU值配置為1000和300，如下圖所示：
DynamoDB表使用c 作為索引的內容列，如下圖所示：
查看S3中的日志數據，如下圖所示：
再次查看Grafana界面，查詢日志信息一切正常運行。
小結：
本文首先簡單介紹了經典的日志系統ELK/EFK架構，引出了Grafana新推出的PLG架構，并探討了兩種架構之間的對比和重點發展的方向。然后，本文介紹了在亞馬遜云平臺的EKS服務上部署Promtail + Loki + Grafana解決方案，以及配置使用Amazon DynamoDB和Amazon S3，以充分借助云服務的高性價比優勢，降低用戶維護管理成本。
更多精彩干貨分享
點擊下方名片關注
IT那活兒
文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。
轉載請注明本文地址：http://specialneedsforspecialkids.com/yun/129761.html
摘要：是一個流行的開源企業級管理平臺，許多組織使用它來管理混合部署的集群。此使用顯示收集的數據。通過選擇左上角的下拉菜單返回集群控制臺，屏幕截圖如下。 James SunAWS解決方案架構師。James 擁有超過 15 年的信息技術行業從業經驗。加入 AWS 前，他曾在 MapR、惠普、NetApp、雅虎和 EMC 等公司擔任多個高級技術職位。他擁有斯坦福大學博士學位。本文原發于亞馬遜AWS...
摘要：前言本文主要介紹最新版本的一些新特性和如何部署到當中。主要亮點是一個新的查詢工作流，用于臨時數據探索和故障排除。已經過測試版并正式發布。使更易于部署并提高安全性。下面是一張使用處理日志的截圖部署我們主要提供將部署到中的方法。 前言 本文主要介紹最新版本grafana6.0的一些新特性和如何部署到k8s當中。 grafana6.0簡介 Grafana的這一更新引入了一種新的查詢展示數據的...
摘要：前言本文主要介紹最新版本的一些新特性和如何部署到當中。主要亮點是一個新的查詢工作流，用于臨時數據探索和故障排除。已經過測試版并正式發布。使更易于部署并提高安全性。下面是一張使用處理日志的截圖部署我們主要提供將部署到中的方法。 前言 本文主要介紹最新版本grafana6.0的一些新特性和如何部署到k8s當中。 grafana6.0簡介 Grafana的這一更新引入了一種新的查詢展示數據的...
摘要：思科云平臺和解決方案高級副總裁解釋說正確配置以在本地和公有云中部署應用需要定制集成，這從操作上來說可能是一項挑戰。近年來，容器由于其靈活性已經成為部署應用的一種流行方式。容器技術將工作負載捆綁成輕量級的便攜式軟件包，可以在不同類型的基礎設施之間輕松移動。今天早上公布的Cisco Hybrid Solution for Kubernetes on AWS解決方案旨在消除大規模使用容器的障礙。 ...
摘要：是谷歌內部為解決這個問題所做的工作的產物，它為管理容器如何在整個集群中運行提供了一個單一的框架。在云中使用服務在許多云中作為標準問題項提供，盡管它在谷歌云平臺，中最突出地表現為本地特性。使用，運行控制平面，將重點部署將用于所需配置的容器。每一項創新都會帶來新的復雜性。容器使以一種方便的、可移植的形式打包和運行應用程序成為可能，但至少要說以規模管理容器是一個挑戰。Kubernetes是谷歌內部...
閱讀 1346·2023-01-11 13:20
閱讀 1684·2023-01-11 13:20
閱讀 1132·2023-01-11 13:20
閱讀 1858·2023-01-11 13:20
閱讀 4100·2023-01-11 13:20
閱讀 2704·2023-01-11 13:20
閱讀 1385·2023-01-11 13:20
閱讀 3597·2023-01-11 13:20
