阿里云视频 2 视频上传
视频推流的上传方式分为凭证方式与STS方式
以下是官方文档 https://help.aliyun.com/document_detail/99379.html?spm=a2c4g.11186623.2.14.46798d6eWZn4BB#concept-1986524
上传凭证、播放凭证和STS方式都能解决上传和播放过程中的授权和安全问题，防止被恶意上传和播放。
Cloud
阿里云视频 1 视频点播
本例是一个 阿里云 视频点播 （不是直播）的 helloworld
这里用户浏览器先后调用两个服务器
我们先看 golang 端
/Users/lizhe/works/aus/alivedioauth/go.mod
module vedioAuth
go 1.14
require (
github.com/tidwall/gjson v1.6.0
github.com/tidwall/sjson v1.1.1
Azure Blob 脚本读写 C#
能有快10年没在windoes上写过代码了
vscode + c# 比以前感觉轻量多了，微软也算与时俱进
在项目根路径下创建 data 文件夹，
Azure Monitoring
Azure 的 Monitoring 做的还是挺有意思的，尤其是可以从 Prometheus 端点直接读数据这个
insights 侵入性好像有点强，不知道能不能像 istio 自动注入，如果能自动注入的话应该还可以
Istio 16 熔断
熔断的概念这里就不提了，主要是为了how而不是why
|
apiVersion: networking.istio.io/v1alpha3 kind: DestinationRule metadata: name: flaskapp-desrule namespace: lizhe spec: host: flaskapp-service trafficPolicy: connectionPool: tcp: maxConnections: 1 http: http1MaxPendingRequests: 1 maxRequestsPerConnection: 1 |
Istio 15 Gateway Https
kubectl create -n istio-system secret tls istio-ingressgateway-certs --key private.key --cert certificate.crt
|
apiVersion: networking.istio.io/v1alpha3 kind: Gateway metadata: name: example-gateway namespace: lizhe spec: selector: istio: ingressgateway servers: - port: number: 80 name: http |
Istio 14 Gateway Nodeport
个人认为 Nodeport 比 LoadBlancer 还坑
找到 Gateway的Ingress, 把它 从 LB 改成 Nodeport，
Istio 13 Gateway LoadBalancer
Kubernetes 提供了 Ingress 规范，用来入站流量管理
Istio的早期版本也实现了自己的 Ingress，后又因为 Ingress 在后来无法满足不断增加的需求，所以又推出了 Gateway，用于在网络边缘进行入站和出站的流量管理
Ingress Gateway 在逻辑上相当于一个负载均衡器
实际上之前做过的 VirtualService 对象， 都默认包含 gateways 字段，如果没有指定，那么默认值是
gateways：
- mesh
这里的 mesh 是 Istio 内部的虚拟 Gateway ， 代表网络内部的所有 Sidecar， 换句话说，所有网络内部服务之间的相互通信，都是通过这个网关进行的。
如果要对外部提供服务，就需要定义 Gateway 对象， 并在 gateways 字段中进行赋值。
一旦在gateways中填写了mesh之外的对象名称，就要继续对内部通信进行流量控制，并必须显示地将内置的mesh对象名称也加入列表中
Istio 12 url rewrite
个人认为 rewrite 比 redirect 好用，因为rewrite可以和route一起工作
|
apiVersion: networking.istio.io/v1alpha3 kind: VirtualService metadata: name: flaskapp-canary namespace: lizhe spec: hosts: - flaskapp-service.lizhe.svc.cluster.local http: - match: - uri: prefix: /env/rewriteme1 rewrite: uri: /env/version |
Istio 11 根据来源进行路由
金丝雀的用例里，是基于 HTTP Header 进行路由的，这里尝试基于 源Pod （ sleep ） 的 label 对请求进行路由
首先我们去修改 sleep 应用，把它拆分成两个部署，分别label成 v1 和 v2
|
apiVersion: v1 kind: Service metadata: name: sleep namespace: lizhe labels: app: sleep spec: selector: app: sleep ports: - name: ssh port: 80
---
|