概念

在 Node.js 中，建立 EventListener 可以使用 EventEmitter，概念與 publish/subscribe 非常相似，如果之前曾經使用過 Redis 的 Pub/Sub 機制，會更容易理解。

假設有一個人先訂閱（subscribe）了一個名為 ‘xxx’ 的頻道（channel），之後當有人發布（publish）訊息到 ‘xxx’ 頻道時，訂閱者就會看到發布者發出的訊息。

Event Listener

回到 Node.js 的 Event Listener 機制，我們可以透過 EventEmitter 建立一個 publish/subscribe 物件。執行物件的 .on 方法就類似於訂閱（subscribe），而 .emit 方法則類似於發布（publish）。以下是範例程式碼：

1
2
3
4
5
6
7
8
9
10

const EventEmitter = require('events');
const channel = new EventEmitter();

// 訂閱 'join' 事件：任何人加入時會通知
channel.on('join', (message) => {
  console.log(`Received message: ${message}`);
});

// 發布 'join' 事件
channel.emit('join', 'Hello, everyone!');

在這個範例中，我們使用 EventEmitter 建立了一個 channel 並且監聽 ‘join’ 事件。當有使用者加入時，會透過 .emit(‘join’) 通知 ‘join’ 事件。我們可以建立一個 HTTP server 並稍微修改一下來驗證我們的想法：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

// server.js
const net = require('net');

const EventEmitter = require('events').EventEmitter;
const channel = new EventEmitter;

channel.clients = {};

// 訂閱 'join' 事件：任何人加入時會通知
channel.on('join', (id, client) => {
    channel.clients[id] = client;
    console.log(`${id} join`);
});

const server = net.createServer(client => {
    // 使用 `IP:Port` 當作 ID
    const id = `${client.remoteAddress}:${client.remotePort}`;

    // 通知 'join' 事件
    channel.emit('join', id, client);
})

server.listen(30000);

.emit 不僅用來觸發事件，還可以同時傳入多個參，當你呼叫 .emit('join', arg1, arg2, ...) 時，所有註冊了這個事件的監聽器 .on('join', (arg1, arg2) => {...}) 都會依序被呼叫，且能接收到這些參數。

net.createServer 是使用 Node.js 的 net module 來建立一個 TCP server。當有 client 進來時會執行 callback function，這個 callback 第一個參數代表接收到一個 net.Socket 的物件。

在 socket 的 callback 中，可以透過 client.remoteAddress 與 client.remotePort 來獲取連線 client 的 IP 與 port，組合成唯一個 id。然後使用 .emit('join', id, client) 觸發一個 join 事件，同時把這個 id 與 client 傳入給 join 事件的 callback，最後儲存在 channel.clients 中。

我們來測試一下，先開一個 server，然後使用 telnet localhost 30000 來連到 server，在 server 上可以看到 xxx join 的訊息。

1
2
3
4
5
6
7
8
9

# 先開一個 server
$ node server.js 
::ffff:127.0.0.1:37282 join

# 然後加入使用者
$ telnet localhost 30000
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.

Error Event

在前面的例子，這個 join 事件名稱是可以自定義的，可以是任何字串，所以如果觸發一個不存在的事件 .emit('notExist')，其實是不會發生什麼事情的，但是有一個例外：error 事件。如果沒有人註冊 error 事件，但有人在 error 事件中發出訊息，程式會直接停止運行並印出錯誤訊息。

1
2
3
4
5
6

const events = require('events');
const myEmitter = new events.EventEmitter();
myEmitter.on('error', err => {
    console.log(`ERROR: ${err.message}`);
});
myEmitter.emit('error', new Error('Something is wrong.'));

如果在執行 error callback 時又發生錯誤，則會丟出 uncaughtException 錯誤，可以透過 process.on('uncaughtException') 來捕捉這個錯誤。

1
2
3

process.on('uncaughtException', err => {
  console.error('There was an uncaught error', err);
});

上述的例子可以增加這兩個事件：

1
2
3
4
5
6
7

process.on('uncaughtException', err => {
    console.log("uncaughtException", err.stack);
});

channel.on('error', err => {
    console.log("channel error", err.message)
});

廣播給所有使用者

現在 server 建立好了，我們想要讓多個使用者加入，如果其中有一個 client 發話，其他 client 都可以收到訊息。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

const net = require('net');

const EventEmitter = require('events').EventEmitter;
const channel = new EventEmitter;

channel.clients = {};

channel.on('join', (id, client) => {
    channel.clients[id] = client;
    channel.on('broadcast', (senderId, message) => {
        if (id != senderId) {
            channel.clients[id].write(message);
        }
    });
    console.log(`${id} join`);
    channel.emit('broadcast', id, `${id} join\n`); // 通知有人加入群組
});

const server = net.createServer(client => {
    const id = `${client.remoteAddress}:${client.remotePort}`;
    channel.emit('join', id, client);
    client.on('data', data => {
        data = data.toString();
        channel.emit('broadcast', id, data);
    });
})

server.listen(30000);

在 join 事件中，當有 client 加入時，會針對每個 client 註冊 broadcast 事件。當有人發送廣播訊息時 channel.emit('broadcast', ...)，就會觸發 callback 事件。這個 callback 需要接收兩個參數：

• senderId：發送者的 id。
• message：廣播的訊息。

如果該 client 不是訊息的發送者，則會使用 channel.clients[id].write(message) 將訊息送給這個 client。

