Repository files navigation

c4-bench: Cloud Container Cluster Common Benchmark

The engineering community at large seems enamored with containers and container platforms like Swarm, Kubernetes, and Mesos. These force multiplying tools are helping the whole community push technological progress faster than ever before.

But there is a difference between having a tool and understanding that tool's strengths and weaknesses relative to the greater ecosystem. It is difficult to improve any tool that you have not measured. Open and repeatable benchmarks, approachable analysis, and clear specific criteria for evaluation will help decision makers do so from an informed and data-driven context.

Please help us further the conversation. We need data on other stacks, cloud providers, and cluster configurations. We need an expanded common benchmark that covers more features. We need a more extendable test harness. We need more people interested in taking the conjecture out of decision making.

Please run these tests yourself and make or suggest improvements. If you're inspired and build something on your own don't hesitate to share it with the world. We need the data.

Building Clusters

See the README in the target platform directory assembly instructions.

Running the Benchmark

Each cluster will start a machine from which the tests should be run. This machine has a known IP address and tests must always be run from that IP address. Once the AWS CF stack has been created access the TestInstance over SSH at the public IP provided in the stack outputs.

From a shell on the test instance verify that Docker is up and running:

docker -H tcp://localhost:2376 info

Verify that the benchmark image has been built:

docker -H tcp://localhost:2376 images | grep local/bench

Before you start the benchmark make sure that the Swarm or Kube cluster is up and healthy:

# for Swarm
docker -H tcp://10.0.0.20:3376 info | grep Status | sort | uniq -c
# for Kube... insert the stack output named, "KubernetesAPIEndpoint" for <APISERVERDNS>
kubectl --server="http://<APISERVERDNS>:8080" get nodes | wc -l
# will show 1001 including the header line for a full cluster

Then start the benchmark with the following command:

docker -H tcp://localhost:2376 run -d --name bench --net host -v /results:/results -w /results local/bench

Test results will be written to appropriately named files in /results. WHen you're done, tar them up and use SCP to get them off the box.

You can monitor the test progress by running:

docker -H tcp://localhost:2376 logs -tf bench

I add timestamps with the -t flag so I can get an idea how quickly progress is being made or judge if the test has gotten stuck.

Important IP Addresses in the Clusters

  • The test instance is always at 10.0.0.40
  • The swarm managers are always at 10.0.0.20
  • Primary etcd instance is always at 10.0.0.10
  • Optional secondary etcd instance is always at 10.0.0.11
  • Nodes are always started in the 10.0.128.0/17 subnet (10.0.0.0/17 conflicts with some LXC config that conflicts with machines at 10.0.3.0/24)
  • Kube API servers are always to be accessed by the ELB DNS name

Copyright Notice

Copyright © 2016 Jeff Nickoloff - All in Geek Consulting Services, LLC

Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at

 http://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.

About

The Cloud Container Cluster Common Benchmark provides a set of tools for building container clusters, a common benchmark suite, and guidance on digesting the collected metrics.

Resources

Stars

49 stars

Watchers

6 watching

Forks

Releases

Packages

Contributors

Languages

