谷歌云Next 19东京会议的备忘录

因为随意记下了一些笔记,所以内容没有保证。

关于Cloud Run

以下是对”サーバレスとは”的汉语本地化解释:
– 无需基础设施管理
– 完全托管的安全性
– 仅按使用量付费

Cloud Run的需求:
– 依赖于语言库
– 对特定供应商的依赖
– 无法访问GPU等设备

Knative
– 在k8s上搭建FaaS/PaaS
– k8s + Isito
– 构建/服务/事件

特点
– 快速部署
– 无服务器原生
– 可移植性

云函数
– 按使用计费
– 支持TLS协议
– 仅管理内存
– 公开访问
– 尚不可用

GKE上的云函数
– 在GKE平台上运行
– 支持内存/CPU/GPU资源
– 自带TLS证书
– 允许VPC访问

未来 – 为了金丝雀部署之类的修订

– 使用Stackdriver整合
– 仅限经过认证的容器访问
– 自动缩放

使用不同方法:
– 事件驱动功能
– 知识丰富:应用引擎
– 价格等:运行

在GCP上的数据管道

蓄积的数据变得有价值了
实时数据也变得更加丰富
– 生成和消失都很快
– 希望能够实时处理

架构
– 移动端
– 数据获取:发布-订阅/卡夫卡
– 数据转换:Apache Beam/Dataflow/Apache Flink/Spark
– 数据分析:BigQuery/BigTable/AI 平台
– 数据可视化:…

数据流
– 托管的Apache Beam
– 集成流式与批处理
– 可移植性

Apache Beam
– 希望能够在熟悉的编程语言中执行聚合SDK
– 希望能够有效地进行后处理和流式处理

自动缩放
– Python3
– 监测/记录

– 流式数据处理器
– 自动缩放
– 低资源消耗
– 可在东京使用
– 如果简单的话,GUI也可以
– 可以使用Stackdriver在关键指标达到时发送警报

有一个名为Beam SQL的东西
– 支持Pub/Sub模式

– 或许可以开发出可用于流媒体人工智能的Beam-on-Flink运行器和Beam-on-Spark运行器吗?

制造业的检验工序自动化

    • センサーデータと観測されうる事象をを記録

 

    • 故障は機械学習で判定

 

    記録されたデータと突き合わせ

关于GKE的容器安全性

    コンテナ化によって他のサーバへの侵入は難しくなった

在k8s上的问题
– k8s访问、防火墙、访问控制列表等都成为问题

通过容器化带来的好处:
– 监控的统一
– 对镜像进行独立扫描
– 镜像签名
– 服务网格

Google Infra Security
– 让Google负责基础设施方面的安全就可以了
– 开发者应该考虑工作负载和节点的安全问题

在生命周期中思考安全问题
– 容器映像的可变性
– 弱点
– 非法入侵
– 权限的正确性和非法访问

Docker映像
– 私人注册表
– 自动构建
– 弱点扫描

部署二进制授权
– 标准化容器发布流程
– 验证镜像的一致性
– 验证注册表的可信度

利用GKE Sandbox
– 在Pod中增加防御
– 限制攻击
– 使用gVisor

选项: 安托斯

    • サービスメッシュで通信元先を限定

 

    • 他にもいろいろできる

 

    Istioつかってサービス間をトンネリング

– 事件威胁检测
– 来自Stackdriver日志的信息

– 被称为用户和权限管理的GKE中的IAM

如果有任何问题,请通知我。
云安全指挥中心
– 仪表盘

关于成本管理

– 组织资源
– 组织
– 文件夹(项目的具体分组)
– 项目
– 标签(资源的注解)
– 结算账户

– 权限丢失
– 发票识别
– 支付错误
– 付款延迟
– 服务停止

权限
– 文件夹之间存在继承关系

域名/组织
– 域名1-1组织
– 可以不使用Google Admin Console
– 可以使用Cloud Identity来使用GSuite
– 特权管理者(成员管理)
– 组织管理者(GCP的管理员)
– 应该分配给多人
– 双因素认证

请求首先账户
– 可分别设置为组织管理员
– 单一货币支付
– 请求首先账户管理员:拥有有关请求的全部权限
– 请求首先账户用户:仅有浏览权限
– 如需分开会计等情况,应分开请求首先账户

项目/文件夹/标签
– 项目创建者:项目所有者
– 项目编辑者:可查看成本和GCP资源,添加标签
– 分离生产环境和开发环境
– 按环境了解成本
– 根据组织结构创建文件夹将实现良好的继承

成本管理
– 成本可视化
– 费用报告
– 责任说明
– 展示报告,使用BigQuery进行分析
– 预测
– 可以在仪表盘上完成
– 智能化
– 导出到BigQuery
– 可以按文件夹进行分隔
– 标签对于只查看GCE很有用
– 也可以使用自动添加的标签

GKE的使用

如果要使应用程序云原生化,
– 如果要实现云原生,就要从一开始考虑可扩展性。
– 预设故障会发生。

GKE的优点
– 强制工作流程的标准化和最优化步骤

代码配置的好处:
– 可以进行代码审核的基础设施
– 可轻松获得演练环境
– 可以进行持续交付
– 版本管理
– 可控制应用的可用性
– 可调整资源的最小/最大限制
– 自动缩放

使用混合多云环境的k8s

混合多云 (hun he duo yun)
– 需要集成的API (xu yao ji cheng de API)
选择Kubernetes的原因 (xuan ze Kubernetes de yuan yin)
– 最小化环境差异 (zui xiao hua huan jing cha yi)
– 可以在后期更改环境 (ke yi zai hou qi geng gai huan jing)
– 最小化功能差异 (zui xiao hua gong neng cha yi)
问题 (wen ti)
– 集群间操作兼容性 (ji qun jian cao zuo jian rong xing)
– 创建管理层实现统一 (chuang jian guan li ceng shi xian tong yi)
– 网络连接 (wang luo lian jie)
– 存储 (cun chu)
– 有状态服务特别依赖环境 (you zhuang tai fu wu te bie yi lai huan jing)

– 数据库等需要保留状态的容器
– 应用程序生成的数据
– 机密信息
– 在Kubernetes中尽可能避免处理的东西

存储
– Kubernetes中的存储
– 在集群上永久存储数据
– Kubernetes的存储
– 为Kubernetes集群准备存储
– 外部动态提供者
– 容器存储接口

将Pod与存储分离

etcd
– 一定要保护和备份
– 有第三方工具,如heptio velero

秘密 – 在HashiCorp有产品。

使用Anthos实现混合云

Anthos
– 混合多云
– 全托管
– 开放式

混合多云
– 有效利用现有资源
– 符合内部政策
– 多云运算

全面托管
– 专注于开发
– 由Google进行测试
– 保障开放性

– 谷歌倡导的开源
– 不破坏开源生态系统

Anthos的目标:
– 灵活性
– 能够享受竞争力
– 整合本地和云端

关于BigQuery的内容

提供了很多更新。
我没有记下来,所以需要确认一下。

数据目录

全面管理/可扩展的数据检测和元数据管理
元数据:表列名、键等等,
将GCP的数据导入Spanner,进行索引化?
访问控制是有效的
同时支持关键词搜索和面向检索。

广告
将在 10 秒后关闭
bannerAds