<p>Per Flink's doc, we can deploy a standalone Flink cluster on top of Kubernetes, using Flink’s standalone deployment，
or deploy Flink on Kubernetes using native Kubernetes deployments.</p>
<p>The document says</p>
<blockquote>
<p>We generally recommend <strong>new</strong> users to deploy Flink on Kubernetes using native Kubernetes deployments.</p>
</blockquote>
<p>Is it because native Kubernetes is easier to get start with, or is it because standalone mode is kind of legacy ?</p>
<p>In native Kubernetes mode, Flink is able to dynamically allocate and de-allocate TaskManagers depending on the required resources. While in standalone mode, task managers have to be provisioned manually.</p>
<p>It sounds to me that native Kubernetes mode is a better choice.</p>

<p>Posted community wiki based on other answers - <a href="https://stackoverflow.com/questions/63270800/how-different-is-the-flink-deployment-on-kubernetes-and-native-kubernetes/63272753#63272753">David Anderson answer</a> and <a href="https://stackoverflow.com/questions/67142140/flink-on-kubernetes/67154143#67154143">austin_ce answer</a>. Feel free to expand it.</p>
<hr />
<p>Good explanation from the <a href="https://stackoverflow.com/questions/63270800/how-different-is-the-flink-deployment-on-kubernetes-and-native-kubernetes/63272753#63272753">David Anderson answer</a>:</p>
<p><a href="https://nightlies.apache.org/flink/flink-docs-release-1.14/docs/deployment/resource-providers/standalone/kubernetes/" rel="nofollow noreferrer">Standalone mode</a>:</p>
<blockquote>
<p>In a <a href="https://ci.apache.org/projects/flink/flink-docs-stable/ops/deployment/kubernetes.html" rel="nofollow noreferrer">Kubernetes session or per-job deployment</a>, Flink has no idea it's running on Kubernetes. In this mode, Flink behaves as it does in any standalone deployment (where there is no cluster framework available to do resource management). Kubernetes just happens to be how the infrastructure was created, but as far as Flink is concerned, it could have been bare metal. You will have to arrange for kubernetes to create the infrastructure that you will have configured Flink to expect.</p>
</blockquote>
<p><a href="https://nightlies.apache.org/flink/flink-docs-release-1.14/docs/deployment/resource-providers/native_kubernetes/" rel="nofollow noreferrer">Native mode</a>:</p>
<ul>
<li>Session deployment
<blockquote>
<p>In a <a href="https://ci.apache.org/projects/flink/flink-stable/ops/deployment/native_kubernetes.html" rel="nofollow noreferrer">Native Kubernetes session deployment</a>, Flink uses its <code>KubernetesResourceManager</code>, which submits a description of the cluster it wants to the Kubernetes ApiServer, which creates it. As jobs come and go, and the requirements for task managers (and slots) go up and down, Flink is able to obtain and release resources from kubernetes as appropriate.</p>
</blockquote>
</li>
<li>Application mode
<blockquote>
<p>In <a href="https://ci.apache.org/projects/flink/flink-docs-stable/ops/deployment/#application-mode" rel="nofollow noreferrer">Application Mode</a> (<a href="https://flink.apache.org/news/2020/07/14/application-mode.html" rel="nofollow noreferrer">blog post</a>) (<a href="https://ci.apache.org/projects/flink/flink-docs-stable/ops/deployment/native_kubernetes.html#flink-kubernetes-application" rel="nofollow noreferrer">details</a>) you end up with Flink running as a kubernetes application, which will automatically create and destroy cluster components as needed for the job(s) in one Flink application.</p>
</blockquote>
</li>
</ul>
<p>The native mode is recommended <a href="https://stackoverflow.com/questions/67142140/flink-on-kubernetes/67154143#67154143">because it is just simpler</a>, I would not say it is legacy:</p>
<blockquote>
<p>The  <code>Native</code>  mode is the current recommendation for starting out on Kubernetes as it is the simplest option, like you noted. In Flink 1.13 (to be released in the coming weeks), there is added support for  <a href="https://ci.apache.org/projects/flink/flink-docs-release-1.13/docs/deployment/resource-providers/native_kubernetes/#pod-template" rel="nofollow noreferrer">specifying Pod templates</a>. One of the drawbacks to this approach is its limited ability to integrate with CI/CD.</p>
</blockquote>