最後每當 client 連線到 server 並傳送資料時，在 data 事件中 client.on('data', callback)，這個 callback 就會被觸發。這個 callback 會透過我們前面新增的 broadcast 事件來廣播給所有人。

在 .on('data', callback) 收到的資料通常是 Buffer，所以會先轉成 string。

我們來測試一下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

# server
$ node server.js 
::ffff:127.0.0.1:40542 join
::ffff:127.0.0.1:40556 join
::ffff:127.0.0.1:40572 join

# user1 再另外開三個 Terminal 分別建立連線
$ telnet localhost 30000
::ffff:127.0.0.1:40556 join
::ffff:127.0.0.1:40572 join
akiicat

# user2
$ telnet localhost 30000
::ffff:127.0.0.1:40572 join
akiicat

# user3
$ telnet localhost 30000
akiicat

先開一個 server，然後分別加入使用者並發話，記得最後要按 enter 才會發送，就可以看到發送的訊息會廣播到其他連線的 client。

如果你持續增加使用者，超過 10 個人訂閱同一個事件時，Node.js 會印出警告你，但可以透過 .setMaxListeners(50) 來增加上限。

1

eventEmitter.setMaxListeners(50);

離開群組 removeListener

現在我們的使用者可以加入群組，並且可以廣播訊息給所有人，看起來很不錯，但是使用者加入後卻沒有辦法離開。我們希望使用者輸入 leave 的時候，會將自己從群組中移除，並且斷開連線。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

channel.on('leave', (id) => {
    channel.emit('broadcast', id, `${id} has left\n`); // 通知有人離開
    channel.clients[id].destroy(); // 斷開連線
    delete channel.clients[id];
});

const server = net.createServer(client => {
    const id = `${client.remoteAddress}:${client.remotePort}`;
    channel.emit('join', id, client);
    client.on('data', data => {         data = data.toString();
        if (data.trim() === 'leave') { // 如果使用者輸入 leave 則觸發 leave 事件
            channel.emit('leave', id);
        } else {
            channel.emit('broadcast', id, data);
        }
    });
})

看起來功能已經完成了，但是有一個小問題。在 join 事件中，使用者訂閱的 broadcast 事件沒有清除。如果有人離開之後，就會在後續的廣播嘗試寫入不存在的連線，這會造成 Node.js 的錯誤。

因此我們在 leave 時需要用 .removeListener 來取消訂閱，注意 removeListener 帶入的 callback 必須跟 on 的 callback 一樣，

1
2
3
4

// removeListener 帶入的 callback 需要跟 on 的 callback 一樣
const callback = () => {...}
.on('broadcast', callback)
.removeListener('broadcast', callback)

所以我們需要修改一下 server.js：

• 新增 channel.subscriptions，並在 join 事件中，每當有使用者加入時儲存每個 client 的 callback。
• 在 leave 事件中 removeListener 將對應使用者的 broadcast callback 移除。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40

const net = require('net');

const EventEmitter = require('events').EventEmitter;
const channel = new EventEmitter;

channel.clients = {};
channel.subscriptions = {}; // 新增 subscriptions 物件用來儲存 client 的 broadcast callback

channel.on('join', (id, client) => {
    channel.clients[id] = client;
    channel.subscriptions[id] = (senderId, message) => { // 儲存 client 的 broadcast callback
        if (id != senderId) {
            channel.clients[id].write(message);
        }
    };
    channel.on('broadcast', channel.subscriptions[id]); // client 訂閱 broadcast 事件
    channel.emit('broadcast', id, `${id} join\n`); // client 訂閱 broadcast 事件
});

channel.on('leave', (id) => {
    channel.removeListener('broadcast', channel.subscriptions[id]); // client 取消訂閱 broadcast 事件
    channel.emit('broadcast', id, `${id} has left\n`);
    channel.clients[id].destroy();
    delete channel.clients[id];
    delete channel.subscriptions[id]; // 從物件中移除
});

const server = net.createServer(client => {
    const id = `${client.remoteAddress}:${client.remotePort}`;
    channel.emit('join', id, client);
    client.on('data', data => {         data = data.toString();
        if (data.trim() === 'leave') {
            channel.emit('leave', id);
        } else {
            channel.emit('broadcast', id, data);
        }
    });
})

server.listen(30000);

在 Terminal 測試使用者能否正常離開群組：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

$ node server.js

# user1 使用者離開
$ telnet localhost 30000
::ffff:127.0.0.1:54538 join
::ffff:127.0.0.1:54554 join
Hello
leave
Connection closed by foreign host.

# user2 使用者離開後照樣可正常廣播
$ telnet localhost 30000
::ffff:127.0.0.1:54554 join
Hello
::ffff:127.0.0.1:54528 has left
Hi

# user3
$ telnet localhost 30000
Hello
::ffff:127.0.0.1:54528 has left
Hi

關閉伺服器 removeAllListeners

現在我們新增一個新功能，輸入 shutdown 指令讓所有人取消訂閱，並斷開所有連線。在前一章節所學的 removeListener，我們可以使用迴圈將每個使用者從 broadcast 事件移除。然而，我們可以更間單的使用 .removeAllListeners('broadcast') ，來一次性移除所有訂閱 broadcast 事件上的使用者。最後我們的完整程式碼如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51

const net = require('net');

const EventEmitter = require('events').EventEmitter;
const channel = new EventEmitter;

