1
|
kubectl create deployment nginx --image=nginx --dry-run -o yaml
|
kubectl run nginx --image=nginx
|
kubectl apply -f deployment.yaml
|
kubectl set image deployment/nginx nginx=nginx:1.9.1
|
kubectl set resource deployment/nginx -c=nginx --limits=cpu=200m,memory=512Mi
|
kubectl edit deployment nginx
|
spec:
strategy:
rollingUpdate:
maxSurge: 25% # 最大额外副本比例
maxUnavailable: 25% # 最少不可以副本比例
type: RollingUpdate
|
kubectl rollout pause deployment/nginx
|
kubectl rollout resume deployment/nginx
|
kubectl rollout undo deployment/nginx --to-revision=2
|
kubectl rollout status deployment/nginx
|
kubectl rollout history deployment/nginx
|
kubectl scale deployment/nginx --replicas=3
|
args:
- --logtostderr
- --kubelet-insecure-tls
- --kubelet-preferred-address-types=InternalIP
|
helm install stable/metrics-server \
-n metrics-server \
--namespace kube-system \
-f metrics-server.yaml
|
kubectl top node
NAME CPU(cores) CPU% MEMORY(bytes) MEMORY%
i-d7uwk2b1 443m 5% 5213Mi 67%
|
kubectl autoscale deployment/nginx --min=1 --max=5 --cpu-percent=80
|
相关推荐
TL; DR: 问题现象是集群运行一段时间后kube-proxy停止更新IPVS规则,造成部分容器无法互通。 这个问题是由一个存在于1.11.5/1.12.2/1.13.0版本中的bug造成的。并在以下版本中得到了修复,可以查看kubernetes/kubernetes#71071了解更多信息。 1.11.7 1.12.5 1.13.2 另一方面,也可以通过将未修复版本的kube-proxy设置为
服务发现在微服务架构里,服务之间经常进行通信,服务发现就是解决不同服务之间通信的问题。比如一个nginx的pod,要访问一个mysql服务,就需要知道mysql服务的ip和port,获取ip和port的过程就是服务发现。 服务发现方式 1.环境变量 Pod创建的时候,服务的ip和port会以环境变量的形式注入到pod里,比如pod创建时有一个redis-master服务,服务ip地址是10.4.8
因为Prometheus operator默认情况下没有将数据持久化存储,当Pod被删除或者意外重启后,可能会造成数据丢失。 这里我使用NFS客户端进行演示,关于其他后端存储引擎可以参考官网的storageclass。文章的大部分部署参数都是以前介绍过的这里不过多说明,不明白可以先看看pv pvc以及storageclass的理论。
https://img.mr
在本博客中,我们将探讨构建基础架构的最佳方法,并根据约束条件做出各种决策。 架构 首先,建议你的架构尽可能模块化,以便在将来有需要时可以灵活地进行增量更改。 入口点:DNS 在任何典型的基础架构中(无论是否为云原生),DNS服务器都必须首先解析请求消息以返回服务器的IP地址。 设置DNS应该基于所需的可用性。如果你需要更高的可用性,则要根据可用性级别,将服务器分布在多个云提供商中。 内容分发网络(
回到顶部