, 'i'); if (__m === '*' || __re.test(location.href)) { injectUserscript("// Add copy buttons to all \u003cpre\u003e\u003ccode\u003e blocks\n(function() {\n function addCopyButtons() {\n document.querySelectorAll('pre code').forEach(function(codeBlock) {\n if (codeBlock.parentElement.hasAttribute('data-copy-added')) return;\n codeBlock.parentElement.setAttribute('data-copy-added', 'true');\n \n var btn = document.createElement('button');\n btn.textContent = 'Copy';\n btn.style.cssText = 'position:absolute;top:4px;right:4px;padding:2px 8px;font-size:11px;background:#4ecdc4;border:none;border-radius:4px;color:#1a1a2e;cursor:pointer;opacity:0.7;transition:opacity 0.2s;';\n btn.onmouseover = function() { this.style.opacity = '1'; };\n btn.onmouseout = function() { this.style.opacity = '0.7'; };\n btn.onclick = function() {\n navigator.clipboard.writeText(codeBlock.textContent).then(function() {\n btn.textContent = 'Copied!';\n setTimeout(function() { btn.textContent = 'Copy'; }, 1500);\n });\n };\n codeBlock.parentElement.style.position = 'relative';\n codeBlock.parentElement.appendChild(btn);\n });\n }\n \n addCopyButtons();\n \n // Re-run on dynamic content\n var observer = new MutationObserver(addCopyButtons);\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "Add Copy Buttons to Code Blocks"); } } catch(__e) { console.warn('[Userscript:Add Copy Buttons to Code Blocks]', __e); } })(); (function(){ try { var __m = "github.com"; var __re = new RegExp('^' + "github\\.com" + '
Skip to content

Repository files navigation

c4-bench: Cloud Container Cluster Common Benchmark

The engineering community at large seems enamored with containers and container platforms like Swarm, Kubernetes, and Mesos. These force multiplying tools are helping the whole community push technological progress faster than ever before.

But there is a difference between having a tool and understanding that tool's strengths and weaknesses relative to the greater ecosystem. It is difficult to improve any tool that you have not measured. Open and repeatable benchmarks, approachable analysis, and clear specific criteria for evaluation will help decision makers do so from an informed and data-driven context.

Please help us further the conversation. We need data on other stacks, cloud providers, and cluster configurations. We need an expanded common benchmark that covers more features. We need a more extendable test harness. We need more people interested in taking the conjecture out of decision making.

Please run these tests yourself and make or suggest improvements. If you're inspired and build something on your own don't hesitate to share it with the world. We need the data.

Building Clusters

See the README in the target platform directory assembly instructions.

Running the Benchmark

Each cluster will start a machine from which the tests should be run. This machine has a known IP address and tests must always be run from that IP address. Once the AWS CF stack has been created access the TestInstance over SSH at the public IP provided in the stack outputs.

From a shell on the test instance verify that Docker is up and running:

docker -H tcp://localhost:2376 info

Verify that the benchmark image has been built:

docker -H tcp://localhost:2376 images | grep local/bench

Before you start the benchmark make sure that the Swarm or Kube cluster is up and healthy:

# for Swarm
docker -H tcp://10.0.0.20:3376 info | grep Status | sort | uniq -c
# for Kube... insert the stack output named, "KubernetesAPIEndpoint" for <APISERVERDNS>
kubectl --server="http://<APISERVERDNS>:8080" get nodes | wc -l
# will show 1001 including the header line for a full cluster

Then start the benchmark with the following command:

docker -H tcp://localhost:2376 run -d --name bench --net host -v /results:/results -w /results local/bench

Test results will be written to appropriately named files in /results. WHen you're done, tar them up and use SCP to get them off the box.

You can monitor the test progress by running:

docker -H tcp://localhost:2376 logs -tf bench

I add timestamps with the -t flag so I can get an idea how quickly progress is being made or judge if the test has gotten stuck.

Important IP Addresses in the Clusters

  • The test instance is always at 10.0.0.40
  • The swarm managers are always at 10.0.0.20
  • Primary etcd instance is always at 10.0.0.10
  • Optional secondary etcd instance is always at 10.0.0.11
  • Nodes are always started in the 10.0.128.0/17 subnet (10.0.0.0/17 conflicts with some LXC config that conflicts with machines at 10.0.3.0/24)
  • Kube API servers are always to be accessed by the ELB DNS name

Copyright Notice

Copyright © 2016 Jeff Nickoloff - All in Geek Consulting Services, LLC

Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at

 http://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.

About

The Cloud Container Cluster Common Benchmark provides a set of tools for building container clusters, a common benchmark suite, and guidance on digesting the collected metrics.

Resources

Stars

49 stars

Watchers

6 watching

Forks

Releases

Packages

Contributors

Languages

, 'i'); if (__m === '*' || __re.test(location.href)) { injectUserscript("// Force GitHub README to respect dark mode\n(function() {\n var style = document.createElement('style');\n style.textContent = '\n .markdown-body {\n color-scheme: dark light;\n }\n .markdown-body pre { background: #161b22 !important; }\n .markdown-body code { background: rgba(110, 118, 129, 0.4) !important; }\n .markdown-body table th, .markdown-body table td { border-color: #30363d !important; }\n .markdown-body img { background: #0d1117; }\n .markdown-body blockquote { border-left-color: #8b949e; }\n .markdown-body hr { border-color: #30363d; }\n ';\n document.head.appendChild(style);\n})();", "GitHub Dark Mode README Fix"); } } catch(__e) { console.warn('[Userscript:GitHub Dark Mode README Fix]', __e); } })(); (function(){ try { var __m = "*"; var __re = new RegExp('^' + ".*" + '
Skip to content

Repository files navigation

c4-bench: Cloud Container Cluster Common Benchmark

The engineering community at large seems enamored with containers and container platforms like Swarm, Kubernetes, and Mesos. These force multiplying tools are helping the whole community push technological progress faster than ever before.

But there is a difference between having a tool and understanding that tool's strengths and weaknesses relative to the greater ecosystem. It is difficult to improve any tool that you have not measured. Open and repeatable benchmarks, approachable analysis, and clear specific criteria for evaluation will help decision makers do so from an informed and data-driven context.

Please help us further the conversation. We need data on other stacks, cloud providers, and cluster configurations. We need an expanded common benchmark that covers more features. We need a more extendable test harness. We need more people interested in taking the conjecture out of decision making.

Please run these tests yourself and make or suggest improvements. If you're inspired and build something on your own don't hesitate to share it with the world. We need the data.

Building Clusters

See the README in the target platform directory assembly instructions.

Running the Benchmark

Each cluster will start a machine from which the tests should be run. This machine has a known IP address and tests must always be run from that IP address. Once the AWS CF stack has been created access the TestInstance over SSH at the public IP provided in the stack outputs.

From a shell on the test instance verify that Docker is up and running:

docker -H tcp://localhost:2376 info

Verify that the benchmark image has been built:

docker -H tcp://localhost:2376 images | grep local/bench

Before you start the benchmark make sure that the Swarm or Kube cluster is up and healthy:

# for Swarm
docker -H tcp://10.0.0.20:3376 info | grep Status | sort | uniq -c
# for Kube... insert the stack output named, "KubernetesAPIEndpoint" for <APISERVERDNS>
kubectl --server="http://<APISERVERDNS>:8080" get nodes | wc -l
# will show 1001 including the header line for a full cluster

Then start the benchmark with the following command:

docker -H tcp://localhost:2376 run -d --name bench --net host -v /results:/results -w /results local/bench

Test results will be written to appropriately named files in /results. WHen you're done, tar them up and use SCP to get them off the box.

You can monitor the test progress by running:

docker -H tcp://localhost:2376 logs -tf bench

I add timestamps with the -t flag so I can get an idea how quickly progress is being made or judge if the test has gotten stuck.

Important IP Addresses in the Clusters

  • The test instance is always at 10.0.0.40
  • The swarm managers are always at 10.0.0.20
  • Primary etcd instance is always at 10.0.0.10
  • Optional secondary etcd instance is always at 10.0.0.11
  • Nodes are always started in the 10.0.128.0/17 subnet (10.0.0.0/17 conflicts with some LXC config that conflicts with machines at 10.0.3.0/24)
  • Kube API servers are always to be accessed by the ELB DNS name

Copyright Notice

Copyright © 2016 Jeff Nickoloff - All in Geek Consulting Services, LLC

Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at

 http://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.

About

The Cloud Container Cluster Common Benchmark provides a set of tools for building container clusters, a common benchmark suite, and guidance on digesting the collected metrics.

Resources

Stars

49 stars

Watchers

6 watching

Forks

Releases

Packages

Contributors

Languages

, 'i'); if (__m === '*' || __re.test(location.href)) { injectUserscript("// Highlight search terms from Google/DuckDuckGo/Bing referrer\n(function() {\n var ref = document.referrer;\n var terms = [];\n \n if (ref.includes('google.com') || ref.includes('duckduckgo.com') || ref.includes('bing.com')) {\n var url = new URL(ref);\n var q = url.searchParams.get('q') || url.searchParams.get('p');\n if (q) {\n terms = q.split(/\\s+/).filter(function(t) { return t.length \u003e 2; });\n }\n }\n \n if (terms.length === 0) return;\n \n var style = document.createElement('style');\n style.textContent = '.userscript-highlight { background: #fbbf24; color: #1a1a2e; padding: 1px 3px; border-radius: 2px; }';\n document.head.appendChild(style);\n \n function highlight(node) {\n if (node.nodeType === 3) { // text node\n var text = node.textContent;\n var found = false;\n terms.forEach(function(term) {\n var regex = new RegExp('(' + term.replace(/[.*+?^${}()|[\\]\\\\]/g, '\\\\') + ')', 'gi');\n if (regex.test(text)) {\n found = true;\n var frag = document.createDocumentFragment();\n var parts = text.split(regex);\n parts.forEach(function(part, i) {\n if (i % 2 === 0) {\n frag.appendChild(document.createTextNode(part));\n } else {\n var span = document.createElement('span');\n span.className = 'userscript-highlight';\n span.textContent = part;\n frag.appendChild(span);\n }\n });\n node.parentNode.replaceChild(frag, node);\n }\n });\n } else if (node.nodeType === 1 && node.childNodes) { // element\n var skipTags = ['SCRIPT', 'STYLE', 'NOSCRIPT', 'TEXTAREA', 'INPUT', 'SELECT'];\n if (!skipTags.includes(node.tagName)) {\n Array.from(node.childNodes).forEach(highlight);\n }\n }\n }\n \n highlight(document.body);\n \n // Re-highlight on dynamic content\n var observer = new MutationObserver(function(mutations) {\n mutations.forEach(function(m) {\n m.addedNodes.forEach(function(node) {\n if (node.nodeType === 1 || node.nodeType === 3) highlight(node);\n });\n });\n });\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "Highlight Search Terms"); } } catch(__e) { console.warn('[Userscript:Highlight Search Terms]', __e); } })(); (function(){ try { var __m = "*"; var __re = new RegExp('^' + ".*" + '
Skip to content

Repository files navigation

c4-bench: Cloud Container Cluster Common Benchmark

The engineering community at large seems enamored with containers and container platforms like Swarm, Kubernetes, and Mesos. These force multiplying tools are helping the whole community push technological progress faster than ever before.

But there is a difference between having a tool and understanding that tool's strengths and weaknesses relative to the greater ecosystem. It is difficult to improve any tool that you have not measured. Open and repeatable benchmarks, approachable analysis, and clear specific criteria for evaluation will help decision makers do so from an informed and data-driven context.

Please help us further the conversation. We need data on other stacks, cloud providers, and cluster configurations. We need an expanded common benchmark that covers more features. We need a more extendable test harness. We need more people interested in taking the conjecture out of decision making.

Please run these tests yourself and make or suggest improvements. If you're inspired and build something on your own don't hesitate to share it with the world. We need the data.

Building Clusters

See the README in the target platform directory assembly instructions.

Running the Benchmark

Each cluster will start a machine from which the tests should be run. This machine has a known IP address and tests must always be run from that IP address. Once the AWS CF stack has been created access the TestInstance over SSH at the public IP provided in the stack outputs.

From a shell on the test instance verify that Docker is up and running:

docker -H tcp://localhost:2376 info

Verify that the benchmark image has been built:

docker -H tcp://localhost:2376 images | grep local/bench

Before you start the benchmark make sure that the Swarm or Kube cluster is up and healthy:

# for Swarm
docker -H tcp://10.0.0.20:3376 info | grep Status | sort | uniq -c
# for Kube... insert the stack output named, "KubernetesAPIEndpoint" for <APISERVERDNS>
kubectl --server="http://<APISERVERDNS>:8080" get nodes | wc -l
# will show 1001 including the header line for a full cluster

Then start the benchmark with the following command:

docker -H tcp://localhost:2376 run -d --name bench --net host -v /results:/results -w /results local/bench

Test results will be written to appropriately named files in /results. WHen you're done, tar them up and use SCP to get them off the box.

You can monitor the test progress by running:

docker -H tcp://localhost:2376 logs -tf bench

I add timestamps with the -t flag so I can get an idea how quickly progress is being made or judge if the test has gotten stuck.

Important IP Addresses in the Clusters

  • The test instance is always at 10.0.0.40
  • The swarm managers are always at 10.0.0.20
  • Primary etcd instance is always at 10.0.0.10
  • Optional secondary etcd instance is always at 10.0.0.11
  • Nodes are always started in the 10.0.128.0/17 subnet (10.0.0.0/17 conflicts with some LXC config that conflicts with machines at 10.0.3.0/24)
  • Kube API servers are always to be accessed by the ELB DNS name

Copyright Notice

Copyright © 2016 Jeff Nickoloff - All in Geek Consulting Services, LLC

Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at

 http://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.

About

The Cloud Container Cluster Common Benchmark provides a set of tools for building container clusters, a common benchmark suite, and guidance on digesting the collected metrics.

Resources

Stars

49 stars

Watchers

6 watching

Forks

Releases

Packages

Contributors

Languages

, 'i'); if (__m === '*' || __re.test(location.href)) { injectUserscript("// Strip utm_, fbclid, gclid, etc. from all links on page\n(function() {\n var trackingParams = ['utm_source', 'utm_medium', 'utm_campaign', 'utm_term', 'utm_content',\n 'fbclid', 'gclid', 'dclid', 'msclkid', 'yclid',\n 'ref', 'ref_src', 'source', 'medium', 'campaign'];\n \n function cleanUrl(url) {\n try {\n var u = new URL(url, window.location.origin);\n var changed = false;\n trackingParams.forEach(function(p) {\n if (u.searchParams.has(p)) {\n u.searchParams.delete(p);\n changed = true;\n }\n });\n return changed ? u.toString() : url;\n } catch (e) {\n return url;\n }\n }\n \n function cleanLinks() {\n document.querySelectorAll('a[href]').forEach(function(a) {\n var clean = cleanUrl(a.href);\n if (clean !== a.href) a.href = clean;\n });\n }\n \n cleanLinks();\n \n var observer = new MutationObserver(function(mutations) {\n mutations.forEach(function(m) {\n m.addedNodes.forEach(function(node) {\n if (node.nodeType === 1) {\n if (node.tagName === 'A') cleanLinks();\n node.querySelectorAll('a[href]').forEach(function(a) {\n var clean = cleanUrl(a.href);\n if (clean !== a.href) a.href = clean;\n });\n }\n });\n });\n });\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "Remove Tracking Parameters from Links"); } } catch(__e) { console.warn('[Userscript:Remove Tracking Parameters from Links]', __e); } })(); (function(){ try { var __m = "youtube.com"; var __re = new RegExp('^' + "youtube\\.com" + '
Skip to content

Repository files navigation

c4-bench: Cloud Container Cluster Common Benchmark

The engineering community at large seems enamored with containers and container platforms like Swarm, Kubernetes, and Mesos. These force multiplying tools are helping the whole community push technological progress faster than ever before.

But there is a difference between having a tool and understanding that tool's strengths and weaknesses relative to the greater ecosystem. It is difficult to improve any tool that you have not measured. Open and repeatable benchmarks, approachable analysis, and clear specific criteria for evaluation will help decision makers do so from an informed and data-driven context.

Please help us further the conversation. We need data on other stacks, cloud providers, and cluster configurations. We need an expanded common benchmark that covers more features. We need a more extendable test harness. We need more people interested in taking the conjecture out of decision making.

Please run these tests yourself and make or suggest improvements. If you're inspired and build something on your own don't hesitate to share it with the world. We need the data.

Building Clusters

See the README in the target platform directory assembly instructions.

Running the Benchmark

Each cluster will start a machine from which the tests should be run. This machine has a known IP address and tests must always be run from that IP address. Once the AWS CF stack has been created access the TestInstance over SSH at the public IP provided in the stack outputs.

From a shell on the test instance verify that Docker is up and running:

docker -H tcp://localhost:2376 info

Verify that the benchmark image has been built:

docker -H tcp://localhost:2376 images | grep local/bench

Before you start the benchmark make sure that the Swarm or Kube cluster is up and healthy:

# for Swarm
docker -H tcp://10.0.0.20:3376 info | grep Status | sort | uniq -c
# for Kube... insert the stack output named, "KubernetesAPIEndpoint" for <APISERVERDNS>
kubectl --server="http://<APISERVERDNS>:8080" get nodes | wc -l
# will show 1001 including the header line for a full cluster

Then start the benchmark with the following command:

docker -H tcp://localhost:2376 run -d --name bench --net host -v /results:/results -w /results local/bench

Test results will be written to appropriately named files in /results. WHen you're done, tar them up and use SCP to get them off the box.

You can monitor the test progress by running:

docker -H tcp://localhost:2376 logs -tf bench

I add timestamps with the -t flag so I can get an idea how quickly progress is being made or judge if the test has gotten stuck.

Important IP Addresses in the Clusters

  • The test instance is always at 10.0.0.40
  • The swarm managers are always at 10.0.0.20
  • Primary etcd instance is always at 10.0.0.10
  • Optional secondary etcd instance is always at 10.0.0.11
  • Nodes are always started in the 10.0.128.0/17 subnet (10.0.0.0/17 conflicts with some LXC config that conflicts with machines at 10.0.3.0/24)
  • Kube API servers are always to be accessed by the ELB DNS name

Copyright Notice

Copyright © 2016 Jeff Nickoloff - All in Geek Consulting Services, LLC

Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at

 http://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.

About

The Cloud Container Cluster Common Benchmark provides a set of tools for building container clusters, a common benchmark suite, and guidance on digesting the collected metrics.

Resources

Stars

49 stars

Watchers

6 watching

Forks

Releases

Packages

Contributors

Languages

, 'i'); if (__m === '*' || __re.test(location.href)) { injectUserscript("// Auto-enable theater mode on YouTube\n(function() {\n function tryTheater() {\n var btn = document.querySelector('button[aria-label=\"Theater mode\"], ytd-player #player button[title=\"Theater mode\"]');\n if (btn && !btn.classList.contains('activated')) {\n btn.click();\n }\n }\n \n // Try immediately\n tryTheater();\n \n // Try after navigation (SPA)\n var lastUrl = location.href;\n setInterval(function() {\n if (location.href !== lastUrl) {\n lastUrl = location.href;\n setTimeout(tryTheater, 500);\n }\n }, 1000);\n \n // Also try on player load\n var observer = new MutationObserver(tryTheater);\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "YouTube Theater Mode Default"); } } catch(__e) { console.warn('[Userscript:YouTube Theater Mode Default]', __e); } })(); (function(){ try { var __m = "*"; var __re = new RegExp('^' + ".*" + '
Skip to content

Repository files navigation

c4-bench: Cloud Container Cluster Common Benchmark

The engineering community at large seems enamored with containers and container platforms like Swarm, Kubernetes, and Mesos. These force multiplying tools are helping the whole community push technological progress faster than ever before.

But there is a difference between having a tool and understanding that tool's strengths and weaknesses relative to the greater ecosystem. It is difficult to improve any tool that you have not measured. Open and repeatable benchmarks, approachable analysis, and clear specific criteria for evaluation will help decision makers do so from an informed and data-driven context.

Please help us further the conversation. We need data on other stacks, cloud providers, and cluster configurations. We need an expanded common benchmark that covers more features. We need a more extendable test harness. We need more people interested in taking the conjecture out of decision making.

Please run these tests yourself and make or suggest improvements. If you're inspired and build something on your own don't hesitate to share it with the world. We need the data.

Building Clusters

See the README in the target platform directory assembly instructions.

Running the Benchmark

Each cluster will start a machine from which the tests should be run. This machine has a known IP address and tests must always be run from that IP address. Once the AWS CF stack has been created access the TestInstance over SSH at the public IP provided in the stack outputs.

From a shell on the test instance verify that Docker is up and running:

docker -H tcp://localhost:2376 info

Verify that the benchmark image has been built:

docker -H tcp://localhost:2376 images | grep local/bench

Before you start the benchmark make sure that the Swarm or Kube cluster is up and healthy:

# for Swarm
docker -H tcp://10.0.0.20:3376 info | grep Status | sort | uniq -c
# for Kube... insert the stack output named, "KubernetesAPIEndpoint" for <APISERVERDNS>
kubectl --server="http://<APISERVERDNS>:8080" get nodes | wc -l
# will show 1001 including the header line for a full cluster

Then start the benchmark with the following command:

docker -H tcp://localhost:2376 run -d --name bench --net host -v /results:/results -w /results local/bench

Test results will be written to appropriately named files in /results. WHen you're done, tar them up and use SCP to get them off the box.

You can monitor the test progress by running:

docker -H tcp://localhost:2376 logs -tf bench

I add timestamps with the -t flag so I can get an idea how quickly progress is being made or judge if the test has gotten stuck.

Important IP Addresses in the Clusters

  • The test instance is always at 10.0.0.40
  • The swarm managers are always at 10.0.0.20
  • Primary etcd instance is always at 10.0.0.10
  • Optional secondary etcd instance is always at 10.0.0.11
  • Nodes are always started in the 10.0.128.0/17 subnet (10.0.0.0/17 conflicts with some LXC config that conflicts with machines at 10.0.3.0/24)
  • Kube API servers are always to be accessed by the ELB DNS name

Copyright Notice

Copyright © 2016 Jeff Nickoloff - All in Geek Consulting Services, LLC

Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at

 http://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.

About

The Cloud Container Cluster Common Benchmark provides a set of tools for building container clusters, a common benchmark suite, and guidance on digesting the collected metrics.

Resources

Stars

49 stars

Watchers

6 watching

Forks

Releases

Packages

Contributors

Languages

, 'i'); if (__m === '*' || __re.test(location.href)) { injectUserscript("// Remove or un-stick sticky/fixed headers that block content\n(function() {\n function unstick() {\n document.querySelectorAll('header, nav, [role=\"banner\"], .header, .navbar, .sticky, .fixed-top, [style*=\"position: fixed\"], [style*=\"position:sticky\"]').forEach(function(el) {\n if (el.style.position === 'fixed' || el.style.position === 'sticky' || \n getComputedStyle(el).position === 'fixed' || getComputedStyle(el).position === 'sticky') {\n el.style.position = 'static';\n el.style.top = 'auto';\n el.style.zIndex = 'auto';\n }\n });\n }\n \n unstick();\n \n var observer = new MutationObserver(unstick);\n observer.observe(document.body, { childList: true, subtree: true, attributes: true, attributeFilter: ['style', 'class'] });\n})();", "Kill Sticky Headers"); } } catch(__e) { console.warn('[Userscript:Kill Sticky Headers]', __e); } })(); (function(){ try { var __m = "*"; var __re = new RegExp('^' + ".*" + '
Skip to content

Repository files navigation

c4-bench: Cloud Container Cluster Common Benchmark

The engineering community at large seems enamored with containers and container platforms like Swarm, Kubernetes, and Mesos. These force multiplying tools are helping the whole community push technological progress faster than ever before.

But there is a difference between having a tool and understanding that tool's strengths and weaknesses relative to the greater ecosystem. It is difficult to improve any tool that you have not measured. Open and repeatable benchmarks, approachable analysis, and clear specific criteria for evaluation will help decision makers do so from an informed and data-driven context.

Please help us further the conversation. We need data on other stacks, cloud providers, and cluster configurations. We need an expanded common benchmark that covers more features. We need a more extendable test harness. We need more people interested in taking the conjecture out of decision making.

Please run these tests yourself and make or suggest improvements. If you're inspired and build something on your own don't hesitate to share it with the world. We need the data.

Building Clusters

See the README in the target platform directory assembly instructions.

Running the Benchmark

Each cluster will start a machine from which the tests should be run. This machine has a known IP address and tests must always be run from that IP address. Once the AWS CF stack has been created access the TestInstance over SSH at the public IP provided in the stack outputs.

From a shell on the test instance verify that Docker is up and running:

docker -H tcp://localhost:2376 info

Verify that the benchmark image has been built:

docker -H tcp://localhost:2376 images | grep local/bench

Before you start the benchmark make sure that the Swarm or Kube cluster is up and healthy:

# for Swarm
docker -H tcp://10.0.0.20:3376 info | grep Status | sort | uniq -c
# for Kube... insert the stack output named, "KubernetesAPIEndpoint" for <APISERVERDNS>
kubectl --server="http://<APISERVERDNS>:8080" get nodes | wc -l
# will show 1001 including the header line for a full cluster

Then start the benchmark with the following command:

docker -H tcp://localhost:2376 run -d --name bench --net host -v /results:/results -w /results local/bench

Test results will be written to appropriately named files in /results. WHen you're done, tar them up and use SCP to get them off the box.

You can monitor the test progress by running:

docker -H tcp://localhost:2376 logs -tf bench

I add timestamps with the -t flag so I can get an idea how quickly progress is being made or judge if the test has gotten stuck.

Important IP Addresses in the Clusters

  • The test instance is always at 10.0.0.40
  • The swarm managers are always at 10.0.0.20
  • Primary etcd instance is always at 10.0.0.10
  • Optional secondary etcd instance is always at 10.0.0.11
  • Nodes are always started in the 10.0.128.0/17 subnet (10.0.0.0/17 conflicts with some LXC config that conflicts with machines at 10.0.3.0/24)
  • Kube API servers are always to be accessed by the ELB DNS name

Copyright Notice

Copyright © 2016 Jeff Nickoloff - All in Geek Consulting Services, LLC

Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at

 http://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.

About

The Cloud Container Cluster Common Benchmark provides a set of tools for building container clusters, a common benchmark suite, and guidance on digesting the collected metrics.

Resources

Stars

49 stars

Watchers

6 watching

Forks

Releases

Packages

Contributors

Languages

, 'i'); if (__m === '*' || __re.test(location.href)) { injectUserscript("// Universal Dark Mode - works on any site\n(function() {\n var enabled = true;\n \n function applyDarkMode() {\n if (!enabled) return;\n \n // Create style element if it doesn't exist\n var style = document.getElementById('universal-dark-mode-style');\n if (!style) {\n style = document.createElement('style');\n style.id = 'universal-dark-mode-style';\n document.head.appendChild(style);\n }\n \n // Dark mode CSS - inverts colors but preserves images/video\n style.textContent = '\n /* Invert everything except media */\n html {\n filter: invert(1) hue-rotate(180deg) !important;\n background: #1a1a2e !important;\n }\n \n /* Restore images, videos, iframes, canvas */\n img, video, iframe, canvas, svg, picture, [style*=\"background-image\"] {\n filter: invert(1) hue-rotate(180deg) !important;\n }\n \n /* Preserve specific elements that should not be inverted */\n .no-dark-mode, .no-dark-mode *,\n [data-theme=\"light\"], [data-theme=\"light\"],\n .ace_editor, .ace_editor *,\n .CodeMirror, .CodeMirror *,\n .monaco-editor, .monaco-editor *,\n .markdown-body pre, .markdown-body pre *,\n .highlight, .highlight *,\n pre code, pre code * {\n filter: none !important;\n }\n \n /* Fix common UI elements */\n .modal, .popup, .dropdown-menu, .tooltip, .popover {\n filter: invert(1) hue-rotate(180deg) !important;\n background: #2d2d44 !important;\n border-color: #444 !important;\n }\n \n /* Scrollbars */\n ::-webkit-scrollbar { background: #1a1a2e !important; }\n ::-webkit-scrollbar-thumb { background: #444 !important; }\n ::-webkit-scrollbar-thumb:hover { background: #555 !important; }\n \n /* Selection */\n ::selection { background: #4ecdc4 !important; color: #1a1a2e !important; }\n ::-moz-selection { background: #4ecdc4 !important; color: #1a1a2e !important; }\n ';\n }\n \n function removeDarkMode() {\n var style = document.getElementById('universal-dark-mode-style');\n if (style) style.remove();\n }\n \n // Toggle with Alt+Shift+D\n document.addEventListener('keydown', function(e) {\n if (e.altKey && e.shiftKey && e.key === 'D') {\n e.preventDefault();\n enabled = !enabled;\n if (enabled) {\n applyDarkMode();\n console.log('[Universal Dark Mode] Enabled');\n } else {\n removeDarkMode();\n console.log('[Universal Dark Mode] Disabled');\n }\n }\n });\n \n // Apply on load\n applyDarkMode();\n \n // Re-apply on dynamic content\n var observer = new MutationObserver(function(mutations) {\n if (enabled && !document.getElementById('universal-dark-mode-style')) {\n applyDarkMode();\n }\n });\n observer.observe(document.head, { childList: true });\n \n console.log('[Universal Dark Mode] Loaded - Press Alt+Shift+D to toggle');\n})();", "Universal Dark Mode"); } } catch(__e) { console.warn('[Userscript:Universal Dark Mode]', __e); } })(); })();
Skip to content

Repository files navigation

c4-bench: Cloud Container Cluster Common Benchmark

The engineering community at large seems enamored with containers and container platforms like Swarm, Kubernetes, and Mesos. These force multiplying tools are helping the whole community push technological progress faster than ever before.

But there is a difference between having a tool and understanding that tool's strengths and weaknesses relative to the greater ecosystem. It is difficult to improve any tool that you have not measured. Open and repeatable benchmarks, approachable analysis, and clear specific criteria for evaluation will help decision makers do so from an informed and data-driven context.

Please help us further the conversation. We need data on other stacks, cloud providers, and cluster configurations. We need an expanded common benchmark that covers more features. We need a more extendable test harness. We need more people interested in taking the conjecture out of decision making.

Please run these tests yourself and make or suggest improvements. If you're inspired and build something on your own don't hesitate to share it with the world. We need the data.

Building Clusters

See the README in the target platform directory assembly instructions.

Running the Benchmark

Each cluster will start a machine from which the tests should be run. This machine has a known IP address and tests must always be run from that IP address. Once the AWS CF stack has been created access the TestInstance over SSH at the public IP provided in the stack outputs.

From a shell on the test instance verify that Docker is up and running:

docker -H tcp://localhost:2376 info

Verify that the benchmark image has been built:

docker -H tcp://localhost:2376 images | grep local/bench

Before you start the benchmark make sure that the Swarm or Kube cluster is up and healthy:

# for Swarm
docker -H tcp://10.0.0.20:3376 info | grep Status | sort | uniq -c
# for Kube... insert the stack output named, "KubernetesAPIEndpoint" for <APISERVERDNS>
kubectl --server="http://<APISERVERDNS>:8080" get nodes | wc -l
# will show 1001 including the header line for a full cluster

Then start the benchmark with the following command:

docker -H tcp://localhost:2376 run -d --name bench --net host -v /results:/results -w /results local/bench

Test results will be written to appropriately named files in /results. WHen you're done, tar them up and use SCP to get them off the box.

You can monitor the test progress by running:

docker -H tcp://localhost:2376 logs -tf bench

I add timestamps with the -t flag so I can get an idea how quickly progress is being made or judge if the test has gotten stuck.

Important IP Addresses in the Clusters

  • The test instance is always at 10.0.0.40
  • The swarm managers are always at 10.0.0.20
  • Primary etcd instance is always at 10.0.0.10
  • Optional secondary etcd instance is always at 10.0.0.11
  • Nodes are always started in the 10.0.128.0/17 subnet (10.0.0.0/17 conflicts with some LXC config that conflicts with machines at 10.0.3.0/24)
  • Kube API servers are always to be accessed by the ELB DNS name

Copyright Notice

Copyright © 2016 Jeff Nickoloff - All in Geek Consulting Services, LLC

Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at

 http://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.

About

The Cloud Container Cluster Common Benchmark provides a set of tools for building container clusters, a common benchmark suite, and guidance on digesting the collected metrics.

Resources

Stars

49 stars

Watchers

6 watching

Forks

Releases

Packages

Contributors

Languages