channel.clients = {};
channel.subscriptions = {}; // 新增 subscriptions 物件用來儲存 client 的 broadcast callback

channel.on('join', (id, client) => {
    channel.clients[id] = client;
    channel.subscriptions[id] = (senderId, message) => { // 儲存 client 的 broadcast callback
        if (id != senderId) {
            channel.clients[id].write(message);
        }
    };
    channel.on('broadcast', channel.subscriptions[id]); // client 訂閱 broadcast 事件
    channel.emit('broadcast', id, `${id} join\n`); // client 訂閱 broadcast 事件
});

channel.on('leave', (id) => {
    channel.removeListener('broadcast', channel.subscriptions[id]); // client 取消訂閱 broadcast 事件
    channel.emit('broadcast', id, `${id} has left\n`);
    channel.clients[id].destroy();
    delete channel.clients[id];
    delete channel.subscriptions[id]; // 從物件中移除
});

channel.on('shutdown', () => {
    channel.emit('broadcast', '', 'Server shutdown');
    channel.removeAllListeners('broadcast');
        Object.keys(channel.clients).forEach(function(id) {         channel.clients[id].destroy();
        delete channel.clients[id];
        delete channel.subscriptions[id];
    })
});

const server = net.createServer(client => {
    const id = `${client.remoteAddress}:${client.remotePort}`;
    channel.emit('join', id, client);
    client.on('data', data => {         data = data.toString();
        if (data.trim() === 'shutdown') {
            channel.emit('shutdown', id);
        } else if (data.trim() === 'leave') {
            channel.emit('leave', id);
        } else {
            channel.emit('broadcast', id, data);
        }
    });
})

server.listen(30000);

測試一下，輸入 shutdown 後所有人將會斷開連線：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

# server
$ node server.js

# user1
$ telnet localhost 30000
::ffff:127.0.0.1:51130 join
::ffff:127.0.0.1:51136 join
shutdown
Server shutdownConnection closed by foreign host.

# user2
$ telnet localhost 30000
::ffff:127.0.0.1:51136 join
Server shutdownConnection closed by foreign host.

# user3
$ telnet localhost 30000
Server shutdownConnection closed by foreign host.

只要 Event Loop 中還有待處理的非同步操作（例如未完成的 I/O、定時器、網絡請求等），Node.js process 就不會自動退出。這對於需要長期運行、持續監聽請求的 Web 伺服器來說是理想的行為；而對於命令行工具或一次性任務，則可能需要在所有非同步操作完成後主動退出。

Reference

• Node.js In Action
• Node.js Events

Node.js 是 Single Thread 的環境執行，是如何透過 Event Loop 的方式來實現 Non-blocking I/O 的操作。

Event Loop 運作方式

想像一個 HTTP Request 進入 Node.js http.Server 時，Event Loop 會觸發對應的 callback。假設該 callback 需要從資料庫拿到使用者資料，並從磁碟讀取電子郵件 template，然後將使用者資料填入 template 後，回傳 HTTP Response。

在這個過程中，Event Loop 會以先進先出 (FIFO) 的方式運行 Event Queue：

1. 首先，Event Loop 包含一個 Timer，可以透過 setTimeout 或 setInterval 設定。
2. 接下來，如果 Timeout 或是有新的 I/O Event 進來，則會進入 poll phase (輪詢階段)，在此階段會安排執行 (schedule) 對應的 callback。

Event Loop 的概念不會太複雜，有 Event 進來，執行相對應的 callback。

那如果正在執行 poll phase 時，又有新的 I/O Event，Node.js 則會透過 setImmediate 設定，在當前 callback 執行完後立刻執行新進來的 I/O Event callback。

Library

Node.js 的 Non-blocking I/O Opertaion 是透過 libuv 實現的，libuv 實現 Node.js 的 Event Loop、Non-blocking I/O、網路、磁碟、檔案系統等功能，位於下圖的左下角：

原先在 Node.js 程式碼是透過 C++ Binding 綁定到 libuv 或其他 library 上，這些 library 會去跟 OS 來溝通。

之後 Google 的 V8 JavaScript 引擎的出現，讓 Node 更加強大。V8 引擎厲害之處就是直接繞過 C++ binding 變成 machine code，這大幅的提升了執行效率，如上圖右半側。

Reference

• Node.js In Action
• libuv
• V8 Engine

很久沒安裝 Windows 11 VM 了，原本想說應該很順利，結果裝了一整個晚上，沒想到會踩了一堆雷，所以這篇來紀錄一下安裝 Windows 11 VM 的過程：

讀取 ISO

在 Windows 11 開機的時候，若出現以下提示文字：

Press any key to boot from CD or DVD…

此時，一定要按下鍵盤上的任意鍵，如果只用滑鼠輸入會失敗。

繞過 TPM 檢查

在安裝 Windows 11 時，系統會檢查硬體是否符合規格。如果是在虛擬機上安裝，得需要手動關閉 TPM 的檢查：

1. 啟動命令提示字元：在安裝畫面按下 Shift + F10，這將開啟命令提示字元 (cmd)。
2. 開啟登錄編輯器：在命令提示字元中輸入 regedit 並按下 Enter 鍵。
3. 新增 LabConfig 機碼：

• 找到 HKEY_LOCAL_MACHINE\SYSTEM\Setup。
• 在此路徑下新增一個名為 LabConfig 的資料夾（機碼）。

