> The inscrutable iptables rules?
You mean the list of calls right there in the shell script?
> Who will know about those undocumented sysctl edits you made on the VM?
You mean those calls to `sysctl` conveniently right there in the shell script?
> your app needs to programmatically spawn other containers
Or you could run a job queue and push tasks to it (gaining all the usual benefits of observability, concurrency limits, etc), instead of spawning ad-hoc containers and hoping for the best.
"We don't know how to learn/read code we are unfamiliar with... Nor do we know how to grok and learn things quickly. Heck, we don't know what grok means "
Who do you quote?
This quote mostly applies to people who don't want to spend the time learning existing tooling, making improvements and instead create a slightly different wheel but with different problems. It also applies to people trying to apply "google" solutions to a non-google company.
Kubernetes and all tooling in the cloud native computing foundation(CNCF) were created to have people adopt the cloud and build communities that then created jobs roles that facilitated hiring people to maintain cloud presences that then fund cloud providers.
This is the same playbook that Microsoft did at Universities. They would give the entire suite of tools in the MSDN library away then then in roughly (4) years collect when another seat needs to be purchased for a new hire that has only used Microsoft tools for the last (4) years.
> You mean the list of calls right there in the shell script?
This is about the worst encoding for network rules I can think of.
Worse than yaml generated by string interpolation?
You'd have to give me an example. YAML is certainly better at representing tables of data than a shell script is.
Not entirely a fair comparison, but here. Can you honestly tell me you'd take the yaml over the shell script?
(If you've never had to use Helm, I envy you. And if you have, I genuinely look forward to you showing me an easier way to do this, since it would make my life easier.)
-------------------------------------
Shell script:
iptables -A INPUT -p tcp --dport 8080 -j ACCEPT
for port in 80 443 8080; do
iptables -A INPUT -p tcp --dport "$port" -j ACCEPT
done
-------------------------------------
Kubernetes (disclaimer: untested, obviously)
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
spec:
trafficPolicy:
firewall:
rules:
- name: allow-port-8080
ports:
- port: 8080
protocol: TCP
podSelector:
matchLabels:
app.kubernetes.io/name: my-app
firewall:
rules:
- name: allow-port-80
ports:
- port: 80
protocol: TCP
- name: allow-port-443
ports:
- port: 443
protocol: TCP
- name: allow-port-8080
ports:
- port: 8080
protocol: TCP
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: firewall
spec:
trafficPolicy:
firewall:
rules:
{{- range .Values.firewall.rules }}
- name: {{ .name }}
ports:
{{- range .ports }}
- port: {{ .port }}
protocol: {{ .protocol }}
{{- end }}
{{- end }}
podSelector:
matchLabels:
app.kubernetes.io/name: my-appI don't know why on earth you'd use mustache with yaml, but the unmustached yaml is much more readable. The reviewer doesn't even need to know iptables. (Which is good; i've only ever worked with nftables (which has the same issue of leaning in to serializing tables as commands) and pf.) Concision is not working in your favor here.
I would take the YAML any day.
Because if one of those iptables fails above you're in an inconsistent state.
Also if I want to swap from iptables to something like Istio then it's basically the same YAML.
> Because if one of those iptables fails above you're in an inconsistent state.
These days iptables is a legacy interface implemented on top of nftables. And nftables does provide atomic rule replacement: https://wiki.nftables.org/wiki-nftables/index.php/Atomic_rul...
So you would have a file with something like:
table inet filter {
chain input {
tcp dport 8080 accept
}
}
$ nft -f input_fileYou obviously didn't use k8s (or k3s or anything other implementation) a lot, because it also messed us iptables randomly sometimes due to bugs, version miss match etc.
Have been Kubernetes for the last decade across multiple implementations.
Never had an iptable issue and these days eBPF is the standard.