- +
+ project1 -+
| +- main.tf
| +- variables.tf
| +- pro.tfvars
| +- debug.tfvars
|
+- modules -+
+- module1 -+
| +- main.tf
| +- variables.tf
| +- outputs.tf
|
+- module2 -+
+- main.tf
+- variables.tf
+- outputs.tfコントローラーはKubernetesのリソース設定を監視して変更があったら自動的にリソースを調整するプログラムです。ちなみに、Deployment、Statefulset、DaemonSetなどはKubernetesの内蔵コントローラーです。
今回はGolangで簡単なLoadBalancerコントローラーを実現する。実際の機能はないですが、作成の流れはただしいと思います。
最初はTypeはLoadBalancerのServiceを作成
apiVersion: v1
kind: Service
metadata:
name: my-service
spec:
selector:
app.kubernetes.io/name: MyApp
ports:
- protocol: TCP
port: 80
targetPort: 80
clusterIP: 10.0.171.239
type: LoadBalancerこの時はIPアドレスを割り当てのコントローラーがないので、ServiceのステータスはPendingです。
新たなKubernetesクライアントを作成
マッピングはNAT内部から外部にパケットを送信時にアドレス変換する行為です。
NAT内部のネットワークの同じIPアドレスとポートで外部のそれぞれのUDPサーバ（IPアドレスとポートが違う）にパケットを送信すると、各個UDPサーバも同じIPアドレスとポートのパケットを受信する。
例えば：
| 送信元アドレス | 宛先アドレス | NATマッピングアドレス |
|---|---|---|
| 192.168.1.1:3000 | 1.1.1.1:3000 | 43.124.222.234:4500 |
| 192.168.1.1:3000 | 1.1.1.1:3001 | 43.124.222.234:4500 |
| 192.168.1.1:3000 | 1.1.1.3:3002 | 43.124.222.234:4500 |
| 192.168.1.1:3000 | 1.1.1.4:3004 | 43.124.222.234:4500 |
UDPサーバのアドレスが同じ（ポートが違う）なら受信したパケットのIPアドレスとポートを変換しない、そうしないと、IPアドレスやポートを変換する。
例えば：
| 送信元アドレス | 宛先アドレス | NATマッピングアドレス |
|---|---|---|
| 192.168.1.1:3000 | 1.1.1.1:3000 | 43.124.222.234:4500 |
| 192.168.1.1:3000 | 1.1.1.1:3001 | 43.124.222.234:4500 |
| 192.168.1.1:3000 | 1.1.1.2:3000 | 43.124.222.234:4501 |
| 192.168.1.1:3000 | 1.1.1.3:3003 | 43.124.222.234:4502 |
UDPサーバのアドレスとポートが同じなら受信したパケットのIPアドレスとポートを変換しない、そうしないと、IPアドレスやポートを変換する。
今回はollamaのオフィシャルクライアントでfuncation callingを使いたいです。
前回はlangchaingoで使っただけと、試してたらollamaの引数toolsは無効です、githubの実例ollama_functions_exampleはsystem messageとtoolsのjsonを組み合わせて内容を生成する。例えば：
func systemMessage() string {
bs, err := json.Marshal(functions)
if err != nil {
log.Fatal(err)
}
return fmt.Sprintf(`You have access to the following tools:
%s
To use a tool, respond with a JSON object with the following structure:
{
"tool": <name of the called tool>,
"tool_input": <parameters for the tool matching the above JSON schema>
}
`, string(bs))
}これはちょっと優雅でない、ollama/apiを使いたいと思います。
日本語はまだ勉強中ですから、変などころあったら、ぜひコメントしてください。
RAGはRetrieval augmented generationの略です。
大規模言語モデル内容を生成する前に、promptによる外部のデーターベースに知識を検索、元のpromptと組み合わせて、アウトプットを改善するための技術です。
sequenceDiagram
actor ユーザ
ユーザ->>サーバー: prompt: 今日の注目<br/>の新聞は何ですか？
サーバー->>ベクトルデータベース: promptをキーワードとして<br/>知識を検索
ベクトルデータベース--)サーバー: 知識を返す
サーバー->>llm: promptと知識を組み合わせて
llm-->>サーバー: 生成する内容を返す
サーバー->>ユーザ: 内容を返す
例えば：
ユーザ：今日の注目の新聞は何ですか？
gemini：
今日の注目の新聞記事については、リアルタイムで変化するため、特定の新聞社名を挙げて「今日の注目の記事はこれです」と断言することは難しいです。chatgpt:
本日（2024年11月6日）の日本の注目ニュースは次のような内容が含まれている可能性があります：
アメリカ大統領選挙の最新動向 - 特に若い世代の投票行動や政策への関心が注目されています。
国内経済とインフレの動き - 日本の物価高騰が続き、家計への影響や政府の対応が議論されています。
アジアの地政学的緊張 - 日本周辺地域の安全保障に関連する動向が続いています。
以上の内容が注目ニュースとして考えられますが、詳細については直接ニュースソースで確認されるとよいでしょう。geminiはリアルタイムによっての内容は回答できません。
chatgptはRAGか、Function Callingか、どちらかを使っていると思います。
今回はgolang+langchaingo+ollama+qdrantでRAGを実験してみます。
首先推荐一个视频 【文法「文の成分」】【10分間の国文法講座：ラーニング・ラボWeb講座】, 大概讲了日本中学（初中）考试的一些文法。
相信不少中国境内的人学习动词都是 一类动词， 二类动词，三类动词， 并且老师甚至还会告诉你不要记《标准日本语》上面带ます的动词，要记字典型。
然后大概会告诉一类动词的活用，类似下面：
「う」段 →「い」段 + ます
以「う」、「つ」、「る」结尾的词 → 去掉词尾 + って
...
...相信不少人（至少我是）会以为这是类似英文那种动词变形，过去式等这类的。
然而后来我发现，这完全是误人子弟啊，日本中学（初中）根本就不用这种所谓的变形，也不是说不用，只是他们不会用这种规则去活用动词。
事实上的动词活用分类：
简单来说，controller就是监听kubernetes的配置/状态变化，自动对资源进行调节。比如kubernetes内置的controller有Deployment、StatefulSet、DaemonSet。
这里我们实现一个简单的loadbalancer controller，使用kubernetes的client-go。
先创建一个新的Serivce,并且指定Type为LoadBalancer。
apiVersion: v1
kind: Service
metadata:
name: my-service
spec:
selector:
app.kubernetes.io/name: MyApp
ports:
- protocol: TCP
port: 80
targetPort: 80
clusterIP: 10.0.171.239
type: LoadBalancer这时Service的状态还是pending,因为还没有controller为其分配IP地址。
创建新的client
+----------------+ +-----------------+
| kubelet | | CRI shim |
| +-----------+ | | +-----------+ | +-----------+
| |grpc client|<-|-------|->|grpc server| |<---->| container |
| +-----------+ | | +-----------+ | | runtime |
+----------------+ +-----------------+ +-----------+描述NAT在映射网络内主机地址的行为
computer(192.168.100.2:30086) -> NAT -> 1.1.1.1:2345Endpoint-Independent Mapping
网络内主机在通过同一监听udp地址向不同地址和不同端口发包时, NAT使用同一映射地址向外发包
如 网络内一主机监听了一udp地址 192.168.100.2:30086
此时主机向 1.0.0.1:53 发送udp包,
NAT使用 1.1.1.1:2345 向 1.0.0.1:53 发包
主机又向 1.0.0.1:63 发送udp包,
NAT也使用 1.1.1.1:2345 向 1.0.0.1:63 发包
主机又向 8.8.8.8:53 发送udp包,
NAT也使用 1.1.1.1:2345 向 8.8.8.8:53 发包
这种无论目标地址和端口是什么都使用同一地址进行发包的NAT行为就是 Endpoint-Independent Mapping,
跟没有NAT一样Address-Dependent Mapping
网络内主机在通过同一监听udp地址向同一地址和不同端口发包时, NAT使用同一映射地址向外发包
如 网络内一主机监听了一udp地址 192.168.100.2:30086
此时主机向 1.0.0.1:53 发送udp包,
NAT使用 1.1.1.1:2345 向 1.0.0.1:53 发包
主机又向 1.0.0.1:63 发送udp包,
NAT也将使用 1.1.1.1:2345 向 1.0.0.1:63 发包
主机又向 8.8.8.8:53 发送udp包,
此时NAT将使用一新映射地址 1.1.1.1:5678 向 8.8.8.8:53 发包
这种依赖目标地址但不依赖端口的NAT映射行为就是 Address-Dependent Mapping