4. 繞過檢查的設定：在 HKEY_LOCAL_MACHINE\SYSTEM\Setup\LabConfig 機碼內新增以下三個 DWORD 32-bit 項目

• BypassTPMCheck，值設為 1。
• BypassRAMCheck，值設為 1。
• BypassSecureBootCheck，值設為 1。

完成這些設定後，關閉登錄編輯器，繼續安裝，即可成功繞過檢查。

帳號登入

在安裝過程的最後階段，Windows 可能會要求輸入帳號密碼，目前還不知道要略過此步驟。

建議

安裝完成後，建議馬上建立一個快照 (snapshot)，這樣如果日後需要重置或修復系統，就不必重新安裝。

Reference

• Install Microsoft Windows 11 on VirtualBox
• Clean Install Windows 11

今天這章會討論什麼時候要把資料放在 Redux 裡面，什麼時候要將資料放在 React 的 components 裡。

React 將 components 分成 Presentational Components (展示組件) 與 Container Components (容器組件)。

Presentational Components

Presentational Components 主要負責 UI 的部分，通常不會有複雜 application 狀態管理的資料，通過會由 props 傳入無狀態 (stateless) 的資料，像是：

• 跟 UI 相關的資料 e.g. 顏色的使用
• 只有在必要時才擁有自己的狀態 e.g. 下拉式選單的狀態
• 需要手動建立新的東西 e.g. new post 的資料儲存

Container Components

Container Components 主要負責 application 的狀態，通常會使用 Redux 來管理，然後在 render 的時候會資料傳給 Presentational Components，通常會儲存有狀態的資料：

• application data flow
• 使用者相關的資訊 e.g. 最喜歡的顏色

Compare

Reference

• React in Action

前一篇介紹 Redux 是參考 Flux 的架構而設計的，這篇要用 Redux 來寫一個簡單的 React Counter App。

再提醒一下，React 跟 Redux 的差別是：React 是一個 front-end library；Redux 是一個架構，可以不用跟 React 一起使用，也可以跟 Vue 或 Angular 搭配。

Counter App

Install

建立一個 React App 然後安裝 Redux：

1
2
3

npx create-react-app counter-app
cd counter-app
npm install --save redux react-redux

Actions

建立 Redux 的 Action，Action 一定要回傳 type 讓 Reducer 去做對應的資料更新，Middleware 會在送到 Reducer 之前執行。

1
2
3
4
5
6
7
8

// actions.js
export const increment = () => ({
  type: 'INCREMENT'
});

export const decrement = () => ({
  type: 'DECREMENT'
});

Reducer

建立 Redux 的 Reducer，Reducer 不能修改原本的 state，必須複製一份，並且回傳最後 state 應該要的資料。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

// reducer.js
const initialState = {
  count: 0
};

const counterReducer = (state = initialState, action) => {
  switch (action.type) {
    case 'INCREMENT':
      return {
        ...state,
        count: state.count + 1
      };
    case 'DECREMENT':
      return {
        ...state,
        count: state.count - 1
      };
    default:
      return state;
  }
};

export default counterReducer;

Store

建立 Redux 的 Store，用來儲存 state 的資料

1
2
3
4
5
6
7

// store.js
import { createStore } from 'redux';
import counterReducer from './reducer';

const store = createStore(counterReducer);

export default store;

Counter

建立 React Counter Element，而且注意這邊需要將 Action 傳入 Dispatcher 來讓後續的 Reducer 來更新狀態。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

// Counter.js
import React from 'react';
import { useSelector, useDispatch } from 'react-redux';
import { increment, decrement } from './actions';

const Counter = () => {
  const count = useSelector(state => state.count);
  const dispatch = useDispatch();

  return (
    <div>
      <h1>Count: {count}</h1>
      <button onClick={() => dispatch(increment())}>Increment</button>
      <button onClick={() => dispatch(decrement())}>Decrement</button>
    </div>
  );
};

export default Counter;

App

最後 react-redux library 透過 Provider Component 來跟 React 串接，Provider 會提供 Store 的資料。

1
2
3
4
5
6
7
8
9
10
11
12
13

// App.js
import React from 'react';
import { Provider } from 'react-redux';
import store from './store';
import Counter from './Counter';

const App = () => (
  <Provider store={store}>
    <Counter />
  </Provider>
);

export default App;

Reference

• Github - Redux
• Github - React Redux

Flux 和 Redux 都是用來管理 application 狀態的架構，差異是不同的設計理念和實做方式：

Flux

Flux 是 Facebook 提出的架構模式，用於解決複雜的 data flow 問題，Flux 的架構如下：

1. Action: 描述 application 的事件或行為。
2. Dispatcher: 分發 Action 給 Store。它是 Flux 架構中的中央樞紐。
3. Store: 儲存 application 狀態和邏輯。每個 Store 負責 application 一部分狀態。
4. View: 展示 application UI，並且可以根據 Store 的變化來更新。

Flux 的 data flow 是單向的，從 Action 到 Dispatcher，再到 Store，最後到 view。

Redux

Redux 參考並簡化 Flux 管理狀態概念，Redux 的架構如下：

1. Action: 與 Flux 中的 Action 類似，用於描述 application 的事件或行為。
2. Reducer: 是一個 function，負責根據 Action 來更新 application 的狀態。Redux 中沒有 Sispatcher，取而代之的是 Reducer。
3. Store: 儲存 application 的狀態。Redux 中只有一個單一的 Store，與 Flux 有多個 Store 不同。而且 Redux 只能透過 Action 可以修改 Store 的資料。
4. Middleware: 用於處理異步操作或其他事件 e.g. Error Handling。

