标签: google-compute-engine

我正在 Google Cloud Compute 上设置一些网络服务器，我需要在所有服务器之间同步一个目录以保持网站同步。我还想在需要时使用自动缩放功能来配置新服务器。

我意识到 GlusterFS 需要了解所有实例，但我的想法是从每个服务器设置监控，并在新/删除的服务器事件上自动更新配置。（虽然还没试过）

有没有人有过使用这些系统的经验？如果是这样，维护是如何进行的，以及涉及哪些成本，因为我不确定 GlusterFS 是否会花费除了它所在的驱动器之外的任何额外费用，而 Google Cloud Storage FS 的存储成本加上它运行的 api 命令.

如何更改 Google Cloud Compute 上的反向 DNS？

我想将反向 DNS 添加到 Google Cloud Compute，但不知道该怎么做。

我想将 11.97.196.104.bc.googleusercontent.com 映射到 ns1.example.com

http://tools.bevhost.com/cgi-bin/dnslookup?data=104.196.97.11&server=

我在验证 DKIM 等发送电子邮件时遇到问题。

[用调查结果的详细信息重写了问题。]

我正在运行一个包含大约 100 个容器的 Google Container Engine 集群，每天执行大约 100,000 个 API 调用。一些 pod 开始在 DNS 解析中失败 50%。我深入研究了这一点，它只发生在正在运行的节点上的 pod 上kube-dns。我还注意到，这只发生在系统中的节点因内存不足而关闭之前。

后台 resque 作业附加到 Google API，然后将数据上传到 S3。当我看到失败的作业时，它们会因“名称解析暂时失败”而失败。这发生在“accounts.google.com”和“s3.amazonaws.com”上。

当我登录到服务器，并尝试以连接到这些（或其他主机）host，nslookup或dig它似乎工作就好了。当我连接到 rails 控制台并运行在队列中失败的相同代码时，我不会发生故障。然而，正如我所说，这些后台故障似乎是间歇性的（大约 50% 的时间运行在节点上运行的工作程序kube-dns）。

到目前为止，我的临时修复是删除失败的 pod，并让 kubernetes 重新安排它们，并继续这样做，直到 kubernetes 将它们安排到一个没有运行的节点kube-dns。

顺便说一下，删除故障节点并没有解决这个问题。它只是导致 kubernetes 将所有内容移动到其他节点并移动了问题。

我们有一个要从 AWS 迁移到 Google Cloud 的系统。服务器通过 Kubernetes 进行容器化和部署。

我们有前端对后端进行 api 调用。很多时候这些 api 调用都会成功。

间歇性地，我们看到 api 调用失败并返回 400 响应，而不是访问后端，正文内容设置为通用的 Google 错误：

“400。这是一个错误。

您的客户发出了格式错误或非法的请求。我们知道的就这些。”

我们在日志中看不到到达后端的请求。就好像它在谷歌内部迷失了一样。

从前端容器内部或从我们的本地机器从命令行执行完全相同的调用每次都有效。

我的问题是：

i) 有没有人看到过类似的东西并且有解决这个问题的方法？

ii) 我们如何调试它？

仅供参考，请求是一个简单的 GET，如下所示：“ https://example.com/v1/session/12345?frontend_ip=1.2.3.4%2C+5.6.7.8&req_timestamp=2018-04-19+10%3A46 ”

我想在现有的 kubernetes 集群中添加一个新节点，但机器类型不同。对于新节点，我将为其添加标签，以便仅在其上运行某些应用程序。

我尝试了以下命令

gcloud compute instance-groups managed resize CONTAINER_GROUP --zone ZONE --size 5 --machine-type n1-standard-8

它返回一个错误

错误：（gcloud.compute.instance-groups.managed.resize）无法识别的参数：--machine-type n1-standard-8

如何将新节点添加到具有不同机器类型的现有 kubernetes 集群中？

我有一个 5TB 的硬盘，我想把它缩小到 2TB。

我使用谷歌计算引擎 PaaS。

我怎样才能做到这一点？

如果 Google 的工具无法解决此问题，您能否建议任何工具来手动执行此操作？

我正在尝试在 Google Compute Engine 上的 Ubuntu 18.04 VM 上使用 Stackdriver Monitoring。看起来 18.04尚不受支持，即使它是 LTS 版本。

我尝试编辑安装脚本以安装 16.04 版本，但看起来需要 libcurl3（18.04 安装 libcurl4，加上 18.04 的 Google Compute Engine 实用程序需要 libcurl4）。

如何安装监控代理？或者如果 18.04 的官方支持即将到来，什么时候？

我想~/.ssh/known_hosts用新创建的 GCE 实例的主机密钥信息更新我的。但我不确定如何安全地检索该信息。

我想像

gcloud compute ssh <GCEUSER>@<GCEHOST> --command='ssh-keyscan 127.0.0.1'

可能工作。但是（根据gcloud 计算 ssh 文档）似乎只是一个包装器ssh（并且，根据StrictHostKeyChecking=no在 $HOME/.config/gcloud/logs/ 下的关联日志文件中列出的参数中看到的，显然没有做任何事情某种检查主机的身份）。

似乎确实有一种方法可以使用 Web 控制台来启动基于浏览器的 ssh 会话（并以交互方式/手动方式运行ssh-keyscan），但是 1）我看不到内部结构以了解它是否真的像它应该的那样安全和 2) 不是用于脚本集成的有效 API。

是否有gcloud用于安全检索 GCE 实例的主机密钥的 API/机制？

这是一个关于 Google Cloud 服务中可用资源暂时短缺的规范问题。

我是 Google Cloud Compute Engine 的巴西用户有一段时间了，我设法使用它好几个月。不幸的是，在过去一个月左右的时间里，由于“区域没有足够的资源来满足请求”的问题，我一直在启动我的实例（上午 9 点左右）时遇到困难。

一开始，它发生了一两次，然后我就可以启动我的实例。但是现在即使经过几十次尝试也几乎不可能启动它！按照消息的建议，我尝试在southamerica-east1-and 中创建其他实例c（我的在 b 中）只是为了找出那里发生的相同问题。我从中得到的印象是，谷歌在南美的物理能力已经饱和，并且没有采取任何措施来增加它。

那么我能做些什么呢？我无法将我的服务器移到美国或其他地方，因为它对 ping 敏感（股票市场应用程序），并且作为仍在使用免费试用期的人，如果 Google 可以为我处理我可以处理的产品，我当然不会开始支付 GC不使用，需要数周或数月才能修复。

我不小心在我的 Google Cloud Compute debian 实例上启用了 UFW，不幸的是端口 22 现在被阻止了。我已经尝试了各种方法进入虚拟机，但我不能。

我正在尝试通过串行端口访问，但它要求我提供从未设置的用户名和密码。

有谁知道我能做什么？