kind: Pod
apiVersion: v1
metadata:
name: marks-dummy-pod
spec:
containers:
- name: marks-dummy-pod
image: djtijare/ubuntuping:v1
command: ["/bin/bash", "-ec", "while :; do echo '.'; sleep 5 ; done"]
restartPolicy: Never
FROM ubuntu
RUN apt-get update && apt-get install -y iputils-ping
CMD bash
PostgreService.yaml
kind: Service
apiVersion: v1
metadata:
name: postgressvc
spec:
type: ClusterIP
ports:
- port: 5432
targetPort: 5432
已创建服务的终结点为
kind: Endpoints
apiVersion: v1
metadata:
name: postgressvc
subsets:
- addresses:
- ip: 172.31.6.149
ports:
- port: 5432
然后我在pod(kubectl exec-it mark-dummy-pod bash)内运行ping172.31.6.149,但不工作。(ping localhost正在工作)
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
pod/marks-dummy-pod 1/1 Running 0 43m 192.168.1.63 ip-172-31-11-87 <none> <none>
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE SELECTOR
service/postgressvc ClusterIP 10.107.58.81 <none> 5432/TCP 33m <none>
NAME ENDPOINTS AGE
endpoints/postgressvc 172.31.6.149:5432 32m
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
pod/postgres-855696996d-w6h6c 1/1 Running 0 44s 192.168.1.66 ip-172-31-11-87 <none> <none>
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE SELECTOR
service/postgres NodePort 10.110.203.204 <none> 5432:31076/TCP 44s app=postgres
NAME ENDPOINTS AGE
endpoints/postgres 192.168.1.66:5432 44s
所以问题出在我的DNS吊舱namespace=kube-system中
我只是创建新的kubernetes设置,并确保DNS正常工作
关于新的设置,请参阅我对另一个问题的回答
我在一个有3个节点的kubernetes集群上运行nginx。 我想知道是否有任何好处,例如,有4个豆荚和限制他们的CPU/MEM约。节点容量的1/4相对于每个节点运行一个pod,限制CPU/MEM,以便pod可以使用整个节点的资源(为了简单起见,我们将cubernet服务排除在等式之外)。 我的感觉是,豆荚越少,开销就越小,每个节点使用1个豆荚应该是性能最好的? 提前致谢
我们有一个应用程序,其中包含 4 个 pod,并使用负载均衡器运行!我们想尝试滚动更新,但我们不确定当 Pod 出现故障时会发生什么!文档不清楚!特别是《豆荚的终止》中的这句话: Pod将从服务的endpoint列表中删除,并且不再被视为复制控制器的运行Pod集的一部分。缓慢关闭的Pod可以继续为流量提供服务,因为负载平衡器(如服务代理)将它们从轮换中删除。 因此,如果有人能在以下问题上指导我们:
我希望我的pod在一段时间后(例如每周或每月)从我的部署中优雅地回收。如果我知道库伯内特斯命令,我知道我可以为此添加一个cron作业。 问题是在库伯内特斯做这件事的最好方法是什么,哪个命令会让我实现这个目标? 非常感谢你在这件事上帮助我。
环境*Kubernetes 1.9.3*使用在AWS(专用网络拓扑)上运行的kops(V1.8)创建的集群*网络:weave-net*集群:1主,3节点 事件实例时间线 > 我们已经使用kops执行了滚动集群更新,以使用我们构建的新AMI(基于kops AMI k8s-1.8-debian-jessie-amd64-hvm-ebs-2017-11-27)启动节点和主机。调整kops AMI从来都不
以下是两位工作人员的日志,这将有助于强调这个问题: 工人-0: 工人2:
客户端版本:version.info{Major:“1”,Minor:“0”,GitVersion:“V1.0.4”,GitCommit:“65D28D5FD12345592405714C81CD03B9C41D41D9”,GitTreesteat:“Clean”} 服务器版本:version.info{Major:“1”,Minor:“2”,GitVersion:“V1.2.0”,GitComm