Redux 的 data flow 也是單向的，並且強調使用 function 來更新狀態。

Redux 使用單一集中狀態的物件，並以特定的方式進行更新。當你想要更新狀態時（e.g click event），會創建一個 Action 並由某個 Reducer 處理。Reducer 會複製當前狀態，且使用 Action 中的資料進行修改，然後返回新的狀態。當 Store 更新時，可以監聽事件並更新

Redux 跟 React 的差別是：React 是一個 front-end library；Redux 是一個架構，可以不用跟 React 一起使用，也可以跟 Vue 或 Angular 搭配。這篇是一個 React Redux 的範例：

Compare

• Redux 使用單一的 store: 與 Flux 在中多個 Store 中定位狀態信息不同，Redux 將所有內容保存在一個地方。在 Flux 中，可以有許多不同的 store。Redux 打破了這一點，強制使用單一 global Store。
• Redux 使用 reducers: Reducers 是以不更動原本資料的方式來更新資料。在 Redux 中，行為是以可預測的，因為所有的改動都要經過 Reducer，且每一次的改動只會更新一次 global Store。
• Redux 使用 middleware: 由於 Action 和資料以單向方式流動，我們可以透過 Redux 增加 middleware，並在資料更新時加上客製化的行為 e.g. Log or Catch Error。
• Redux decouple Action 與 Store: 建立 Action 時不會向通知 Store 任何東西，反而是回傳 Action 物件；Flux 的 Action 則會直接修改 Store。

Reference

• React in Action
• Redux Devtools Extension

由於 kube-proxy 在 ipvs scheduler 的模式是 rr，這篇會教學如何在 kubernetes cluster 裡面改變 ipvs scheduler 的模式。

環境

目前有三台 node 所組成的 kubernetes cluster

1
2
3
4
5

# kubectl get nodes -o wide
NAME    STATUS   ROLES    AGE    VERSION   INTERNAL-IP     EXTERNAL-IP   OS-IMAGE             KERNEL-VERSION      CONTAINER-RUNTIME
node1   Ready    master   5d7h   v1.16.6   192.168.0.121   <none>        Ubuntu 16.04.5 LTS   4.15.0-88-generic   docker://18.9.7
node2   Ready    master   5d7h   v1.16.6   192.168.0.146   <none>        Ubuntu 16.04.5 LTS   4.15.0-88-generic   docker://18.9.7
node3   Ready    <none>   5d7h   v1.16.6   192.168.0.250   <none>        Ubuntu 16.04.5 LTS   4.15.0-88-generic   docker://18.9.7

Kubernetes 裡面有一個 hello world deployment，並使用 NodePort 暴露 8080 port 的位置。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

# kubectl get all
NAME                         READY   STATUS    RESTARTS   AGE
pod/hello-868dc85486-8lvps   1/1     Running   0          3d2h
pod/hello-868dc85486-j2q7x   1/1     Running   0          3d2h
pod/hello-868dc85486-n2lvt   1/1     Running   0          3d2h
pod/hello-868dc85486-njcfn   1/1     Running   0          3d2h

NAME                 TYPE           CLUSTER-IP      EXTERNAL-IP     PORT(S)          AGE
service/kubernetes   ClusterIP      10.233.0.1      <none>          443/TCP          5d8h
service/node-port    NodePort       10.233.2.107    <none>          8080:31191/TCP   35h

NAME                    READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/hello   4/4     4            4           3d2h

NAME                               DESIRED   CURRENT   READY   AGE
replicaset.apps/hello-868dc85486   4         4         4       3d2h

使用 ipvsadm 查看 ipvs 的 scheduler 模式，目前的模式是 rr。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

# ipvsadm -ln
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags
  -> RemoteAddress:Port           Forward Weight ActiveConn InActConn
TCP  169.254.25.10:31191 rr
  -> 10.233.90.16:8080            Masq    1      0          0         
  -> 10.233.92.16:8080            Masq    1      0          0         
  -> 10.233.92.17:8080            Masq    1      0          0         
  -> 10.233.96.12:8080            Masq    1      0          0         
TCP  172.17.0.1:31191 rr
  -> 10.233.90.16:8080            Masq    1      0          0         
  -> 10.233.92.16:8080            Masq    1      0          0         
  -> 10.233.92.17:8080            Masq    1      0          0         
  -> 10.233.96.12:8080            Masq    1      0          0         
TCP  192.168.0.121:31191 rr
  -> 10.233.90.16:8080            Masq    1      0          0         
  -> 10.233.92.16:8080            Masq    1      0          0         
  -> 10.233.92.17:8080            Masq    1      0          0         
  -> 10.233.96.12:8080            Masq    1      0          0
TCP  10.233.90.0:31191 rr
  -> 10.233.90.16:8080            Masq    1      0          0         
  -> 10.233.92.16:8080            Masq    1      0          0         
  -> 10.233.92.17:8080            Masq    1      0          0         
  -> 10.233.96.12:8080            Masq    1      0          0 
...

下一節將說明如何修改 ipvs scheduler 的方法。

方法

首先，IPVS scheduler 的設定是在 kube-proxy 的 ConfigMap 裡面。

1

kubectl edit cm kube-proxy -n kube-system

將 data.config.conf.ipvs.scheduler 裡的參數修改成其他的 scheduler 模式：

1
2
3
4

data:
  config.conf:
    ipvs:
      scheduler: sh

在 Service: IPVS proxy mode 裡面有提供以下的 scheduler 的模式：

• rr: round-robin
• lc: least connection (smallest number of open connections)
• dh: destination hashing
• sh: source hashing
• sed: shortest expected delay
• nq: never queue

或參考 IPVS wiki

刪除原有的 kube-proxy 的 pod，daemonset.apps/kube-proxy 會自動重新建立新的 kube-proxy Pod。

1

kubectl delete -n kube-system $(kubectl get all -n kube-system | grep pod/kube-proxy | cut -d ' ' -f 1)

再次使用 ipvsadm 查看 ipvs 的 scheduler 就會是修改後的狀態。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

# ipvsadm -ln
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags
  -> RemoteAddress:Port           Forward Weight ActiveConn InActConn
TCP  169.254.25.10:31191 sh
  -> 10.233.90.16:8080            Masq    1      0          0         
  -> 10.233.92.16:8080            Masq    1      0          0         
  -> 10.233.92.17:8080            Masq    1      0          0         
  -> 10.233.96.12:8080            Masq    1      0          0         
TCP  172.17.0.1:31191 sh
  -> 10.233.90.16:8080            Masq    1      0          0         
  -> 10.233.92.16:8080            Masq    1      0          0         
  -> 10.233.92.17:8080            Masq    1      0          0         
  -> 10.233.96.12:8080            Masq    1      0          0         
TCP  192.168.0.121:31191 sh
  -> 10.233.90.16:8080            Masq    1      0          0         
  -> 10.233.92.16:8080            Masq    1      0          0         
  -> 10.233.92.17:8080            Masq    1      0          0         
  -> 10.233.96.12:8080            Masq    1      0          0
TCP  10.233.90.0:31191 sh
  -> 10.233.90.16:8080            Masq    1      0          0         
  -> 10.233.92.16:8080            Masq    1      0          0         
  -> 10.233.92.17:8080            Masq    1      0          0         
  -> 10.233.96.12:8080            Masq    1      0          0 

Reference

• Service: IPVS proxy mode
• IPVS: Connection Scheduling Algorithms inside the Kernel

這次是將現有的 Google Cloud Functions (GCF) 專案透過 GitHub Actions 自動化部屬至 Google Cloud Platform (GCP)。GitHub Actions 是第三方的服務，GCP 須建立金鑰給第三方服務使用，這篇將會記錄要如何設定 GCP 的金鑰。

環境

• Google Cloud Platform: 需先建立專案，並開啟帳單功能，ProjectID 為 short-url-256304。

方法

建立憑證金鑰

1. 點選「 IAM 與管理員」
2. 點選「服務帳戶」
3. 點選「建立服務帳戶」

4. 輸入服務帳戶名稱
5. 點選「建立」

6. 點選「角色」-> 選擇要部署要應用程式「ＸＸＸ開發人員」（下圖以 Gloud Functions 為例） -> 點選「建立」

7. 點選「建立金鑰」

8. 選擇金鑰類型「JSON」
9. 點選「建立」，此時會下載一份金鑰檔，將這份檔案保存好
10. 點選「完成」

11. 建立完成畫面

賦予服務帳戶權限

這時候根據建立完還不能透過第三方部署應用程式，會出現以下錯誤訊息：

1
2
3

ERROR: (gcloud.functions.deploy) ResponseError: status=[403], code=[Forbidden], message=[Missing necessary permission iam.serviceAccounts.actAs for ***@appspot.gserviceaccount.com on project ***. 
 Please grant ***@appspot.gserviceaccount.com the roles/iam.serviceAccountUser role. 
 You can do that by running 'gcloud projects add-iam-policy-binding *** --member=***@appspot.gserviceaccount.com --role=roles/iam.serviceAccountUser' 

錯誤訊息有提示你要如何解決這個問題，所以照提示訊息輸入以下指令，需將 PROJECT_ID 與 DEPLOY_NAME 改成你現在使用的專案：

1
2
3
4

export PROJECT_ID=short-url-256304
export DEPLOY_NAME=deploy-to-gcp

gcloud iam service-accounts add-iam-policy-binding $PROJECT_ID@appspot.gserviceaccount.com  --member=serviceAccount:$DEPLOY_NAME@$PROJECT_ID.iam.gserviceaccount.com --role=roles/iam.serviceAccountUser --project=$PROJECT_ID

操作步驟：

1. 點選右上角圖示「啟用 Cloud Shell」
2. 在終端機上輸入賦予帳戶權限的指令

測試

使用的 Repo 是 akiicat/short-url，透過 GitHub Actions 自動部署至 Google Cloud Functions 的設定檔，注意 jobs.deploy.steps[] 裡的前兩個步驟：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

# .github/workflows/google-cloud-functions.yml
name: GoogleCloudFuncitons
on: [push]
jobs:
  deploy:
    name: GCP Authenticate
    runs-on: ubuntu-latest
    steps:
    - name: Setup Google Cloud
      uses: actions/gcloud/auth@master
      env:
        # https://github.com/actions/gcloud/issues/13#issuecomment-511596628
        GCLOUD_AUTH: ${{ secrets.GCLOUD_AUTH }}

    - name: GCP Setup Project ID
      uses: actions/gcloud/cli@master
      with:
        args: "config set project ${{ secrets.ProjectID }}"

    - name: GCP Functions List
      uses: actions/gcloud/cli@master
      with:
        args: "functions list"

    - name: Deploy to GCP
      uses: actions/gcloud/cli@master
      with:
        args: "functions deploy link --entry-point=Link --runtime=go111 --trigger-http"

第一個步驟（Setup Google Cloud），是使用先前下載 JSON的金鑰向 Google Cloud Platform 認證權限，這裡的 GCLOUD_AUTH 需先將 JSON 檔轉成 base64 的格式，可以參考這篇 issue：

1
2
3

$ base64 short-url-256304-287.json
ewogICJ0eXBlIjogInNlcnZpY2VfYWNjb3VudCIsCiAgInByb2plY3RfaWQiOiAic2hvcnQtdXJsLTI1NjMwNCIsCiAgI...
lcGxveS10by1nY2YlNDBzaG9ydC11cmwtMjU2MzA0LmlhbS5nc2VydmljZWFjY291bnQuY29tIgp9Cg==

第二個步驟（GCP Setup Project ID），是設定 Google Cloud Platform 的 Project ID

secrets.GCLOUD_AUTH 與 secrets.ProjectID 的設定請參考 Virtual environments for GitHub Actions

Reference

• Testing: Github akiicat/short-url Repo
• StackOverflow: The caller does not have permission
• Cloud Build documentation
• Virtual environments for GitHub Actions: Setting Secrets
• GitHub Actions: My secret is always invalid

環境

• Google Kubernetes Engine
• Kubernetes version 1.12.8
• Helm version 2.14.1

安裝 Helm without RBAC

Helm 是 Kubernetes 的管理工具，Tiller 則是 API server，至於之間的差別，Helm 是 Client 端，Tiller 是 Server 端。輸入以下指令會安裝 Helm 和 Tiller：

1

helm init

官方文件建議加上 –history-max 參數，限制最大歷史指令的數量，如果沒有設定最大歷史記錄，則永遠保留歷史記錄。

1

helm init --history-max 200

##設定 RBAC

在雲端平台上，由於有安全性的問題，如果不設定 RBAC，之後可能會無法正常使用，所以需要提供足夠的權限給 tiller，輸入以下指令建立權限，ServiceAccount 的名稱為 tiller：

1
2

kubectl create serviceaccount --namespace kube-system tiller
kubectl create clusterrolebinding tiller-cluster-rule --clusterrole=cluster-admin --serviceaccount=kube-system:tiller

套用 tiller 的 ServiceAccount 到已經現有的上

1

kubectl patch deployment --namespace kube-system tiller-deploy -p '{"spec":{"template":{"spec":{"serviceAccount":"tiller"}}}}'

安裝 Helm with RBAC

所有設定一次到位，在 helm init 的時候，加了 –service-account 參數，直接套用 ServiceAccount：

1
2
3

kubectl create serviceaccount --namespace kube-system tiller
kubectl create clusterrolebinding tiller-cluster-rule --clusterrole=cluster-admin --serviceaccount=kube-system:tiller
helm init --service-account tiller --history-max 200

測試

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

$ helm install --name my-db stable/influxdb
NAME:   my-db
LAST DEPLOYED: Wed Jul  3 23:13:08 2019
NAMESPACE: default
STATUS: DEPLOYED

RESOURCES:
==> v1/ConfigMap
NAME            DATA  AGE
my-db-influxdb  1     1s

==> v1/PersistentVolumeClaim
NAME            STATUS   VOLUME    CAPACITY  ACCESS MODES  STORAGECLASS  AGE
my-db-influxdb  Pending  standard  1s

==> v1/Pod(related)
NAME                             READY  STATUS   RESTARTS  AGE
my-db-influxdb-689d74646c-6fwc4  0/1    Pending  0         1s

==> v1/Service
NAME            TYPE       CLUSTER-IP     EXTERNAL-IP  PORT(S)            AGE
my-db-influxdb  ClusterIP  10.11.249.197  <none>       8086/TCP,8088/TCP  1s

==> v1beta1/Deployment
NAME            READY  UP-TO-DATE  AVAILABLE  AGE
my-db-influxdb  0/1    1           0          1s

...

查看套件清單

1
2
3

$ helm ls
NAME    REVISION        UPDATED                         STATUS          CHART           APP VERSION     NAMESPACE
my-db   1               Wed Jul  3 23:13:08 2019        DEPLOYED        influxdb-1.1.9  1.7.6           default

刪除測試檔案，–purge 參數可以徹底刪除，不留下任何記錄，名稱可以透過上面的指令查詢：

1

helm delete --purge my-db

解除安裝 Helm

1
2
3

kubectl -n kube-system delete deployment tiller-deploy
kubectl delete clusterrolebinding tiller
kubectl -n kube-system delete serviceaccount tiller

Reference

• Helm Quickstart Guide
• Easily install/uninstall Helm on RBAC Kubernetes

環境

• Google Kubernetes Engine
• Kubernetes 版本為 1.12.8

建立 Secret

Kubernetes secret 可以存放重要訊息，像是使用者密碼之類，不適合暴露在外。

設定以下參數，稍後提供給 influxdb 使用：

1. INFLUXDB_DATABASE：資料庫名稱
2. INFLUXDB_HOST：主機名稱
3. INFLUXDB_USERNAME：使用者名稱
4. INFLUXDB_PASSWORD：使用者密碼

1
2
3
4
5

kubectl create secret generic influxdb-creds \
  --from-literal=INFLUXDB_DATABASE=db \
  --from-literal=INFLUXDB_USERNAME=root \
  --from-literal=INFLUXDB_PASSWORD=root \
  --from-literal=INFLUXDB_HOST=influxdb

輸入以下指令檢查參數是否設定完成：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

$ kubectl get secrets
NAME                  TYPE                                  DATA   AGE
influxdb-creds        Opaque                                4      46m

$ kubectl describe secrets influxdb-creds
Name:         influxdb-creds
Namespace:    default
Labels:       <none>
Annotations:  <none>
Type:  Opaque
Data
====
INFLUXDB_DATABASE:  12 bytes
INFLUXDB_HOST:      8 bytes
INFLUXDB_PASSWORD:  4 bytes
INFLUXDB_USERNAME:  4 bytes

密文型態為 Opaque，裡面有四筆資料

建立儲存空間 Persistent Volume Claim (PVC)

使用 Kubernetes PVC 宣告儲存空間，將儲存空間命名為 influxdb，容量大小 2GB：

1
2
3
4
5
6
7
8
9
10
11
12
13

# pvc.yaml
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  labels:
    app: influxdb
  name: influxdb
spec:
  accessModes:
  - ReadWriteOnce
      resources:
    requests:
      storage: 2Gi

套用設定：

1

kubectl apply -f pvc.yaml

建立 Deployment

直接使用 Docker Hub 上的 influxdb，版本為 1.7.7

1

kubectl run influx-deployment --image=influxdb:1.7.7

套用 Secret

套用先前設定的 influxdb-creds Secret，輸入以下指令進入修改模式：

1

kubectl edit deployment influxdb

在 spec.template.spec.containers 位置加入 kubernetes secret：

1
2
3
4
5
6
7
8

spec:
  template:
    spec:
      containers:
      - name: influxdb
        envFrom:
        - secretRef:
            name: influxdb-creds

套用 Persistent Volume Claim (PVC)

套用先前設定的 influxdb PVC，輸入以下指令進入修改模式：

1

kubectl edit deployment influxdb

在 spec.template.spec.volumes 位置加入 Persistent Volume Claim (PVC)：

1
2
3
4
5
6
7

spec:
  template:
    spec:
      volumes:
      - name: var-lib-influxdb
        persistentVolumeClaim:
          claimName: influxdb

並且在 spec.template.spec.containers.volumeMounts 位置加入 Persistent Volume (PV)：

1
2
3
4
5
6
7

spec:
  template:
    spec:
      containers:
        volumeMounts:
        - mountPath: /var/lib/influxdb
          name: var-lib-influxdb

最後整份文件的結果會長得如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56

apiVersion: apps/v1
kind: Deployment
metadata:
  annotations:
    deployment.kubernetes.io/revision: "4"
  creationTimestamp: 2019-07-02T15:59:33Z
  generation: 4
  labels:
    run: influxdb
  name: influxdb
  namespace: default
  resourceVersion: "15136"
  selfLink: /apis/apps/v1/namespaces/default/deployments/influxdb
  uid: 62295880-9ce2-11e9-8f7f-42010a8000e8
spec:
  progressDeadlineSeconds: 600
  replicas: 1
  revisionHistoryLimit: 2
  selector:
    matchLabels:
      run: influxdb
  strategy:
    rollingUpdate:
      maxSurge: 25%
      maxUnavailable: 25%
    type: RollingUpdate
  template:
    metadata:
      creationTimestamp: null
      labels:
        run: influxdb
    spec:
      containers:
      - envFrom:
        - secretRef:
            name: influxdb-creds
        image: docker.io/influxdb:1.7.7
        imagePullPolicy: IfNotPresent
        name: influxdb
        resources: {}
        terminationMessagePath: /dev/termination-log
        terminationMessagePolicy: File
        volumeMounts:
        - mountPath: /var/lib/influxdb
          name: var-lib-influxdb
      dnsPolicy: ClusterFirst
      restartPolicy: Always
      schedulerName: default-scheduler
      securityContext: {}
      terminationGracePeriodSeconds: 30
      volumes:
      - name: var-lib-influxdb
        persistentVolumeClaim:
          claimName: influxdb
status:
  ...

Expose Service

這裡使用 LoadBalancer 來 expose 我們的服務，需要有雲端平台的支援：

1

kubectl expose deployment influx-deployment --name=influx-service --type=LoadBalancer --port=8086 --target-port=8086

若 EXTERNAL-IP 顯示為 pending，則再過一陣再重輸入一次。

1
2
3

$ kubectl get service
NAME             TYPE           CLUSTER-IP      EXTERNAL-IP    PORT(S)          AGE
influxdb         LoadBalancer   10.11.255.248   34.68.51.223   8086:31365/TCP   69m

看到 IP address 就代表完成了，接下來就測試看看是否能連進 server。

測試

從是否能從外部連進來：

1
2
3
4
5
6
7

$ influx --version
InfluxDB shell version: 1.7.7

$ influx -host '34.68.51.223' -port '8086' -username 'root' -password 'root'
Connected to http://34.68.51.223:8086 version 1.7.7
InfluxDB shell version: 1.7.7
>

Reference

• Deploy InfluxDB and Grafana on Kubernetes to collect Twitter stats